51–60 of 82 posts
https://www.youtube.com/watch?v=ekr2nIex040
ROSÉ & Bruno Mars - APT. (Official Music Video)
As someone who’s done a fair amount with parsing of Unicode strings lately, I’m not at all surprised by this bug. Unicode is a surprisingly elegant system but also an open invitation for all kinds of abuse.
> Unicode is a surprisingly elegant system… s/elegant/clever What could go wrong? I bet unicode is how AGI escapes and enslaves humanity.
Working with Unicode is anything but elegant, but that’s another story.
> Now, all of this might have been fine had Beyond Trust not written a feature which allowed users to directly, programmatically interact with psql (the postgres command line interface). That's the buried lede. Yes, there was a vulnerability in psql... but that's so much less a problem than the huge gaping hole of allowing users to directly interact with psql. No DB can be safe if you are turning untrusted user comma…
Let's be clear: Beyond Trust is not a company that wrote a database-backed web app and made the all-too-common mistake of writing insecure code that tickled a bug in the database that allowed privilege escalation. Beyond Trust's is a company whose entire contribution is adding a security layer to prevent privilege escalation , and their solution here was to bypass Postgres's standard functionality and use this weird…
we now have one job to ask for accountability and will not do it.
SELECT * FROM users WHERE username = []raw-text-of-len-not-parsed-at-all
SELECT * FROM users WHERE username = [21]flyin' and wavin' guy
^^^^^^^^^^^^^^^^^^^^^
these 21 chars are NOT parsed AT ALL, just taken as data
> Now, all of this might have been fine had Beyond Trust not written a feature which allowed users to directly, programmatically interact with psql (the postgres command line interface). That's the buried lede. Yes, there was a vulnerability in psql... but that's so much less a problem than the huge gaping hole of allowing users to directly interact with psql. No DB can be safe if you are turning untrusted user comma…
Let's be clear: Beyond Trust is not a company that wrote a database-backed web app and made the all-too-common mistake of writing insecure code that tickled a bug in the database that allowed privilege escalation. Beyond Trust's is a company whose entire contribution is adding a security layer to prevent privilege escalation , and their solution here was to bypass Postgres's standard functionality and use this weird…
The problem is that getting information security right is a matter of process control, which everyone hates, and so CEOs are absolute suckers for being sold a product which magically "adds on" security. This is like trying to buy "anti-lead-paint" rather than actually remove all your existing lead paint.
>Beyond Trust did their due diligence by properly calling a sanitization method on the user’s string input using it in a PostgreSQL query. This is not due diligence. In band messaging of user controlled data has been proven to be bad for security and this is not the first time "escaping" user controlled data for SQL has been done incorrectly.
Earlier quoted context omitted.
> They sanitized the data, so it should have been fine. This is a 101 rookie level approach to SQL or injection defense. It's dumb for exactly the same reason why this is dumb "SELECT * FROM foo WHERE bar=" + sanitize(userInput) The correct way to do something like this will always be parameterized input which looks something like this "SELECT * FROM foo WHERE bar=?" bindParameter(1, userInput); Why? Because that the…
> The correct way to do something like this will always be parameterized input which looks something like this > Why? Because [] the postgres protocol splits out the command and the data for the command in a way that can't be injected. I'm not sure I'm comfortable with this. You can create a prepared statement and then pass user input to it as parameters, sure. https://www.postgresql.org/docs/17/sql-prepare.html But…
BeyondTrust used it as input to the 'psql' tool, which is an interactive tool you're not really supposed to programmatically invoke, and the documentation for the postgres escape function didn't say it escaped input for psql. Even though postgres was fine calling it a CVE and fixing it, I think this is 100% on BeyondTrust for assuming that escaping a string for a postgres query meant it was safe for psql.
If BeyondTrust had just used it as part of a postgres query string, the escape function would have been sufficient.
.... and that's also exactly the reason that using parameterized queries is better. With parameterized queries, the escaping and the query parsing are done in the same place, so there's no chance of confusion for the programming language's string library to get in the way, or for the psql tool's input parsing to re-interpret and alter the escaped string before sending it over the wire.
Could someone please explain to me why "sanitizing database inputs" was ever considered a good idea? Why not just add a feature in SQL like so? SELECT * FROM users WHERE username = [ ]raw-text-of-len-not-parsed-at-all E.g. SELECT * FROM users WHERE username = [21]flyin' and wavin' guy ^^^^^^^^^^^^^^^^^^^^^ these 21 chars are NOT parsed AT ALL, just taken as data I am not very familiar with SQL so you might need a dif…
Earlier quoted context omitted.
> They sanitized the data, so it should have been fine. This is a 101 rookie level approach to SQL or injection defense. It's dumb for exactly the same reason why this is dumb "SELECT * FROM foo WHERE bar=" + sanitize(userInput) The correct way to do something like this will always be parameterized input which looks something like this "SELECT * FROM foo WHERE bar=?" bindParameter(1, userInput); Why? Because that the…
The more you work in software the more you should realize the developers writing security-critical software (in this case the one writing that sanitizer) are often/usually as clueless as you are. The solution? Hard to say.
Security by obscurity from self. It was very hard to explain to that person what was wrong with that line of reasoning.
Could someone please explain to me why "sanitizing database inputs" was ever considered a good idea? Why not just add a feature in SQL like so? SELECT * FROM users WHERE username = [ ]raw-text-of-len-not-parsed-at-all E.g. SELECT * FROM users WHERE username = [21]flyin' and wavin' guy ^^^^^^^^^^^^^^^^^^^^^ these 21 chars are NOT parsed AT ALL, just taken as data I am not very familiar with SQL so you might need a dif…
The basic idea behind your proposal exists and is called prepared statements. It's actually, I hope, the normal way to write queries these days.
You write your query like: "SELECT * FROM users WHERE username = ?" and execute your query like "execute(query, username)".
The problem? It's optional.