Many only know internet identity theft and similar crimes from movies or television. But stories of online fraudsters are not just merely screenwriters’ fantasies; for many the experience is all too real. Online identity theft has become more and more of a problem over the past few years, and everyone is a potential victim. We have compiled some preventative steps than can help you stay out of the...
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
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.
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.