Re: [openstack-dev] [security] [api] Script injection issue

2017-11-19 Thread TommyLike Hu 
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
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].

[1]: https://refstack.openstack.org/#/guidelines
[2]:
https://github.com/openstack/tempest/blob/c961a656ccdc0f1242b4ff3237a16d4a7cdf4e07/tempest/api/volume/test_volumes_get.py#L98


Duncan Thomas 于2017年11月20日周一 上午11:08写道：

> 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"  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 于2017年11月17日周五 下午11:55写道：
>>
>>> On November 17, 2017 1:56 pm, Jeremy Stanley wrote:
>>> > On 2017-11-17 12:47:34 + (+), 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
>
__
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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-19 Thread Duncan Thomas 
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"  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 于2017年11月17日周五 下午11:55写道：
>
>> On November 17, 2017 1:56 pm, Jeremy Stanley wrote:
>> > On 2017-11-17 12:47:34 + (+), 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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-19 Thread TommyLike Hu 
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 于2017年11月17日周五 下午11:55写道：

> On November 17, 2017 1:56 pm, Jeremy Stanley wrote:
> > On 2017-11-17 12:47:34 + (+), 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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-19 Thread TommyLike Hu 
The special character is allowed in default, tested in nova's and cinder's
master branch. And I guess most of the projects allow  those characters as
the community doesn't have a explicit red line for this :)

Adam Heczko 于2017年11月17日周五 下午8:33写道：

> Thanks TommyLike for this bug report. Sounds like Stored XSS [1].
> Could you please share more details, e.g. branch / release, APIs tested
> etc.?
>
> [1] https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
>
> On Fri, Nov 17, 2017 at 12:36 PM, Davanum Srinivas 
> wrote:
>
>> Adding [api] to make sure the API (SIG?) sees this too
>>
>> On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu 
>> wrote:
>> > Hey all,
>> >  Recently when we integrating and testing OpenStack services. We
>> found
>> > there is a potential script injection issue that some of our services
>> accept
>> > the input with special character [1] [2], for instance we can create an
>> > instance or a volume with the name of 'script inside'.
>> One
>> > of the possible solutions is add HTML encode/decode support in Horizon,
>> but
>> > it's not guaranteed every OpenStack user is using Horizon. So should we
>> > apply more strict restriction on user's input?
>> >  Also, I found  Google Cloud have a strict and explicit restrction
>> in
>> > their instance insert API document [3].
>> >
>> > [1]: Nova:
>> >
>> https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L148
>> > [2]: Cinder:
>> >
>> https://github.com/openstack/cinder/blob/master/cinder/api/openstack/wsgi.py#L1253
>> > [3]: Google Cloud:
>> > https://cloud.google.com/compute/docs/reference/latest/instances/insert
>> >
>> > Thanks
>> > TommyLike.Hu
>> >
>> >
>> >
>> >
>> __
>> > 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
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> 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
>>
>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
> __
> 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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-17 Thread Jeremy Stanley 
On 2017-11-17 15:55:33 + (+), Tristan Cacqueray wrote:
[...]
> 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.
[...]

To be clear, I don't object to making whatever developers and API
SIG members feel are sane filtering choices service-side, it's just
that I think the VMT will consider those security hardening patches
and not vulnerability fixes. If Horizon or any other consuming
application fails to properly sanitize data before performing
potentially unsafe actions with it, that's a vulnerability and would
generally warrant an official security advisory.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-17 Thread Tristan Cacqueray 

On November 17, 2017 1:56 pm, Jeremy Stanley wrote:

On 2017-11-17 12:47:34 + (+), 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


pgpn3umvdd5Hj.pgp
Description: PGP signature
__
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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-17 Thread Jeremy Stanley 
On 2017-11-17 12:47:34 + (+), 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.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-17 Thread Luke Hinds 
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.

Apologies for top post, replying from phone.

On 17 Nov 2017 12:34 pm, "Adam Heczko"  wrote:

