How to prevent XSS/cross-site scripting and close security gaps

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.

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.