5 ms·

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

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.
      - carbonica 15y ago
        Those flaws were all over their entire codebase in very basic parts of the site's functionality. They had literally zero authorization checks.
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.

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.
    - carbonica 15y ago
      Those flaws were all over their entire codebase in very basic parts of the site's functionality. They had literally zero authorization checks.

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.