Currently I'm performing a security assessment of a webapp hosted on a windows server that uses angular.js as its web framework. To be able to crawl the webapp manually (after some research I figured out this is required for JS apps since Burp does not currently have this feature) I have to disable the Burp proxy within the web browser, then navigate to the URL being tested, in which I then have to provide credentials in order to get through the organizations BIG IP F5 proxy. Once on the web page, I then turn on the Burp proxy within the browser and I'm able to crawl through and populate the site map. However, when I try and scan ANY of the URLs within the site map, I get the following consistent errors:
Skipping current scanner check for <URL>, request timeout
javax.net.ssl.SSLProtocolException: Connection Reset
I'm a little confused as to why Burp cannot perform the audit, even though it has been populating the site map. Would I have to whitelist the Burp Proxy to bypass the F5 proxy when reaching the application? If I try and reach the application with Burp set as the browser proxy, the F5 proxy asks for login credentials which I provide, but then I get a 401 not authorized error after putting in my credentials. Also, the main URL does have a padlock image on the lefthand side, so I assume that means I cannot audit this? I can't seem to find correct documentation on how to troubleshoot this. Is anyone able to point me in the right direction?
If the site map is being populated, Burp Scanner should work on that traffic.
It’s possible that there is a small incompatibility between Burp’s SSL and some elements of your site. You may be able to work around this by going to Project Options > SSL. In SSL Protocol, select “Use custom protocols and ciphers”.
Have you tried installing the Flow extension to check exactly what is happening to the Scanner traffic?
Please let us know if this helps.
I've started using the Flow extension and it looks like there is an F5 reverse proxy ending the session - Flow is showing a 404 error that originates from a BIGIP F5 error page. It looks like this was caused by the F5 storing the session I used to manually crawl the site, then once I started auditing it has to use the same session, thus detecting that it is a duplicate session and errors out. The exact error message is "Access policy evaluation is already in progress for your current session".
Steve, Burp Suite contains Session Handling Rules which can be used to manipulate session headers and replace them with values configured in the Cookie Jar during scanning based on certain conditions, these settings can be found in Project Options > Sessions.
Depending on the structure of your target application, these in combination could be used to work around your issue.