Everything, Everything

2024: J F M A M J J A S O N D
2023: J F M A M J J A S O N D
2022: J F M A M J J A S O N D
2021: J F M A M J J A S O N D
2020: J F M A M J J A S O N D
2019: J F M A M J J A S O N D
2018: J F M A M J J A S O N D
2017: J F M A M J J A S O N D
2016: J F M A M J J A S O N D
2015: J F M A M J J A S O N D
2014: J F M A M J J A S O N D
2013: J F M A M J J A S O N D
2012: J F M A M J J A S O N D
2011: J F M A M J J A S O N D
2010: J F M A M J J A S O N D
2009: J F M A M J J A S O N D
2008: J F M A M J J A S O N D
2007: J F M A M J J A S O N D
2006: J F M A M J J A S O N D
2005: J F M A M J J A S O N D
2004: J F M A M J J A S O N D
Using Burp Session Handling With Sqlmap
Thursday 25th February, 2016 16:28 Comments: 0
Earlier this month, I used Burp's Session Handling Rules to get around an anti-CSRF token in order to get sqlmap working. Sqlmap does have native support for anti-CSRF tokens, but when the parameter it needs to update is part of a multipart form it appears that sqlmap fails to find the parameter that will be updated and it just gives up with an error message.

By configuring sqlmap to use Burp's proxy, and configuring a session handling rule in Burp to acquire and update the token, sqlmap doesn't even need to know about the CSRF protection. I stumbled across the idea based on this article.

It turns out that none of the fields were vulnerable to SQL injection (which I sort of knew from manual testing), but it was an interesting challenge.
© Robert Nicholls 2002-2024
The views and opinions expressed on this site do not represent the views of my employer.
HTML5 / CSS3