A couple months ago I had lunch with Collin Jackson, Andrew Bortz, and Dan Boneh from Stanford University’s Security Laboratory. The same guys who created SafeHistory, SafeCache, and bunch of other cool stuff. Their mission is conducting security research that everyone can benefit by. We talked all the around web application security, how everything is completely broken, and brainstormed ideas of what might be done about it. Sometime during the conversation they asked something that caught me completely off guard. They asked, “if we could start all over, what would you do different?”.Like most I’m always locked up in the gory details of the current environment and rarely afforded an opportunity to think in purely theoretical terms. Any proposed solution must take prioritization and resistance to migration into account, which makes real progress difficult. Now imagine for a moment you could forget all about how many websites are vulnerable, what it would take to fix all the code, and dismiss any concerns about overhauling the security infrastructure of ANYTHING. You have a magic wand. For myself, it took a long while before I could piece together some core ideas (below).
This is was a fun exercise and before scrolling down to read my thoughts, I encourage everyone to try it. We might generate some crazy innovative ideas to draw from. And please don’t think that I have all the answers, I don’t. Just some ideas.
1. Complete language separation of JavaScript from HTML
2. Nuke Basic and Digest Auth for something way more secure, but just as simple.
3. HTTP stripped down and streamlined (no off-domain referers, no passive third-party cookies, native support for URL and cookie encryption)
4. Browsers only support well-formatted XHTML
5. Compliable web pages (HTML/JavaScript) into byte-codes
6. SSL certificates may contain trademarked logos that show up in the browser chrome
7. Browser integration of Secure Cache, Safe History, and Netcraft’s anti-XSS URL features in their toolbar
8. Implement Content Restrictions
9. Same-origin policy applied to the JavaScript Error Console
10. Restrict websites with public IP’s from including content from websites with non-routable IP address
4 comments:
I'm surprised to see bytecode on the list. Wouldn't malformed bytecode be another source of exploits? Binary formats are dangerous - every major browser and OS had at least one critical vulnerability related to parsing structs in images.
Certificates with logos are neat idea, however it has been shown that people can be tricked by fake browser implementations within a page (http://it.slashdot.org/it/07/01/26/1325228.shtml) and when you fake entire browser and addressbar, you can fake logo too.
> I'm surprised to see bytecode on the list. Wouldn't malformed bytecode be another source of exploits? Binary formats are dangerous - every major browser and OS had at least one critical vulnerability related to parsing structs in images.
No more or less than Java or C#. I believe there would be many benefits to an optional style of compiled web pages. Seems the idea was never popular among the general open source web developers though.
> Certificates with logos are neat idea, however it has been shown that people can be tricked by fake browser implementations within a page (http://it.slashdot.org/it/07/01/26/1325228.shtml) and when you fake entire browser and addressbar, you can fake logo too.
Yah, this is a tough problem to solve. I still like the idea, even if it would only be able to help me. :)
Really, nothing about making HTTP stateful so programmers wouldn't have to hide the crown jewels in cookies and hidden form fields?
- Steve Christey
Hey Steve, you know thats a good point, but Im now entirely sure what that would do to overal performance.
Post a Comment