Cross-Site Scripting

• Cross-site scripting is a vulnerability rooted in the way HTML content is generated and interpreted by client browsers.
• These vulnerabilities are usually found in Web applications and allow attackers to inject HTML or client-side scripting into input of a web-based application in the hope (or with the knowledge) that the input the attacker provided will be returned unparsed.
• This basic vulnerability, depending on how it's exploited, can be used for a multitude of purposes. The number of these seems to grow all the time, but some of these are:
  • Cookie theft
  • Session ID theft
  • Defacing a Web site
  • Limited execution of arbitrary code on the victim's machine, particularly, if it's a trusted Web site or a Web-driven client application. or even if it is combined with an unsafe ActiveX control.
  • Manipulating the DOM (Document Object Model)
  • Cookie poisoning
  • Changing user settings
• Malicious scripting can he created using a variety of languages or technologies, such as:
  • JavaScript
  • VBScript
  • ActiveX
  • HTML
  • Flash

• This is the most common type of cross-site scripting vulnerability by far — a vulnerability where data from a Web client is immediately used by the server to generate a page to return to the user.
• A classic example of this is encountered in search engines: If you search for a string that includes some HTML. special characters. often search string will be redisplayed on the results page to indicate what was searched for, or the search terms will at least appear in a new search text box for easier editing. If all occurrences of the search term are not HTML entity-encoded, an XSS vulnerability will exist because that redisplayed search string would then contain the client-side script that your browser would execute.

• This is not the most common type of attack, but it is the most powerful. This vulnerability occurs when data provided to a Web application by an attacker is first stored persistently on the server, and then later it's displayed to users in a Web page without being HTML-encoded.
• One of the reasons this is a more serious or significant vulnerability is that an attacker can post an attack once and can potentially affect a large number of users without having to resort to social engineering. The attacker also doesn't need to use the Web application itself to exploit this vulnerability. Any data received by the Web application by other means, including e-mail, system logs, etc.. is capable of exploiting these vulnerabilities.

• This cross-site scripting vulnerability is one that is focused on the DOM (Document Object Model ).When JavaScript is executed. the browser sends several objects that represent the DOM hack to JavaScript.
• The document object contains multiple other objects, all populated from the browsers point of view — which is important to remember.
• Basically, this type of XSS modifies the DOM itself to take advantage of any Web pages that then use the DOM information.

• An example of this would be the document.URL that contains the URL the browser navigated to, not the URI extracted from the HTML body.
• This means that if a hyperlink is sent that contains scripting as part of the URL, and the page referenced uses that document.URL value in a dynamic page, the script embedded in the URL is executed.
• Some DOM objects that are at risk:
  • Document.URL
  • Document.URLEncoded
  • Document location (and many of its properties)
  • Document.referrer
  • Window.location (and many of its properties)

• Nonpersistent or Reflected Exploit:
  • Here, the attacker discovers a Web site that has an XSS vulnerability by entering a string such as “<test>” to see if the string is reflected back with the greater-than and less-than symbols unencoded.
  • Once XSS vulnerability is found, the attacker crafts a URL that Will exploit the vulnerability, and he sends the crafted URL to another user of the site, generally as a spoofed e-mail.
  • When the potential victim visits the site using the link contained in the e-mail, the malicious script contained in the crafted URL is executed by the potential victim's browser as if it came from the Web site with the XSS vulnerability. The script steals whatever sensitive information It can and sends the data to the attacker.
