Google Releases Web Security Book

northern squirrel writes "As reported by Security Focus, Google had publicly released their 50-page Browser Security Handbook (under a CC BY license, too). To quote, the document is 'meant to provide developers, browser engineers, and information security researchers with a one-stop reference to key security properties of contemporary web browsers,' and features a comparison of security features in Internet Explorer, Firefox, Opera, Safari, and — you guessed it — Chrome. Is it a belated Christmas gift to web developers, or just a reaction to recent bad publicity?"

Comments

HTTP authentication

[sakdoctor]

What the hell happened to http authentication anyway? I'm oblivious to the history, but we have basic and digest, both suck so everyone uses cookies instead.
Why don't we have something more modular where new hashes can be plugged in over time, and maybe negotiate down to md5 for older agents.

Re:HTTP authentication

[Zarhan]

There is work on that arena. Basically, when HTTPBis WG was being chartered, during the BOF discussion it was acknowledged that authentication is too big can of worms to simply be considered a "revision", thus it's going to happen in a separate WG. In November, a BOF for OAuth was held...have to see if anything comes out of it.

2009 Conspiracy!!

[fat_mike]

Google secretly bought Slashdot for $20 and a bag of Frito's BBQ style.

CHROME!

shttp

[hey]

The document mentions shttp which I have never heard of before
http://www.ietf.org/rfc/rfc2660.txt
I wonder what's its used for.

Where is Konqueror?

[bogaboga]

Konqueror is not mentioned yet it's a [major] browser on the KDE desktop. Why?

Re:Where is Konqueror?

[Anonymous Coward]

Konqueror is not mentioned yet it's a [major] browser on the KDE desktop. Why?

Good question, I think it's something to do with the fact that firefox uses Gtk and NIH KDE Keeple Ket Kheir Kanties Kwisted Khen Kaced Kith Khe "G" Krospect.

Re:Where is Konqueror?

[larry bagina]

Because it's major browser, on a minority desktop environment, on an irrelevant (to the desktop) OS. They didn't mention Net+, Cyberdog, or QNX Voyager either.

Open browser engineering issues

[fermion]

Just perusing the report, I found this section interesting.

Relatively unsafe core programming languages
There is no question that programming in C and C++ requires skill, and that memory management is an issue, and automatic heap allocation and garbage collection is the popular solution to that issue, but there is no silver bullets, and they are always compromises. It seems to me like every is so scared of they tools that they don't even want to learn to use them. They never learn to use an Exacto knife because they never get past those plastic scissors they give you in grade school. At some point one has to take off the training wheels, at least for some projects. For better or worse,the core stuff, the stuff that does the heavy work, has to be written efficiently, and that may mean a human has to code it without over-dependence on the compiler.

No security compartmentalization
Again, there are no silver bullets. For instance, the Java sandbox is one solution to a security issue. It is not perfect, and it's imperfections lead to a false sense of security. It is ok for developers to be sloppy because garbage collection and the sandbox will protect the user. Not true. The real issue is that we are running what are essentially single user stand alone apps in multiuser networked contexts, at least in Windows. Of course in *nix there is segregation of processes built from the OS up, which is good. I do believe that such segregation at the user application level has the same benefit. It is a hack to make people feel better. Now, in chrome there is a side benefit that each page is it's own process. We will see how that works out.

Web technologies are used in browser chrome:
This seems to counteract what they were saying in the first item. C and C++ leads to coding bugs, but using standard complex libraries leads to unexpected behaviour. This is why we use C and C++, because it is simple enough to understand and carries very little useless overhead. Once we start using more complex libraries, we end up with a few functions we use, much more code we do not use, and many side effects we do not understand. I mean do we write everything in C++, and gain understanding, or use a range of technologies to maximize efficiency? If there are bugs in some high level libraries, all we need to do is fix the bug in library. Is the risk of the library greater than the risk of using a simple language like C?

The rest of this just seem like subjective opinions of design. In terms of setting, I almost prefer about:config to any of the GUI stuff. The last item about data storage is important, but again is an OS issue. Each application should have a predefined space in the user directory to store files. If any application can store anything to anywhere on the disk, even outside the user directory, that is not a browser issue.

Re:Open browser engineering issues

[Teckla]

