3 ms·
Any time "$var" is interpolated without check into an INSERT, and any maintainer finds it easier to just check for null as a string rather than ask a DB admin o
by lores 2y ago
Any time "$var" is interpolated without check into an INSERT, and any maintainer finds it easier to just check for null as a string rather than ask a DB admin or committee to update the DB after a lot of red tape and risk assessment.
So... very often.
- hsbauauvhabzb 2y agoGuess I’ll change my name to ‘;drop table customers then ;)
- lores 2y agoYou can make a good case to spend time sanitising requests to avoid catastrophic failure, but the "null" problem is one that quickly becomes a lot of work and risk to fix after the fact, for no obvious benefit except what's seen as the pedantry of some nerd, so it gets ranked all the way at the back of the list... until someone named Null comes along, and probably still even then.
- hsbauauvhabzb 2y agoI disagree. If your system is failing to correctly type check strings during SQL interpolation, you should probably kill it with fire.
- lores 2y agoI don't disagree... In most cases, it's not your system, though, it's someone else's.
- hsbauauvhabzb 2y ago> You can make a good case to spend time sanitising requests > In most cases, it's not your system, though You can’t pick and chose whether you own a system or not when presented with an opposing argument. That’s not how this works.
- lores 2y ago"System owner, we need to spend $10K to sanitise requests or a kid can destroy our business overnight". "System owner, we need to spend $10K to clean up the database and code so that null and "null" are not the same thing, even though it works 99.99% of the time". Do you see the difference?
- hsbauauvhabzb 2y agoIf there are type confusion bugs related to SQL statements, I think SQL injection is likely to exist, if not some other super nasty bugs will eclipse it. You can waste 10k paying someone to look at it or you could not waste your money, but I’d be fucked before I sign off on a system with those kinds of bugs as being secure, evidence or not. Someone higher up can accept that risk, but I’d rather not be liable when it’s breached or catastrophically damaged because some kid changed their last name to an SQL injection payload. And yes, I’ve checked, in my country unpronounceable names are not permitted, otherwise I’d have one. There are existing case studies of this, iirc in the UK.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- munchler 2y agoI don't buy that. The string "Null" is different from the keyword null in programming, so `if $var = null` would be false when $var is the string "Null". Note that when interpolated into SQL, the contents of $var must be surrounded by single quotes, so you end up with `insert into Table (Name) values ('Null')`, which correctly inserts the string "Null" into the table. If you were to leave off the quotes, you'd get a SQL syntax error for all other people, so that code would never make it into production. E.g. `insert into Table (Name) values (Smith)` is a syntax error.
- lores 2y ago> $req = "insert into people (name) ('$name')"; > $db.exec($req) Now you have "null" as strings in the DB in any language that interpolates null as "null". > select * from people where name is not null "Why do we see nulls in testing? Damn, the DB has dirty data. Go through the trouble of fixing it, or... > select * from people where name is not null and name != "null" The end. Sorry Mr Null.
- Terr_ 2y ago> I don't buy that. I think you underestimate how many systems are stringly-typed, not just in terms of problematic programming languages, but data traveling between different APIs or through literal dead-tree paperwork. They don't have to all fail at null handling, just one or two can gum up the works.
- mrkeen 2y agoI don't buy that type-checkers would look at the value null, and say "Yep, that's a String/Integer/User". But here we are.