One of the contentious issues from vulnerability scanning, in particular with web applications, is false positives. This means that the scanning shows vulnerabilities exist, whereas in reality there is no vulnerability (i.e. it is a response to the scanning that has been incorrectly classified). These are type I errors – a result that indicates a given condition is present when actually it is not.
A type II error is where a condition is present but is not indicated as being so. This type of error is a false negative and is often more serious as it generates a false sense of security.
Web applications are frequently vulnerable to injection exploits. These techniques involve various vulnerabilities to SQL injection, Cookie manipulation, command injection, HTML injection, Cross-site scripting and so on.
To prevent injection it is recommended that the application uses a combination of parameterised statements, escaping, pattern checking, database permissions and input validation. Additionally, the application should also be checking input to ensure that input values are within range, and unexpected values are handled in a consistent manner. Generated error messages should not give away information that may be useful to an attacker but should help a user enter the required input, improving the user experience of the website.
The testing for injection vulnerabilities is done by modifying GET and POST requests as well as Cookies and other persistent data storage. The scanner attempts an injection attack by changing the content to inject a piece of additional code before sending the modified requests to the web application. The additional code can represent a SQL command, HTML code or OS command, dependent if the attack is simulated.
The scanner then examines the responses back from the web application to determine if the injection attempt was successful. It looks for evidence of a successful execution of the code which can be:
- a delay in the return of the response
- a response including the injected input within it which the browser interprets as HTML code
- an error message which has been detected or
- data that has been retrieved by the simulated attack.
ASV and vulnerability scans generate a large number of reactions when testing for various injection techniques. These reactions can indicate that a vulnerability exists, or that it is a false positive.
Often the scanning detects that the response has the injected code embedded within it, even though it failed to execute in the intended manner. The automated software includes these as a result in its report.
In reality, these results are false positives in that the attempt did fail. However, they also indicate that the inputs to the application have not been sanitised to ensure only the expected range of inputs are processed by the application. What has happened is the modified input has passed through the application and has been included in the response by the web server back to the vulnerability scan engine without being filtered out.
Although these false positives can be ignored, they show that the application is not sanitising variables and values, and is allowing a potential vector for future unknown attacks to occur. Eliminating an attack vector by properly sanitising variables, cookies and other forms of persistent data within a web application environment will help protect against attacks in the future.
The advantage of having an application that correctly sanitises the input is that the number of false positives detected during vulnerability scanning is reduced. Therefore ‘noise’ that may be masking a true vulnerability is removed and the number of false positives is reduced, especially if ASV scans are being conducted.
A disadvantage of not sanitising the input is that often blocks of results are classed as false positives, rather than examining of the individual results. Occasionally this means a true result can be incorrectly classed as a false positive, creating a type II error. The incorrect identification of a positive response as a false positive gives a false sense of assurance.
When attempting to manually examine the results from automated testing to identify false positives, additional problems are encountered. Vulnerability scanners use their own engines to generate HTTP requests and analyse responses. Trying to emulate the testing using browsers is problematic. The current generation is equipped with technology that is designed to reduce attack vectors by filtering the responses sent and the requests received. Browsers such as IE will detect and block attempts at cross-site scripting IE has improved since V6 and the latest versions prevent traversal attacks etc. from the URL box in the browser.
The browser behaviour requires the use of additional tools to manually test for vulnerabilities. Tools such as web proxy (like Web Scarab or Burpsuite) are used to intercept the request objects from the browser, allowing modification before sending them onto the server. The proxy also allows interception of the response objects before they reach the browser. This permits the response to be examined at a HTML source code level, rather than being done by the browser.
Even with just a reasonably-sized website, there can be hundreds of results from the testing. Eliminating the generation of responses (especially the false ones), by correctly sanitising the input to the application will make the scanning and reporting more efficient and reduce the time spent on false positives in the future. An organisation that looks at what is causing the generation of false positive response to a test scenario, and eliminates the causes rather than ignoring the false responses, will be improving their security posture and making scanning more efficient, reducing the chance of a vulnerability being ignored.
In summary, it is import to ensure a web application correctly sanitises the input to reduce the production of false positives and improve the effectiveness of vulnerability scanning.
Don’t make it easy for cyber attackers to hack into your systems. Act now! Arrange your vulnerability scanning today!