Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Sending a Form POST with out URL encoding?
Date: January 08, 2009 02:05PM

I'm researching a possible CSRF vector where the server does NOT URL decode the POST parameters. It looks like the site uses XMLHttpRequest to send the parameters unencoded, but from my understanding, XMLHttpRequest can't be used to send cross domain POSTs. If I make a simple autosubmitting form with enctype="text/plain", then the content-type header is also text/plain, so the app doesn't accept it.

Does anyone have any ideas on how to submit a POST with Content-Type: application/x-www-form-urlencoded, but where the POST parameters aren't actually URL encoded?

Thanks,
NWS

Options: ReplyQuote
Re: Sending a Form POST with out URL encoding?
Posted by: NickWilliams
Date: January 10, 2009 03:45PM

There shouldn't be any way to do this. HTML spec dictates that all browsers should URLEncode parameters for a form with enctype=application/x-www-form-urlencoded before sending the message. If you did find a way to do this it would definitely be browser specific as it will have been an oversight on the browser manufacturer's part.

There is no way to override the Content-Type a browser assigns when using a form. XHR can set Content-Type to whatever it wants, but you'd run into the cross-domain issue at that point.

I see this as an odd but, at first look, effective method of preventing CSRF. It would make more sense for the developer to have the XHR object assign a Content-Type that has no enctype equivalent. Then again, the URLEncoding of that enctype is an established standard while more enctypes could be added to the spec so perhaps it is safer than setting Content-Type to an arbitrary value and checking that value server side. It is conceivable that in the future the arbitrary value may become incorporated into the standard and then implemented by browsers.

Options: ReplyQuote


Sorry, only registered users may post in this forum.