Have you ever had a client (or your own employer) say, "There's no way a user could hack our internal Web apps; they can't run anything but authorized applications like a Web browser and e-mail client." Happens all the time, right? Guess what -- you're not alone.Jeremiah Grossman has posted a list of the top eight reasons Web vulns aren't fixed on his blog, and Chris Eng has a great follow-up titled, "But That's Impossible!"

It's not uncommon to find organizations that take the ostrich-with-its-head-in-the-sand approach to security, hoping that if they ignore it, then it will go away. I think we've all run into those types of managers and/or clients, but what about issues where a lack of understanding of the problem and attack methods is what's leading the company to think they are more secure? Let's use a couple of the statements from the Veracode blog.

"That system isn't even exposed to the outside." -- This is a great starter because by now you all should know that this is a non-issue for attackers when other systems on the same network are exposed or internal users who access that system are also receiving e-mail and browsing the web. Can you say client-side exploit? Maybe something like a zero day exploit against Adobe Acrobat that phones home giving an attacker an interactive shell to then attack internal systems?

"You are using specialized tools; our users don't use those." -- You gotta love this one! I've blogged about weaponizing Firefox with some great add-ons. All it takes is a Web browser, or even telnet, to exploit a Web browser vulnerability. I'd love to see reaction of the person who made that statement when you display the contents of his database through SQL injection with nothing but Internet Explorer.

"We don't even link to that page." -- How many data exposures could be attributed to this misguided statement? Tools like Nikto have existed for years that enumerate directories on a Web server by running through a common list of directories. In fact, that's how Metasploit and a new script for Nmap work to detect servers vulnerable to the IIS WebDAV zero-day vulnerability. They make repeated requests to a Web server looking for common directories, send a request using the Unicode string to any directories found, and determine whether it's vulnerable based on the HTTP response code.

Oh, I could go on and on with examples, but what I want to leave you with is that we as security pros must realize it is our responsibility to educate the people who respond with statements such as those. Our reports should detail the vulnerability and the risk carried with it. We should also be able to explain it to our clients during a presentation or in a private meeting in a way that they can understand it and aren't left feeling insulted them. That last part can be difficult, but it's crucial to getting repeat business and recommendations.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.