Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

More reliable authenticated scanning

Chris | Last updated: Sep 11, 2017 03:06PM UTC

1) Consider this scenario: burp is configured to determine if the session is valid every 30 requests. Lets assume that the session will expire on the 20th request. In this case burp will recover the session but will have "wasted" the 21th until the 29th payload. It will be good if scanner keeps track what is going on and request again the whole group of 30 payloads. 2) Authenticated scan with 10 threads: Lets assume that burp is configured to determine a valid session by the current request. The application allows only 1 valid sessionID. At some point the session expires. Burp does not handle all these threads as one entity. Burp will be starting to issue the authentication action on each thread and this results to chaos. Almost all the subsequent requests will be unauthenticated. For example the thread #5 will try to authenticate but until issues the actual request, another thread will have been authenticated so the actual request of #5 thread will be unauthenticated. To overcome this limitation I only scan these kind of applications with only 1 thread.

Liam, PortSwigger Agent | Last updated: Sep 11, 2017 03:08PM UTC

Have you tried using Burp's session handling rules? - https://support.portswigger.net/customer/portal/articles/2363088-configuring-burp-s-session-handling-rules

Burp User | Last updated: Sep 11, 2017 03:47PM UTC

Of course. I am talking exactly about the Session handling rules. Most specifically for how the scanner handles them.

PortSwigger Agent | Last updated: Sep 13, 2017 08:44AM UTC

Hi Chris, Thanks for your message, they are interesting questions. 1) In general, if your session is invalid, tools like Scanner, Spider or Intruder will waste requests. While in theory it would be possible to avoid this, by identifying temporary errors and retrying, in practice many applications use HTTP status codes incorrectly, so reliably detecting temporary errors is difficult. This is an area we'd like to improve though - we'll have a discussion about this internally. You need to make your session checking as tight as possible. Use "Issue current request" if at all possible - the "Validate session only every xx minutes" option only applies to macros. Burp handles this intelligently - if the session is valid, current request is only issued once. If invalid, the session is restored and request reissued. You can check this yourself either using the Session Tracer, or an extension like Flow. 2) Yes, right now, using a single thread for such applications in the best approach. I guess we could introduce some locking to make this work more reliably. Again, we'll have a discussion about this internally. Please let us know if you need any further assistance.

PortSwigger Agent | Last updated: Sep 13, 2017 09:56AM UTC

Hi Chris, We've had a discussion about this. Both your concerns should be fully covered by the new Crawler which we're working on. We don't have an official ETA for this; it will probably be next year now.

Burp User | Last updated: Sep 13, 2017 07:02PM UTC

Hi Paul, 1) I usually use “Issue current request” for scanning but many times it is necessity to use a macro for various reasons. Also I could set the option "Validate session only every xx requests” to "1" but many applications have long response times. Imagine in an application which has 5 sec response time how much overhead I will introduce if burp sends 1 macro for every request. "Both your concerns should be fully covered by the new Crawler " Nice! I hope these features will be included in the scanner also. Thank you

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.