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

49 comments

  1. Why? by Anonymous Coward · · Score: 0

    Why is the story red?

    1. Re:Why? by janrinok · · Score: 0

      What can you see that is coloured red? Each linked page looks completely normal to me.

      --
      Have a look at soylentnews.org for a different view
    2. Re:Why? by Anonymous Coward · · Score: 0

      At time of posting on the /. Homepage the story was in red.

  2. HTTP authentication by sakdoctor · · Score: 4, Interesting

    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.

    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. Re:HTTP authentication by Anonymous Coward · · Score: 1, Funny

      Mod parent down ASAP. FYI, Meaning of post TBD. Informative tag apparently now AKA gibberish tag.

      Parent's excessive use of acronyms typical MO for somebody with insufficient IQ.

    3. Re:HTTP authentication by Anonymous Coward · · Score: 1, Insightful

      People who actually made the web sites didn't like it because 1) you can't log out, 2) you can't style it to look vaguely related to your site (say, if it's loading in a background tab), 3) it's modal.

    4. Re:HTTP authentication by Anonymous Coward · · Score: 1, Insightful

      Flamebait, really?

      Come on, Slashdot. It was meant to give readers a chuckle, while pointing out that excessive use of acronyms that won't be immediately familiar to most readers is a bit silly.

      Somebody got out of the wrong side of the bed this morning, didn't they?

    5. Re:HTTP authentication by porneL · · Score: 2, Interesting

      It has been discussed recently on HTML5 WG.

      Browsers' UI for HTTP authentication so far is absolutely awful, and there's no standard mechanism for logging out.

      Although HTTP Digest authentication does offer slighly better security than cookies, HTTP authentication is helpless against any MITM attacks.

      There have been proposals to give HTML forms front-end for HTTP authentication, but they haven't gone anywhere, since there is little to gain (same UI as cookie-based auth, negligible security improvement) and backwards compatibility is poor.

  3. Rookie mistake or just poor judgement? by djupedal · · Score: 1

    > "Is it a belated Christmas gift to web developers, or just a reaction to recent bad publicity?"

    Did CT really forget??!! 'Any publicity is good...and good publicity is even better.'

    Not a good way to start the year, Taco - you should know betta' than to bait like this :) Perhaps 2009 is the year to move over and let some edge in.

  4. 2009 Conspiracy!! by fat_mike · · Score: 4, Funny

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

    CHROME!

  5. shttp by hey · · Score: 4, Interesting

    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.

    1. Re:shttp by Anonymous Coward · · Score: 1, Informative

      Nothing. It's not very useful anyway because it doesn't encrypt the HTTP headers, just the content.

    2. Re:shttp by Anonymous Coward · · Score: 0

      This may mean it supports 'secure' HTTP with vhosts...

    3. Re:shttp by Anonymous Coward · · Score: 0

      SHTTP = SHiTTy Protocol

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

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

    1. Re:Where is Konqueror? by Anonymous Coward · · Score: 3, Funny

      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.

    2. Re:Where is Konqueror? by Korin43 · · Score: 1

      Could be because it's so similar to Chrome and Safari?

    3. Re:Where is Konqueror? by larry+bagina · · Score: 5, Insightful

      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.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    4. Re:Where is Konqueror? by Yvanhoe · · Score: 1

      Because KDE on Windows is still not user-ready. Expect some interesting time after its completion.

      --
      The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
  7. Open browser engineering issues by fermion · · Score: 3, Interesting
    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.

    --
    "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    1. Re:Open browser engineering issues by Teckla · · Score: 4, Insightful

      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.

    2. Re:Open browser engineering issues by hey · · Score: 5, Interesting

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

    3. Re:Open browser engineering issues by Anonymous Coward · · Score: 0

      "I do believe that such segregation at the user application level has the same benefit."

      Cue the "That's Racist!!!" animation in 4-3-2-1...

    4. Re:Open browser engineering issues by Mad+Merlin · · Score: 1

      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.

      Speaking as a developer, it really doesn't. If you actually need a specific size of variable (rare), just use one of the standard types that's guaranteed to be that specific size.

      If you're assuming that sizeof(int) == sizeof(void *) (or similar) on all platforms and getting bitten, then that's your own stupid fault for making dumb assumptions.

    5. Re:Open browser engineering issues by ion.simon.c · · Score: 1

      If you use glibc and a modern compiler (like GCC), you get many memory randomization and heap/stack protection mechanisms, for (almost) free!

      Folks should switch to an OS that's more secure by default. ;)

    6. 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.

    7. Re:Open browser engineering issues by yupa · · Score: 2, Informative

      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.

  8. how many pages? by Cyko_01 · · Score: 1

    the article says 50 and the google blog says 60...or are there 10 pages of dedications?

    1. Re:how many pages? by cbiltcliffe · · Score: 2, Funny

      The last 10 pages are just full of browser, Flash, PDF and Javascript exploits....

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    2. Re:how many pages? by RockDoctor · · Score: 2, Interesting
      cbiltcliffe suggested that

      The last 10 pages are just full of browser, Flash, PDF and Javascript exploits....

      But I think the 50/60 page difference could easily be because one version was printed on A4 with margins suitable for US-Letter size paper. Which would imply that GoogleHQ are using the US-size paper, and paying the 20% extra because of it. I've recently been having to work in a mixed US and european environment (US-configured software, installed on a Hebrew-US defaulted OS on machines locally-sourced, and printing to locally-sourced printers which use the normal A4 paper. What a fucking mess.

      --
      Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
  9. My gift to google by Anonymous Coward · · Score: 2, Insightful

    Will be a book about basic HTML authoring; the importance of setting text color when they set the background color, making pages work without javascript where there's no requirement for it. Like I said, the basics.

    Perhaps then (no disrespect intended to Zalewski) I'll take google branded advice seriously.

  10. Re:Frist reply to a red story by Anonymous Coward · · Score: 0

    It's not a fantasy, it's a true story.

  11. # Written and maintained by Michal Zalewski lcamt by EddyPearson · · Score: 2, Interesting

    # Written and maintained by Michal Zalewski .

    Couldn't have chosen a better person in my opinion. http://lcamtuf.coredump.cx/

    --
    You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
  12. A modest proposal by Anonymous Coward · · Score: 1, Interesting

    New tagline: Slashdot -- Google news for nerds, Google stuff that matters.

    Yes, this is on topic. However, the article is yet another in a long line of Slashvertisements for Google. Can we all just agree that the IT world does not revolve around Google, and even if it did, that would be a very dangerous thing to promote?

    1. Re:A modest proposal by FlyingGuy · · Score: 3, Interesting

      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.

      --
      Hey KID! Yeah you, get the fuck off my lawn!
  13. 55 pages? by girlintraining · · Score: 1

    Okay, did they put this in 3 point font size on poster-board sized pages? Because 55 pages can't even describe how to avoid buffer overflows, let alone something as all-encompassing as browser security. I don't need to read this to know that it fails in its objective as a "one stop" source. At best it might serve as an introduction to rudimentary security concepts. -_-

    --
    #fuckbeta #iamslashdot #dicemustdie
  14. Non-Google Slashdot Filter needed? by Anonymous Coward · · Score: 0

    Is a non-google /. filter needed? I too am very tired of all google, all the time.

  15. Unless it's in cartoon format... by Anonymous Coward · · Score: 0

    I'm not going to read it...

    http://www.google.com/googlebooks/chrome/ [chrome cartoon]

  16. Why no PDF? by Master+of+Transhuman · · Score: 1, Offtopic

    I'm getting really tired of Web sites that post articles covering many pages and provide no PDF download or single page view.

    No, I'm not buying anything off your ads anyway, so give me the goddamn PDF!

    --
    Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
  17. What would you wind up with then? by zogger · · Score: 2, Insightful

    How would a new web work, what would it look like? We have very powerful governmental and corporate interests outstanding that would force more of a totally censored and locked down web then what we have now is my best guess. I mean it is sucky now in that regard, but there's still an element of random anarchy there, but any "new" web would probably be rather strict big brotherish, IMO, with a ton of features and software being made illegal or restricted, anything that would facilitate "IP piracy" for example. It might technically work better or be more efficient in moving packets around, but I am afraid it would lose the free wheeling aspects that have made it so popular. But..I don't know either, just guessing, how would you change it and to what? What needs to be dumped, and what needs to be changed or added, do you have any specifics, browsers or otherwise?

    1. Re:What would you wind up with then? by FlyingGuy · · Score: 1

      Hey there... The document pointed of a lot of problems from a security POV and those need to be fixed, and fixed quickly.

      The basics of the http protocol are pretty good, it just needs to be cleaned up, and I mean reviewed from the 1st to the last byte and fix all the kludges that have been piled on.

      HTML is a freaking mess as is The DOM and CSS. There are so many issues it is really hard to know where to start. I think a good place would be more closely couple the DOM to the browser. CSS needs to have its guts ripped out and start over. The very notion that there are things in HTML elements that cannot be affected by your style sheets is completely ludicrous. As an example take talbes for instance. Tables are a perfectly valid tool in HTML and yet you cannot set the number of columns, or their width from with CSS, if you want that to change that you have to encode in the HTML, which is utterly counter to the entire mission of CSS. Don't get me started on the whole "Its Structure" -v- "Its display" argument because it comes down to who shouts the loudest.

      Browsers are not ment to be FTP clients so you should not even be able to put "ftp://" in your browsers address bar. The notion that you can put in various munged address formats in there is also something that just needs to be removed. t either goes in in standard doted notation as in IPV4 or the standard notion of IPV6. Additionally the very notion that you can leaves whole segments of and IPV6 address out and just put in "::" is something the IPV6 gang should be slapped for.

      I could go on and on and on put you get the point. The basics are not that bad, it is the functionality that has been shoehorned in that needs to be ripped out and redesigned in a homogeneous form so its all works in concert.

      --
      Hey KID! Yeah you, get the fuck off my lawn!
  18. Password Manager Section Entry Correction? by Czmyt · · Score: 2, Interesting

    For the password manager model in MSIE7, didn't they change it from IE6 so that you can click on a user name field and it will display a drop-down list with all of the recorded passwords? In some ways, that made it better than Firefox and the other browsers that automatically fill in recorded fields on page load. In IE6 you did not really need to know the complete user name either, just the first letter of the user name, which was a not as good as how they made it work in IE7.