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

191–200 of 463 posts

Re: I Went to SQL Injection Court

#191

Post by cyanydeez »

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?

Many times the people answering the requests aren't part of the conspiracy to commit random acts of malice. Sometimes they're roped into it under threat of termination.

And often times, the denials eventually lead to significant reorg once judges and Congress can revise laws to fix the ambiguities.

Re: I Went to SQL Injection Court

#192

Post by jrockway »

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?

It's always a possibility that some low level official not in on the scam sees the FOIA request before management tells them not to work on it. The more you ask for, the less filtering there is going to be, simply because of how people work.

If you're running the scam, you don't want to tell low level employees about it, because they have no incentive not to blow the whistle.

Re: I Went to SQL Injection Court

#193

Post by chaps »

cyanydeez wrote: post #190
chaps wrote: post #184

Earlier quoted context omitted.

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.

Seems like you could asked for a verbally masked description? Like an enigma coda specific to the FOIA. "Describe to me the columns, in simple non-programmatic english, and what the purpose of the table is for, for each table related to parking tickets" Essentially a human to schema DSL That is only technically decipherable by the admin of the database. Then you're not having actual code and only the admin could deci…

I wish it were that easy easy. I'll go more into this specific question in my post, but the short answer is that FOIA does not statutorily require the creation of new records in response to a request. The gov agency creating a description of the data in response to the FOIA request would be creating new records. It's silly.

Re: I Went to SQL Injection Court

#194

Post by dataflow »

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 the "files" (records) are laid out on the "file system" (database tables). For example, denormalization is very analogous to inlining of data in a file record. The notion that filesystems are effectively databases itself is a well known one too. How do you argue they aren't analogous?

Re: I Went to SQL Injection Court

#195

Post by Muromec »

cyanydeez wrote: post #190
chaps wrote: post #184

Earlier quoted context omitted.

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.

Seems like you could asked for a verbally masked description? Like an enigma coda specific to the FOIA. "Describe to me the columns, in simple non-programmatic english, and what the purpose of the table is for, for each table related to parking tickets" Essentially a human to schema DSL That is only technically decipherable by the admin of the database. Then you're not having actual code and only the admin could deci…

They don't do describe, as it creates the new document, which is a blind spot of FOI

Re: I Went to SQL Injection Court

#196

Post by default-kramer »

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

Earlier quoted context omitted.

> 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-shott…

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.

Re: I Went to SQL Injection Court

#197

Post by shagie »

skissane wrote: post #90
copypasterepeat wrote: post #58

Earlier quoted context omitted.

I am not a lawyer, but my understanding is that's just how the justice system works. Reasonable people can disagree about what exactly a complicated statement says, since language is full of ambiguities. People have been discussing what the U.S. Constitution says exactly from the day it was written and there are still a lot of disagreements. The standard response to this is that laws should be written in ways that ar…

I’ve often thought we’d get more sensible results in court cases on computer-related issues if we had specialised courts where the judges were required to have a relevant degree (computer science, software engineering, computer engineering, information systems, etc). But I doubt it is going to happen any time soon.

It happens from time to time. https://www.theverge.com/2017/10/19/16503076/oracle-vs-googl... ( https://news.ycombinator.com/item?id=15834800 42 comments)

> These days, he often looks for some kind of STEM background for the IP desk. It’s not necessary, but it helps. Bill Toth, the IP clerk during Oracle v. Google, didn’t have a STEM background, but he told me that the judge had specifically asked him to take a computer science course in preparation for his clerkship. When I asked Alsup about it, he laughed a little — he had no recollection of “making” Toth take any classes — but he did acknowledge that sometimes he gives clerks a heads up about what kind of cases are coming their way, and what kind of classes might be useful ahead of time.

Note that it's not necessarily the judge that's important as an individual knowing the material, but that the clerks who work for the judge are.

Re: I Went to SQL Injection Court

#198

Post by default-kramer »

butlike wrote: post #169
Volundr wrote: post #155

Earlier quoted context omitted.

I'm not an attacker, just a boring old software dev. If there's an SQL Injection I'd say all bets are off re: schema. That said I've definitely worked on applications where knowing the schema could help you exfill data in the absence of a full injection. The most obvious being a query that's constructed based on url parameters, where the parameters aren't whitelisted. So I actually do agree that the schema could pote…

Wouldn't admitting this in court pin you with some sort of negligence? (if you knew having a schema revealed would compromise your app in some way).

"Defense in depth" is an easy argument to make. I sure hope I don't have any SQL injection holes, but I can't prove it with 100% certainty.

Re: I Went to SQL Injection Court

#199

Post by hot_gril »

SJC_Hacker wrote: post #114
crazygringo wrote: post #83

Earlier quoted context omitted.

Why not? Conceptually, that's literally what it is. Rows of values labeled by columns.

Spreadsheets are poorly structured. Different entries in the same column can have different data types. There is no concept of a superkey, so duplicates are allowed. There is a concept of ordering by row/column number which does not necessarily exist in a DBMS. Querying facilities are generally poor. Now you can kinda fix this by restricing the type of column, etc. but most people don't bother They are good at what t…

Excel sheets are databases. That's their purpose. They store rows/cols like an RDBMS. They allow joins and constraints, including uniqueness. There are even backends that use a spreadsheet as a DB. What else do you want?
Post reply on HN