Results 1 to 2 of 2

Thread: Stored Cross Site Scripting

  1. #1
    Junior Admin UkCvs Senior Member
    Join Date
    Aug 2013
    Thanked 32 Times in 16 Posts

    Default Stored Cross Site Scripting

    All my posts on this forum are reposts from my blog.

    In 2014, Twitter had a self*retweeting*tweet. That should never have happened but a developer of TweetDeck forgot basic web security and didn't even try to filter cross site scripting(XSS). Even 5 years later, in 2019, XSS is just as severe and still worryingly common. XSS is unusual in that it attacks the client but the vulnerability is in the server, it's a very simple vulnerability too, forgetting to sanitise angle brackets and quotes leads to XSS. Web Browsers are designed to take almost any crap and turn it into a properly formatted web page, this is great for web developers but it means when a script tag turns up in the middle of a web page, the web browser doesn't question it and runs the code. There's 3 types of XSS, stored, reflected and DOM-based, I'll explain stored XSS in this post.

    The Damn Vulnerable Web App(DVWA) is used to practice exploiting web app vulnerabilities, although for obvious reasons, you have to host it yourself.

    DVWA shows this vulnerability by a basic guestbook application, the user enters a name and a message and it will be publicly displayed.

    Low Security

    On low security, DVWA has no protection against XSS, any input will be accepted and stored. The only protection on low security is the name field being limited to 10 characters which means there is very little opportunity for XSS, however, this limit is client side so it can be easily bypassed but I'll come back to that later.

    XSS is most commonly done by including script tags in an input. If we submit the following comment:

    You would expect the user to see exactly that message but when a web browser processes the web page, the message hasn't been sanitised so it reads it as , it reads that message as javascript. That means that when we load the web page to view our new message, we see this popup:

    Medium Security

    This time, DVWA has a bit of protection against XSS. If the same message used for low security is sent again, the message ends up like this:

    This means that DVWA is removing all html tags from the input and escaping quotes. This stops the web browser from thinking the code is javascript so it will not be run.

    DVWA escapes script tags in the message but does it escape them in the name? Well, it turns out the input for name is limited to 10 characters which means it's difficult to write any javascript in there because just the script tages take up 15 characters. Fortunately, this limit is client side so we can remove it using inspect element.

    Changing the maxlength attribute to 100 is more than enough to include an XSS attack in the name.

    When this message is submitted, you would expect it to function exactly the same as last time. However, the comment is shown like this:

    This means the developer is removing script tags from the name input. The script tags have been removed instead of being sanitised, this means the developer is likely using a find and replace to remove the script tags. Assuming it is just a simple find and replace, doing something to make the input unique will avoid it. In this case, changing the case of some letters will avoid the find and replace.

    When this message is submitted, it will bypass the XSS filter because it is only looking for <script> and not <Script>. This happens because web browsers are made to process any bad input so whilst the script tag should be lowercase, it will still accept one with upper case however the find replace is only looking for lower case script tags.

    When the website loads, we see the message box which proves the XSS has worked.

    High Security

  2. #2
    Junior Admin UkCvs Senior Member
    Join Date
    Aug 2013
    Thanked 32 Times in 16 Posts


    On high security, this is much harder to exploit. Using similar input to medium security gives an unexpected result.

    Whilst its obviously not XSS, it isn't anywhere near what a good XSS filter would show. Because its left one angle bracket at the end, it appears to be removing instances of the word script and everything between them. If we can include html, we can include XSS even if it's not using script tags. The following input is simply a test to see if html can be included:

    My name is in bold here which means the html has been included, this means it is possible to include XSS. Luckily, javascript can be included in other html elements, its usually used to call a function when something is clicked, loaded or any other event occurs. To get around this filter, there are loads of different XSS vectors that can be used but I will use an invalid img tag and put javascript in the onerror attribute.

    When this is loaded by the browser, it will try and fail to load an image from x causing it to run the javascript code in onerror.

    When the page loads, the name appears as an invalid image and a popup appears which proves that XSS happened.

    Mitigating XSS

    XSS can be mitigated by proper input sanitising. This can be done manually by, for example using htmlspecialchars after stripslashes in php(this is DVWA's impossible level - it is completely secure), however, there are lots of ways it can go wrong depending on the context of the input so it is recommended to use an encoding library such as Zend Escaper to prevent XSS. If you still want to try and prevent it manually, OWASP provide a set of rules to follow to filter XSS.

    In the next few days and weeks, I'll write more posts explaining more common vulnerabilities and I might start explaining how to use common tools like nmap, etc.

  3. The Following User Says Thank You to david For This Useful Post:

    Renwich (23-01-2019)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts