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

261–270 of 463 posts

Re: I Went to SQL Injection Court

#261

Post by ludston »

tptacek wrote: post #61
ludston wrote: post #40

Earlier quoted context omitted.

But on the other hand, in all database systems the schema is used to determine how the files are laid out. Although I suppose the same thing could be argued for any data that is stored in a file, excepting that a schema is metadata that determines the organisation of data so it's a bit of a special case.

In a Microsoft Word document, the section headings also tell Word how to lay out the Word document file.

Arguably, all requests for files could be returned with all of the letters in the document but scrambled in a random order soas to obfuscate the file layout.

Re: I Went to SQL Injection Court

#262

Post by londons_explore »

hot_gril wrote: post #259
default-kramer wrote: post #198

Earlier quoted context omitted.

"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.

I can't imagine how the schema would reveal SQL injection holes. Maybe other holes, though. Any poor choices for PKs, dumb use of MD5 computed fields, insecure random, misuse of NULL, weird uniqueness constraints (this also ties back to NULLs), vulnerable extensions, wrong timestamp type, too-small integer type, varchar limits, predictable index speed... Edit: More NULL, or maybe lack thereof cause they use the strin…

The schema can provide an insight into what the application developer was thinking when writing the code, which in turn can direct an attacker towards tricky corners where mistakes might have been made.

Re: I Went to SQL Injection Court

#263

Post by tptacek »

paulddraper wrote: post #253
tptacek wrote: post #121

Earlier quoted context omitted.

I don't follow your point.

Yes, it's a file format. (Kinda a file format inside a file format inside a file format.)

"Excel" is a file format, but my point is that if a schema is a file format, so are the contents of an Excel spreadsheet.

Re: I Went to SQL Injection Court

#265

Post by default-kramer »

hot_gril wrote: post #259
default-kramer wrote: post #198

Earlier quoted context omitted.

"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.

I can't imagine how the schema would reveal SQL injection holes. Maybe other holes, though. Any poor choices for PKs, dumb use of MD5 computed fields, insecure random, misuse of NULL, weird uniqueness constraints (this also ties back to NULLs), vulnerable extensions, wrong timestamp type, too-small integer type, varchar limits, predictable index speed... Edit: More NULL, or maybe lack thereof cause they use the strin…

> I can't imagine how the schema would reveal SQL injection holes.

It wouldn't. I'm just assuming that the thrust of the hypothetical negligence accusation was "The schema is useless unless you have SQL injection holes. So give us the schema or admit you are negligent!" But you're correct that there are other justifications one could make to keep the schema secret.

Re: I Went to SQL Injection Court

#266

Post by default-kramer »

tczMUFlmoNk wrote: post #217
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…

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... Plus, generally if you have SQL injection, you have multiple tries. You're not going to be locked out after one shot. And there's only so many combinations of `SELECT {id,userid,user_id,uid} FROM {user,users,login,logins,customer…

A good DBA would restrict the account so that it can't access the information schema. It's easy to imagine an environment with a vigilant DBA and less vigilant web developers.

Re: I Went to SQL Injection Court

#267

Post by tptacek »

qingcharles wrote: post #255
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-...

Matt, you do the Lord's work. Bear in mind that Matt technically lost this, even with the backing of some of the absolute best civil rights lawyers in the country, Loevy and Loevy, fighting on his behalf. This shows you the absurd difficulty in fighting city hall, especially if you're crazy enough to do it without representation. The one thing working in our favor is what is proposed in TFA: change the law. Once the…

A losing public body is also generally on the hook for attorney's fees, which can be considerable. But the general problem here is that the public bodies are all spending someone else's money, so the real deterrent you have is how much of their time you can credibly threaten to eat up with legal actions.

Re: I Went to SQL Injection Court

#269

Post by closeparen »

Waterluvian wrote: post #236
zachrip wrote: post #225

Earlier quoted context omitted.

That's a good point, has anyone hardened a database by locking out users who select columns that don't exist? Or run other dubious queries? This would obviously interrupt production but if someone is running queries on your db it's probably worth it?

On the surface that’s a very attractive idea. A sort of “you shouldn’t be in here, even if we left the door unlocked.”

So if you deploy code before you run the associated db migration, or misspell a column name, you magnify the impact from whichever code paths (& application tier nodes) are running the broken SQL, to your entire production environment.

Re: I Went to SQL Injection Court

#270

Post by hot_gril »

londons_explore wrote: post #262
hot_gril wrote: post #259

Earlier quoted context omitted.

I can't imagine how the schema would reveal SQL injection holes. Maybe other holes, though. Any poor choices for PKs, dumb use of MD5 computed fields, insecure random, misuse of NULL, weird uniqueness constraints (this also ties back to NULLs), vulnerable extensions, wrong timestamp type, too-small integer type, varchar limits, predictable index speed... Edit: More NULL, or maybe lack thereof cause they use the strin…

The schema can provide an insight into what the application developer was thinking when writing the code, which in turn can direct an attacker towards tricky corners where mistakes might have been made.

That's true.
Post reply on HN