Back
Multiple NONCE (one-time token) Value Tracking with Burp Extender
From time to time, application developers implement strong security controls. A “strong control” might not capture exactly what we will be talking about today, but it does pose a huge problem for most application scanners. We have all seen a wide usage of one-time tokens in applications (aka nonce values) that are used to deter cross-domain attacks. However, in most instances observed, a sole nonce value is utilized for a particular form or utilized on the next request issued. In these cases, application scanners have fared well against this protection by setting it in the exclusion lists. Below is an attempt to capture how traditional nonce is used (Nonce A and B are not different parameters, but different values):
If you are like me, you have come across developed applications as of late using separate one-time tokens for each action submitted. In these cases, each action, whether it be a link or form, contains its own unique nonce. The following diagram illustrates this concept of distinct nonce values for each action (Nonce A, B and C are not different parameters, but different values):
Another way to understand this is by looking at the HTML source code:
If a nonce is submitted that is reissued, used for the wrong request, or expired, the application promptly kicks you out of your session and/or back to the main page. At which point the scanner tries to authenticate and reuse old nonce values it collected in the crawl (which are probably expired) or collects new ones and issues them out of order. In either case, your testing results will be poor with an automated tool and you may miss something crucial in your testing.
As alluded to before, implementing unique nonces for each and every action does mitigate some attacks, but merely masks an issue for a great majority of others. This is where the ever-useful Burp Suite saves the day. The Burp Extender API allows us to expand on an already great tool to create new request and response handling routines that previously could not be created in the Macro creator. The challenge presented needs to be addressed by parsing out server responses to obtain the nonce values and storing/updating them continuously from each response. In conjunction, the requests need to be monitored to verify that the issued nonce is the most current and switch it accordingly. This small piece of code will not only make sure that Burp Scanner is able to defeat nonce verification, but also allow application scanners to be daisy-chained to Burp proxy to handle the nonce switching.
The following image captures the Nonce Tracker loading in new pages and values as well switching the errant value:
The code that I am distributing is not one-solution-fits-all, as there is no telling how a particular application will implement the nonce validation and issuance. You may find that there may be one or two extra routines in my code; sorry, that is because I had to sanitize a few necessary functions that were required in an application I was recently testing. However, by adjusting the Java patterns (regex) and maybe changing a few lines, you should be up and running.
Here are a few references to help you on your way:
Regex Pattern Tools:
http://gskinner.com/RegExr/
http://www.regexplanet.com/advanced/java/index.html
Burp API:
http://portswigger.net/burp/extender/api/index.html
I hope you find this helpful in either a nonce scenario or some other parameter tracking routine. I have a few other Burp Extensions to share as soon as I can sanitize them for general use. Let us know if you want to know more about Burp Extenders or if you want to see other cool examples of what it can do.
Feel free to download and share the Nonce Tracker code from our repository: Download Here
12.02.13