One of the contentious issues from vulnerability scanning, in particular with web applications, is false positives. This means that the scanning indicates vulnerabilities exist, whereas in reality there is no vulnerability, it is a response to the scanning that has been incorrectly classified. These are type I errors - a result that indicates that a given condition is present when actually it is not.
A type II error is where a condition is present but not indicated as being so. This type of error is a false negative and is often a worse condition as there is a false sense of security generated since vulnerabilities where not identified.
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 are used. 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 web site.
The testing for injection vulnerabilities is done by modifying GET and POST requests as well as Cookies and other persistent data storage, by changing the content to inject a piece of additional code before sending the modified requests to the web application the scanner attempts an injection attack. The additional code can represent a SQL command, HTML code or OS commands dependent on the attack being simulated.
The scanner then examines the responses back for the web application to determine if the injection attempt has succeeded by looking for evidence of a successful execution of the code. This evidence can be a delay in the return of the response, the response including the injected input within it which the browser interprets as HTML code, an error message is 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 a vulnerability exists or be a false positive.
Often the scanning detects that the response has the injected code embedded within it even though the injected code 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 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; noise that may be masking a true vulnerability is removed and the need to argue which results are false positives is reduced, especially if ASV scans were being conducted.
A disadvantage of not sanitising the input is often blocks of results are classed as false positives rather than examining hundreds of results and occasionally this means a true result is incorrectly classed as false positive creating a type II error. The incorrectly identification of a positive response as a false positive is worse than including all the responses to a test as it gives a false sense of assurance if vulnerabilities do not appear to have been identified.
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. Then trying to emulate the testing using browsers the current generation are 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 manual 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, allowing the response to be examined often at a HTML source code level rather than allowing a browser to interpret the response and display it in their pane with filtering out of malicious scripts etc being done by the browser.
Even with just a reasonable size website, there can be hundreds of results from the testing.
Eeliminating the generation of responses, especially 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 response will be improving their security posture and making scanning more efficient. They will be reducing the chance of a vulnerability being ignored as it was lost in the noise or wrongly classified as being false.
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 by reducing noise which masks important results.
No comments:
Post a Comment