6 ms·

I don't know how is possible that a so obvious bug passed their quality department, and I wonder if someone didnt discovered it before and was doing this to tak

I don't know how is possible that a so obvious bug passed their quality department, and I wonder if someone didnt discovered it before and was doing this to take out competitors indexes..

DrJokepu 15y ago
Bugs happen. Even big ones like this. Any engineer worth his money knows that no amount of Q&A will discover 100% of the bugs. But, as Joel Spolsky said somewhere, bugs are just bugs, you fix them and then they're fixed.
- juliano_q 15y ago
  I know, I am an engineer and I obviously let bugs pass too. But this is a little too obvious to me, to check if the user is allowed to remove this url. Maybe I am neurotic? :)
  - trotsky 15y ago
    most bugs are obvious after someone has pointed them out to you.
    - cooldeal 15y ago
      I think the point is that it's a basic dev and QA fail not to check for this, especially with people of the caliber that Google is supposed to recruit.
      - trotsky 15y ago
        Process always falls down at some point, it's why we have bugs in the first place. The point of view that "obvious bugs should never happen" is pretty obviously broken, you just try to make them as rare as humanly possible. Besides, simple looking things from the outside can be maddeningly complex from the inside - for all we know this could be related to an obscure bug in their test framework marking it as passed when it isn't. Most of the time when people say "what a stupid mistake" they mean "that's a mistake I haven't made yet"
        pueblo 15y ago
        Well said!
  - dangrossman 15y ago
    I can see having this pass by a reviewer or two. They look and see all of this: - There are permission checks - The user has to be logged in to GWT - The user has to have access to this page - The user has to be the owner of the siteUrl After all those permission checks, it might appear that everything was covered. It's just one little omission, verifying that the urlt parameter corresponds to a page within the siteUrl website, that was missed.
    - pak 15y ago
      eh? I don't see that as one little omission. It's kind of straightforward that you would need to be the owner of the actual URL to be deleted, so checking the siteUrl is not sufficient. I can understand if they only intended to allow relative paths from the siteUrl, and if there was some kind of bug in special characters or parameter parsing. But no, this is as bad as that bug in Citibank's site where you could just change the account number in the address bar [1]. Color me disillusioned with Google's security practices. [1] http://consumerist.com/2011/06/how-hackers-stole-200000-citi-accounts-by-exploiting-basic-browser-vulnerability.html http://consumerist.com/2011/06/how-hackers-stole-200000-citi...
    - jpeterson 15y ago
      This is a pretty amateurish mistake, actually, and I'm shocked that it was in production at Google. Proper authorization checks are web programming 101.
      - dangrossman 15y ago
        If you make a checklist of security practices the QA testers should look for, they'd see and check off "proper authorization checks", as they were done on other fields of the same page. If you can't imagine a professional making this mistake, your mental image of an engineer is not realistic. Humans are not that perfect, and this mistake does not make everyone that reviewed this code an amateur.
        jpeterson 15y ago
        Well, people are down voting me, but everyone ripped the developers of Diaspora apart for basically the same exact flaw in an early alpha release of their system. The Google fanboyism seems to be running strong here.
  - JoeAltmaier 15y ago
    ...but Intel released the Pentium and it couldn't divide by 10. Sometimes testers use the shotgun approach, and things get missed. It can help to write exhaustive tests (you have a computer, right?) and try everything. But the problem space has to be orderly, orthogonal, something that can be spanned. This bug is in a pretty small problem space - an API with many dimensions (arguments), external dependencies. I'm not at all surprised something got thru.
- kmt 15y ago
  Quoting Spolky regarding bugs and bug fixes? He has a horse in the game, I wouldn't quote him for anything bug-related. Regarding bugs: a fast thinker always thinks about the consequences of checking in any code. Checking in code, not to mention releasing it, changes the word (in a very minor way but it still does). Not exploring the possible consequences and the alternative options is just negligence and/or lack of experience. You don't have to be a perfectionist to see this, you just have to be fast: finding a wise, balanced solution quickly every time you change the world.
flatline 15y ago
My guess would be that someone took an internal tool with few security requirements and rolled it straight to production. If that is the case, this is probably an excellent candidate for a security audit, there are almost certainly more issues if something this basic was not in place.

