CAPEC-199 XSS Using Alternate Syntax

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.

1. [Explore] [Survey the application for user-controllable inputs] Using a browser or an automated tool, an adversary follows all public links and actions on a web site. They record all the links, the forms, the resources accessed and all other potential entry-points for the web application. 2. [Experiment] [Probe identified potential entry points for XSS vulnerability] Possibly using an automated tool, an adversary requests variations on the inputs they surveyed before using alternate syntax. These inputs are designed to bypass incomplete filtering (e.g., incomplete HTML encoding etc.) and try many variations of characters injection that would enable the XSS payload. They record all the responses from the server that include unmodified versions of their script. 3. [Experiment] [Craft malicious XSS URL] Once the adversary has determined which parameters are vulnerable to XSS, they will craft a malicious URL containing the XSS exploit. The adversary can have many goals, from stealing session IDs, cookies, credentials, and page content from the victim. 4. [Exploit] [Get victim to click URL] In order for the attack to be successful, the victim needs to access the malicious URL.

• Target client software must allow scripting such as JavaScript.

• [Low] To inject the malicious payload in a web page • [High] To bypass non trivial filters in the application

• Integrity: Modify Data • Confidentiality: Read Data • Authorization: Execute Unauthorized Commands • Accountability, Authentication, Authorization, Non-Repudiation: Gain Privileges • Access Control, Authorization: Bypass Protection Mechanism

• 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: Disable scripting languages such as JavaScript in browser • 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.