[Owasp-leaders] Java Servlet parameter pollution problem in the spec
psiinon at gmail.com
Wed Jul 11 13:50:26 UTC 2012
I've raised it as a ZAP enhancement request: Issue
As you say it should be easy to implement, so I'll try to implement it asap.
(Resent to owasp-leaders at lists.owasp.org instead of owasp-leaders at owasp.org,
On Wed, Jul 11, 2012 at 1:59 PM, Jeff Williams <jeff.williams at owasp.org>wrote:
> Hi everyone,
> So there doesn't seem to be a great resolution here. It seems we need
> to tell developers that they MUST specify the action URL in their
> forms. We could approach the W3C to try to make this required, but
> I'm skeptical they'll move on this. (Anyone know where to submit
> something like this?) The Java Servlet Spec team is resistant to
> making a change as well. Sigh.
> I'd love to have some numbers about how many sites are susceptible to
> this. Anyone want to write a scanner that detects this? All you need to
> search for is pages that don't specify a form action. It would
> make a very nice Zap or Burp passive check, "Unspecified form target:
> HTTP parameter override attack possible"
> On Wed, Jul 4, 2012 at 5:53 PM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
> > Hey Jeff, on the scan you request below, what do you want to search for?
> > "web pages that submit form data with no action, that ends up being
> > collected by a server side getParameter?"
> > Is there a sample app we could use to test the scan acuracy?
> > Dinis Cruz
> > On 3 Jul 2012, at 14:51, Jeff Williams <jeff.williams at owasp.org> wrote:
> >> Hi Leaders,
> >> See the attached paper from a Google researcher…
> >> The latest (3.0) Java Servlet spec says that "Data from the query
> >> string and the post body are aggregated into the request parameter
> >> set. Query string data is presented before post body data."
> >> So if your Java web app has a form with no target and will POSTs back
> >> to the same URL (or less likely, if the application somehow propagates
> >> GET parameters to the target URL), here's the attack...
> >> 1) Get victim to click on a link like
> >> http://example.com/changePassword?pw1=foo&pw2=foo
> >> 2) Victim visits the changePassword page and fills in the form with
> >> pw1=bar&pw2=bar
> >> 3) Server calls getParameter(“pw1”) and gets “foo” not “bar”, same
> for pw2
> >> 4) Server changes password to “foo”
> >> 5) Attacker takes over account
> >> This is relatively easy to find both statically and dynamically. It’s
> >> sort of like CSRF, but adding a token won’t fix the problem. To fix
> >> it, you can change the form to have a separate target, but that could
> >> be a decent amount of work.
> >> Is there something else crafty that we could suggest to the servlet
> >> team to fix this in the spec? One idea is to add an optional
> >> parameter to the getParameter() method to allow you to specify
> >> GET_ONLY or POST_ONLY. Or what about a security setting that puts
> >> POST parameters first, since that’s almost certainly what was
> >> expected?
> >> Other ideas? Remember, you can’t break existing apps. I'm going to
> >> need some ammo to get a change for this into the spec. Anybody want
> >> to do a scan to see how widespread this problem is?
> >> Thanks,
> >> --Jeff
> >> <OnParameterPollutionAttacks.pdf>
OWASP ZAP: Toolsmith Tool of the Year
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders