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

331–340 of 463 posts

Re: I Went to SQL Injection Court

#331

Post by tptacek »

Xelynega wrote: post #325
Y_Y wrote: post #62

Earlier quoted context omitted.

Of course I can't disagree that it's good that it's now settled. Still I can't help but imagine a world where the meaning, at least in terms of which words apply to which others (rather than qualifiers like "reasonable"), should be settled before the law is debated, voted on, and passed. Even (some) programmers have learnt the dangers of parsing at run time (e.g. "eval is evil"). How can we decide it's the law we wan…

That's not the only alternative though. Why are experts not involved in the interpretation and it's left up to how two seperate non-technical groups interpret it? Other countries have legal specialists for different areas and update their laws continuously based on expert opinion, common law gets expert testimony but is based on generalists to make the final determination

Something something something Article III of the US Constitution something.

Re: I Went to SQL Injection Court

#332

Post by hot_gril »

Xelynega wrote: post #328
hot_gril wrote: post #125

Earlier quoted context omitted.

Do you mean that section headings aren't a file layout? That's their entire purpose. Edit: If you're talking about the byte representation only, I don't think section headings indicate the placement of the body's bytes.

Does your interpretation not mean that(coupled with the court ruling that file formats can't be foia'd) any document with sections cannot be requested via FOIA?

If this format is reused across many files, they might want to give the contents of those docs in a different format from the original.

Re: I Went to SQL Injection Court

#333

Post by hot_gril »

pavon wrote: post #157
hot_gril wrote: post #49

Earlier quoted context omitted.

Schema is definitely software, a operating protocol, source code, and file layout. Maybe also documentation.

I think a schema will definitely be part of the source listing, either in the main programming language source code or in a some other file used to define or initialize the database. But I don't think it is software, any more than a protocol is software. Software does something. One tricky aspect of this is that even if the schema itself as a higher level concept doesn't fit into any of those definitions, all existin…

The schema defines how the DBMS sets up its tables and such, so it does quite a bit imo. And if the schema isn't stored in any doc cause just manually punched in CREATE TABLE once, yeah what you said about creating new docs.

Re: I Went to SQL Injection Court

#334

Post by Jean-Papoulos »

I understand freedom of information, but what exactly does the public gain by Matt getting the database schema ?

If the answer is "the ability of the request data from a specific table/column", I would say that this should possible to do by asking for the relevant data directly (instead of asking for "the timestamps of each ticket" ask for the "time-related data of each ticket" for example) ?

And yes, having your db schema out in the wild can be a vector of attack, if only because it allows targeting the sql injections (the blog author himself argues this in court).

The court was right to reject this. Maybe the exact word of the law doesn't ask for it, but the spirit certainly does.

Re: I Went to SQL Injection Court

#335

Post by dataflow »

tptacek wrote: post #310
AdamJacobMuller wrote: post #307

Earlier quoted context omitted.

> And I don't think I disagree with the court on schema vs. file layouts either. I disagree that the law should prohibit disclosing "file layouts" but it's pretty clear that the law does block that, and I fundamentally agree with you that schemas are directly analogous to file layouts and thus restricted.

A SQL schema literally does not indicate the locations of data inside of a file. In fact, the whole reason schemas exist is to decouple the relationships between table rows and the pages and indexes that store that data. We had relational databases before SQL, and there are non-SQL relational (and non-relational) databases today, but you program them, at the query level, with code that is aware of what tables live wh…

Let me put this differently.

If you tell me that you have a closet for your jackets and another closet for your shirts, you're telling me how clothes are laid out in your wardrobe. Specifically, you're telling me that you're laying those out separately, and able to deal with them independently, with little interference between the two. It's not the entirety of the layout information, but it sure is some of it.

If you tell me that you have a column for your first names and another column for your last names, you're telling me how names are laid out in your database('s files). Specifically, you're telling me that you're laying those out separately, and able to deal with them independently, with little interference between the two. It's not the entirety of the layout information, but it sure is some of it.

Sure -- in theory, you could be actually throwing everything together into a dumpster, then paying enough people to search it all in parallel when you want to retrieve that red jacket. If you're actually doing that, maybe you could legitimately claim that you haven't divulged anything about your closet's layout by telling me that shirts and jackets are separate. But chances are pretty darn good you're not actually doing that (and I would know this for a fact if I already somehow knew you were actually using closets built by Joe down the street), and thus actually are exposing layout information by telling me that you're storing them separately. One security implication of which is that, the moment that I get a glimpse of your closet and notice that it contains a shirt, I know it's not the one with the jackets, and I can skip it when trying to steal that expensive red jacket.

Re: I Went to SQL Injection Court

#337

Post by makach »

Does disclosure of a database schema really jeopardize the security of the system? Yes

How plausible or likely does that jeopardy need to be? Very

Does a database Schemas constitute “source code”? Yes

Is a SQL schema a “file format”? No & yes. In that order.

And, finally, does the “would jeopardize” language apply to everything in the exemption, or just to the nearest noun “any other information”? Yes

Re: I Went to SQL Injection Court

#338

Post by thaumasiotes »

WatchDog wrote: post #313
AdamJacobMuller wrote: post #307

Earlier quoted context omitted.

> And I don't think I disagree with the court on schema vs. file layouts either. I disagree that the law should prohibit disclosing "file layouts" but it's pretty clear that the law does block that, and I fundamentally agree with you that schemas are directly analogous to file layouts and thus restricted.

It seems like an unnecessarily ambiguous term. Without additional context, I would interpret the term “file layout” to mean the file and directory structure of an application. Such an application could potentially store data as plain files, the names of those files may contain personal or sensitive information.

> Without additional context, I would interpret the term “file layout” to mean the file and directory structure of an application.

I would interpret it to mean a description of what the file contains and where. This is information you need if you have a mysterious file and you want to parse it. It's also information you need if you have some data and you want to create a readable file that expresses it. But for the concept to apply to a database schema, (a) the database would have to be a file, and (b) the schema would have to specify where the information in the database is stored. That's difficult to do, since the schema has no knowledge of how much information there is in the database or how it might be written down.

Re: I Went to SQL Injection Court

#339

Post by IshKebab »

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.

There are trivial ways around all of those. `LIMIT 1`, `SELECT .. FROM information_schema...`, etc.

Re: I Went to SQL Injection Court

#340

Post by IshKebab »

valenterry wrote: post #300
wglb wrote: post #287

Earlier quoted context omitted.

Sanitization almost always fails. This becomes an arms race.

If you do it wrong, yes. Sure, there is no 100% security, but honestly, it's 2025. We already know the techniques how to prevent SQL injection of any kind. I wrote about this here: https://valentin.willscher.de/posts/sql-api/

Right but the case that is being imagined here is a site that perfectly sanitises * but somehow still allows SQL injection? I don't think so.
Post reply on HN