Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Went to SQL Injection Court

sockpuppet.org

Post reply on HN
Print view View original

201–210 of 463 posts

Re: I Went to SQL Injection Court

#201

Post by Muromec »

chaps wrote: post #184
foota wrote: post #182

Earlier quoted context omitted.

I agree this is something of a technical solution, but the court wasn't interpreting whether you could ask for rows from a database, but whether you could ask for the schema directly. I don't think the court had the option of saying "you can't ask for the schema, but asking for a sample row is ok".

The short answer is yes, you can do this. I've seen this work for emails, where the request is basically, "Give me the most recent email of blah@gov.com". And yeah, the plan was to eventually submit a batch of requests using the table names, similar to `SELECT * FROM {table_name_from_schema_request} LIMIT 1`, but one FOIA request per-table.

I have once wrote a script that translated sql requests into proper Ukrainian legalize invoking the equivalent of FOI to quite citizenship statistics from the agency. It worked, but they were not very happy when I had to get to them on the phone.

Re: I Went to SQL Injection Court

#202

Post by tptacek »

default-kramer wrote: post #196
jstanley wrote: post #183

Earlier quoted context omitted.

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.

Re: I Went to SQL Injection Court

#203

Post by Muromec »

9dev wrote: post #186
chaps wrote: post #56

Earlier quoted context omitted.

Hard to say. One of my personal drivers for this lawsuit is a tip I received that said that Chicago has a list of vendors whose tickets are dropped in the back-end. When I requested that info, the city said they had no such list. I trust my source, so having schema information could help figure out the extent and if they were lying.

Earnest question: If you suspect them of lying on the issue, why would you trust them to release the full schema in response to the FOIA request, and not just omit any possibly incriminating columns?

Because this is not how government works. Most of the time it's not a heavily entranched conspiracy. Once the request is approved to go through by the legal department, some technician will happily give you everything you want and it won't be censored or tampered with in process.

Re: I Went to SQL Injection Court

#204

Post by Muromec »

MBCook wrote: post #143
chaps wrote: post #56

Earlier quoted context omitted.

Hard to say. One of my personal drivers for this lawsuit is a tip I received that said that Chicago has a list of vendors whose tickets are dropped in the back-end. When I requested that info, the city said they had no such list. I trust my source, so having schema information could help figure out the extent and if they were lying.

Well that certainly sounds suspicious. But it could also provide more damming evidence of targeting groups, people skimming the till, bribes to make tickets go away, all sort of fun shenanigans. And boy they’re fighting suspiciously hard. Good luck.

Bribes are most certainly not logged in the system under the "bribes" column or codified in any way. The data discovered through foi could show some patterns which are suggestive of bribes, but the actual thing is negotiated "off chain".

Re: I Went to SQL Injection Court

#205

Post by LegionMammal978 »

tptacek wrote: post #202
default-kramer wrote: post #196

Earlier quoted context omitted.

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.

Re: I Went to SQL Injection Court

#206

Post by default-kramer »

tptacek wrote: post #202
default-kramer wrote: post #196

Earlier quoted context omitted.

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 .

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?

Re: I Went to SQL Injection Court

#207

Post by tptacek »

9dev wrote: post #186
chaps wrote: post #56

Earlier quoted context omitted.

Hard to say. One of my personal drivers for this lawsuit is a tip I received that said that Chicago has a list of vendors whose tickets are dropped in the back-end. When I requested that info, the city said they had no such list. I trust my source, so having schema information could help figure out the extent and if they were lying.

Earnest question: If you suspect them of lying on the issue, why would you trust them to release the full schema in response to the FOIA request, and not just omit any possibly incriminating columns?

How is this different from literally any other FOIA transaction, computer-y or otherwise?

Re: I Went to SQL Injection Court

#208

Post by ra »

chaps wrote: post #35

Hi everyone, I'm the plaintiff in this lawsuit. I'm still working on my companion post for tptacek's post! I'll have it ready Soon TM, but feel free to me any questions in the meantime here. While you're waiting, check out this older post: https://mchap.io/that-time-the-city-of-seattle-accidentally-...

They can produce a report using english language labels instead of the db column names. Their argument isn't fact it's vexatious obstenance.

Re: I Went to SQL Injection Court

#209

Post by flutas »

kmoser wrote: post #164
Terr_ wrote: post #151

> Each spreadsheet has a header row, labeling the columns, like “price” and “quantity” and “name”. A database schema is simply the names of all the tabs, and each of those header rows. This is also how I explain it to my relatives, I'm kind of surprised this analogy (one so direct that it's almost literal) didn't fly with the judges. If database column names cannot be revealed, then shouldn't that mean the state is a…

Knowing a spreadsheet header doesn't help an attacker gain access to that spreadsheet in any way. Knowing SQL column names may give an attacker an advantage in accessing a database.

Per the post, this also wouldn't fly.

> Believe it or not, there’s case law on “would” versus “could” with respect to safety. “Could” means you could imagine something happening. But the legal standard for “would” is “clear evidence of harm leaving no reasonable doubt to the judge”. The statute set the bar for me very low and I managed to clear it.

Re: I Went to SQL Injection Court

#210

Post by ic4l »

dataflow wrote: post #194
chaps wrote: post #35

Hi everyone, I'm the plaintiff in this lawsuit. I'm still working on my companion post for tptacek's post! I'll have it ready Soon TM, but feel free to me any questions in the meantime here. While you're waiting, check out this older post: https://mchap.io/that-time-the-city-of-seattle-accidentally-...

I don't understand the argument that knowing the column names doesn't help an attacker? Especially in a database that doesn't allow wildcards, doesn't it make things much easier if you know you can do '); SELECT col FROM logins, as opposed to having to guess the column name? And I don't think I disagree with the court on schema vs. file layouts either. It's not the file layout, but it's analogous: it tells you how th…

I agree with you. Knowing the exact column names can speed up an attack and, in some cases, make it more feasible.

Why don’t they just request disclosure of what’s actually stored and allow renaming of the columns? It seems odd that knowing the exact column names would be necessary if the goal is simply to understand what data is being stored and its intended purpose.

Post reply on HN