Implemented inconsistent encoding is one of the attack surfaces described here; there is more about the dangers in structured comparison and why it matters to cryptography and application security.
Thanks for the article, but I’m not sure if the title is faithful to the content. Isn’t it a big leap to go from all this to not recommending “user provided primary keys”?
UUIDs in upper case and lower case are both accepted by UUID parsers
The title is definitely where I began but not exactly where I ended up.
User provided primary keys and indexes is just the start of trusting user input, particularly where there is parsing and structure involved.
The shotgun parsing part of that article definitely caught my eye so I’ve appended a note about it to mine.
One time while driving in Kansas, I stopped at a gas station and filled up. But in order to afford access to the rest room, I had to ask for a key at the cashier. I received a PVC pipe with a key strung on the end. Is this normal in Kansas?
As someone from Kansas, yes, this is pretty common :)
It’s super-common all across Australia, any servo where you have to go outside the building to get to the toilet. Same with the ice storage freezers, unless you’re in the metro area and they’re in direct sight of the cashier.
If you use an embedded type like PostgreSQL UUID everywhere, then this is not an issue for you.
One could say that the Postgres approach here is “parse, don’t canonicalize”.
…oh, and right at the end there is that link :)
It truly is annoying that SQLite does not like types. But hey, there is a strict mode now at least, maybe useful native types will eventually come too.
This is a lot of words to say: don’t use inconsistent encoding for values that need to comparable.
Implemented inconsistent encoding is one of the attack surfaces described here; there is more about the dangers in structured comparison and why it matters to cryptography and application security.
Thanks for the article, but I’m not sure if the title is faithful to the content. Isn’t it a big leap to go from all this to not recommending “user provided primary keys”?
I’d like to mention that parsers shouldn’t just accept but they should actually parse.
The title is definitely where I began but not exactly where I ended up. User provided primary keys and indexes is just the start of trusting user input, particularly where there is parsing and structure involved.
The shotgun parsing part of that article definitely caught my eye so I’ve appended a note about it to mine.
As someone from Kansas, yes, this is pretty common :)
It’s the Toilet Mutex.
It prevents concurrent access to the io.
It’s super-common all across Australia, any servo where you have to go outside the building to get to the toilet. Same with the ice storage freezers, unless you’re in the metro area and they’re in direct sight of the cashier.
It is common across the US.
Mind blown
Heck, I’ve even seen this kind of thing in offices where the bathroom is shared with other tenants!
One could say that the Postgres approach here is “parse, don’t canonicalize”.
…oh, and right at the end there is that link :)
It truly is annoying that SQLite does not like types. But hey, there is a strict mode now at least, maybe useful native types will eventually come too.