Understanding XSS Auditor



Understanding XSS Auditor

We see a lot of confusion regarding the X-XSS-Protection header and thought it might be worthwhile to go over exactly what this header is and what it isn’t.

What is XSS Auditor?

XSS Auditor is a built-in function of Chrome and Safari designed to mitigate Cross-site Scripting (XSS) attacks. It aims to identify if query parameters contain malicious JavaScript and block the response if it believes the payloads were injected into the server response. XSS Auditor is enabled by default, but can be configured or disabled with the X-XSS-Protection HTTP header. X-XSS-Protection is a non-standard header, meaning there is no official W3C or IETF specification. Despite this, the common configurations can be seen below.

Valid Configurations

  1. Disable XSS auditor
    X-XSS-Protection: 0
  2. Run in rewrite mode (default if header is not set).
    X-XSS-Protection: 1
  3. Run in “block” mode. Once the auditor is triggered the response is blocked and a blank page is shown to the user.
    X-XSS-Protection: 1; mode=block
  4. Run with reporting. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
    X-XSS-Protection: 1; report=http://example.com/your_report_URI

So what isn’t X-XSS-Protection?

XSS Auditor isn’t a solution to XSS attacks. As Justin Schuh of Google mentions, “XSS auditor is a defense-in-depth mechanism to protect our users against some common XSS vulnerabilities in web sites. We know for a fact it can’t catch all possible XSS variants, and those it does catch still need to be fixed on the affected site. So, the auditor is really an additional safety-net for our users, but not intended as a strong security mechanism.” Because of this, XSS Auditor bypasses are rated as ‘SecSeverity-None’ and, if you we’re wondering, are not eligible for bug bounty payments.

How does the XSS Auditor Work?

XSS Auditor takes a black list approach to identify dangerous characters and tags supplied in request parameters. It also attempts to match query parameters with content to identify injection points. If the query parameter can’t be matched to content in the response, the auditor will not be triggered. Because the browser will never have insight to server-side code, an application that mangles an XSS payload will always render the XSS auditor useless in preventing attacks.
To take a quick look at the code behind Chrome’s XSS auditor, we can get an idea of the inner workings of the detection mechanisms:


Just by looking through the function names we can see that the auditor searches for script tags, valid HTML attributes, and other XSS injection vectors. Before rendering the response in the Document Object Model presented to the user, XSS auditor searches for instances of (malicious) parameters sent in the original request. If a detection is positive, the auditor is triggered and the response is “rewritten” to a non-executable state in the browser DOM. Chrome’s ‘view-source’ has a builtin component to highlight sections on code in red that caused the XSS auditor to fire.


Bypassing XSS Auditor

A bypass of XSS auditor should not be considered a vulnerability. While the Chromium team does actively improve the auditor, there are likely to always be number of bypasses for the auditor. We will not go in depth about specific bypasses as they do change with time and are likely to be outdated fast. At the time of this writing two examples that are functional in the latest version of chrome can be found here and here.

Defeating Android Emulator Detection



Defeating Android Emulator Detection

At some point while performing vulnerability assessments on android applications you will encounter apps that don’t want to be run within an emulator. We can’t blame application owners for wanting to ensure that the user interaction they see comes from genuine devices, but it doesn’t help us do any security testing on it.

There are several ways to detect an emulator; however this example is only relevant to the most common way we see. In this application, a check is performed for an IMEI value of ‘000000000000000’ which is the value used by the emulator that ships with the Android SDK.

The code segment below checks for this value and exits if true. While we could easily patch the value from within the application, it may be more efficient in the long run to simply change the IMEI value of our emulator. This way we don’t have to patch the next application that does this.

android emulator check

The IMEI is stored as a text string, so we will search for a ‘text string’ accordingly. Open the binary with hexeditor, hit ^W, and search for the fifteen zeroes. Note that the binary we wish to open is not the “emulator” binary, but the “emulator-arm” binary. If you are using a different architecture you may be using the mips or x86 binary.

cp emulator-arm emulator-arm.bak
hexeditor emulator-arm

hexedit search

Note once again this is an ascii string, so the zeroes are 0x30.


In this case, we just replace four characters with 1234 by updating 0x31, 0x32, 0x33, and 0x34. Do not change the length of data in this segment or overwrite bytes outside this segment or you will corrupt the binary.


Just save and exit. Now our emulator will be using our new custom value.

Preventing Cross-site Scripting in PHP



Preventing Cross-site Scripting in PHP

Preventing Cross-site Scripting (XSS) vulnerabilities in all languages requires two main considerations: the type of sanitization performed on input, and the location in which that input is inserted. It is important to remember that no matter how well input is filtered; there is no single sanitization method that can prevent all Cross-site Scripting (XSS). The filtering required is highly dependent on the context in which the data is inserted. Preventing XSS with data inserted between HTML elements is very straightforward. On the other hand, preventing XSS with data inserted directly into JavaScript code is considerably more difficult and sometimes impossible.

Input Sanitization

