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

381–390 of 463 posts

Re: I Went to SQL Injection Court

#381

Post by jajko »

lyu07282 wrote: post #371
spoaceman7777 wrote: post #367

Earlier quoted context omitted.

You can definitely disable it, in a variety of ways, for whatever role, user, etc. you wish to.

Nevermind you are right its possible, but I still think it breaks so much stuff that at least I've never seen anybody doing it or recommending it. All kinds of ORMs and migration tools would break for example. But I guess it would be a defense-in-depth strategy.

Yeah those tools may break if such a change is introduced suddenly, without testing etc. But that's not how normal reality for most companies look like, such rules are there for 2 decades at least. DBs are very old tech without much change in past 20 years and this is DB security 101.

Not even going into reasonability of ORMs, most of the stuff I've seen or implemented added practically 0 added value, and added hard-to-debug issues down the line as software evolved. Cargo culting at its best, often done on trivial schemas that could handle either direct SQL or some sql-query-to-object mapping easily.

Re: I Went to SQL Injection Court

#382

Post by count »

hunter2_ wrote: post #289
count wrote: post #274

Earlier quoted context omitted.

Zane Lackey (with Dan Kaminsky) gave a talk that discussed doing literally that sort of things, back in 2013. Zane went on to found Signal Sciences (acquired by Fastly), doing this sort of stuff in the 'WAF' space. https://youtu.be/jQblKuMuS0Y?t=866 (timestamp is when Zane starts talking about it)

