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

391–400 of 463 posts

Re: I Went to SQL Injection Court

#391

Post by lucb1e »

ethbr1 wrote: post #189
lucb1e wrote: post #180

Earlier quoted context omitted.

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

> 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

Re: I Went to SQL Injection Court

#392

Post by aerzen »

tptacek wrote: post #98
aqueueaqueue wrote: post #91

Interesting takeaways from me: All that pompous sounding legalese can still be ambiguous! I feel less bad for not understanding contracts that have 100 word compound sentences. Legal people can't keep up with our tech jargon but they have their own jargon including "predicate" lol. So same logical thinking, different jargon framework. Question: why do they want the schema not the data?

Because once you have the schema you can issue FOIA requests that include queries for them to run.

Could you ask them to run an introspection query? Something like SELECT * FROM information_schema.tables?

Re: I Went to SQL Injection Court

#393

Post by maratc »

tptacek wrote: post #320
HDThoreaun wrote: post #317

Earlier quoted context omitted.

I dont think "file layout" has to mean the exact location of every byte. An abstract file layout is still a file layout.

It is in literally no sense a layout; the whole point of a schema is that it doesn't tie you down to a layout. SQL schemas make sense even in the absence of files!

You suggest that we interpret "file formats" as exactly this -- no more, no less. This approach is also called "textualism". The other option is to interpret "file formats" in the context of the law that includes these words. Or: what exactly did the lawmakers have in mind when they said that (a) government needs to provide information; (b) except for several cases, of which one is (c) "file formats". What kind of information did they think it was ok for the government not to provide?

I agree with the Court's argument that "the information about how the actual information is stored and connected one piece to another" is what the lawmakers meant in this case.

- If the actual information is stored in the files, the government does not need to disclose how these files are organized ("file formats").

- If the actual information is stored in the database, the government does not need to disclose how the database is organized (database schema).

- If the actual information is stored in the block memory -- with structs and pointers -- the government does not need to disclose the structs and the pointers.

The "textualist" opponent would of course argue, as OP did, that the second and the third example aren't excepted by clause (c) because "when there is no file, there could be no file format". This however is missing the point (in my opinion), as it doesn't see the forest for the trees.

Re: I Went to SQL Injection Court

#394

Post by econ »

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…

If you have an injection friendly application then that is the security problem.

Say someone hacks the db, is the problem easy to guess table names? The column should never have be called "passwords"?

Perhaps 30 years ago that would sound good.

Obscurity should hardly ever be a line of defense. If it is the only defense the problem isn't that it wasn't obscure enough.

Edit:

I'll do you one better. If you so much as suggest that obscurity is good security you actually openly invite people to fool around with your applications. The odds holes are to be found are much better than elsewhere.

Re: I Went to SQL Injection Court

#395

Post by olau »

tptacek wrote: post #57
Y_Y wrote: post #53

Is it not absurd that the supreme and appeal courts disagreed on a syntactical matter? Never mind that this isn't uncommon, or that (IMHO) it would be ridiculous to interpret it as "any file layouts at all, and other stuff too, but only bad other stuff". It's crazy to me that were happy for laws to sit on the books being utterly ambiguous. I know this suits the courts who benefit from the leeway, and that (despite va…

To me it feels like the kind of dispute that is exactly why we have multiple levels of appeals court. The "file format" thing is super dumb, and they got it wrong, but the "that if disclosed" statutory interpretation is a thing that seems important to get a final, consistent determination on.

I find it slightly odd that you get hung up on the file format thing. The law as you quoted it says "including but not limited to" and the first example given is then "software".

Re: I Went to SQL Injection Court

#396

Post by wglb »

dataflow wrote: post #223
IshKebab wrote: post #211

Earlier quoted context omitted.

'); SELECT * FROM logins --

This fails if either the UI sanitizes wildcards, or if the database prohibits them, or if it produces so much data that you can't ingest it in time, etc.

Injections don't always need ''. The statements

  1=1
and

  1=0
if injected into a query will give different answers if SQLI exists.

There are MANY other tricks that don't involve ''.

Besides, consider the number of valid queries done by the application that involve '*'. You are not going to turn that off.

Re: I Went to SQL Injection Court

#397

Post by HDThoreaun »

econ wrote: post #394
dataflow wrote: post #194

Earlier quoted context omitted.

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…

If you have an injection friendly application then that is the security problem. Say someone hacks the db, is the problem easy to guess table names? The column should never have be called "passwords"? Perhaps 30 years ago that would sound good. Obscurity should hardly ever be a line of defense. If it is the only defense the problem isn't that it wasn't obscure enough. Edit: I'll do you one better. If you so much as s…

What do you do when you know you've got a pile of poorly written insecure software and no money to improve it?

Re: I Went to SQL Injection Court

#398

Post by Ylpertnodi »

scotty79 wrote: post #380

> Does the “would jeopardize” language in the statute apply to everything in the exemption, or just to the nearest noun “any other information”? I think law and lawmaking would be vastly improved if only lawyers learned the miracle of parentheses.

Comma's can be expensive, too.

Re: I Went to SQL Injection Court

#399

Post by dataflow »

fc417fc802 wrote: post #383
dataflow wrote: post #376

Earlier quoted context omitted.

> If I understand correctly, you're saying that you expect items in a column to tend to cluster near one another on disk. That's one thing I'm saying would be sufficient to consider this file layout, yes. I'm not saying it's necessary. Databases can obviously be row-oriented too. Knowing that they don't cluster would also be layout information. As could any number of other things. > Notably though that doesn't give y…

Note that "some information related to the file layout" or "some information that has an impact on the file layout" is not "the file layout" in a literal sense. Thus it seems to me to follow that the answer to the question "is this a file layout" should be no. Symbolically it isn't [ schema -> file layout ] it's [ schema, engine version -> file layout ]. Even if you had that additional information, neither item by it…

> I can fairly trivially fix a sandwich out of bread, peanut butter, and jam; in no way does that imply that the three ingredients sitting next to each other on the counter are a sandwich.

What is "sandwich" in this analogy? Nobody is claiming the schema is a "database", or a "table". I was saying it's one component of the file layout.

Using your own analogy: if you know you put the jam near the peanut butter, you know part of the ingredient layout. You can't say "it's not ingredient layout if you haven't told me where the bread is."

Re: I Went to SQL Injection Court

#400

Post by mcv »

dataflow wrote: post #223
IshKebab wrote: post #211

Earlier quoted context omitted.

'); SELECT * FROM logins --

This fails if either the UI sanitizes wildcards, or if the database prohibits them, or if it produces so much data that you can't ingest it in time, etc.

It also fails if the system was written using parameterized queries. I wouldn't expect a system to be sanitizing anything if fails to take the most basic step for db access. This whole discussion is only relevant for systems developed by amateurs. SQL injection can only work at all if you use string concatenation to create queries, which you should never do.
Post reply on HN