3 ms·

Yeah, I beat this dead horse every time the armchair security quarterbacks climb on their high horse in these comments. These “dumb” mistakes happen to everyone

Yeah, I beat this dead horse every time the armchair security quarterbacks climb on their high horse in these comments. These “dumb” mistakes happen to everyone, at every company. Even security experts. Even one of tptacek’s companies had a well known incident, and people said all the same things about their “dumb” mistakes. Companies are very porous, people take shortcuts, temporary workarounds get forgotten and left in place, etc. You can tell who actually has real experience by who is saying this and getting downvoted for it, ironically. All of the downvoted comments in this thread are correct.

dj_mc_merlin 6y ago
I take the same standpoint as you most of the time. But you can't fucking interpolate user input into SQL queries without physically cringing and call yourself an experienced engineer. Can you really pull up a code editor and write that out without your brain sounding off a thousand alarm bells that you're massively messing up something? I can imagine myself doing this, having not slept in the last 20 hours, after 7 martinis and one especially long island. Maybe he did that too, but he should have the common sense as CTO of the company not to!
- oji0hub 6y ago
  Who knows what was going on. In an ideal world we have the time needed to do things well. In reality, you've got twenty developers asking for something, users requesting features, various government agencies asking for documents, the lawyers inform you about some case and... oh your wife is calling on the other line because... etc etc etc.
  - jdxcode 6y ago
    I get so busy I rip out query builders to SQL concat strings all the time. /s That’s like going 120mph and telling the cop you were just “distracted”. You’re correct that we often make mistakes when we’re busy, but this isn’t that. This is OWASP #1 and the most plain example of it. This is not a “mistake” that engineers make, this is unethical to allow this to go into production. He even has a stackoverflow answer where he explains this exact problem: https://stackoverflow.com/questions/11554015/syntax-sql-where-and-like/11554036#11554036 https://stackoverflow.com/questions/11554015/syntax-sql-wher... If you think I’m wrong, then what could an engineer be responsible for? Literally nothing ever?
tobasq 6y ago
This is the textbook example of what not to do with SQL queries. You can't even learn SQL or an SQL library API without being warned against this a dozen times. If the CTO pushed this code, and the processes the CTO themself is responsible for designing did not catch this, it is safe to say the CTO is incompetent.
ikiris 6y ago
No they don't. If you do something as blindingly stupid as this, you don't deserve commit access.
kcartlidge 6y ago
> These “dumb” mistakes happen to everyone, at every company. Even security experts. Dumb mistakes happen, true. This one should never happen to security experts, ever, unless their expertise is fake/bluff. Stripping out safe parameterised code and replacing it with injected user input is only something that "happen(s) to everyone" at a very early stage in their career. - For an intern or a junior dev, it's just a learning experience and no names. - For a dev with a few years experience, it's a cause for concern but still no names. - For a senior dev, I'd wonder if they lied on their CV but still no names. - At CTO level this is not acceptable. Maybe no names, I'm on the fence, but they are a semi-public figure by nature of their role and their name was on the commit so they are the ones that made it public. Either way, the CTO should have lost all credibility with their colleagues and be out the door. They represent the norms, processes, and safeguards the company employs and should not be in that role. PS. I understand that there is no proof this commit caused/allowed the data exfiltration. It doesn't matter; the commit is heinous enough on it's own merits.

dj_mc_merlin 6y ago

I take the same standpoint as you most of the time. But you can't fucking interpolate user input into SQL queries without physically cringing and call yourself an experienced engineer. Can you really pull up a code editor and write that out without your brain sounding off a thousand alarm bells that you're massively messing up something? I can imagine myself doing this, having not slept in the last 20 hours, after 7 martinis and one especially long island. Maybe he did that too, but he should have the common sense as CTO of the company not to!

oji0hub 6y ago
Who knows what was going on. In an ideal world we have the time needed to do things well. In reality, you've got twenty developers asking for something, users requesting features, various government agencies asking for documents, the lawyers inform you about some case and... oh your wife is calling on the other line because... etc etc etc.
- jdxcode 6y ago
  I get so busy I rip out query builders to SQL concat strings all the time. /s That’s like going 120mph and telling the cop you were just “distracted”. You’re correct that we often make mistakes when we’re busy, but this isn’t that. This is OWASP #1 and the most plain example of it. This is not a “mistake” that engineers make, this is unethical to allow this to go into production. He even has a stackoverflow answer where he explains this exact problem: https://stackoverflow.com/questions/11554015/syntax-sql-where-and-like/11554036#11554036 https://stackoverflow.com/questions/11554015/syntax-sql-wher... If you think I’m wrong, then what could an engineer be responsible for? Literally nothing ever?

tobasq 6y ago

This is the textbook example of what not to do with SQL queries. You can't even learn SQL or an SQL library API without being warned against this a dozen times. If the CTO pushed this code, and the processes the CTO themself is responsible for designing did not catch this, it is safe to say the CTO is incompetent.

ikiris 6y ago

No they don't. If you do something as blindingly stupid as this, you don't deserve commit access.

kcartlidge 6y ago

> These “dumb” mistakes happen to everyone, at every company. Even security experts. Dumb mistakes happen, true. This one should never happen to security experts, ever, unless their expertise is fake/bluff. Stripping out safe parameterised code and replacing it with injected user input is only something that "happen(s) to everyone" at a very early stage in their career. - For an intern or a junior dev, it's just a learning experience and no names. - For a dev with a few years experience, it's a cause for concern but still no names. - For a senior dev, I'd wonder if they lied on their CV but still no names. - At CTO level this is not acceptable. Maybe no names, I'm on the fence, but they are a semi-public figure by nature of their role and their name was on the commit so they are the ones that made it public. Either way, the CTO should have lost all credibility with their colleagues and be out the door. They represent the norms, processes, and safeguards the company employs and should not be in that role. PS. I understand that there is no proof this commit caused/allowed the data exfiltration. It doesn't matter; the commit is heinous enough on it's own merits.