> Thanks TommyLike for this bug report. Sounds like Stored XSS [1].
> Could you please share more details, e.g. branch / release, APIs tested
> etc.?
>
> [1] https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
>
> On Fri, Nov 17, 2017 at 12:36 PM, Davanum Srinivas 
> wrote:
>
>> Adding [api] to make sure the API (SIG?) sees this too
>>
>> On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu 
>> wrote:
>> > Hey all,
>> >  Recently when we integrating and testing OpenStack services. We
>> found
>> > there is a potential script injection issue that some of our services
>> accept
>> > the input with special character [1] [2], for instance we can create an
>> > instance or a volume with the name of 'script inside'.
>> One
>> > of the possible solutions is add HTML encode/decode support in Horizon,
>> but
>> > it's not guaranteed every OpenStack user is using Horizon. So should we
>> > apply more strict restriction on user's input?
>> >  Also, I found  Google Cloud have a strict and explicit restrction
>> in
>> > their instance insert API document [3].
>> >
>> > [1]: Nova:
>> > https://github.com/openstack/nova/blob/master/nova/api/valid
>> ation/parameter_types.py#L148
>> > [2]: Cinder:
>> > https://github.com/openstack/cinder/blob/master/cinder/api/o
>> penstack/wsgi.py#L1253
>> > [3]: Google Cloud:
>> > https://cloud.google.com/compute/docs/reference/latest/instances/insert
>> >
>> > Thanks
>> > TommyLike.Hu
>> >
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> 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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-17 Thread Adam Heczko 
Thanks TommyLike for this bug report. Sounds like Stored XSS [1].
Could you please share more details, e.g. branch / release, APIs tested
etc.?

[1] https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting

On Fri, Nov 17, 2017 at 12:36 PM, Davanum Srinivas 
wrote:

> Adding [api] to make sure the API (SIG?) sees this too
>
> On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu 
> wrote:
> > Hey all,
> >  Recently when we integrating and testing OpenStack services. We
> found
> > there is a potential script injection issue that some of our services
> accept
> > the input with special character [1] [2], for instance we can create an
> > instance or a volume with the name of 'script inside'.
> One
> > of the possible solutions is add HTML encode/decode support in Horizon,
> but
> > it's not guaranteed every OpenStack user is using Horizon. So should we
> > apply more strict restriction on user's input?
> >  Also, I found  Google Cloud have a strict and explicit restrction in
> > their instance insert API document [3].
> >
> > [1]: Nova:
> > https://github.com/openstack/nova/blob/master/nova/api/
> validation/parameter_types.py#L148
> > [2]: Cinder:
> > https://github.com/openstack/cinder/blob/master/cinder/api/
> openstack/wsgi.py#L1253
> > [3]: Google Cloud:
> > https://cloud.google.com/compute/docs/reference/latest/instances/insert
> >
> > Thanks
> > TommyLike.Hu
> >
> >
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>



-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
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

Re: [openstack-dev] [security] [api] Script injection issue

2017-11-17 Thread Davanum Srinivas 
Adding [api] to make sure the API (SIG?) sees this too

On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu  wrote:
> Hey all,
>  Recently when we integrating and testing OpenStack services. We found
> there is a potential script injection issue that some of our services accept
> the input with special character [1] [2], for instance we can create an
> instance or a volume with the name of 'script inside'. One
> of the possible solutions is add HTML encode/decode support in Horizon, but
> it's not guaranteed every OpenStack user is using Horizon. So should we
> apply more strict restriction on user's input?
>  Also, I found  Google Cloud have a strict and explicit restrction in
> their instance insert API document [3].
>
> [1]: Nova:
> https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L148
> [2]: Cinder:
> https://github.com/openstack/cinder/blob/master/cinder/api/openstack/wsgi.py#L1253
> [3]: Google Cloud:
> https://cloud.google.com/compute/docs/reference/latest/instances/insert
>
> Thanks
> TommyLike.Hu
>
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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