<div dir="ltr">Based on my understanding. the BASIC LIMITATION in the API here is only a guidance or suggestion from community. It defines the default API behaviour and also configurable. BTW, OpenStack now doesn't have an explicit rule for valid user input (such as name and description), and this is inconsistent across different projects. So no matter what the agreement<div>we finally reach. could we document the supported characters in API? The inconsistency and ambiguity would confuse any release provider who wants to add the security support in API while obey the testcases in our DefCore [1]&[2].</div><div><br></div><div>[1]: <a href="https://refstack.openstack.org/#/guidelines">https://refstack.openstack.org/#/guidelines</a></div><div>[2]: <a href="https://github.com/openstack/tempest/blob/c961a656ccdc0f1242b4ff3237a16d4a7cdf4e07/tempest/api/volume/test_volumes_get.py#L98">https://github.com/openstack/tempest/blob/c961a656ccdc0f1242b4ff3237a16d4a7cdf4e07/tempest/api/volume/test_volumes_get.py#L98</a><br><div><br></div><br><div class="gmail_quote"><div dir="ltr">Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>>于2017年11月20日周一 上午11:08写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On 20 Nov 2017 2:18 am, "TommyLike Hu" <<a href="mailto:tommylikehu@gmail.com" target="_blank">tommylikehu@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<br><br><div class="gmail_quote"><div dir="ltr">Tristan Cacqueray <<a href="mailto:tdecacqu@redhat.com" target="_blank">tdecacqu@redhat.com</a>>于2017年11月17日周五 下午11:55写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On November 17, 2017 1:56 pm, Jeremy Stanley wrote:<br>
> On 2017-11-17 12:47:34 +0000 (+0000), Luke Hinds wrote:<br>
>> This will need the VMT's attention, so please raise as an issue on<br>
>> launchpad and we can tag it as for the vmt members as a possible OSSA.<br>
> [...]<br>
><br>
> Ugh, looks like someone split this thread, and I already replied to<br>
> the original thread. In short, I don't think it's safe to assume we<br>
> know what's going to be safe for different frontends and consuming<br>
> applications, so trying to play whack-a-mole with various unsafe<br>
> sequences at the API side puts the responsibility for safe filtering<br>
> in the wrong place and can lead to lax measures in the software<br>
> which should actually be taking on that responsibility.<br>
><br>
> Of course, I'm just one voice. Others on the VMT certainly might<br>
> disagree with my opinion on this.<br>
<br>
We had similar issues[0][1] in the past where we already draw the line<br>
that it is the client responsibility to filter out API response.<br>
<br>
Thus I agree with Jeremy, perhaps it is not ideal, but at least it<br>
doesn't give a false sense of security if^Wwhen the server side<br>
filtering let unpredicted malicious content through.<br>
<br>
-Tristan<br>
<br>
[0] <a href="https://launchpad.net/bugs/1486565" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1486565</a><br>
[1] <a href="https://launchpad.net/bugs/1649248" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1649248</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>