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

441–450 of 463 posts

Re: I Went to SQL Injection Court

#441

Post by fc417fc802 »

dataflow wrote: post #399
fc417fc802 wrote: post #383

Earlier quoted context omitted.

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

The point about the sandwich was that the inputs to a function are not correctly referred to as its output. Those are distinct things.

If you wanted to further extend the analogy to apply to schemas then I guess the recipe would be the database engine and the final product that you eat would be the file layout. Knowing that the final dish will include jam does not mean that you have the final dish in your possession. The jam sitting on the counter is not the final dish.

Importantly, you don't even know how I'm going to use the jam. I could put it only on one half, or I could arrange it in stripes, or I could even use more than two pieces of bread! I might not even make a sandwich! I could even throw it all in a blender and make a (disgusting) smoothie.

Re: I Went to SQL Injection Court

#442

Post by sfink »

Muromec wrote: post #214
Y_Y wrote: post #48

Earlier quoted context omitted.

Like a hedge fund? Or are we including those committed to violence?

Would would you ever exclude ones committed to violence? Violence consistently works.

That's what you'd think, but actually violence mostly pushes things to the extreme and sinks the effort permanently. Nonviolent movements are often defeated by one side goading the other into losing control and doing something violent, at which point they immediately cede the moral high ground and lose the support of the masses. (The masses are mostly useless in pushing a movement forward, but are critical for a movement to succeed.)

Violence can work if you have the biggest club, but it's mostly ineffective at grassroots change.

Re: I Went to SQL Injection Court

#443

Post by el_snark »

Enjoyed the read. Good luck with the future developments.

Now a nerdy question. As someone who investigates SQL injections, why are you running a server based on nginx 1.4.6? Do you know something I don't? :-)

Re: I Went to SQL Injection Court

#444

Post by valenterry »

wglb wrote: post #415
valenterry wrote: post #300

Earlier quoted context omitted.

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/

The parser isn't shown there, so it isn't clear what would happen with weird input. Have you had anyone do a penetration test on it?

Well, I would suppose that you pick an existing parser that is well tested and battle proven. No need to write your own. For most languages those parsers already exist. I would also not write my own json parser, so why would I do that for SQL, which is even more complex?

But in any case, the weird input would just be rejected. In my case I'd get a "parser error" from my library and then wrap it into my own "query not supported" error and return that as a 400.

> Have you had anyone do a penetration test on it?

Actually, yes. The pen-testers were surprised about the technique but did not find any problems with it.

Re: I Went to SQL Injection Court

#445

Post by valenterry »

IshKebab wrote: post #437
dataflow wrote: post #353

Earlier quoted context omitted.

> 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. It could literally just reject anything with asterisks. It doesn't even need to do anything perfectly, it just needs to do it enough to produce hurdles for you. Like blowing through the number of attempts you realistically have remaining.

You vastly underestimate the creativity of people that bypass imperfect sanitisers.

I think sanitizing is the wrong word in this context. That sounds as if the idea were to take the SQL, try to ensure it's valid and then run it. That approach is of course very risky and I'd never do that.

No, my idea (as you can see from my post) is: parse the SQL, then check the resulting structure (that is basically a whitelisting process) and then turn the structure into SQL again. The last part is crucial, because it means that you have turned a whitelisted structure into SQL. Or in other words: even if some evil person found a bug and was able to convince the sql parser that everything is fine even though it is not, they would not be able to leverage that, because you are not actually running their SQL.

Or to be more concrete: let's say the parser thinks that something is a comment, but the DMBS would actually run it as SQL - then that would be a problem if you jsut sanitize the SQL. But it's not a problem if you turn the SQL structure into SQL again, because your code to do that would just reject anything that it doesn't expect (and that definitely includes comments).

Re: I Went to SQL Injection Court

#446

Post by aja12 »

fifticon wrote: post #386
dataflow wrote: post #347

Earlier quoted context omitted.

> You can always `SELECT table_name, column_name, data_type FROM information_schema.columns`, which is part of the SQL standard. https://www.postgresql.org/docs/current/infoschema-columns.h . You can "always" do that? Well I just did that. My database said: no such table: information_schema.columns And what if my database had disabled this capability entirely? Also, is there anything implying SQL here at all? Can't o…

There is one further problem with this entire sub-discussion: There are two mitigation strategies discussed: - A: guaranteed SQL-injection-proof (SQL injection impossible.) - B: Having non-obvious table-names and 'secure-defaults' (e.g. INFORMATIONSCHEMA disabled). So, the original commenter says, he wants to _hide the schema_, so that B can protect him in case of A. Well, failure of A is Amateur Hour. If you fail on…

That's fallacious for two reasons:

1: you can set secure defaults at one place globally, but your code must be correct all the time to be free of SQLi

2: it's usually not the same persons who configure the DB and who write the code.

Security is an onion, not a coconut.

Re: I Went to SQL Injection Court

#447

Post by hot_gril »

HDThoreaun wrote: post #434
hot_gril wrote: post #431

Earlier quoted context omitted.

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.

Re: I Went to SQL Injection Court

#448

Post by thaumasiotes »

tptacek wrote: post #416
thaumasiotes wrote: post #414

Earlier quoted context omitted.

No, as other comments in the thread have pointed out, you can easily have an SQLI that doesn't send information back to you. You may find value in changing what's in the database even if you can't read from it. If you do have the ability to retrieve information, then one of the first things you'll do is retrieve the schema. And the reason you'll retrieve the schema, if you can, is that it facilitates the attacks you…

There is a whole sub-field of software security dedicated to retrieving information from SQL injections that don't directly return results. This is not a plausible objection.

Well, again, you make your attack and you retrieve the schema. Why did you do that?

Re: I Went to SQL Injection Court

#449

Post by eru »

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…

> A SQL schema literally does not indicate the locations of data inside of a file.

That's only true if you apply eg the Unix definition of what a file on a file system is (like a sequence of bytes or whatever).

For all we know, the law might take a broader view. Something like: a 'file' is anything that in the olden days you would have stuck into a filing cabinet.

The 'Unix' definition isn't even particularly natural: it's one specific level of abstraction. On disk, the bytes aren't necessarily laid out one after another. Especially with fragmentation, compression and encryption going on.

An SQL schema tells you how data is laid out in a different layer of abstraction than the Unix view of bytes. But that view isn't the only one that the law can mean by 'file'.

Re: I Went to SQL Injection Court

#450

Post by eru »

Xelynega wrote: post #323
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.

How can you literally interpret the two words "file layout" without it pertaining to the layout of a file?

I'm not sure whether 'file' necessarily has to refer to the 'Unix' view of a 'sequence of bytes'? Or just 'some organisational unit of information'? Ie like the stuff you would put into a filing cabinet?

The 'sequence of bytes' view is just one specific level of abstraction. It's not what's actually on disk because of things like compression, encryption and fragmentation.

Database schemas are a different level of abstraction.

Post reply on HN