Quantcast

Ruby on Rails, Io, Lisp, JavaScript, Dynamic Languages, Prototype-based programming and more...

Technoblog reader special: $10 off web hosting by FatCow!

Thursday, June 08, 2006

A JavaScript Based Firewall-Immobilizing Port Scanner

I finally found a totally unacceptable cross-domain Ajax security issue.

After the hotly debated Debunking Strong Misconceptions About Cross-Domain Ajax Security Issues, most current known security issues concerning cross-domain Ajax were explored and found wanting. All but one edge case of cross-domain Ajax that affects corporations with corporate secrets on intranets. I stand by most of my arguments and believe that many web developers still greatly mis-understand the fundamental principals behind Ajax.

However, I was wrong. Very very wrong. There is something you can do with cross-domain Ajax that is deeply and fundamentally insecure. Something nobody could argue against. I was chatting with my friend Dave Fayram (whom I have started doing a podcast with) when we came across a security issue that would affect every single person who has a cross-domain Ajax enabled browser, not just the corporate intranets.

If you are on a Mac, download safariexploit.html as a file onto your hard drive. Now open it up with Safari and prepared to be scared.

Using the fact that the file:/// protocol in Safari allows you to do cross-domain Ajax as much as you like, you can experiment with the potential security concerns of cross-domain Ajax. I was able to build was a JavaScript based Firewall-Immobilizing Port Scanner in 50 lines of JavaScript. Luckily Safari does not allow cross-domain Ajax from the http:// protocol so this is not something that can be taken advantage of throughout the internet (there is no need to switch away from Safari because of this).

What the port scanner is able to do is explore not only your localhost, but your surrounding network. It can look at the 10.0.0.0/24 and 192.168.0.0/24 ranges (as well as any other you specify). It can look at any port you want on any computer you want as long as the local machine can access it. It can even report what version SSH server and web server you are running on all of those computers. It works all in the background without your knowledge while simply viewing a page. At the end of the port scan it posts this data in a public forum that anyone can access.

Nobody can argue that this isn't a Very Bad Thing. Without a white-listing crossdomain.xml file that explicitly lists other sites that are allowed to do cross-domain Ajax communication (an idea that I whole-heartedly believe would change the landscape of the web for the better without the aforementioned otherwise insurmountable security problems), cross-domain Ajax is clearly and fundamentally a very big risk that should remain unimplemented like it stands today.

Many of you might laugh at this conclusion since I was so brazen in my previous post, but if someone would have given me an example half as clear as the one provided here as to why cross-domain Ajax brings up serious security concerns, I would have never had to write that post. The post was intended to straighten out false claims and try to beat out any true claims. As shown by this revelation, I succeeded. The truth remains that many people are and will remain to be confused as to why cross-domain Ajax is a bad idea. They don't understand that the grand majority of the concerns they might have already exist today in many alternative forms. Even those who understood the real security concerns introduced by cross-domain Ajax were not able to give me a clear and penetrating example.

I am currently developing some very interesting applications using a hack that imitates cross-domain Ajax (without any of the security concerns mentioned here). This is why I wanted to explore in detail the security issues surrounding the technology. Google was unable to shed much light because people were not having enlightening conversations, so I am very thankful to all of you who commented on the previous post. I am glad there is now a permanently recorded insightful conversation for a relatively misunderstood topic.

If anyone from IE, Firefox, or Apple is listening, please please please integrate the use of crossdomain.xml policy file and allow us developers some secure cross-domain freedom. The web is missing out on a lot of innovative applications and too many people are creating ugly hacks to get around it.

You should follow me on twitter here.

Technoblog reader special: click here to get $10 off web hosting by FatCow!

8 Comments:

Anonymous Anonymous said...

"If you are on a Mac, download safariexploit.html as a file onto your hard drive. Now open it up with Safari and prepared to be scared."

It would be nice if you included a link to the file :-)

11:40 PM, September 18, 2006

 
Blogger Web app security info said...

You mean the file you open is stored on the disk? Or is it served from a http link?

4:35 AM, September 27, 2006

 
Anonymous Small Business Web Hosting said...

Ajax has an unprecedented number of major security flaws. Which is why I wonder why google is pusing it soo hard.

6:28 AM, October 01, 2006

 
Anonymous Ivan said...

having the local network scanned that way sounds scary, but again, how much exactly can outside attacker do knowing eg. that my 10.0.0.42 machine has old insecure ssh server? If router is configured properly, not much..

There's a number of security issues with cross-domain ajax, but IMHO most of them are related to exploiting poorly written server-side solutions. And you can't blame a technology for people being stupid..

5:11 AM, October 02, 2006

 
Blogger rickdog said...

What I'd like to see is a service that allows bloggers to grab XML as a javascript string (JSON) and inject that into a script element. The client app can then load it into a DOMDocument. Then client-based apps can have some cross-domain RPC capabilities.

The service would be very simple, like:

http://convertXML2String.com?url=http://del.icio.us/rss/rickdog

and return an escaped string:

xmlString="<?xml version="1.0" encoding="UTF-8"?><rdf:RDF ...></rdf:RDF>";

Then I can do something like this:
<script id="myXML" src="http://convertXML2String.com?url=http://del.icio.us/rss/rickdog">
</script>
<script>
var parser = new DOMParser(); // gecko only
var doc = parser.parseFromString(xmlString, "text/xml");
</script>

12:00 AM, October 03, 2006

 
Anonymous Anonymous said...

Did you mean you loaded the file from your local disk? You should feel lucky that it didn't wipe out your hard drive. Didn't safari give you a warning or something?

1:12 PM, October 10, 2006

 
Anonymous Anonymous said...

goto http://www.gmail.com for free mail

6:03 PM, July 21, 2007

 
Blogger Raybeam said...

I don't really understand how this has anything to do with AJAX. You're talking about running a .html/js file from your local drive. IE has Scripting.FileSystemObject and Firefox has Components.interfaces.nsIFileInputStream / nsIFileOutputStream.
Both will allow you to wipe out your whole hard drive.

4:56 AM, July 13, 2008

 

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

 

If you like this blog, you might also like top photography schools.