• Persistent or Stored Exploit
  • This attack also requires that the attacker discover a Web site allowing users to post information for retrieval by other users in something other than plaintext (i.e., HTML-encoded, etc.). For HTML encoding of messages to be available, the browser reading the post or data has to process the HTML.
  • The attacker can also test this by posting data to this Web site, using a test string to see if the user input is filtered or otherwise encoded.
  • Once the attacker finds that the site has an exploitable XSS vulnerability the attacker posts a message designed to attract the maximum that possible (so it's generally controversial or even obnoxious), and in message is embedded the code to exploit XSS vulnerability.
  • Now, whenever the posted message is viewed, the session cookies other credentials are sent to the attacker's Web server.
• DOM-Based or Local
  • Here, the attacker must know of a Web site with a page that uses part of the DOM not wholly under the control of the server-side page.
  • Once the attacker finds a page that parses the URL, or similarly uses information in the DOM to provide data for client-side logic, the attacker can craft a URL to take advantage of that vulnerability and e-mail or otherwise distribute the URL to potential victims.
  • When the potential victim receives the link and clicks on it, the malicious code is exploited; the vulnerable Web page is returned from the server and may now run a variety of commands with whatever privileges the user has on the computer it is running on.

• In December 2004, a vulnerability was reported in Bugzilla' (The Mozilla Foundation, California) where, if an internal error was encountered, an error page used JavaScript to write the URL (using document.location) to the Web page without filtering or encoding it. This would allow someone to force an error and inject JavaScript code.
• The fix for this was to encode the special characters in the document.location string before it is written to the page. More details and some sample codes are available at https://bugzillamozilla.org/show_bug.cgi?id=272620.

• In June 2006, PayPal6 (EBay, Inc., San Jose, California) was hit by a complex attack that used a combination of an e-mail phishing that asked the users to click on a link leading to a URL on the real PayPal Web site. The link to this URL utilized cross-site scripting to present the users with some text informing them that their account is disabled because of suspicions that it had been compromised and that they would be redirected to a resolution center. Then the users were indeed redirected but to a trap site in South Korea.
• This trap site was basically a phishing site. The users were asked for their PayPal login details, and even more sensitive information such as Social Security number, bank account numbers, etc.
• One of the most interesting facts about this attack is that on the initial PayPal page the user is directed to is an SSL page; the valid 256-bit SS certificate to confirm it belongs to PayPal. By the time users are actually redirected to the fake PayPal phishing site, they may be off guard because they've already done what they have been taught: They think they have verified that the original page is HTTPS, complete with its little lock ion and a security certificate.

• In October 2001, a security researcher, Marc Slemko, conducted some investigations into the integrated Passport'“ (Microsoft Corporation. Redmond, Washington) system and its component services and brought one vulnerability to light: using Hotmail's HTML filtering and cross-site scripting can expose the user's Passport data.
• In this case, an e-mail was sent to a Hotmail user that included a tag, starting with “<_img.” Hotmail thinks this is the start of an Fine tag and treats the information inside as attributes but Internet Explorer (IE) doesn’t recognize any tag starting with an invalid character, so it just continue as if the tag isn't there.
• Part of the problem is that IE is performing what is called a “white list” check for the tag. If the tag is not specifically considered to be invalid, then it is invalid by default. Hotmail, however, is performing what is checked . a 'black list“ check. If the tag is not specifically considered to be invalid then it is valid by default.
• This Hotmail issue is merely an easy way to got around the necessarily of sending some social engineering e-mails to get the user to click on the link— it's not actually a required part of the vulnerability demonstration.
• We recall that since the user is doing this through a Hotmail account, passport has already been logged into and a Passport cookie has been issued.
• Once the HTML exploit pages is loaded, its opens two frames, one of these connect to a page in the passport’s secure path to enable the attacker to steal passport cookie.
• The second frame exploit an XSS vulnerability in Passport: if you are already logged in, a page is returned including the unencoded passed in information — in this case- executed by JavaScript on the attacker's server. This JavaScript then proceeds to capture the user‘s Passport cookie and sends the cookie off to CGI script that captures them.

• The first incident of an XSS worm occurred in late 2005 when a MySpace(MySpace, Inc.) user figured out a way to increase his friend's list by first creating a script in his user profile that overcame the MySpace restriction against JavaScript. It achieved this by splitting it between two lines and then placing this script code within a cascading style sheet, exposing a leniency in IE.
• Then, the attacker used a JavaScript object to load a MySpace URL that would automatically invite the attacker as a friend, and later as a “hero,” into the visitor's own profile.
• Next, he turned around and embedded this script into each of his visitor's profiles, so that the code continued to propagate to anyone who viewed their profiles.
• By 9:30 that night, there were over 1 million requests, and less than an hour later the entire MySpace site had to be taken offline while the worm was removed from all user profiles.

• One of the difficulties in testing cross-site scripting is that the more advanced efforts often involve encoding some of the telltale signs of cross site scripting exploits in any one of a number of formats.
• Following table gives examples of texts that can represent the <script> tag in HTML.
• If your application accepts UTF-8 characters, this becomes even more complex because you have multiple ways to encode each character. If this is the case for your application, it's a strong argument for deleting characters that are not explicitly safe and allowable.

• A valuable exercise you can do before actually starting the test is to ask several questions about every field in your product:
  • Does this field have a limited set of expected input?
  • Is there filtering or error checking in place to enforce that only input that meets the requirements of the field is passed through?
  • If your product accepts UTF-8 characters, is there filtering in place to delete all characters not explicitly safe?
• There may be reasons that input cannot be as severely filtered as you might wish, but the fields should all be filtered as closely as possible without impairing necessary functionality.
• In addition, there is a set of minimum characters that should always he encoded into their literal, printable equivalents. If this is done. any script code that makes it into the system can't be output again unless it's converted to safe formatting. This list is shown in following table.

• The best way to start testing for cross-site vulnerabilities is to test every input field you can find with a simple test script:
  • <script>alert('XSS Vulnerability Found')</script>
  • <img xsstest=javascript:alert('XSS Vulnerability Found')>
  • &(alert('XSS Vulnerability Found'));
• If the message box displays “XSS Vulnerability Found,” the input field you are testing has an XSS vulnerability. If it doesn't display the phrase but the HTML page retuned displays incorrectly, the component may still be vulnerable and should be further tested.

• Now for each visible variable, submit the following string:

11; ! —”<XSS_Check>=&{()} On the page that is returned, search for the string “<XSS_Check>.”

• If you can find that test string in the retuned page, it's likely that the component has an XSS vulnerability.
• If it's displayed literally (including the greater than or less than characters at any point), there is a definite XSS vulnerability.
• If only the phrase “XSS_Check” is displayed but the greater-than and less-than symbols have been stripped away completely, the component is not vulnerable.
• If there was some encoding done and you see something such as “&lt;XSS_Check&gt;” then a vulnerability may still exist.

• Now examine the other characters that were input around the test string to see what characters are filtered or encoded. This will indicate if the component may still be vulnerable.
• Carefully examine the returned HTML page to see if you can identify what string an attacker could use to break out of the HTML code or sequence surrounding the test string. If these codes exist in an unfiltered form in the previous step it is very likely that the component is vulnerable.

• The steps for black-box testing are still needed. but if you are doing white-box testing , you can follow the input string through the code to see wherever it may be used or returned to the client browser.
• Some of these places may not be obvious or may be difficult to find with black box testing, especially pages that are not pan of the well-known normal code path. This includes error pages, and the like.
• There are two other tests that should he done if you are conducting white-box testing:
  • Hidden Fields
    • Repeat the set of black-box tests on every hidden field, the ones that are not normally editable. This may require the use of automation, a custom tool, or one of the proxy servers available commercially. You need to be able to edit HTTP requests between client and server.
  • GET Versus POST
    • If particular components are submitting data via an HTTP GET request try turning the submission into an HTTP POST request for any components if the results of the prior testing indicate the possibility of an XSS vulnerability.

• https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29