Common Attack Pattern Enumeration and Classification
A Community Resource for Identifying and Understanding Attacks
An adversary uses alternate forms of keywords or commands that result in the same action as the primary form but which may not be caught by filters. For example, many keywords are processed in a case insensitive manner. If the site's web filtering algorithm does not convert all tags into a consistent case before the comparison with forbidden keywords it is possible to bypass filters (e.g., incomplete black lists) by using an alternate case structure. For example, the "script" tag using the alternate forms of "Script" or "ScRiPt" may bypass filters where "script" is the only form tested. Other variants using different syntax representations are also possible as well as using pollution meta-characters or entities that are eventually ignored by the rendering engine. The attack can result in the execution of otherwise prohibited functionality.
In this example, the attacker tries to get <script>alert(1)</script> executed by the victim's browser. The target application employs regular expressions to make sure no script is being passed through the application to the web page; such a regular expression could be ((?i)script), and the application would replace all matches by this regex by the empty string. An attacker will then create a special payload to bypass this filter:
when the applications gets this input string, it will replace all "script" (case insensitive) by the empty string and the resulting input will be the desired vector by the attacker:
and replaces all matches by the empty string. For example each occurrence of alert(), eval(), foo() or even the string "alert" would be stripped. An attacker will then create a special payload to bypass this filter:
this['al' + 'ert'](1)
Skill or Knowledge Level: Low
To inject the malicious payload in a web page
Skill or Knowledge Level: High
To bypass non trivial filters in the application
Design: Use browser technologies that do not allow client side scripting.
Design: Utilize strict type, character, and encoding enforcement
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Ensure all content coming from the client is using the same encoding; if not, the server-side application must canonicalize the data before applying any filtering.
Implementation: Perform input validation for all remote content, including remote and user-generated content
Implementation: Perform output validation for all remote content.
Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.
Client web browser may be used to steal session data, passwords, cookies, and other tokens.
[R.199.1] [REF-9] "OWASP Cheatsheets". XSS Filter Evasion Cheat Sheet. The Open Web Application Security Project (OWASP). <https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet>.
[R.199.2] [REF-4] "OWASP Testing Guide". Testing for Cross site scripting. v2. The Open Web Application Security Project (OWASP). <http://www.owasp.org/index.php/Testing_for_Cross_site_scripting>.
More information is available — Please select a different filter.