For the majority of PHP applications, htmlspecialchars() will be your best friend. htmlspecialchars() supplied with no arguments will convert special characters to HTML entities, below shows the conversions performed:

'&' (ampersand) becomes '&'
'"' (double quote) becomes '"'
'<' (less than) becomes '&lt;'
'>' (greater than) becomes '&gt;'

Eagle eyed readers may notice this does not include single quotes. For this reason we recommend that htmlspecialchars() is always used with the ‘ENT_QUOTES’ to ensure single quotes will be encoded. Below shows the singe quote entity conversion:

"'" (single quote) becomes '&#039;' (or &apos;)  

htmlspecialchars() vs htmlentities()

Another function exists which is almost identical to htmlspecialchars(). htmlenities() performs the same functional sanitization on dangerous characters, however, encodes all character entities when one is available. This may lead to excessive encoding and cause some content to display incorrectly if character sets change.


strip_tags() should NOT be used exclusively for sanitizing data. strip_tags() removes content between HTML tags and cannot prevent XSS instances that exist within HTML entity attributes. strip_tags() also does not filter or encode non-paired closing angle brackets. An attacker may be able to combine this with other weaknesses to inject fully functional JavaScript on the page. We recommended that strip_tags() only be used for its intended functional purpose: to remove HTML tags or content. In these situations, input should be passed through htmlspecialchars() after strip_tags() is used.


addslashes() is often used to escape input when inserted into JavaScript variables. An example is shown below:

 var = "te\"st ";   // addslashes()

As we can see, addslashes() adds a slash in attempt to prevent an attacker from terminating the variable assignment and appending executable code. This works, sort of, but has a critical flaw. Most JavaScript engines will construct code segments from open and closed <script> tags before it parses the code within them. This is done before the browser even cares about the data that resides between the two quotes. So to exploit this, we don’t actually need to “bypass” addslashes(), but simply terminate the script tag.

 var = "test1</script><script>alert(document.cookie);</script>";

As far as the browser is concerned, the code injected is an entire new code segment and contains valid JavaScript.

Where Entity Encoding Fails

We talked before about considerations for the location of data, and will go over some examples where entity encoding with htmlspecialchars() is not enough. One of the most common examples of this is when data is inserted within the actual tag or attribute of an element.

HTML Event Attributes: HTML has a number of elements with attributes that allow for JavaScript to be called after a particular event. For example, the onload attribute can execute JavaScript when an HTML object is loaded.

<body onload=alert(document.cookie);>

This is just one of many somewhat rare situations where extremely strict filtering is required. For an in depth look at many injection scenarios and their prevention methods, take a look at the OWASP XSS Prevention Cheat Sheet.

Third Party PHP Libraries

Virtue Security makes no recommendation or provides any warranty for third party products or software; however, we are aware that several third party PHP libraries are commonly used to assist in XSS prevention. Below are projects that may assist developers building suitable whitelists:

HTML Purifier – http://htmlpurifier.org/
PHP Anti-XSS – https://code.google.com/p/php-antixss/
htmLawed – http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Other Things to Remember

A great rule of thumb to go by is simply not to insert user controlled data unless its explicitly needed for the application to function. It’s often surprising to see XSS vulnerabilities exist because parameters are inserted into HTML or JavaScript comments. Not only does this serve no functional purpose to the application, but it can introduce serious security vulnerabilities.

Getting the Most Out of Application Vulnerability Assessments



Application Vulnerability Assessments

Application vulnerability assessments are a vital part of a security process for any organization deploying online applications. Vulnerability assessments identify critical threats, sensitive information leakage, and a wide array of other security issues. While the discovery of these vulnerabilities is the most immediate value returned from an assessment, there are several other commonly missed benefits from them. If performing multiple engagements, an even greater opportunity is provided for organizations to build better long term security practices. Below are several things to keep in mind after performing an assessment:

Build Fixes into the SDLC

As vulnerability assessments are conducted across multiple applications within an organization, a clear picture is often painted of areas in which need improvement. While vulnerabilities are often remediated with quick patches to insecure code, by putting slightly more effort into a long term solution an even larger benefit can be gained. This is a great opportunity to take the remediation and build it into the development process. Instead of creating many small code patches, build the patches into trusted frameworks which can be reused by many applications.

If issues of Cross-site Scripting (XSS) are a recurring problem, development teams should take the time to build proper input validation into request handling functions. This will ensure input is properly validated across the application, and that these controls are reused across the organization, rather than a few isolated areas.

A CISO looking at recurring XSS issues may wish to meet with lead developers and discuss long term solutions to input validation coding practices. Remember that each issue has a cost, both in terms of a security tester finding and reporting it, and the developers remediating the issue. Over multiple years, multiple applications, and multiple vulnerability assessments, the cost of issues can be compounded greatly.

Pay Attention to the Lows

Low Risk vulnerabilities are often not remediated if a significant cost associated with it. While threat prioritization is a necessity, Virtue Security strongly recommends Low Risk issues be remediated within 90 to 180 calendar days. While these issues often disclose only minimally sensitive information, it’s important to keep in mind this is still useful to an attacker. If an attacker were to discover every low risk item across an organization, chances are high that they will have an easier time carrying out other attacks against the organization.

