Hacker News Reader

Comment by juliano_q | Hacker News Reader

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? :)

View on HN

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.

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

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.

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.

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.

Those flaws were all over their entire codebase in very basic parts of the site's functionality. They had literally zero authorization checks.

most bugs are obvious after someone has pointed them out to you.

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.

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"

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

Reply on news.ycombinator.com