There is no question that programming in C and C++ requires skill, and that memory management is an issue, and automatic heap allocation and garbage collection is the popular solution to that issue, but there is no silver bullets, and they are always compromises. It seems to me like every is so scared of they tools that they don't even want to learn to use them. They never learn to use an Exacto knife because they never get past those plastic scissors they give you in grade school. At some point one has to take off the training wheels, at least for some projects. For better or worse,the core stuff, the stuff that does the heavy work, has to be written efficiently, and that may mean a human has to code it without over-dependence on the compiler.

Well, let's think about it from the point of view of a regular old user of software and applications, rather than from the viewpoint of chest thumping uber-geeks that insist you're a pussy if you don't use a low level programming language like C or C++.

Would you prefer software that's as fast and lean as possible, but may have a bunch of vulnerabilities (via stack smashing, buffer overruns, etc.)? Then you may prefer applications written in C and C++ and other low level but high danger programming languages.

Or would you prefer software that's slower and fatter, thus requiring more hardware to get equivalent performance, but with less vulnerabilities because whole classes of exploits are now extremely unlikely? Then you may prefer applications written in higher level languages such as Java, Python, and JavaScript.

I posit that most users would be better off spending the extra $20 on hardware to run software written in higher level and safer programming languages.

Again, there are no silver bullets. For instance, the Java sandbox is one solution to a security issue. It is not perfect, and it's imperfections lead to a false sense of security. It is ok for developers to be sloppy because garbage collection and the sandbox will protect the user. Not true. The real issue is that we are running what are essentially single user stand alone apps in multiuser networked contexts, at least in Windows. Of course in *nix there is segregation of processes built from the OS up, which is good. I do believe that such segregation at the user application level has the same benefit. It is a hack to make people feel better. Now, in chrome there is a side benefit that each page is it's own process. We will see how that works out.

Yeah, you hear about stack smashing and buffer overrun exploits in Java programs all the time. Not.

This seems to counteract what they were saying in the first item. C and C++ leads to coding bugs, but using standard complex libraries leads to unexpected behaviour. This is why we use C and C++, because it is simple enough to understand and carries very little useless overhead. Once we start using more complex libraries, we end up with a few functions we use, much more code we do not use, and many side effects we do not understand. I mean do we write everything in C++, and gain understanding, or use a range of technologies to maximize efficiency? If there are bugs in some high level libraries, all we need to do is fix the bug in library. Is the risk of the library greater than the risk of using a simple language like C?

I've been programming in C for 20 something years now. Just because the language is simple does not mean programming in the language is simple.

When you (as the developer) can't even count on primitive types being the same size all over, it makes writing portable software a huge pain in the ass. It's easy to constantly stumble into undefined behavior, and the compiler won't even warn you.

C and C++ are very, very good at some things, like implementing low level routines where top performance is critical, and low level access to the hardware is required. But for many other programming tasks, they have become completely impractical.

Re:Open browser engineering issues

[hey]

But C/C++ is changing. Memory randomization makes many attacks impractical, for example. So you get something as safe as Java but faster.

Re:Open browser engineering issues

[cant_get_a_good_nick]

But C/C++ is changing. Memory randomization makes many attacks impractical, for example. So you get something as safe as Java but faster.

1) to be pedantic, the randomization you mention is not in 'changes' to C/C++, or even C or C++ specific, but is part of the OS. It would make Fortran code more safe, for example.

2) Fortran doesn't need to be more safe. It doesn't have pointers, or a heap.
Pointers are the good and evil in C and C++. You can never have a program with all the checks that a handle type memory allocator like Java or C# has in C or C++. Pointers also prevent some optimizations that both Java and the CLR can perform since they know what's pointing to what. With pointers around, you never know if this memory you have is being pointed to by something, so there are some assumptions you'd like to make but just can't. With managed handles (references, objects, whatever you want to call them) the VM (JVM, CLR) knows these things.

There are other classes of exploits that can occur. There was a telnetd bug years ago that was exploitable because of bad counting of character expansions that overran a buffer. this simply wouldn't exist in a managed environment like a JVM or the CLR.

C and C++ were simply not designed for the class of programs that are out there now - large apps with many dependent libraries of unknown quality constantly exposed to malicious users with huge profit motives. Neither was Java or C# (or any common OS, though security fixes were backported), but the design factors they did have eliminate a fair number of exploit classes.

Re:A modest proposal

[FlyingGuy]

Well, at some point I could agree with you, but not in this case.

This document painfully illustrates the truly hosed nature of the web and most browsers in particular from a security POV, chrome included.

The web in it's current form is one massive kludge piled on top of a pretty good idea.

The time is long passed due to take what is there, screw backwards compatibility and rebuild it correctly.