I don't know how is possible that a so obvious bug passed their quality department, and I wonder if someone didnt discovered it before and was doing this to take out competitors indexes..

DrJokepu 15y ago

Bugs happen. Even big ones like this. Any engineer worth his money knows that no amount of Q&A will discover 100% of the bugs. But, as Joel Spolsky said somewhere, bugs are just bugs, you fix them and then they're fixed.

juliano_q 15y ago
I know, I am an engineer and I obviously let bugs pass too. But this is a little too obvious to me, to check if the user is allowed to remove this url. Maybe I am neurotic? :)
- trotsky 15y ago
  most bugs are obvious after someone has pointed them out to you.
  - cooldeal 15y ago
    I think the point is that it's a basic dev and QA fail not to check for this, especially with people of the caliber that Google is supposed to recruit.
    - trotsky 15y ago
      Process always falls down at some point, it's why we have bugs in the first place. The point of view that "obvious bugs should never happen" is pretty obviously broken, you just try to make them as rare as humanly possible. Besides, simple looking things from the outside can be maddeningly complex from the inside - for all we know this could be related to an obscure bug in their test framework marking it as passed when it isn't. Most of the time when people say "what a stupid mistake" they mean "that's a mistake I haven't made yet"
      - pueblo 15y ago
        Well said!
- dangrossman 15y ago
  I can see having this pass by a reviewer or two. They look and see all of this: - There are permission checks - The user has to be logged in to GWT - The user has to have access to this page - The user has to be the owner of the siteUrl After all those permission checks, it might appear that everything was covered. It's just one little omission, verifying that the urlt parameter corresponds to a page within the siteUrl website, that was missed.
  - pak 15y ago
    eh? I don't see that as one little omission. It's kind of straightforward that you would need to be the owner of the actual URL to be deleted, so checking the siteUrl is not sufficient. I can understand if they only intended to allow relative paths from the siteUrl, and if there was some kind of bug in special characters or parameter parsing. But no, this is as bad as that bug in Citibank's site where you could just change the account number in the address bar [1]. Color me disillusioned with Google's security practices. [1] http://consumerist.com/2011/06/how-hackers-stole-200000-citi-accounts-by-exploiting-basic-browser-vulnerability.html http://consumerist.com/2011/06/how-hackers-stole-200000-citi...
  - jpeterson 15y ago
    This is a pretty amateurish mistake, actually, and I'm shocked that it was in production at Google. Proper authorization checks are web programming 101.
    - dangrossman 15y ago
      If you make a checklist of security practices the QA testers should look for, they'd see and check off "proper authorization checks", as they were done on other fields of the same page. If you can't imagine a professional making this mistake, your mental image of an engineer is not realistic. Humans are not that perfect, and this mistake does not make everyone that reviewed this code an amateur.
      - jpeterson 15y ago
        Well, people are down voting me, but everyone ripped the developers of Diaspora apart for basically the same exact flaw in an early alpha release of their system. The Google fanboyism seems to be running strong here.
- JoeAltmaier 15y ago
  ...but Intel released the Pentium and it couldn't divide by 10. Sometimes testers use the shotgun approach, and things get missed. It can help to write exhaustive tests (you have a computer, right?) and try everything. But the problem space has to be orderly, orthogonal, something that can be spanned. This bug is in a pretty small problem space - an API with many dimensions (arguments), external dependencies. I'm not at all surprised something got thru.
kmt 15y ago
Quoting Spolky regarding bugs and bug fixes? He has a horse in the game, I wouldn't quote him for anything bug-related. Regarding bugs: a fast thinker always thinks about the consequences of checking in any code. Checking in code, not to mention releasing it, changes the word (in a very minor way but it still does). Not exploring the possible consequences and the alternative options is just negligence and/or lack of experience. You don't have to be a perfectionist to see this, you just have to be fast: finding a wise, balanced solution quickly every time you change the world.

flatline 15y ago

My guess would be that someone took an internal tool with few security requirements and rolled it straight to production. If that is the case, this is probably an excellent candidate for a security audit, there are almost certainly more issues if something this basic was not in place.