Cross Site Scripting


Cross Site Scripting is a popular attack technique on the Internet in which malicious code is executed either on the server side or client side, in order to steal sensitive data or digital identities. Together with SQL injections, cross-site scripting also called XSS or even general HTML injections, it constitutes the most commonly used attack technique on web applications and websites. [1]

General information

Cross Site Scripting attacks presuppose that

a) a hacker or attacker sends a modified hyperlink to a recipient (user or server)

b) The recipient opens it by clicking it or processes it because it is not verified

c) The browser of the recipient has Javascript enabled (other scripting languages are usable as well)

d) Or the server on which the recipient originally wanted to surf uses web applications that issue dynamic websites and the data doesn’t get checked.

A cross-site scripting attack takes place in the course of accessing websites. If a user visits a website to enter login information, the browser sends a form with data to the server. The server grants access to the website, if the data is correct. A cross-site scripting attack takes place exactly between the these two websites and the sites don’t have to be different sites with different URLs, rather, the attack technique is used for dynamically generated sites to get between client and server while data is being entered. Answers from the server get imitated to send the data entered by the user to an address, which the attacker determines.

This is done by running scripts that the attacker has interposed. These scripts use parameters such as GET, POST and (document.cookie) to subvert communication between client and server. Both in the markup language HTML and in the PHP programming language such methods are supported. Since millions of sites use these languages, XSS attacks are effective means to gain access to user data.

Features

Cross Site Scripting is divided into three types of attacks: [2]

1.) Persistent: With persistent XSS attacks, malicious code remains on the display and the user is not necessarily identifiable. In forums, communities or guestbooks of sites, malicious code is unfiltered and presented in the form of links since such sites often check your entries. A persistent XSS attack can take place in the cache of a web application or in a connected database of such websites. Persistent attacks are always on the server side and have large potential risk.

2.) Non-persistent: Here, the user is sent a manipulated link. Once the link is clicked, the malicious code will launch and run a script. Often fake emails from attackers are sent to prompt users to interact. Attackers mimic forms and websites and insert a script to reach session cookies with user data. The risk potential associated with non-persistent XSS attacks is relatively low, because they require a high degree of user interaction. They are always on the client side and are usually used in conjunction with dynamic websites.

3.) Local: In this case, the malicious code will be sent directly to a client to execute it, for example, in the browser. A local XSS attack is always directly executable malicious code that does not depend on a vulnerability in the server-client communication. Rather, it is a direct attack in the form of a script that asks certain information, such as URL arguments or script tags. After the interrogation, the malicious code runs in the background without the user’s knowledge. Local XSS attacks aim to attack static HTML pages but they are also dependent on a user who clicks on a malicious link.

Countermeasures to Cross Site Scripting

Both users and webmasters can adopt protective measures. Users can use, for example, the NoScript add-on, which prohibits the execution of scripts. Even disabling JavaScript is possible. However, other scripting languages will then be used, such as VBScript, PHP and Pearl scripts. It is especially important for users to be skeptical when encountering hyperlinks in emails, messages or forums, because XSS attacks pretend to be an official website. With the right amount of skepticism, such risks can be excluded from the outset. For webmasters and hosts, it is crucial that the programming of the source code, especially of data format, is done correctly and in a secure way. Any form data should be checked for correctness in terms of characters, encoding and completeness. White lists which define what data is allowed are considered best practice. Large projects also accumulate a lot of data. Therefore, actions that convert certain characters from scripts are recommended. This avoids executable meta scripts being read by the server or client. The rewriting of characters is possible in any programming language by either replacing or masking them. A final, but unsafe action is using WAFs: Web Application Firewalls are designed to protect the special web applications against unauthorized access by a firewall.

Importance to search engine optimization

Cross Site Scripting is also used in the field of search engine optimization. A website is hacked to place backlinks on it that point to a domain to be strengthened. Cross site scripting is a known black-hat method, which exploits the vulnerabilities of servers and clients in order to embed links that webmaster of the affected website are not supposed to know about. Google and other search engines punish such links because they are regarded as manual, unnatural measures. Search engines often cannot find where these links originated from or how they came to the site.[3] In order to prevent cross-site scripting effectively, the webmaster has to take various measures which have been described above.

References

  1. Cross Site Scripting Attack. acunetix.com. Accessed on 05/26/2014.
  2. Cross Site Scripting: Documentation, Analysis & Techniques. vulnerability-lab.com. Accessed on 05/26/2014.
  3. Search Engine Optimization Companies: Break Google's Rules to Get Top Rankings? searchenginewatch.com. Accessed on 05/26/2014.

Weblinks