Many security software vendors claim that their web application security scanner can identify all vulnerabilities in the OWASP Top 10. How true is such a claim?
A question we are typically asked is if Netsparker Web Application Security Scanner can detect all vulnerabilities and security flaws listed in the OWASP Top 10. Many are lead to believe, and told that some automated web application security scanners can detect all vulnerabilities and security issues listed in the OWASP Top 10.
I have personally seen responses from security software companies stating that their web vulnerability scanner, or network scanner can detect all vulnerabilities listed in the OWASP Top 10. To start off with let us be clear, such statements are not true. There is no automated tool that can detect all security flaws listed in the OWASP top 10.
Apart from the fact that such statements are not true, they are also misleading security professionals and decision makers. But simply answering the question is not enough. This article goes into the details and explains why no security software can automatically identify all vulnerabilities listed in the OWASP Top 10 list.
For those who are new in the web application security field; OWASP is short for Open Web Application Security Project. OWASP is a non profit organization that raises web application security awareness. Every three years OWASP publishes the OWASP Top 10 list. The list highlights the most commonly exploited vulnerabilities and security problems found in websites and web applications.
The list as such is not the holy grail for web application security experts, but it servse as guidelines for organizations to ensure their web applications are not vulnerable to these most commonly exploited vulnerabilities and web application security issues. In fact there are many other vulnerabilities and security issues that can be found in web applications that are not listed in the OWASP Top 10 lists, and ideally all of them should be addressed with time.
The first in the list are injection vulnerabilities such as SQL Injection and OS Command injection. Such vulnerabilities are technical vulnerabilities and can be detected by an automated web application security scanner, or as also known web vulnerability scanner.
Second in the list are authentication and session management security issues. Unlike A1, A2 does not refer to a specific list of vulnerabilities, but addresses a number of security issues related to the design of the web application that might lead to authentication vulnerabilities.
This is the first category in the OWASP Top 10 list which lists a number of security issues that CANNOT be automatically identified by a web vulnerability scanner. For example insecure storage of user credentials; credentials are stored in clear text and are not protected using hashing or encrypted when stored in the backend database. An automated web vulnerability scanner, or any other automated security tool can never determine how user authentication details are stored in your web application’s backend database. Such checks can only be done manually by a human.
Having said that some of the security issues listed in this category can be identified automatically by web application security scanners. For example session IDs exposed in URLs, or the transmission of usernames and passwords over an unencrypted connection.
There are many different variants of cross-site scripting vulnerabilities such as reflected, persistent and DOM XSS. Since all of them are technical vulnerabilities, they can all be detected by using an automated web application security scanner. Though before choosing your web application security scanner make sure you properly test it because some of them have a number of shortcomings, especially when it comes to detecting DOM XSS vulnerabilities.
Category A4 refers to a number of logical security problems in web applications. Logical issues; this is already an indication that such type of security issues cannot be detected by automated web vulnerability scanners as explained in the section Identifying Logical Vulnerabilities of the web application security getting started guide.
This category refers to a number of security issues where typically a sensitive object or resource is not protected properly. For example a user account has access to information he or she should not have access to. To prevent such problem the application should verify if the authenticated user has access to such resource before allowing the user to access it. Such type of problem can never be identified by an automated tool because tools cannot determine if a specific user should have access to a specific resource or not. Only a person who is familiar with the operations and business scope of the web application can determine who should be able to access what.
This category refers to a number of security issues which are the result of a misconfiguration in the server or the software and framework being used. Most of these security issues can be automatically identified with an automated web vulnerability scanner, though most of them still need to be verified by a human who is familiar with the web application before being confirmed as security issues, as explained below.
Unnecessary network services: You can identify running network services such as FTP, DNS and SMTP on your web server by using a port scanner. The scanner will report the open ports but it is up to you to determine if the reported network services are needed or not.
Out of Date Software: A web vulnerability scanner will alert you if any of the software being used to run your web application is outdated and most probably vulnerable. A scanner can also identify the web server version, the development framework (php, .NET etc) version and even the version of well known web applications such as WordPress, Drupal etc.
Security Settings of Development framework: A web vulnerability scanner can also notify you of some configuration issues in development frameworks that might leave your web application exposed to malicious hack attacks. For example a scanner will alert you if debugging is enabled, or if error messages disclose sensitive information.
Default Accounts and Passwords: By default web vulnerability scanners do launch brute force attacks against login forms using a dictionary, and in fact weak credentials will be identified. Though of course this is limited to what you are scanning. For example if you use weak credentials to access the web server itself, the scanner will never be able to identify them. Hence why it is important to audit every component that make up your web farm.
The criticality of the security issues listed in this category vary depending on the organization’s scope; while some data is considered as sensitive by a particular business, it might not be sensitive for other businesses. Hence most of the security issues in this category cannot be identified automatically with security tools because it is impossible to cater for all cases, or alternatively you will be flooded with false positives.
Only a person who is familiar with the scope of the web application is in a position to be able to determine if some data should be available to the visitors or a specific user. Though having said that, there is data that is always considered as sensitive and automated scanners can identify it, such as cardholder data, social security numbers, users’ credentials and similar data.
Category A7 refers to access control. For example do users have to be authenticated to access an admin portal or it can be accessed anonymously? Though this category is not just about admin portals. For example looking at web based finance solutions, are the accounts clerks or bookkeepers able to access all the records that are typically reserved to financial controllers only? Ideally they should not.
Hence like in the previous category, not all security issues in this category can be identified with an automated web application security scanner. If an admin portal is accessible anonymously most probably an automated tool will advise you of such problem, because it can notice a specific pattern in the URL, such as /admin/ or /private/. But the tool won’t alert you if a logged in user can see records that he should not be able to see, or is able to access specific sections of the website that he should not.
As per the above example, an automated tool cannot differentiate between what a bookkeeper and a financial controller should see, hence such type of security issues or vulnerabilities cannot be identified automatically. They can only be identified manually, and even so, unless the penetration tester is familiar with the scope of the web application being auditing it is very difficult to highlight such problems.
Cross-site Request Forgery (CSRF) vulnerability is the opposite of cross-site scripting vulnerability, where the trust that a site has in a user’s browser is exploited rather than the user’s trust in a site. When exploited malicious requests are sent to the web application from the user’s browser without the user’s consent.
Typically CSRF vulnerabilities can be automatically identified though to protect from CSRF attacks developers implement anti-CSRF tokens in web applications. Because of these tokens scanners are unable to detect other vulnerabilities listed in the OWASP Top 10, such as XSS and SQL Injection. Therefore many automated web vulnerability scanners recommend users to disable these anti-CSRF tokens while scanning the website, and funnily enough then the same scanners raise alerts that no Anti-CSRF tokens were found.
Netsparker has inbuilt anti-CSRF token support, therefore it is possible to scan websites and automatically detect vulnerabilities without the need to disable anti-CSRF tokens, hence allowing you to scan real live scenarios sites.
This is most probably common sense for many security people out there but you would be surprised by how many people still run old and vulnerable software.
Web vulnerability scanners do run a number of checks to verify if the web server, database server and other server components that you are running are not vulnerable to any known vulnerabilities. Typically automated scanners also have a number of checks for well known web applications and components, such as WordPress, Joomla!, Drupal etc.
Though it is virtually impossible for a web vulnerability scanner to have a list of all possible vulnerable components and software, therefore it is up to you to ensure that you always use the latest version of a particular software.
The last category of the OWASP Top 10 refers to unvalidated redirects and forwards, also known as open redirects. These happen when the web application tries to automatically redirect or forward the visitor to a specific URL, though such URL can be tampered with, thus risking of forwarding the visitor to a malicious website.
For example imagine you have to select a language upon visiting a website so you are automatically redirected to that specific language website. Let’s say you have chosen English, then the website will automatically populate the address parameter in the example URL below with the URL of the english website.
In such cases, if the attacker can change the URL in the address parameter to another URL then the target website is vulnerable to unvalidated redirects and forwards. In most cases web vulnerability scanners can identify such security issues automatically.
As this article explains there are some vulnerabilities and security flaws from the OWASP Top 10 list that can be identified with an automated web application security scanner while others that cannot. To ensure that all web application vulnerabilities are identified on your websites use a mix of both, i.e. use the automated tools and also do a manual penetration test. As we have seen from some of the vulnerabilities mentioned above it is also important that the person doing the manual audit is also familiar with the business scope of the web application, else not all security issues will be identified, especially the logical ones.
Oh, and by the way, the next time someone tells you that their scanner can identify all vulnerabilities listed in the OWASP Top 10 list automatically tell them to stop fooling around and send them the link of this article. Alternatively ask them to send you a report that shows that their tool actually did identify all vulnerability and security issues variants mentioned in the OWASP Top 10 list.