How to prevent XSS/cross-site scripting
Cross-site scripting (shortened to XSS), denotes the exploitation of security gaps in web applications. Harmful scripts are injected into a trusted context where they can then attack the user’s system. Scripts are programs in scripting languages such as JavaScript that are executed in the internet browser. An example of a fairly harmless variant could be a ‘welcome’ pop-up. But in worst case scenarios, attackers can gain access to confidential information or are able to access the unsuspecting user’s computer.
The danger of cross-site scripting arises when the respective web application passes user data onto the web browser without verifying it. This is how harmful scripts reach the affected clients. Once there, the infiltrated applications manipulate the server-side scripts, such as user registration forms. From the user’s point of view, the registration process looks encrypted and anonymous, but in actual fact, the data is being forwarded without being filtered.
Not all XSS attacks aim to steal sensitive data or directly harm the affected client. Just as prevalent are scripts that use the client as the initiator of phishing and malware attacks or change the content of a website in a negative way. The actual perpetrators usually stay anonymous.
Cross-site scripting examples: what types of XSS attacks are there?
In order to demonstrate what cross-site scripting means for website operators and visitors, here is a short list and explanation of the different types of XSS:
Reflected cross-site scripting/XSS
The harmful script is sent to the web server when a manipulated URL is called up or a prepared form is sent. The script is then sent back to the client without being verified. The malicious code isn’t saved on the server and only exists temporarily when the website is created by the affected client. Favoured targets are dynamic websites or e-mail applications.
Example: With this type of XSS variant, the attacker places their script in a prepared link. When connected, the attacker tries to forward the link, preferably via e-mail. The received malicious code is only activated when the user opens the received link. When this happens, the user receives a log-in screen identical to that of their online bank. Instead of the entered data being sent to the bank, the script makes sure that it takes a detour to the address that the attacker determined earlier.
Persistent cross-site scripting/XSS
Persistent or constant XSS is when the harmful scripts are saved on the web server and delivered through a client with every information request. For the attacks, web applications are chosen that save user data on the server and distribute it without verification or coding. Blogs and forums are especially susceptible to these types of scripting.
Example: Forum posts are saved in a database – often without being checked properly. Attackers can take advantage of this opportunity and add their harmful script to a normal forum post. Users receive the respective post’s link in an e-mail or coincidentally come across the post and unknowingly activate the script by clicking on the link.
DOM based cross-site scripting/XSS
This type of attack is also known as local XSS. When a manipulated URL is called up, the malicious code is executed via a hole in the client-side script without verification. On the contrary to persistent and reflected XSS, the web server is not involved in the process. Static websites, which support this particular script language, are also at risk from this type of scripting.
Example: The DOM based XSS (just like the reflected cross-site scripting) requires the user to open a link. After the link has been opened, the script reads the argument value of the URL on the website and executes the received script code. This could lead to session cookies being stolen, for example.
How to protect yourself against XSS attacks
The negative consequences of cross-site scripting for website users and operators are not to be underestimated. Users risk losing their data or inadvertently acting as an accomplice to the attacker. As a website owner, you’re responsible for your customers’ data and can be directly affected by an attack. Harmful content and server crashes reduce visitor numbers and can lead to penalisation by search engines like Google, as well as losing trust from potential customers. This can lead to financial losses. Therefore, as a website operator, you should definitely introduce measures to prevent cross-site scripting.
Safety precautions for internet users
The simplest way to prevent cross-site scripting from the client is to disable JavaScript support in the browser. If JavaScript is deactivated, the DOM based XSS, which targets JavaScript, doesn’t have any effect since the harmful application cannot even be started. Some browsers can use add-ons that protect against XSS attacks; for example, Mozilla Firefox has the NoScript extension. In the standard settings all active website content e.g. JavaScript, Java-Applet, Adobe Flash or Microsoft Silverlight are automatically disabled. You can temporarily remove the blockage or place the website on a whitelist if you're sure that this site can be trusted. One last tip that you should always follow, and not just when regarding the dangers of cross-site scripting, is to always be wary of external data and scrutinise it carefully before clicking.
What should a website operator do to prevent XSS attacks?
To ensure that your web application isn’t vulnerable to XSS attacks, you must view all received input values as being unsafe. Before they are received by the web server they should be verified appropriately. The most secure method is to create a whitelist, just like the NoScript extension for clients. As long as the capacity allows it, you should scan the inputs on your website and only trusted content should be allowed. This way you create excellent protection against cross-site scripting.
In addition to the input data, the data output should also be protected. For this reason, it’s necessary for the HTML metacharacters to be replaced by appropriate character references. As a result, the metadata is classified as normal characters and potentially infiltrated scripts cannot start. Most programming and scripting languages such as Perl, JavaScript, or PHP already possess predefined features for character replacement or masking, which they can promptly use. Furthermore, you can fend off simple XSS attacks by using a web application firewall.
Cross-site scripting often set the gears in motion for more serious attacks. You can thwart their attempts with extensive protection of your web server’s inward and outward data streams.
Want to make your website more secure? Learn more about SSL certificates from IONOS and how they increase your site’s trustworthiness.