What is cross-site scripting (XSS)?

Cross-site scripting (XSS) is one of the most commonly used attack methods on the Internet. The goal of cross-site scripting is to obtain confidential data, hijack applications, or cause other damage. XSS embeds the attack code in a supposedly secure context.

What is cross-site scripting (XSS)?

The abbreviation XSS stands for Cross Site Scripting and refers to one of the most common attack methods on the Internet. Through a security hole on the client or the server, the attacker manages to embed his malicious code in a supposedly trustworthy environment. XSS can be used to modify websites, take over browsers or steal confidential information such as passwords.

Cross Site Scripting is one of the active attack methods and can be used as a basis for further attacks. The attack method uses scripting languages that are widely used on the Internet, such as JavaScript. XSS can be successful if the web application does not sufficiently check the received data and subsequently processes or passes it on. In this way, scripts can be sent to a web server or to a browser that executes them. Cross site scripting distinguishes three different types of attacks. These are:

• Reflected XSS
• Persistent XSS
• Local XSS

Reflected Cross Site Scripting

Reflected Cross Site Scripting runs server-side. A victim clicks on a crafted URL in which malicious code is inserted. The server takes over this code due to lack of security and generates a dynamically modified web page. The user sees a web page manipulated by the attacker and believes it to be trustworthy. The user’s input can then be forwarded to one of the attacker’s servers, for example.

Reflected Cross Site Scripting can be used very well for phishing attacks. Since the user believes the XSS-modified web pages to be genuine, he or she does not suspect anything and enters confidential credentials, which the attacker receives.

Persistent Cross Site Scripting

In persistent XSS, a vulnerability on the server is also the starting point of the attack. The attacker passes the malicious code to the server by invoking a manipulated link. The server then stores the changes permanently (persistently) in its database. The user himself does not have to call a manipulated link. By modifying the web server’s database, manipulated pages can be displayed to all visitors when the regular link is called.

Attackers often use insufficiently protected forums on the webserver to submit their code. A simple forum entry with the malicious script code can be enough. Subsequently, the manipulated web server can be used to grab user credentials.

Local cross-site scripting

Local XSS does not require a security hole on a web server. The malicious code is sent directly to the user and executed in the browser, for example, without the user noticing. The starting point of the attack is the user clicking on a manipulated link.

Due to the script placed in the browser, static web pages can also be displayed in modified form on the client computer. If the browser has special rights on the computer, it is also possible to modify local data on the device.

A possible attack via local cross-site scripting can proceed as follows. A user is sent a manipulated link by e-mail and clicks on it. By opening the link, the browser integrates a client-side JavaScript that launches the malicious application.

Protective measures against XSS

On the client side, you can protect against local cross-site scripting by prohibiting the browser from executing scripts such as JavaScript. In addition, add-ons are available for browsers that prevent the execution of scripts.

Basically, it is important to critically examine links received via e-mail and not to call them arbitrarily. Webmasters protect their servers from reflected or persistent cross-site scripting by securing the server source code.

All data to be processed by the server must be checked before execution. Whitelists of permitted data can be used for this purpose. General conversion of certain script characters is also a popular method. This prevents executable metacharacters of the scripts from being read by the server.