Skip to main content

Cross Site Scripting

The Cross Site Scripting (XXS) is a popular attack technique on the Internet in which malicious code is executed on both the server and client sides, in order to steal sensitive data or digital identities. Along with SQL injections, cross-site scripting also called XSS or even general HTML injections, constitutes the most used attack technique in apps and websites.[1]

General information

Cross Site Scripting attacks assume that

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

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

c) The recipient's browser has JavaScript enabled (other scripting languages are also usable).

d) Or, the server on which the recipient wanted to browse uses web apps that serve dynamic websites and the data is not verified.

A Cross Site Scriptings attack takes place when a website is accessed. 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 web portal, if the data is correct. A cross site scripting attack takes place precisely between these two websites and they do not have to be different sites with different URLs. Rather, the XXS technique is used so that dynamically generated sites stand between client and server while data is entered. The responses from the server are mimicked 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 like GET, POST, and (document.cookie) to subvert the communication between the client and the server. Both the HTML markup language and the PHP programming language support these methods. Since millions of sites use these languages, XSS attacks are effective means of accessing user data.


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

1.) Persistent: With persistent XSS attacks, the malicious code remains on the screen and the user is not necessarily identifiable. In forums, communities or web guestbooks, malicious code is not filtered and is presented in the form of links, since these webs usually check your entries. A persistent XSS attack can take place in the cache of a web application or in a connected database of those websites. Persistent attacks always they are on the server side and have a great potential risk.

2.) Non-persistent: Here, the user receives a manipulated link. Once the link is clicked, the malicious code will launch and run a script. Often times, fake emails from attackers are sent to entice 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, as they require a high degree of user interaction. They are always on the client side and are normally used in conjunction with dynamic websites.

3.) Local: In this circumstance, the malicious code will be sent directly to a client to be executed, 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 for certain information, such as URL fundamentals or script tags. After interrogation, the malicious code runs in the background without the user's knowledge. Local XSS attacks aim to attack static HTML pages, but also rely on a user clicking on a malicious link.

Countermeasures to Cross Site Scripting

Both users and webmasters can adopt protective measures. Users can use, for example, the NoScript plugin, which prohibits the execution of scripts. It is even feasible to disable JavaScript. However, other programming languages will be used, such as VBScript, PHP, and Pearl. It is especially important that users are skeptical when finding 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 start. For webmasters and hosts, it is crucial that the programming of the source code, especially the data format, is done correctly and safely. All data on the form must be verified to verify its accuracy in terms of characters, encoding and integrity. White lists that define what data is allowed are considered best practice. Large projects also accumulate a lot of data. Thus, actions that convert certain script characters are recommended. This prevents executable meta scripts from being read by the server or client. Rewriting characters is feasible in any programming language by substituting or masking them. A final but insecure action is the use of WAFs: Web app firewalls are designed to protect special web apps against unauthorized access by a firewall.

Importance for SEO

Cross Site Scripting is also used in the field of SEO. A web portal is hacked to place backlinks on it that point to a domain to be strengthened. Cross site scripting is a well-known "black-hat" method, which exploits vulnerabilities in servers and clients to embed links that the webmaster of the affected web portal should not be aware of. Google and other search engines punish these links because they are considered manual and unnatural measures. Search engines usually cannot find where these links originated or how they got to the site.[3] To effectively prevent cross-site scripting, the webmaster has to take the measures described above.

Web Links