Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: browsers

Some thoughts on HTTP response codes

I’ve been playing on and off over the last year with HTTP response codes (yeah, I know, I’m a sad panda). As part of my research I’ve been looking at how various browsers handle content returned with the various standard response codes (some of the newer ones aren’t supported in Apache and the like and therefore aren’t that interesting for my uses at the moment).

I setup a simple tester script (JavaScript required, sorry) that loads images from a server setup to deliver them with specific response codes. You can have a play with it yourself if you’re interested[1] (I suggest running the requests through a proxy to see the fun happen).

The results are interesting [2] and could be used for a few interesting defensive tricks I’m mulling over. There are also a few interesting applications possible when it comes to fingerprinting browsers (and scripting languages for that matter). Although this level of granularity is never going to give you a specific version of browser and list of plugins installed, it could offer a simple test for checking if the browser is Internet Explorer or Opera for example. It’s also interesting to think that scripts/tools that fake the user-agent string might be detectable using some carefully crafted response code tricks. User-Agent string are fun and all, but the old adage “trust but verify” springs to mind. I also included some details on a couple of scripting languages which are interesting. I’m certainly not foolish enough to think that these issues can’t be coded around, but it’s interesting to see the initial state of things when it comes to 3 of the more popular scripting languages (Perl, Python and Ruby).

I’ll leave it to the reader to think over further uses for this stuff… I’ve certainly got a few interesting ideas that have been keeping my brain busy for a while. Hopefully I’ll be moving forward on the research and coming up with a few interesting things in the future. Maybe even a presentation that’s NOT about SAP… that would be nice wouldn’t it ;) It’s therapeutic to think defensively for a while. It’s especially fun when you can use defensive research to screw with script kiddies and scanner junkies <insert evil laugh here>

Note: I’m constantly updating and tweaking the results spreadsheet as I find new results… I’ve also tweaked some of the results I previously noted due to some false positives with specific browsers. If you see anything that looks wrong, just let me know!

{Quick Post} URL shortcuts

I’ve had this little snippet hanging about for a while, and I’m almost sure 99% of people are already aware of this, but hey, that still means 1% aren’t. So here’s a quick quirk that I noticed a few years back in the way browsers process values entered into the location bar.

If you’re like most users, you type google.com to get to Google much more than you type http://www.google.com&#8230; after all, if HTTP is the default and the remote site handles the redirect to the right place, it’s all good! Still, in the location bar, HTTP isn’t the default! Before tying that, your browser is going to check you didn’t mean something else…

To test this, create a shortcut on your Windows desktop called yahoo.com and assign the shortcut to go to http://www.google.com&#8230; if you want to do this programatically, just open an editor and enter the following :

[InternetShortcut]
URL=http://www.google.com/
IDList=

Now save that as yahoo.com.url on the desktop and open your favourite browser. Type yahoo.com into the location bar and see what happens!

Conclusion:

As far as a security issue goes, I’m not sure you can class this as a problem. After all if you have the ability to edit files on a system, then surely altering the etc/hosts file would be more effective. Still, maybe on restricted systems this might come in handy!

Note:

A few people have mentioned that this seems fixed in the latest Chrome and in IE 8. Tested this end and IE 7 is “vulnerable” to this quirk. Nice to see browser vendors have started fixing this over the past year or so!

Follow

Get every new post delivered to your Inbox.

Join 124 other followers