XSS Evasion: Hiding in Plain Sight
Is there a holistic solution for ensuring the secure, fast, and reliable delivery of applications?
By Lori MacVittie
Today's Web users continue to demand more from their online experience. Accessibility and speed drive programmers and keep users happy -- but at what price? The ever-increasing interactive capabilities of the Web's most progressive sites ultimately put a user's security in jeopardy. These new programming channels, coupled with Web 2.0, leave user security susceptible to new XSS (Cross Site Scripting) threats.
Threat prevention systems of yesteryear such as UTM (Unified Threat Management), Web application firewalls, intrusion prevention systems, and intrusion detection systems are now vulnerable to XSS invasions. The previous method of plugging holes with content filtering and signature-based databases no longer sufficiently combats attackers' evasion techniques. XSS attacks are now two-pronged, not only attacking a target system but also attacking defensive systems protecting the targets. To counter them requires a system to first recognize an e-evasion attempt, and then identify invasion techniques. The latest attack attempts utilize HTML manipulation injection and encoding tags in different code sets or base systems to slide attacks through the filtering process.
The Vagaries of Language
It is often said that the English language is one of the most complex and confusing languages in existence. Homophones, such as "there" and "their" (not to mention "they're") constantly trip up even native speakers, and other eccentricities can cause great confusion and consternation among speakers and writers alike.
Although systems and secure coding techniques exist that prevent traditional XSS attacks from successfully exploiting vulnerabilities across the application infrastructure, today's attackers have grown more sophisticated. Using the same attacks from yesterday, they have discovered how to embed and hide them from the filters and signature-based comparisons that have traditionally protected Web sites and applications.
Traditional filtering techniques capable of detecting XSS injection are generally based on regular expressions that expect specific formatting of HTML. This formatting includes white spaces, carriage returns, and tabs. An attacker can bypass these regular expressions filters simply by decreasing, increasing, or inserting extra white spaces. In this way, the attack -- though a well-known one -- does not match the expected pattern and the resulting malicious code is allowed to pass through and exploit the application.
White-space-based injection attacks work because the filters in threat-prevention systems do not cover all the possible cases, and HTML rendering engines ignore white space contained inside HTML tags.
Similarly, regular-expression-based filters are also used to look for malicious code within well-formed HTML. Well-formed HTML must contain opening and closing tags where appropriate. Adding or dropping closing tags or even adding additional opening tags can confuse these filters and enable the attacker to successfully evade detection.
HTML manipulation injection attacks work because filters cannot anticipate the irregular placement of opening and closing tags on HTML elements, and rendering engines are forgiving and will often close tags on their own.
HTML manipulation is a growing threat as the number of social networking sites and communities continues to grow and users demand the ability to include formatting in their messages. By allowing more lattitude for users to include links and other HTML, entities it becomes even easier for attackers to embed attacks and affect potentially hundreds or thousands of users with one successful attack.
Making it even easier to bypass threat-prevention systems and filters is the fact that HTML can be encoded in multiple code sets. HTML tag names can easily be encoded in different code sets (such as hexadecimal, octal, and Base64) that are recognized and interpreted correctly by browsers but are not understood by traditional regular expressions and filters.
Use of different character encodings works because although the filter may not recognize the attack, the browser will correctly interpret the data during the rendering process.
URL String Evasion
Part of an XSS-based attack is the injection of malicious code, with the second step requiring that some data or script be loaded from an external site. Because of this requirement, many threat prevention systems recognize the presence of external domains and will prevent them from being accepted by the application. To evade the systems' ability to block such URLs, attackers employ several methods to hide the URL from being recognized as external.
Such methods include using an IP address instead of a domain name, using URL encoding to hide the domain name, and encoding the URL numerically as a DWORD, hexadecimal, or octal string. Some attackers will mix and match these methods, causing further confusion to threat prevention systems.
URL string evasion works because filters expect a string-based domain name, not a numeric one, and because modern Web browsers are capable of understanding the encoded version of the domain name or IP address.
In much the same way that cable television provides parents with the means to block channels that deliver, by their assessment, unacceptable content, some of today's Web application firewalls have evolved to provide the same control over user-initiated requests. This control provides the means by which XSS-based attacks -- even those hiding in plain sight -- can be stopped before they reach back-end applications and databases, and wreak havoc on application infrastructure.
XSS injection attacks themselves have not changed, only the manner in which they are delivered has been modified. By detecting these attempts to hide in plain sight -- within the same HTML code and HTTP requests -- Web application firewalls can continue to prevent such attacks from successfully being injected in applications and subsequently affecting either mission-critical data or, in the case of Web 2.0 communities and social networks, potentially thousands of users.
What is required to detect these evasion attemps is normalization before evaluation. When a request is received, it needs to pass through a process that removes extraneous comments and white space, and further decodes the request into a common, understood code set. This allows proven methods of detecting and preventing XSS injection attacks to be applied and thus stops the evasion from accomplishing its task of injecting malicious code into an application.
Threat prevention systems based purely on signature or keyword matching cannot properly deal with evasion attacks. While these techniques are a good basis for preventing known threats from reaching applications, such a static method of threat detection cannot continue to be successful against the evolving dynamic nature of Web application attacks, in particular XSS injection.
Advanced technology is required to detect the evasions used today to penetrate existing threat prevention solutions. These solutions, such as IPS or stand-alone Web application firewalls, provide protection primarily at the Web application layer and cannot address the broader issue of application delivery security. A modern Web application firewall -- when coupled with the network and application transport layer security of an application delivery platform and integrated into an application delivery network -- offers a holistic solution for ensuring the secure, fast, and reliable delivery of applications.
- - -
Lori MacVittie is a technical marketing manager for application services at F5 Networks. You can reach the author at firstname.lastname@example.org