Persistent Cross-Site Scripting

Persistent XSS (or Stored XSS) attack is one of the three major categories of XSS attacks, the others being Non-Persistent (or Reflected) XSS and DOM-based XSS.  In general, XSS attacks are based on the victim’s trust in a legitimate, but vulnerable, website or web application. XSS vulnerabilities are the most common type of input validation vulnerabilities, according to Context Information Security report “Web application vulnerability statistics 2013”. The Persistent XSS condition is met when a website or web application stores user input, serves it back to other users when retrieving it at a later stage without validation before storage or before embedding stored content into HTML response pages.

Hence, malicious code is inputted by attackers into vulnerable web pages and is then stored on the web server for later use. The payload may be served back to other users browsing web pages and is executed in their context, at a later stage. Thus, the victims do not need to click on a malicious link in order to run the payload (as in the case of Non-Persistent XSS); they simply have to visit the vulnerable web page, serving back un-sanitized user input from other web sessions.

Persistent XSS is less frequent than Non-Persistent XSS, as the vulnerabilities which make it possible are less common and more difficult to find. On the other hand, the damage that Persistent XSS can do is more devastating than the damage done by Non-Persistent XSS – because once the payload is stored, it has the potential of infecting most of the visitors of the vulnerable web page. Persistent XSS is also referred to as Type 2 XSS because the attack is carried out via two requests: one for injecting malicious code and having it stored on the web server, and the other for when victims load HTML pages containing the payload.

Description of Persistent / Stored Cross-site Scripting

As is with most web-based attacks, exploiting Stored XSS vulnerabilities requires some research. Usually attackers search vulnerable websites that can be used to carry out an attack. There are some types of websites which are prone to such vulnerabilities because they allow content sharing between users, and consequently they constitute the starting points of research in this respect:

  • Forums / message boards
  • Blogging websites
  • Social networks
  • Web-based collaboration tools
  • Web-based CRM/ERP systems
  • Web-based email server consoles and web-based email clients

Once a website is identified as being potentially vulnerable, attackers will try to inject script code into data that is going to be stored on the server. Then, they will access the web pages that are serving back the content they have posted and test if the script executes.

The malicious code itself is usually delivered manually by the attacker in input fields on the vulnerable web pages, but there are cases where attackers build tools that regularly inject scripts automatically.

Unlike Non-Persistent XSS, Persistent XSS does not require a social engineering phase, as victims of this attack do not need to be lured into clicking on a crafted link. However when exploiting Persistent XSS vulnerabilities, attackers will try to get more and more victims to visit the vulnerable web page so they will most probably still send SPAM messages or promote it on social networking websites.

Examples of Stored XSS

Forums / message boards

Once a forum is identified as vulnerable, attackers may open a new topic and insert malicious scripts in the topic title or body. They can also tag the topic using popular keywords so that the topic is a popular search result. The content of the forum post will be stored by the server. When the victims browse topics or search for certain keywords, they may reach the infected topic. When the topic loads, its contents will be sent to the victim’s browser and the payload may be executed. Alternatively, attackers may build tools that automatically post malicious scripts in replies on popular / sticky topics, send private messages containing the payload to forum members, etc.

Example of Stored XSS in a Forum (click to enlarge)

Social networks

Social networking websites allow users to build a profile that contains private information. Attackers can inject JavaScript code into either of these fields. This information gets stored on the server and when the victims access this malicious profile, the payloads will be delivered to their browser and eventually get executed.

Consequences

The consequences are vast, because the attack enables execution of arbitrary code, usually with elevated privileges – most home users still use the default “administrator” account and although latest Windows operating systems come with user access control and hardened browser policies, they are usually disabled in order to improve on the user experience.

Typical goals of Persistent XSS attacks:

  • Cookie theft
  • Data theft

Defending Against Persistent / Stored XSS

a) Server-side

The best way to prevent Persistent XSS is to make sure that all user input is properly sanitized before it gets stored permanently on the web server, and as a second line of defense, make sure that the static content presented to users is also sanitized. As malicious scripts can be encoded in various ways, sanitization parsers should take encoding into consideration, as well as various ways to inject code, when searching for payloads in the content to be stored / served back.

Web applications can be kept XSS-free by conducting assessment tests on a regular basis using a web vulnerability scanner that detects cross-site scripting vulnerabilities while providing you with details on how to fix them.

b) Client-side

Users cannot take any particular actions in order to prevent such an attack, other than disabling JavaScript within their browser (disabling JavaScript is not seen as an adequate solution since several websites require it to function properly). Victims simply need to visit a vulnerable web page. Most victims of Persistent XSS attacks would be regular users of the vulnerable website, making it nearly impossible for them to prevent the attack from happening just by being weary about what they do within their browser. The only thing that can help in this case is using secure and up to date web browsers, with XSS filters turned on and hope for the best.

Share this post
  • What’s up colleagues, its great piece of writing on the topic of teachingand fully defined, keep itt upp all the time.

  • Leave a Reply

    Your email address will not be published.


    *