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.
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=http://example.com/your_report_URI
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.
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.
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.
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.
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 ^W
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.
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 '<' '>' (greater than) becomes '>'
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 ''' (or ')
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.
http://www.example.com/view.php?name=te"st [...] <script> var = "te\"st "; // addslashes() displayname(var); </script>
<script> var = "test1</script><script>alert(document.cookie);</script>"; displayname(var); </script>
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.
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.
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/
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:
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.
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.
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.
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 email@example.com
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:
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:
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:
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:
The IETF RFC can be found at the following URL: http://tools.ietf.org/html/rfc6797