Slashdot Mirror
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?"
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.
Konqueror is not mentioned yet it's a [major] browser on the KDE desktop. Why?
Nothing. It's not very useful anyway because it doesn't encrypt the HTTP headers, just the content.
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.
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. I Yes, project need to be written with security in mind. There are program with few security hole written in C/C++ but most of the time they use special API for strings, allocation, ...
For example vsftpd : http://vsftpd.beasts.org/#security
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.
Sandbox doesn't imply high level language. Even in a sandbox, if it is not correctly configured, there can be security hole.
On the other side you can be sandboxing in C/C++ (using the OS). For example using chroot/PR_SET_SECCOMP ...)
I think the problem is writing a safe application is really hard and can be tricky. You need to know well "secure" programming and what offer the OS.
For the average programmer using high level language can help : it is the writer of the high level language who have managed security, not you. And you can expect them to do better than you.