Insights
-2.png)
Stored XSS and reflected XSS cause a lot of problems for corporations today. Let’s take a look at the two and their differences.
What is Stored Cross Site Scripting (XSS)?
Stored XSS, also known as persistent XSS, occurs when a malicious script injection is permanently stored on a target’s server. The code that will be maliciously injected into a user’s session resides on the webserver and waits for the user to visit. When a user requests non-sanitized information that is stored in the database, the application can then send the malicious script to the user. Bad actors execute stored XSS by leaving the payloads in message forums, site posts, and comment fields.
Due to a previous XSS vulnerability in Twitter’s TweetDeck client, an attacker retweeted a malicious post over 80,000 times. When a user logged into TweetDeck and viewed the XSS-injected tweet, the JavaScript code executed. It then hijacked the viewer’s TweetDeck account and performed the “retweet” action to propagate the attack. If Twitter verified the sanitization of user inputs, the stored XSS attack would not have happened.
Reflected XSS
Reflected XSS is the more common variety of cross-site scripting. This type of XSS occurs when a web application accepts input from a user and then immediately renders that data back to the user in an unsafe way.
A reflected XSS attack occurs when a malicious injection affects a user directly. Yet the malicious script is not on the webserver the user attempted to reach.
Example of a vulnerable site:
https://target-site.com/status?message=this+is+insecure
<p>Status: this is insecure</p>
The site above accepts the user’s input data and renders it immediately. Therefore a bad actor could construct a more malicious attack:
Attack example:
<a href=”https://target-site.com/status?message=<script>/*+malicious+content+here…+*/https://target-site.com/status?message=<script>/*+malicious+content+here…+*/</script>
<p>Status: <script>/* malicious content here… */</script></p>
If an authorized user visits the URL above, then the bad actor’s malicious script executes in the user’s browser. At that point, the script can carry out any action authorized by the user’s permission level within the application.
Web applications vulnerable to reflected XSS can unsafely display search results, error messages, or any other immediate response from a user’s query. To execute reflected XSS attacks, bad actors need an external delivery mechanism. In other words that means these can be message forums, email, or text messages, that deliver the malicious injected link. While the payload may not be immediately apparent in a URL. Bad actors can use shortened URLs to conceal the injected code.
Attack against Vatican City’s website
Due to a previously discovered security hole in Vatican City’s official website, anyone with knowledge of performing a reflected XSS attack could post on the site. Upon discovering the vulnerability, a bad actor published a post with the title, “The Lord is an Onion.” That is to say that they sent out an embedded link with the XSS code. Anyone who clicked on it could view the Vatican News page and see the fabricated post. This attack shows how malicious scripts are a source of false information through reflected XSS.
Stored vs. Reflected Cross Site Scripting
Stored XSS vulnerabilities support self-contained attacks within a target application. Reflected XSS vulnerabilities support malicious inputs that are instantly reflected back to the user.
A user will encounter Reflected XSS payloads in their email system through phishing emails. Or they will also find them in social media posts or a few other ways.
Stored XSS attacks affect the web application that delivers content to its users. Reflected XSS affects the individual who clicks on the maliciously injected link, which renders an unsafe content response on a target website. Because stored XSS affects anyone who interacts with the web application directly, any authenticated users can quickly experience account takeover, as exemplified in the TweetDeck attack. As opposed to reflected XSS, where attackers play a waiting game since they need the user to click on the malicious link to then reflect the malicious request off of the web application.
While both stored and reflected XSS attacks display unsafe content and exploit their victims in many ways. Although reflected XSS attacks are more prevalent due to the ease of execution. Stored XSS attacks are more challenging to carry out. The bad actor must find a highly viewed site and taking advantage of a vulnerability that enables the permanent embedding of a malicious script.
Contact us to learn more about how our crowdsourced security platform can help you safeguard your rapidly growing business from malicious threats and vulnerabilities.
Share this post
Insights
