Web browser security is broken. Completely shattered.
Take the Top 10 Web Hacks of 2006 and the 60 more that follow to see what I mean. XSS, CSRF, and other attacks make it so bad we can’t be certain we’re the ones driving our browsers. Short of completely reinventing HTTP/HTML/JavaScript/Cookies and other fundamental Web technologies (not going to happen) there are a few things we can do. People will get infected with JavaScript Malware, but there’s no reason why we can’t limit the damage without impacting the user experience.
Here are 3 web browser security enhancements I’d like to see. The sooner the better.
1) Restrict websites with public IP’s from including content from websites with non-routable IP address (RFC 1918)
This restriction is designed to protect against Hacking Intranet Websites from the Outside (Port Scanning, Fingerprinting, etc.). If JavaScript Malware can’t force a browser to make non-routable IP requests, then there’s not much left it can do whether or not if it has your private IP. I can’t think of any good reason that a website with a public IP would legitimately need to include data from a private IP.
2) Browser integration of Secure Cache, Safe History, and Netcraft’s anti-XSS URL features in their toolbar
The name says it all. There are excellent extensions and provide a good amount of security that all users can benefit by. Collin Jackson, Andrew Bortz, Dan Boneh, John Mitchell from Stanford and the guys from Netcraft did a great job. I don’t know what Mozilla’s policy is on this kind of thing, but this is one they should definitely consider building in by default. Another feature I’d like to see is restriction of any non-alphanumeric character in the fragment portion of the URL. Designed to stop DOM-based XSS and UXSS.
3) Same-origin policy applied to the JavaScript Error Console
JavaScript errors from code located on DomainA should not be readable from DomainB. This enhancement is design to protect again the Login/History Detection Hack. So when SCRIPT SRCing in a page from another domain (Gmail, Yahoo Mail, MSN, etc.), hoping to get a signature match, you’d be out of luck because you can’t see the error message. This might hinder debugging in some cases, but not much I don’t think.
Bonus
Content-Restrictions. Are we there yet?
4 comments:
> "I’d like to see is restriction of any non-alphanumeric character in the fragment portion of the URL."
Oh, I wouldn't like that. Fragment is a great way to store state of "AJAX" applications in URL (so it can be saved in a bookmark, shared, etc.)
To store state you would need more than alpha-numeric characters? Especially meaning like > and < for example?
Browser do too much. They're like a little OS inside the OS now, and they're being beaten up badly. Basically being kicked in the head while they're already curled up in the fetal position on the ground out cold. I'd love to see browsers take about 10 steps back and move away from "do all be all every function you can imagine" tools.
Sadly, that may never happen, but I like your list in this post. These are very doable things for every browser vendor with these issues.
lonervamp,
It certainly seems that way, and your example isn't too far off. I guess that's why we have the new buzzword WebOS being carried about.
Post a Comment