Authenticated web security scans are one of the most frustrating parts of web security assessments. I mean they're downright painful, oftentimes seemingly impossible - especially if multi-factor authentication (MFA) technology is in use. Yet authenticated scans are critically important. It's scary how many times I uncover serious flaws (i.e. SQL injection) while logged-in as a typical user of a web site/application. That is if I can get my web vulnerability scanners to login and work properly!
Side note I have to bring up: I hate to think how many web security flaws are overlooked because people aren't testing their applications as authenticated users. Who am I to question it...
You see, the problem is that web vulnerability scanners are often tripped up with form-based logins. Why? Because they struggle to determine and maintain session state (the browser's/scanner's ongoing communication with the web application). Newer web technologies such as Flash and AJAX are big contributors to the problem, but web applications using MFA can be especially troublesome.
During a recent web security assessment, I struggled - hours on end - to get two different commercial vulnerability scanners to work with Oracle's Bharosa multi-factor authentication technology. I literally lost a day's worth of work trying to get these scanners to record login macros and properly maintain their session state so they could complete their scans.
What a frustrating scenario. The solution was simpler than I thought it'd be. I ended up using a third scanner - NTOSpider, which I've leaned on before to get me out of a bind in such situations - and it worked like a charm! What took me 6+ hours of pain and hassle with the other scanners (with no results, mind you), took just 6 minutes with NTOSpider.
I recorded the login macro, tested it, and got the scan rolling. It was amazingly simple. Given how much NTOSpider got logged out and had to log back in to the application, I could tell it was struggling a bit to maintain state, but it still WORKED! NTOSpider's feature that shows whether or not the scanner is current logged-in to the application is especially nice in these situations.
Side note I have to bring up: I can't imagine how many web security scans are deemed "complete" when they, in reality, failed to authenticate and properly test the application. I suspect this is a huge problem that's being overlooked all the time and people wonder why their web applications are hacked. Who am I to question it...
I'm a big advocate of using multiple scanners when testing web applications...just not in this context! But you've got to do what you've got to do in order to get good results. If you're testing web applications as authenticated users (you should!) and end up struggling to get your login macros to work, know that NTOSpider might just get you out of a bind like it did for me. Or, if it's one of your main scanners, prevent these problems in the first place.
Whether your applications use MFA, form-based logins, or good old-fashioned NTLM pop-up windows, just make sure you're using multiple scanners to test your web applications as they all tend to find unique flaws you probably can't afford to overlook. Oh, and never rely on scanners alone...do that and you'll surely get bitten.
Side note I have to bring up: I hate to think how many web security flaws are overlooked because people aren't testing their applications as authenticated users. Who am I to question it...
You see, the problem is that web vulnerability scanners are often tripped up with form-based logins. Why? Because they struggle to determine and maintain session state (the browser's/scanner's ongoing communication with the web application). Newer web technologies such as Flash and AJAX are big contributors to the problem, but web applications using MFA can be especially troublesome.
During a recent web security assessment, I struggled - hours on end - to get two different commercial vulnerability scanners to work with Oracle's Bharosa multi-factor authentication technology. I literally lost a day's worth of work trying to get these scanners to record login macros and properly maintain their session state so they could complete their scans.
What a frustrating scenario. The solution was simpler than I thought it'd be. I ended up using a third scanner - NTOSpider, which I've leaned on before to get me out of a bind in such situations - and it worked like a charm! What took me 6+ hours of pain and hassle with the other scanners (with no results, mind you), took just 6 minutes with NTOSpider.
I recorded the login macro, tested it, and got the scan rolling. It was amazingly simple. Given how much NTOSpider got logged out and had to log back in to the application, I could tell it was struggling a bit to maintain state, but it still WORKED! NTOSpider's feature that shows whether or not the scanner is current logged-in to the application is especially nice in these situations.
Side note I have to bring up: I can't imagine how many web security scans are deemed "complete" when they, in reality, failed to authenticate and properly test the application. I suspect this is a huge problem that's being overlooked all the time and people wonder why their web applications are hacked. Who am I to question it...
I'm a big advocate of using multiple scanners when testing web applications...just not in this context! But you've got to do what you've got to do in order to get good results. If you're testing web applications as authenticated users (you should!) and end up struggling to get your login macros to work, know that NTOSpider might just get you out of a bind like it did for me. Or, if it's one of your main scanners, prevent these problems in the first place.
Whether your applications use MFA, form-based logins, or good old-fashioned NTLM pop-up windows, just make sure you're using multiple scanners to test your web applications as they all tend to find unique flaws you probably can't afford to overlook. Oh, and never rely on scanners alone...do that and you'll surely get bitten.
