How to prevent XSS/cross-site scripting

In order to demon­strate what cross-site scripting means for website operators and visitors, here is a short list and ex­plan­a­tion of the different types of XSS:

Reflected cross-site scripting/XSS

The harmful script is sent to the web server when a ma­nip­u­lated 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 tem­por­ar­ily when the website is created by the affected client. Favoured targets are dynamic websites or e-mail ap­plic­a­tions.

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, prefer­ably 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 de­term­ined earlier.

Per­sist­ent cross-site scripting/XSS

Per­sist­ent or constant XSS is when the harmful scripts are saved on the web server and delivered through a client with every in­form­a­tion request. For the attacks, web ap­plic­a­tions are chosen that save user data on the server and dis­trib­ute it without veri­fic­a­tion or coding. Blogs and forums are es­pe­cially sus­cept­ible to these types of scripting.

Example: Forum posts are saved in a database – often without being checked properly. Attackers can take advantage of this op­por­tun­ity and add their harmful script to a normal forum post. Users receive the re­spect­ive post’s link in an e-mail or co­in­cid­ent­ally come across the post and un­know­ingly activate the script by clicking on the link.

The negative con­sequences of cross-site scripting for website users and operators are not to be un­der­es­tim­ated. Users risk losing their data or in­ad­vert­ently acting as an ac­com­plice to the attacker. As a website owner, you’re re­spons­ible for your customers’ data and can be directly affected by an attack. Harmful content and server crashes reduce visitor numbers and can lead to pen­al­isa­tion 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 def­in­itely introduce measures to prevent cross-site scripting.

Safety pre­cau­tions for internet users

The simplest way to prevent cross-site scripting from the client is to disable JavaS­cript support in the browser. If JavaS­cript is de­ac­tiv­ated, the DOM based XSS, which targets JavaS­cript, doesn’t have any effect since the harmful ap­plic­a­tion 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. JavaS­cript, Java-Applet, Adobe Flash or Microsoft Sil­ver­light are auto­mat­ic­ally disabled. You can tem­por­ar­ily 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 scru­tin­ise it carefully before clicking.

What should a website operator do to prevent XSS attacks?

To ensure that your web ap­plic­a­tion isn’t vul­ner­able 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 ap­pro­pri­ately. 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 pro­tec­tion 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 metachar­ac­ters to be replaced by ap­pro­pri­ate character ref­er­ences. As a result, the metadata is clas­si­fied as normal char­ac­ters and po­ten­tially in­filt­rated scripts cannot start. Most pro­gram­ming and scripting languages such as Perl, JavaS­cript, or PHP already possess pre­defined features for character re­place­ment or masking, which they can promptly use. Fur­ther­more, you can fend off simple XSS attacks by using a web ap­plic­a­tion firewall.

Cross-site scripting often set the gears in motion for more serious attacks. You can thwart their attempts with extensive pro­tec­tion of your web server’s inward and outward data streams.