Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Releases Web Security Book

Posted by CmdrTaco on from the posted-from-my-own-chair dept.

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?"

3 of 49 comments (clear)

  1. Re:HTTP authentication by Zarhan · · Score: 4, Informative

    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.

  2. Where is Konqueror? by bogaboga · · Score: 3, Informative

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

  3. Re:Open browser engineering issues by cant_get_a_good_nick · · Score: 3, Informative

    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.