I guess the main difference is that a WAF attempts to spot things like injection (unbalanced delimiters, SQL keywords in HTTP payloads where SQL shouldn't exist, etc.) typically without knowledge of the schema, whereas GP is talking about the DBMS spotting queries where queries must exist but disagree with the schema. Might as well do both, I suppose.

That’s not what the talk is about - it’s using dbms query error logs to spot attackers. Stuff like “table doesn’t exist” or “invalid syntax” on your production database can be extremely high signal indications that something is wrong, potentially maliciously so.

Re: I Went to SQL Injection Court

#383

Post by fc417fc802 »

dataflow wrote: post #376
fc417fc802 wrote: post #374

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. Notably though that doesn't give you any sort of relative or absolute offset. Neither does it have anything to say about, for example, blocks of different types which might be interleaved. Or compression. Or indexes. Or copy on write related garbage collection. Or journaling. Or any number of other…

> 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 itself nor even the pair together would be correctly considered a file layout. If I have a function f( foo, bar ) -> baz neither a foo nor a bar is a baz. 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.

For that matter, even the [ schema -> file layout ] case isn't technically a file layout any more than a json blob is an xml blob. Being trivially translatable doesn't change the definition.

Compare that with the question (also commonly asked by courts) "is thing equivalent in intent (or use, or ...) to other thing" in which case the answer might feasibly be yes.

> Could you really claim the schema didn't contain any file layout information in that scenario, when it certainly affected which bytes are interpreted as belonging to which columns?

In that example you have made an educated guess about the file layout and then taken advantage of that (guessed) information. "You can imagine a database" tells you everything you need to know here, namely that this is entirely dependent on the implementation. So yes, I would claim that the schema did not on its own contain any file layout information though in conjunction with knowledge of the implementation it could be used to derive such.

Re: I Went to SQL Injection Court

#384

Post by gizmo »

Jean-Papoulos wrote: post #334

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…

Municipalities obstinately refuse reasonable requests because they resent that the Freedom of Information Act allows regular civilians to get all up in their business. The excuses they make for noncompliance (it's burdensome! it violates privacy! sql injection!) are not serious. They don't want to comply because they don't like accountability. That's it.

Re: I Went to SQL Injection Court

#385

Post by fifticon »

dataflow wrote: post #347
tczMUFlmoNk wrote: post #217

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

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

Your reasoning and motivation is reductio ad absurdum. It does not make sense to base your system security on hiding from the public that your 'Users' table is called 'Users'. If you are vulnerable to this attack, the guilt rests on your deplorable application code, not whether or not your schema table names are known. If we should follow your logic, we would have to name our Users table U_ZER_CLEVER_S because naming it something people could guess would be a vulnerability.

Re: I Went to SQL Injection Court

#386

Post by fifticon »

dataflow wrote: post #347
tczMUFlmoNk wrote: post #217

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

> 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 A, I highly doubt you would have delivered correctly on B. To write it out in plain text: If you have set up and manage an application with SQL injection errors, I have a hard time seeing you still taking care to disable /enable obscure security defaults, or take care to avoid obvious and trivial table names.

Just to put icing on the cake: As soon as you have an SQL injection attack, a simple select * from randomTable or DESC randomTable would give you the table COLUMNS, so it utterly makes no sense to want to hide those column names - you have already lost them! (in the case you are arguing you need their protection in). ..Unless you argue that the guy making sql injection applications ALSO has set up a secure default to disallow select *..

In my experience, SQL injection is evidence of work of the sloppiest and immature nature; it was bad in 2003, and presumably still is.

Re: I Went to SQL Injection Court

#387

Post by florbnit »

SkidanovAlex wrote: post #76

While I believe that the city should share the schema, and that the city is effectively argues for security through obscurity, I disagree with the main premise of the article: that knowing SQL schema doesn't help the attacker. If I understand the argument of the author here: > Attackers like me use SQL injection attacks to recover SQL schemas. The schema is the product of an attack, not one of its predicates The auth…

> that knowing SQL schema doesn't help the attacker.

Knowing the name of the service helps the attacker, knowing the name of government officials working at city hall helps attackers, knowing the legal description of what a parking ticket is helps attackers. If you are sued and decide you want to hack the government knowing the details of the suit against you helps you in your attack.

The barrier is not “any helpful information must be censored” the barrier is “don’t disclose passwords or code that would divulge backdoors” a schema cannot be that.

Re: I Went to SQL Injection Court

#388

Post by fc417fc802 »

tptacek wrote: post #55
pchristensen wrote: post #43

Earlier quoted context omitted.

My real goal is zoning. God speed to you sir! What is your goal wrt zoning?

The categorical elimination of single-family zoning along with any building envelope restrictions that would make as-of-right 3-flats uneconomical.

Rather than the complete elimination of single family (and by extension even larger lots) I feel like it ought to follow something resembling an iterated 80/20 rule out to huge rural lots at the far end. Notice that this would imply a plurality of the land being zoned for the highest density at any given time.

The thing that really kills density in most cases is the height restrictions. A lot of the upzoning in my area has resulted in ugly, wall-to-wall low-single-digit floor count buildings with near zero setback. It's better than single family but it isn't particularly dense and it's a huge step backwards aesthetically.

Re: I Went to SQL Injection Court

#389

Post by DangitBobby »

tptacek wrote: post #268
DangitBobby wrote: post #254

When a law is ambiguous by wording, why do they never ask the people who drafted the law what was intended?

The current sitting ILGA is not the ILGA that passed the statute.

They are probably still alive, shouldn't be that hard to find. They have no problem giving subpoenas to other witnesses or soliciting expert testimony.

Re: I Went to SQL Injection Court

#390

Post by DangitBobby »

jaza wrote: post #275
DangitBobby wrote: post #254

When a law is ambiguous by wording, why do they never ask the people who drafted the law what was intended?

That would be against the separation of powers doctrine inherent in all Western democracies. The job of the legislature is to write the law. The job of the judiciary is to interpret the law. Besides, when the law is ambiguous, it's very often because the legislature themselves weren't sure what they intended, and/or because the legislature had deeply divided views and arrived at ambiguous wording as a compromise, and…

I don't see how it could break separation of powers, especially if a legislator could provide minutes and/or a paper trail of discussions and revisions pointing the intent in a certain direction. You know, like evidence. The legislature surely has intent while writing the law, otherwise what would be the point in trying to interpret it, and the whole thing being litigated is the authors intent. I don't think the separation of powers doctrine presupposes that the legislature has no idea what their goals are while writing laws, that would be quite an insane assumption to bake into our system, and broken by design. And in this case, I very much doubt it was left intentionally ambiguous, since FOIA was clearly intended to help people get information from obstinate government agencies. What would even be the point in writing the law if obstinate government agencies are supposed to be able to weasel around the ambiguity behind a comma? Regardless, if we are able to ask the people who spent time drafting it, we could ask. There might even be a paper trail!
Post reply on HN