Saturday 23 February 2013

Stored XSS in Using Embed

Back in December I came across a stored XSS vulnerability in I was unfortunately too slow in my reporting and was beaten to it by Subho Halder. It was quite funny as he plastered the site with his own swf file to demonstrate the vulnerability.

This is a quick post covering the vulnerability and how it was exploited.


When it comes to sites that allow direct modification of html, the likelihood of XSS can go up massively. In the case of they used a home-grown (or what appeared to be home-grown) comment system for their forum that let you edit the HTML of your comments. Although there were some protections in place to stop you inserting <script>, <object> and <applet> tags, they did allow you to use <img> and <embed>.

Note: For more info on tags and insertion of malicious code I found the following URL really useful:

I first tried <img> based XSS and it worked when previewing the post but when actually posting the onerror was stripped.



Instead of trying to find a filter bypass I decided to take a look at the embed tag.

Our friend the SWF file

Some of you may have read my previous post on SWF analysis where i looked at exploiting an SWF for XSS:

In that post I focused on exploiting a poorly built SWF, however we can just build a malicious SWF that contains a javascript payload. Subho's SWF can be found here:

Using SWFScan to analyse the file its really easy to spot the exploit code he used:

public static function main ()
    var __callResult_20 = getURL("javascript:alert(\"XYSEC TEAM
\"+document.domain)", "_self");

Looking up getURL from the Adobe site:
Loads a document from a specific URL into a window or passes variables to another application at a defined URL.

So we could grab a payload from a remote site or to perform XSS we could use "javascript:" which simply runs javascript locally in the browser in the security context of the current site.

And to deploy our SWF as a stored XSS attack all we need to do is embed our malicious content in a comment:
<embed allowscriptaccess="always" src="" height=1 width=1></embed>

The allowscriptaccess parameter allows our remote script to communicate with the domain in which its embedded and I've used height=1 and width=1 to effectively make it invisible.

Whenever anyone viewed the comment the remote SWF would be loaded and they would be pwned XSS style, sweet!

Final Thoughts

Allowing users to edit HTML on your site can be a risky feature. Script, applet, object, iframe, image and embed tags need to be carefully filtered to prevent abuse. In this case it was a lack of SWF filtering that allowed us to use the embed tag for stored XSS.

Congrats to Subho for reporting this before me, his site can be found here:

Pwndizzle out


  1. You can certainly see your expertise within the article you write. The arena hopes for even more passionate writers like you who aren’t afraid to mention how they believe. All the time go after your heart.

    Birthday Wishes For Friend , Birthday Messages For Wife , Honeymoon Messages , GoodNight Messages for Girl Friend , Graduation Messages , anniversary messages for wife , Wedding Messages

  2. I got so involved in this material.
    This post give me lots of advise it is very useful for me.
    If you face any technical faults with CANON device then visit to Certified technicians are always available at the support desk to help customers.
    With immense http// knowledge and experienced experts, we are able to provide excellent services to our customers.
    Hurry up and contact us for availing of the service.

  3. Hi...
    Stored XSS, also known as persistent XSS, is the more damaging of the two. ... website and one with vulnerabilities that enables permanent script embedding.
    You are also read more Personal Loan Emi Calculator