Hacker News Reader

Comment by tptacek | Hacker News Reader

If you specifically log failed database queries, where "failure" means "indicative of SQL injection", then nothing you can do with the schema is going to reduce the signal in that feed --- even a single SQL syntax error would be worth following up on. No, I don't think your logic holds.

View on HN

I don't understand your logic. Knowledge of the schema can give an attacker an edge because they now know the exact column names to probe. Whether these probes get logged is irrelevant; even if it makes the system more vulnerable for an instant, it's still more vulnerable.

Even if logging failed queries is your metric, then knowledge of column names would make it more likely for an attacker to craft correct queries, which would not get logged, thus making your logs less useful than if the attacker had to guess at column names and, in so doing, incur failed queries.

To probe for what? How does knowledge of a column name make it easier for me to discern whether a SQL injection vulnerability exists? I've spent a lot of time in my career probing for SQL injection, and I can't remember an instance where my stimulus/response setup involved the table names.

SQL injection is a property of a SQL query, not of the schema itself. To have a meaningful chance of blind-one-shotting a query, getting a TRUE/FALSE answer about susceptibility without ever generating a SQL syntax error, I would need to see the queries themselves.

Knowledge of the column names doesn't give you insight into whether a vulnerability exists. It gives you insight into what you can do with a vulnerability, should it exist. For example, if you want to set your account balance to $1 million, you'd need to know the column name in order to generate a valid query. Without advance knowledge of the column name, your job becomes harder.

SQL injection will give you the entire schema anyway. It doesn't help if someone tells you the col names beforehand. I'm more wondering about non-SQL-injection vulns.

SQL injection isnt just an ssh tunnel to the database. If the line you've injected isnt a select and the backend never fetches it how does the injection give you the column names?

Wait, this is known as a blind SQLi, and it's not so blind. You can still use timing to get the info you need one bit at a time. This may be slow, but it's doable without triggering any DB errors, so you have time.

people come up with the darndest things.

Yeah, it's a cool trick and not obvious. I think when I said SQL injection gets you the schema, I was recalling some faint old memory from a security course without remembering why this is doable.

I've seen this done by enumerating possible table names.

That's a typical way, but the errors might alert them, and of course maybe the names aren't so easily guessed.

Oops you're right, it's possible that you have no way to read things back.

> How does knowledge of a column name make it easier for me to discern whether a SQL injection vulnerability exists?

It doesn't. It just means that as soon as you find one, you can immediately begin crafting valid queries instead of randomly guessing table names and columns, therefore not setting off the "DB query failed" alert.

EDIT: I guess this is the part I missed:

> To have a meaningful chance of blind-one-shotting a query, getting a TRUE/FALSE answer about susceptibility without ever generating a SQL syntax error, I would need to see the queries themselves.

Really? I guess I have to take your word for it because I've never attempted it, but I would have thought that in some (horribly broken) systems `bobby tables' or 1=1 --` would have a very reasonable chance of detecting SQL injection without alerting anyone.

You can craft valid queries that don't reference any table or column name.

Right, and that's what you use to find the vulnerability. But imagine you've found the vulnerability and now you want to use it to update all of your parking tickets as paid. Without the schema, this is going to be quite tricky and will generate a lot of failed SQL. With the schema, you might be able to do it on your first try.

Which is why in the ordinary course of a pentest you'd use the SQL injection vulnerability to recover the information in the schema.

Is there not any SQLi vulnerability in practice that doesn't allow such an information recovery? That is, is the schema-recovery step so foolproof that it can always be performed on any target form? GP is suggesting that this may be difficult, depending on the kind of signal that gets returned from the form.

In my entire experience as a software security practitioner, which at the time of my testimony encompassed some hundreds of assessments of SQL-backed websites, the availability of a schema has never impacted my ability to exploit a SQL injection. It's not my job as an expert witness, nor Matt's job as a plaintiff, to invent improbable scenarios where security could hinge on schema availability. The court (all of them, in fact) found that testimony dispositive, so I'm happy to leave the issue there.

"Blind" SQLi is a thing, but even in the real-life example I could find, it wasn't exactly blind. They could still use the timing to get one bit of info at a time and discern the email addresses. https://www.invokesec.com/2025/01/13/a-real-world-example-of...

It's hard to imagine a case where you can't even get info based on timing. But it requires more effort and knowledge to exploit this.

Maybe I'm ignorant, but if the account the app is using doesn't have access to the information_schema how do you do this?

I don’t think that’s a very common setup but perhaps I’m just exposing my own ignorance. Just consider the popularity of ORMs. They explicitly load the schema into the application in many cases.

Not just that, but perhaps the app is smart enough to lock you out the second it detects an attempt to gather the schema, e.g. by logging and automatically responding to a query that displays the schema. Then you have to look for other ways in (another IP, etc.). But if you know the schema in advance, you have a better chance of a one-shot injection that accomplishes your malicious goal.

In other words, advance knowledge of the schema may make it easier to act maliciously.

> nothing you can do with the schema is going to reduce the signal in that feed --- even a single SQL syntax error would be worth following up on

Syntax errors coming from your web application mean there is a page somewhere with a bugged feature, or perhaps the whole page is broken. Of course that's worth following up on?

Edit: maybe I should add a concrete example. I semi-regularly look at the apache error logs for some of my hobby projects (mainly I check when I'm working on it anyway and notice another preexisting bug). I've found broken pages based on that and either fixed them or at least silenced the issue if it was an outdated script or page anyway. Professionals might handle this more professionally, or less because it's about money and not just making good software, idk

> Syntax errors coming from your web application mean there is a page somewhere with a bugged feature, or perhaps the whole page is broken. Of course that's worth following up on?

This is a government system, with apps probably built by lowest-bid contractors.

I imagine most of us would be horrified by the volume of everyday failed queries from deployed apps.

Can be, but I'm not sure it's worth investigating whether a particular deployment has such a specific monitoring system before being able to do a FOIA. The schema is marginally relevant for attacks at best (with heavy emphasis on just how marginal it is) and that's no barrier to releasing it

Reply on news.ycombinator.com