But the filtering requirements are going to be different for different front ends, and we can't hope to catch them all. Trying to do any filtering at the cinder/nova API level just provides a false sense of security - horizon and other UI *have* to get their escaping right. If you put incomplete filtering at the cinder level, it becomes more likely that consumers will assume they don't need to bother.
On 20 Nov 2017 2:18 am, "TommyLike Hu" <tommylik...@gmail.com> wrote: > Our API service is open to any client or any API consumer. We can not > guarantee every frontend has the ability to protect themself from script > injections. Although the specific cases would differ, the security issue is > the same. If we have to keep asking them to add this support repeatedly, > Can we just define the BASIC limitation for the input? > > Tristan Cacqueray <tdeca...@redhat.com>于2017年11月17日周五 下午11:55写道： > >> On November 17, 2017 1:56 pm, Jeremy Stanley wrote: >> > On 2017-11-17 12:47:34 +0000 (+0000), Luke Hinds wrote: >> >> This will need the VMT's attention, so please raise as an issue on >> >> launchpad and we can tag it as for the vmt members as a possible OSSA. >> > [...] >> > >> > Ugh, looks like someone split this thread, and I already replied to >> > the original thread. In short, I don't think it's safe to assume we >> > know what's going to be safe for different frontends and consuming >> > applications, so trying to play whack-a-mole with various unsafe >> > sequences at the API side puts the responsibility for safe filtering >> > in the wrong place and can lead to lax measures in the software >> > which should actually be taking on that responsibility. >> > >> > Of course, I'm just one voice. Others on the VMT certainly might >> > disagree with my opinion on this. >> >> We had similar issues[0][1] in the past where we already draw the line >> that it is the client responsibility to filter out API response. >> >> Thus I agree with Jeremy, perhaps it is not ideal, but at least it >> doesn't give a false sense of security if^Wwhen the server side >> filtering let unpredicted malicious content through. >> >> -Tristan >> >> [0] https://launchpad.net/bugs/1486565 >> [1] https://launchpad.net/bugs/1649248 >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
