If you’ve ever ran a Web vulnerability scan you’ve likely experienced this situation. You fire up your scanner, tweak your settings, and click Start. The next thing you know people in customer service, marketing, IT, etc. are wondering why they’re getting hit with hundreds – often thousands – of emails from the site. You immediately realize it’s your Web vulnerability scanner doing the misdeed. So you stop the scan and discuss some options with everyone. Odds are you couldn’t come up a good solution for the short term. After all, your auditor or compliance manager is breathing down your neck for the scan results in the name of PCI compliance or whatever. Everyone decides to continue on with the scan and they’ll just live with the consequences of the email floods.
Sound familiar? That’s the typical scenario I’ve seen. Before you go down this path – again – you have some options for preventing email floods to begin with. Depending on the environment, timing, etc., I’ve found the following to work well:
• Setup a rule in your email server to block, reject, or black-hole email messages coming from your scanner or specific forms
• Code the application with a dummy email account that just sends emails to the bit bucket
• Depending on application logic, you may be able to point email requests back to the localhost where they’re queued or black-holed
• Setup a CAPTCHA on each form (this will help prevent email floods but it also may get in the way of effectively testing for input validation problems)
These may not work in your environment – especially if you’re scanning against production. You have another option: don’t submit form data, or depending on how your scanner handles this, just ignore the forms altogether. I don’t like this approach because you’re overlooking the very root of many XSS, SQL injection and related input validation issues. To me, if it’s there for the bad guys to access it needs to be tested in-depth.
There’s no real good answer to the dilemma of how to handle email floods other than it depends. Given all the different programming languages, methods for form handling and so on the possibilities for preventing email floods are endless. The important thing is to think this through beforehand to see what can be done both short-term and over the long haul. Above all, no matter what controls you have in place to prevent email floods, let people know that it could happen. Setting everyone’s expectations during security assessments is half the battle anyway.
I’m curious to know what you do to address this situation. Drop us a comment.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
