 |
» |
|
|
|
Web application security testing tools are extremely savvy and are able to root out vulnerabilities in minutes that would take the best hacker in the world hours, months or more to find. The issue is that you’ve got to take the tool results and determine what actually matters in your environment. We’ve seen inexperienced Web application security consultants, managed security service providers and auditors run vulnerability assessment scans and then hand the results over to their clients purporting they have a bunch of problems that need to be fixed. Likewise, we’ve seen network administrators panic when they see that their Web application security testing tool has found a dozen or more vulnerabilities. They believe the sky is falling and immediately run to management asking for more budget to buy more technology to fix the problems.
|
|
|
Web application security testing tools are extremely savvy and are able to root out vulnerabilities in minutes that would take the best hacker in the world hours, months or more to find. The issue is that you’ve got to take the tool results and determine what actually matters in your environment. We’ve seen inexperienced Web application security consultants, managed security service providers and auditors run vulnerability assessment scans and then hand the results over to their clients purporting they have a bunch of problems that need to be fixed. Likewise, we’ve seen network administrators panic when they see that their Web application security testing tool has found a dozen or more vulnerabilities. They believe the sky is falling and immediately run to management asking for more budget to buy more technology to fix the problems.
It doesn’t have to be this way, and shouldn’t be this way, if you want people to take your Web application security testing seriously—especially managers and developers. You’ll need to step back and look at the big picture in order to really wrap your head around which results of a vulnerability assessment matter in your organization’s specific situation. This may mean looking at the findings from a different angle (i.e. inside the firewall instead of from the outside only), while logged in (or logged in through various roles), or manually carrying out the exploit.
Bottom line, unless your Web application security testing tool has exploited the vulnerability and handed you the findings on a silver platter, it’s going to require you digging into the results of the vulnerability assessment and verifying the problem is indeed a problem.
The following are some real-world examples of Web application security vulnerabilities discovered when testing various Web applications. Label them as false-positives, oversights or paranoia. The bottom line is that that they appeared serious on the surface but ended up not really mattering in the end.
|
|
Vulnerability Assessment Finding
|
End result
|
SQL injection discovered something that can lead to database access
|
Adequate user input validation was taking place behind the scenes and no data was actually extractable
|
SSL is not present on the login page allowing session IDs and login credentials to be sent in clear text that could lead to capturing, hijacking, and more
|
Administrator had not yet loaded the digital certificate on the server
|
Buffer overflow vulnerability present in the Web server software that can be exploited to obtain a remote command prompt on the server
|
Trusting firewall and IDS rules were enabled allowing all traffic into the Web server
|
Microsoft FrontPage virtual directories, FTP directories, etc. were found that could lead to exploitation
|
Proper directory permissions were present preventing actual access
|
Backup files with a .old extension were found that could lead to source code leakage and exploitation
|
The files were executable, documentation and home page files that had little to no relationship to the application or bearing on its security
|
An outdated version of the Apache Web server was installed that has multiple known vulnerabilities that can be exploited and lead to unauthorized system access
|
Was nowhere to be found on the system
|
Files, links and email addresses found in the Google Hacking Database (GHDB) were discovered that leak sensitive information
|
These files, links and email addresses were necessary for proper operation of the Web application
|
Macromedia Dreamweaver remote database scripts were accessible that can lead to an attacker executing arbitrary SQL queries
|
By design these files were only accessible when logged in as the manager/admin account for the Web application
|
|
|
Some of these vulnerabilities may seem benign, but anyone taking them out of context can make a big deal out of nothing. These types of issues can be the difference between a relatively secure Web application that’s safe to use and a failed Web application security audit that stirs up unnecessary controversy leading to time, effort and money spent on remediation.
When it comes to Web application security testing and remediation, focus on the urgent and important in your environment. That is, root out the vulnerabilities that can be exploited by an attacker in a typical working scenario in your specific situation. What needs to be addressed between now and next week? What can wait a month or so? What’s not even worth the effort? The bottom line is to focus on context. We are not saying ignore the other issues that come across in a vulnerability assessment. We're just saying that you’ve likely got more things to do when thinking about Web application security than worry about vulnerabilities that may never be found (and if they are will have a very minor chance of being exploited leading to anything of value).
No matter how solid your Web application security is, someone somewhere will find a way to attack the applications. That’s why you have to have layered fail-safe controls such as firewalls, IPS, input validation, solid authentication requirements, minimum necessary access controls, hardened Web servers and underlying operating systems, system monitoring, and so on. When one control fails, you’ve got a half-dozen other things to protect the system.
If you put the results of a vulnerability assessment into perspective, and not jump at every issue, your scanners will come across to help take your Web application security testing to the next level. You’ll not only show management that you understand the business side of balancing strong Web application security with reality, but, perhaps most importantly, you’ll create less work for you, your team, and your developers so everyone can focus on things that really matter.
|
|
|
Printable version