Even small amounts of internal knowledge, can be used as strong leverage when carrying out social engineering attacks. An attacker can gain a lot of credibility if he or she is able to ask specific questions regarding internal systems or software. Additionally, some low issues have compounding risk; the existence of some low risk issues can increase the exploitability of higher risk issues.

Think More Than Compliance

To some, vulnerability assessments may be like a trip to the dentist; not everyone wants to go through an audit, but they exist to help. They may be conducted as part of a PCI, HIPAA, or regulatory audit, but it’s important that they ultimately exist to benefit the organization. Performing assessments with the only goal of maintaining compliance is not a sustainable practice. It’s also important to realize that compliance is only a short term goal, and only doing the minimum to meet these goals is a recipe for disaster.

Working with vendors to ensure the scope of assessments is properly defined is also critical for a thorough assessment. Ensuring test dates are fair and reasonable and start on time will only benefit the organization. Attempting to squeeze assessments into shortened time frames should be avoided if possible.

Compare Vendors

Large organizations should use multiple vendors; keeping a competitive atmosphere can deter a vendor from complacency and ensure engagements are performed with diligence. While some organizations perform direct simultaneous comparative tests between two vendors, this can result in assessments double in price. Organizations wishing to save money but still validate another vendor’s findings may wish to alternate applications between vendors on an annual or biannual basis. Over time, a weak security vendor may become apparent. Do consider that ethical hacking changes quickly, and additional issues should be expected to be discovered after one year’s time.


Application vulnerability assessments are one of the most cost effective ways to identify weaknesses in application business logic. By coordinating long term plans with development teams, even greater value can be obtained. To keep a steady value, work with vendors to make sure testing scope reflects real world attack scenarios and ensure testers have reasonable timeframes to complete testing. Thinking in terms of long term solutions often has far greater rewards than simply maintaining short term compliance. Avoiding a breach is the ultimate goal of just about everything we do, if we keep this in mind and properly manage short term goals, we will all be better off.

For more information on how you can get the most out of your next application vulnerability assessment, contact Virtue Security founder Elliott Frantz at elliott.frantz@virtuesecurity.com

The Do’s and Don’ts of HSTS


HTTP Strict Transport Security

The Do’s and Don’ts of HSTS

HTTP Strict Transport Security (HSTS) is an IETF specification to instruct web browsers to strengthen HTTPS requirements when connecting to a host. HSTS accomplishes this in two ways:

  1. The web browser shall make all future requests to the given host over HTTPS. If content is included over insecure channels, or the user follows a direct link to an insecure channel, the browser will ensure only requests over HTTPS are made. This protects session tokens from being disclosed as well as the
  2. Users cannot accept SSL warnings. Browsers supporting HSTS will not give users the ability to accept SSL warnings. If a user is the victim of a MITM attack, they will not be able to accept SSL warnings and continue to use the application.

Below shows the error a user sees when an SSL warning is induced, no options so accept the error are presented:

The HSTS header takes the following form:

Strict-Transport-Security: max-age=31536000

The max-age parameter specifies the length of time the browser should enforce the policy. 31536000 is the maximum allowed value, which equates to one years’ time (in seconds). There are a few very important things to understand about the limitations of HSTS:

  1. HSTS is not a compensating control for having application functionality accessible over HTTP. Applications should still forcefully redirect users via 301/302 redirects to HTTPS URLs.
  2. HSTS cannot prevent a MITM attack on the first visit to a website. An attacker conducting a MITM attack on the initial connection can successfully man in the middle the victim if the very first plain text session is hijacked.
  3. HSTS can be issued over HTTPS only. Browsers will not observe any Strict-Transport-Security headers issued over plain text.

Ethical hacking service providers should raise issues surrounding HSTS similar to that of cookies missing http-only flags (ie. “Low Risk” or “Note”). One thing to keep in mind is that although this is an optional security enhancement, the current model of HTTP is far from ideal. HSTS simply brings us a step closer to a secure trust model. So although this is an optional feature, it is highly recommended this is adopted for secure applications.

Strict-Transport-Security is just one of many new headers developed in the recent years to combat increasing web attacks. Similar headers such as X-Frame-Options exist to prevent clickjacking attacks, and X-XSS-Protection/CSP headers can in some cases protect against XSS attacks. It is more important than ever that security professionals understand the latest security web browser controls and ensure they are implemented where appropriate.

In summary, below are the do’s and don’ts of using HTTP Strict-Transport-Security:

    Do use HSTS to secure return visits to your application.
    Do send your Strict-Transport-Security over HTTPS.
    Do use an appropriate ‘max-age’ value for return visits.
    Do NOT use HSTS as a replacement for server-side HTTPS enforcement.
    Do NOT expect HSTS will prevent a first contact MITM attack,

The IETF RFC can be found at the following URL: http://tools.ietf.org/html/rfc6797

 Page 1 of 2  1  2 »