HTTP Parameter Pollution
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
 |
HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Hi guys,
during OWASP AppSec Poland 2009 we presented a newly discovered input validation vulnerability called "HTTP Parameter Pollution" (HPP). Basically, it can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimiters. In the last months, we have discovered several real world flaws in which HPP can be used to modify the application behaviors, access uncontrollable variables and even bypass input validation checkpoints and WAFs rules. Exploiting such HPP vulnerabilities, we have found several problems in some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail Classic and many other products. If you are interested, you are kindly invited to have a look at: http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf We're going to release additional materials in the next future, including a video of the Yahoo! attack vector. Stay tuned on http://blog.mindedsecurity.com and http://blog.nibblesec.org Cheers, Stefano Di Paola and Luca Carettoni -- Stefano Di Paola Chief Technology Officer, LA/ISO27001 Minded Security Research Labs Director Minded Security - Application Security Consulting Official Site: www.mindedsecurity.com Personal Blog: www.wisec.it/sectou.php .................. |
|
|
|
|
|
|
|
|
Re: [WEB SECURITY] HTTP Parameter Pollution
by bugtraq-2
::
Rate this Message:
A few comments/questions,
Slide 24: I had a related post on attacking permalinks that touches on this @ http://www.cgisecurity.com/2006/11/attacking-perma.html Slide 28: page.php would only be 'affected' if it failed to properly authorize the user before performing an edit function and really this is a failure to have CSRF protection. This isn't any different than just directly sending the parameter to page.php. This is technically a subclass/use of content spoofing. Slide 33: It appears you've found JS that utilizes this parameter, and if you specified it you could specify your own image but not necessarly get XSS. This could be classified as content spoofing. Slide 37: The bug here is a failure to validate CSRF tokens before executing the commands. In the url I don't see a CSRF token, if I am misunderstanding please clarify. Keep up the good work. Regards, - Robert http://www.cgisecurity.com/ http://www.webappsec.org/ > > Hi guys, > > during OWASP AppSec Poland 2009 we presented a newly discovered input > validation vulnerability called "HTTP Parameter Pollution" (HPP). > > Basically, it can be defined as the feasibility to override or add HTTP > GET/POST parameters by injecting query string delimiters. > > In the last months, we have discovered several real world flaws in which > HPP can be used to modify the application behaviors, access > uncontrollable variables and even bypass input validation checkpoints > and WAFs rules. > > Exploiting such HPP vulnerabilities, we have found several problems in > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail > Classic and many other products. > > If you are interested, you are kindly invited to have a look at: > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf > > We're going to release additional materials in the next future, > including a video of the Yahoo! attack vector. > > Stay tuned on http://blog.mindedsecurity.com and > http://blog.nibblesec.org > > Cheers, > Stefano Di Paola and Luca Carettoni > > -- > Stefano Di Paola > Chief Technology Officer, LA/ISO27001 > Minded Security Research Labs Director > > Minded Security - Application Security Consulting > > Official Site: www.mindedsecurity.com > > Personal Blog: www.wisec.it/sectou.php > .................. > > > > ---------------------------------------------------------------------------- > Join us on IRC: irc.freenode.net #webappsec > > Have a question? Search The Web Security Mailing List Archives: > http://www.webappsec.org/lists/websecurity/archive/ > > Subscribe via RSS: > http://www.webappsec.org/rss/websecurity.rss [RSS Feed] > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > |
|
|
|
|
|
Re: HTTP Parameter Pollution
by Ivan Ristic
::
Rate this Message:
Hi Stefano,
Your presentation discusses two separate issues: 1. The differences in how various components handle multiple request parameters with the same name when an application expects only one (parameter). 2. Attacks against query string construction flaws in applications. Just from reading the slides I couldn't determine which is the main topic, and which is the one you named HPP? On Tue, May 19, 2009 at 1:52 PM, Stefano Di Paola <stefano.dipaola@...> wrote: > Hi guys, > > during OWASP AppSec Poland 2009 we presented a newly discovered input > validation vulnerability called "HTTP Parameter Pollution" (HPP). > > Basically, it can be defined as the feasibility to override or add HTTP > GET/POST parameters by injecting query string delimiters. > > In the last months, we have discovered several real world flaws in which > HPP can be used to modify the application behaviors, access > uncontrollable variables and even bypass input validation checkpoints > and WAFs rules. > > Exploiting such HPP vulnerabilities, we have found several problems in > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail > Classic and many other products. > > If you are interested, you are kindly invited to have a look at: > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf > > We're going to release additional materials in the next future, > including a video of the Yahoo! attack vector. > > Stay tuned on http://blog.mindedsecurity.com and > http://blog.nibblesec.org > > Cheers, > Stefano Di Paola and Luca Carettoni > > -- > Stefano Di Paola > Chief Technology Officer, LA/ISO27001 > Minded Security Research Labs Director > > Minded Security - Application Security Consulting > > Official Site: www.mindedsecurity.com > > Personal Blog: www.wisec.it/sectou.php > .................. > > > > > -- Ivan Ristic |
|
|
Re: [WEB SECURITY] HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Hi Robert,
Inline Il giorno mar, 19/05/2009 alle 13.27 -0400, bugtraq@... ha scritto: > A few comments/questions, > > Slide 24: I had a related post on attacking permalinks that touches on this > @ http://www.cgisecurity.com/2006/11/attacking-perma.html Yes, the technique of injecting stuff into permalinks is widely known. The point here is that it's used for attacks like Xss, XYZ injections or similar. We used that technique to get advantage of HPP also when dealing with URL Rewriting. We didn't mean to define the URLRewriting injection as a new attack class - infact there's no such phrases which states that - but the use of HPP in those contexts. However we will add it to the paper as reference. Thanks for letting us know. > Slide 28: page.php would only be 'affected' if it failed to properly authorize > the user before performing an edit function and > really this is a failure to have CSRF protection. This isn't any different than > just directly sending the parameter to page.php. > This is technically a subclass/use of content spoofing. Of course yes, and thanks for asking. As stated on slide 29 "Client Side HPP ... * It's more about ** Anti-CSRF ** Functional UI Redressing ..." HPP has to be considered when you have anti CSRF tokens hardcoded in links or forms or whatever. Client side HPP _is_, obviously, content spoofing since it acts inside urls/query string in the html page. Probably we should have used "Content Spoofing" instead of "Functional UI Redressing". BTW, the word "pollution" suggests exactly this aspect. We could think about it as the Poor man's CSRF in the same way CSRF is called poor man's Xss :) The fact is that it could be used to bypass anti CSRF tokens when no Xss are found. > Slide 33: It appears you've found JS that utilizes this parameter, and if you > specified it you could specify your own > image but not necessarly get XSS. This could be classified as content spoofing. You're right, that was a wrong screenshot. It's just an example, since it's harmless, but it works also if you inject %26... on 'ip' parameter: http://host/....?ip=523ca699% 26imagesrc=http://anotherhost/images/image.jpg (Consider it as if the imagesrc was correctly checked). Moreover, it.ask.com is full of client side HPP entry points, I used that specific example just to give an idea about javascript playing the game too. > Slide 37: The bug here is a failure to validate CSRF tokens before > executing the commands. In the url I don't see > a CSRF token, if I am misunderstanding please clarify. Regarding the Yahoo! mail attack, the url you see on Slide 37 is the "view Inbox" url, so no anti CSRF on that. There was actually a CSRF token, and no way to do it from external evil site for every other server side state change functionality. We'll publish the video in a few days with more details. > Keep up the good work. Thanks man :) > Regards, > - Robert > http://www.cgisecurity.com/ > http://www.webappsec.org/ > > > > > > Hi guys, > > > > during OWASP AppSec Poland 2009 we presented a newly discovered input > > validation vulnerability called "HTTP Parameter Pollution" (HPP). > > > > Basically, it can be defined as the feasibility to override or add HTTP > > GET/POST parameters by injecting query string delimiters. > > > > In the last months, we have discovered several real world flaws in which > > HPP can be used to modify the application behaviors, access > > uncontrollable variables and even bypass input validation checkpoints > > and WAFs rules. > > > > Exploiting such HPP vulnerabilities, we have found several problems in > > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail > > Classic and many other products. > > > > If you are interested, you are kindly invited to have a look at: > > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf > > > > We're going to release additional materials in the next future, > > including a video of the Yahoo! attack vector. > > > > Stay tuned on http://blog.mindedsecurity.com and > > http://blog.nibblesec.org > > > > Cheers, > > Stefano Di Paola and Luca Carettoni > > > > -- > > Stefano Di Paola > > Chief Technology Officer, LA/ISO27001 > > Minded Security Research Labs Director > > > > Minded Security - Application Security Consulting > > > > Official Site: www.mindedsecurity.com > > > > Personal Blog: www.wisec.it/sectou.php > > .................. > > > > > > > > ---------------------------------------------------------------------------- > > Join us on IRC: irc.freenode.net #webappsec > > > > Have a question? Search The Web Security Mailing List Archives: > > http://www.webappsec.org/lists/websecurity/archive/ > > > > Subscribe via RSS: > > http://www.webappsec.org/rss/websecurity.rss [RSS Feed] > > > > Join WASC on LinkedIn > > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > > > ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Owasp Italy R&D Director Web: www.wisec.it .................. |
|
|
Re: HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Hi Ivan,
HPP is an input validation vulnerability and, consequentially a possible attack, triggered by injection flaws in the context of generating QueryStrings/POST payloads. If you have only an injection (server or client side) in the context of query string construction, it doesn't mean you can actually override hardcoded parameters' values because of web server behaviour. On the other hand, if you know the web server/application behaviour and you cannot inject any parameter then you are obviously safe. So you need both hypothesis in order to exploit the issue. The main topic is that after identifying the application behaviour in managing multiple occurrences and considering which are the layers data passes through, an attacker could exploit the parameter injection vulnerability. And this is HPP. I hope we answered your question. However within the whitepaper, we are going to explain everything in detail and likely, we will be able to show the essence of this flaw. Cheers, Stefano & Luca Il giorno mer, 20/05/2009 alle 10.06 +0200, Ivan Ristic ha scritto: > Hi Stefano, > > Your presentation discusses two separate issues: > > 1. The differences in how various components handle multiple request > parameters with the same name when an application expects only one > (parameter). > 2. Attacks against query string construction flaws in applications. > > Just from reading the slides I couldn't determine which is the main > topic, and which is the one you named HPP? > > > On Tue, May 19, 2009 at 1:52 PM, Stefano Di Paola > <stefano.dipaola@...> wrote: > > Hi guys, > > > > during OWASP AppSec Poland 2009 we presented a newly discovered input > > validation vulnerability called "HTTP Parameter Pollution" (HPP). > > > > Basically, it can be defined as the feasibility to override or add HTTP > > GET/POST parameters by injecting query string delimiters. > > > > In the last months, we have discovered several real world flaws in which > > HPP can be used to modify the application behaviors, access > > uncontrollable variables and even bypass input validation checkpoints > > and WAFs rules. > > > > Exploiting such HPP vulnerabilities, we have found several problems in > > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail > > Classic and many other products. > > > > If you are interested, you are kindly invited to have a look at: > > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf > > > > We're going to release additional materials in the next future, > > including a video of the Yahoo! attack vector. > > > > Stay tuned on http://blog.mindedsecurity.com and > > http://blog.nibblesec.org > > > > Cheers, > > Stefano Di Paola and Luca Carettoni > > > > -- > > Stefano Di Paola > > Chief Technology Officer, LA/ISO27001 > > Minded Security Research Labs Director > > > > Minded Security - Application Security Consulting > > > > Official Site: www.mindedsecurity.com > > > > Personal Blog: www.wisec.it/sectou.php > > .................. > > > > > > > > > > > > > ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Owasp Italy R&D Director Web: www.wisec.it .................. |
|
|
Re: HTTP Parameter Pollution
by Ivan Ristic
::
Rate this Message:
I don't think the two issues are "married", as you imply. For example,
let's assume that my application uses a backend subrequest whose query string is constructed out of the value of the paramter "param": http://backend.server/doSomething?key=$param and that you inject "value&injectedKey=injectedValue" (URL-encoded) into "param". The resulting backend request would thus be http://backend.server/doSomething?key=value&injectedKey=injectedValue So you have managed to pull off an attack using just query string injection. Depending on the backend service, that alone may be enough for exploitation. Thus, I think HPP is the injection part alone. I think your presentation would benefit from moving the discussion of parameter processing inconsistencies into the second half, positioning it as an additional technique that is needed to maximise the effect of the injection vulnerability. On Wed, May 20, 2009 at 2:13 PM, Stefano Di Paola <stefano.dipaola@...> wrote: > Hi Ivan, > > HPP is an input validation vulnerability and, consequentially a > possible attack, triggered by injection flaws in the context of > generating QueryStrings/POST payloads. > > If you have only an injection (server or client side) in the context of > query string construction, it doesn't mean you can actually override > hardcoded parameters' values because of web server behaviour. > On the other hand, if you know the web server/application behaviour and > you cannot inject any parameter then you are obviously safe. > > So you need both hypothesis in order to exploit the issue. > > The main topic is that after identifying the application behaviour in > managing multiple occurrences and considering which are the layers data > passes through, an attacker could exploit the parameter injection > vulnerability. And this is HPP. > > I hope we answered your question. > However within the whitepaper, we are going to explain everything in > detail and likely, we will be able to show the essence of this flaw. > > Cheers, > Stefano & Luca > > Il giorno mer, 20/05/2009 alle 10.06 +0200, Ivan Ristic ha scritto: >> Hi Stefano, >> >> Your presentation discusses two separate issues: >> >> 1. The differences in how various components handle multiple request >> parameters with the same name when an application expects only one >> (parameter). >> 2. Attacks against query string construction flaws in applications. >> >> Just from reading the slides I couldn't determine which is the main >> topic, and which is the one you named HPP? >> >> >> On Tue, May 19, 2009 at 1:52 PM, Stefano Di Paola >> <stefano.dipaola@...> wrote: >> > Hi guys, >> > >> > during OWASP AppSec Poland 2009 we presented a newly discovered input >> > validation vulnerability called "HTTP Parameter Pollution" (HPP). >> > >> > Basically, it can be defined as the feasibility to override or add HTTP >> > GET/POST parameters by injecting query string delimiters. >> > >> > In the last months, we have discovered several real world flaws in which >> > HPP can be used to modify the application behaviors, access >> > uncontrollable variables and even bypass input validation checkpoints >> > and WAFs rules. >> > >> > Exploiting such HPP vulnerabilities, we have found several problems in >> > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail >> > Classic and many other products. >> > >> > If you are interested, you are kindly invited to have a look at: >> > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf >> > >> > We're going to release additional materials in the next future, >> > including a video of the Yahoo! attack vector. >> > >> > Stay tuned on http://blog.mindedsecurity.com and >> > http://blog.nibblesec.org >> > >> > Cheers, >> > Stefano Di Paola and Luca Carettoni >> > >> > -- >> > Stefano Di Paola >> > Chief Technology Officer, LA/ISO27001 >> > Minded Security Research Labs Director >> > >> > Minded Security - Application Security Consulting >> > >> > Official Site: www.mindedsecurity.com >> > >> > Personal Blog: www.wisec.it/sectou.php >> > .................. >> > >> > >> > >> > >> > >> >> >> > -- > ...oOOo...oOOo.... > Stefano Di Paola > Software & Security Engineer > > Owasp Italy R&D Director > > Web: www.wisec.it > .................. > > > -- Ivan Ristic |
|
|
|
|
|
Re: HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Ivan,
let's try doing some minimal statements so that there's no misunderstanding: 1. Web servers/frameworks/applications can do whatever they want with multiple occurrences of the same parameter. No standard is actually defined. 2. It would be better if an RFC or similar states how to treat them. 3. The main problem is _definitely_ the chance to "inject" in the construction of query string which is further used by the next layer. 4. Sometimes it's the application itself that parses the url and changes the default behaviour of the server/framework. 5. It has to be considered a behaviour not an issue. Having said that, we think there's something you're missing from the application point of view. The fact that the web server behavior does not affects HPP, would be correct only, and only if, there is no other hardcoded parameter. But think about: URL #1 http://backend.server/doSomething?action=view&key=$param and URL #2 http://backend.server/doSomething?key=$param&action=view Given that the injection is the issue, and that the attack is: value%26action=delete%23 which is the safe url and which the vulnerable one? It depends on how the backend server manages multiple occurrences. If it gets the first one then URL #1 is safe and URL #2 is vulnerable, otherwise both are vulnerable since you can override the hardcoded value in action. So, we didn't claim that having multiple occurrences of the same parameter is an issue by itself. Actually, this is legal behavior according to RFC (1866, 2388). However this behavior should be considered in order to get the attack working (and protect our application as well). Speaking about your last comments in the new post, we definitely agree that, in the context of WAFs, the problem is much wider in scope (all parts of an HTTP request are involved). However, we have decided to analyze all issues related to GET/POST/Cookie parameters since they're the usual entry point whenever you want to change the application behavior. Once again, as reported in the slides #6, we want to empathize that HPP is surely around since many years but it is definitely underestimated. In our humble opinion, no current research covers in a broad way all the implications that we have raised. This is not only a problem of WAFs but actually it has very strong implications with several building blocks of our web technologies. However we'll add some of the links you posted in the paper for references. Thanks for giving us the opportunity to better clarify on the subject. Cheers, Stefano & Luca Il giorno mer, 20/05/2009 alle 16.07 +0200, Ivan Ristic ha scritto: > I don't think the two issues are "married", as you imply. For example, > let's assume that my application uses a backend subrequest whose query > string is constructed out of the value of the paramter "param": > > http://backend.server/doSomething?key=$param > > and that you inject "value&injectedKey=injectedValue" (URL-encoded) > into "param". The resulting backend request would thus be > > http://backend.server/doSomething?key=value&injectedKey=injectedValue > > So you have managed to pull off an attack using just query string > injection. Depending on the backend service, that alone may be enough > for exploitation. > > Thus, I think HPP is the injection part alone. > > I think your presentation would benefit from moving the discussion of > parameter processing inconsistencies into the second half, positioning > it as an additional technique that is needed to maximise the effect of > the injection vulnerability. > > > On Wed, May 20, 2009 at 2:13 PM, Stefano Di Paola > <stefano.dipaola@...> wrote: > > Hi Ivan, > > > > HPP is an input validation vulnerability and, consequentially a > > possible attack, triggered by injection flaws in the context of > > generating QueryStrings/POST payloads. > > > > If you have only an injection (server or client side) in the context of > > query string construction, it doesn't mean you can actually override > > hardcoded parameters' values because of web server behaviour. > > On the other hand, if you know the web server/application behaviour and > > you cannot inject any parameter then you are obviously safe. > > > > So you need both hypothesis in order to exploit the issue. > > > > The main topic is that after identifying the application behaviour in > > managing multiple occurrences and considering which are the layers data > > passes through, an attacker could exploit the parameter injection > > vulnerability. And this is HPP. > > > > I hope we answered your question. > > However within the whitepaper, we are going to explain everything in > > detail and likely, we will be able to show the essence of this flaw. > > > > Cheers, > > Stefano & Luca > > > > Il giorno mer, 20/05/2009 alle 10.06 +0200, Ivan Ristic ha scritto: > >> Hi Stefano, > >> > >> Your presentation discusses two separate issues: > >> > >> 1. The differences in how various components handle multiple request > >> parameters with the same name when an application expects only one > >> (parameter). > >> 2. Attacks against query string construction flaws in applications. > >> > >> Just from reading the slides I couldn't determine which is the main > >> topic, and which is the one you named HPP? > >> > >> > >> On Tue, May 19, 2009 at 1:52 PM, Stefano Di Paola > >> <stefano.dipaola@...> wrote: > >> > Hi guys, > >> > > >> > during OWASP AppSec Poland 2009 we presented a newly discovered input > >> > validation vulnerability called "HTTP Parameter Pollution" (HPP). > >> > > >> > Basically, it can be defined as the feasibility to override or add HTTP > >> > GET/POST parameters by injecting query string delimiters. > >> > > >> > In the last months, we have discovered several real world flaws in which > >> > HPP can be used to modify the application behaviors, access > >> > uncontrollable variables and even bypass input validation checkpoints > >> > and WAFs rules. > >> > > >> > Exploiting such HPP vulnerabilities, we have found several problems in > >> > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail > >> > Classic and many other products. > >> > > >> > If you are interested, you are kindly invited to have a look at: > >> > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf > >> > > >> > We're going to release additional materials in the next future, > >> > including a video of the Yahoo! attack vector. > >> > > >> > Stay tuned on http://blog.mindedsecurity.com and > >> > http://blog.nibblesec.org > >> > > >> > Cheers, > >> > Stefano Di Paola and Luca Carettoni > >> > > >> > -- > >> > Stefano Di Paola > >> > Chief Technology Officer, LA/ISO27001 > >> > Minded Security Research Labs Director > >> > > >> > Minded Security - Application Security Consulting > >> > > >> > Official Site: www.mindedsecurity.com > >> > > >> > Personal Blog: www.wisec.it/sectou.php > >> > .................. > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > > -- > > ...oOOo...oOOo.... > > Stefano Di Paola > > Software & Security Engineer > > > > Owasp Italy R&D Director > > > > Web: www.wisec.it > > .................. > > > > > > > > > ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Owasp Italy R&D Director Web: www.wisec.it .................. |
|
|
Re: HTTP Parameter Pollution
by Ivan Ristic
::
Rate this Message:
On Wed, May 20, 2009 at 5:30 PM, Stefano Di Paola
<stefano.dipaola@...> wrote: > > ... > > Having said that, we think there's something you're missing from the > application point of view. > > The fact that the web server behavior does not affects HPP, would be > correct only, and only if, there is no other hardcoded parameter. > > But think about: > > URL #1 > http://backend.server/doSomething?action=view&key=$param > > and > > URL #2 > http://backend.server/doSomething?key=$param&action=view > > > Given that the injection is the issue, and that the attack is: > > value%26action=delete%23 > > which is the safe url and which the vulnerable one? Both are vulnerable because both can be manipulated. Only one is exploitable. The difference here is that I don't care about exploitability and you do. My view is that if I don't know how to exploit a vulnerability that does not mean that there isn't someone else who can :) That's why, in my view, the additional technique you need for exploitability does not matter. -- Ivan Ristic |
|
|
Re: HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Il giorno mer, 20/05/2009 alle 17.49 +0200, Ivan Ristic ha scritto:
> On Wed, May 20, 2009 at 5:30 PM, Stefano Di Paola > <stefano.dipaola@...> wrote: > > > > ... > > > > Having said that, we think there's something you're missing from the > > application point of view. > > > > The fact that the web server behavior does not affects HPP, would be > > correct only, and only if, there is no other hardcoded parameter. > > > > But think about: > > > > URL #1 > > http://backend.server/doSomething?action=view&key=$param > > > > and > > > > URL #2 > > http://backend.server/doSomething?key=$param&action=view > > > > > > Given that the injection is the issue, and that the attack is: > > > > value%26action=delete%23 > > > > which is the safe url and which the vulnerable one? > > Both are vulnerable because both can be manipulated. Only one is > exploitable. The difference here is that I don't care about > exploitability and you do. My view is that if I don't know how to > exploit a vulnerability that does not mean that there isn't someone > else who can :) > > That's why, in my view, the additional technique you need for > exploitability does not matter. :) agree. Nevertheless the impact in risk analysis changes. Also, the client side HPP is a way to warn developers and reviewers to pay attention in the right way to encode output in its own context: htmlentities Vs. UrlEncoding. Stefano & Luca -- ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Owasp Italy R&D Director Web: www.wisec.it .................. |
|
|
|
|
|
RE: [WEB SECURITY] Re: HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Martin,
"... 1. Web servers/frameworks/applications can do whatever they want with multiple occurrences of the same parameter. No standard is actually defined. ... 5. It has to be considered a behaviour not an issue. ..." we do not claim that it's wrong to expect more than one parameter. As you said, this is perfectly acceptable. The problem is about which occurrence should be considered in a way that all behaviours are consistent. A standard may mitigate this aspect of the issue. Resume: we totally agree with you. :) Cheers, Stefano & Luca Il giorno mer, 20/05/2009 alle 19.03 +0100, Martin O'Neal ha scritto: > > 2. It would be better if an RFC or similar states how to treat them. > > I would disagree with this. This isn't a standard thing really; it is > perfectly valid for an application to expect zero/one/infinity > parameters; the issue only arises when the application does not handle a > mismatch between expectation and actuality... > > Martin... > > > > ---------------------------------------------------------------------------- > Join us on IRC: irc.freenode.net #webappsec > > Have a question? Search The Web Security Mailing List Archives: > http://www.webappsec.org/lists/websecurity/archive/ > > Subscribe via RSS: > http://www.webappsec.org/rss/websecurity.rss [RSS Feed] > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Owasp Italy R&D Director Web: www.wisec.it .................. |
|
|
|
|
|
|
|
|
RE: [WEB SECURITY] Re: HTTP Parameter Pollution
by Stefano Di Paola
::
Rate this Message:
Martin,
Il giorno mer, 20/05/2009 alle 22.47 +0100, Martin O'Neal ha scritto: > (thereby breaking all the apps that currently work in the opposite way) that is a reasonable point :) When anarchy is in place (no rules) trying to introduce a standard (rules) could have its own drawbacks. In an utopian world, anarchy could be also acceptable (people respect each other, developers know their environment), but since people does mistakes, rules helps persons in having a guideline. I'd also prefer to let people, developers and servers do whatever they want, knowing and respecting the unspoken rules. Going too much into philosophy, so I stop here :) Cheers, Stefano & Luca -- Stefano Di Paola Chief Technology Officer, LA/ISO27001 Minded Security Research Labs Director Minded Security - Application Security Consulting Official Site: www.mindedsecurity.com Personal Blog: www.wisec.it/sectou.php |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
