Pentesters Need to Keep Track of Browser Options

Penetration testers searching for vulnerabilities always include cross-site scripting (XSS) attacks as one of their methods. Recently we observed an unusual XSS-related case that taught us something new.

During an XSS-related test, we inserted the “<script>alert(1)</script>” payload as a GET request’s parameter and executed this command in Internet Explorer 11. We expected to see our “malicious” alert but instead the browser returned “The webpage cannot be found,” making us think that our command had failed. We next ran the command on Firefox and saw a different response—a successful XSS execution with “alert box 1.”

Different browser responses for the same HTTP response code.

When we examined the request/response traffic in Burp’s proxy server, we saw “HTTP/1.1 400 Bad Request” with our inserted XSS payload in the response body. This suggested that the command should work at all times.

The actual page response in Burp.

Clearly there are differences in browser behavior for the same response HTTP code. After further investigation we found Internet Explorer’s advanced feature “Show friendly HTTP error messages”:

Internet options in IE.

When this feature is checked (the default), Internet Explorer shows its own friendly error message instead of the page response from web server.

In our XSS attempt, Internet Explorer ignored the web server’s bad request response (the injected XSS payload was even reflected in the response) and showed its own message. By looking only at this response, there is a strong chance that we could miss a serious issue during our testing.

We unchecked this option, restarted the browser, and ran the same malicious URL. This time we saw the successfully executed response with the alert box.

Successful XSS execution after disabling the “friendly error message” feature in IE.

There are some other specific browser settings/dependencies that need attention while pentesting:

Enable XSS filter (in IE): When this option is enabled, the browser recognizes a potential attack in its response (reflected script), and will automatically block script code from running. When this occurs, we see a message in the notification bar that the web page was modified to help protect your privacy and security. Disable this option in the security field while pentesting:

The XSS filter option in IE.

Developers also have the choice to set a custom XSS-protection response header to enable XSS filters in browsers. Read this page for more information.

Next time you are pentesting, take a look at these sorts of browser options. They may help you to greater success.

References:

http://www.liutilities.com/products/registrybooster/tweaklibrary/tweaks/11253/

https://support.isqsolutions.com/article.aspx?id=10161

The post Pentesters Need to Keep Track of Browser Options appeared first on McAfee Blogs.

Read more: Pentesters Need to Keep Track of Browser Options