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

221–230 of 463 posts

Re: I Went to SQL Injection Court

#221

Post by [deleted] »

9dev wrote: post #186
chaps wrote: post #56

Earlier quoted context omitted.

Hard to say. One of my personal drivers for this lawsuit is a tip I received that said that Chicago has a list of vendors whose tickets are dropped in the back-end. When I requested that info, the city said they had no such list. I trust my source, so having schema information could help figure out the extent and if they were lying.

Earnest question: If you suspect them of lying on the issue, why would you trust them to release the full schema in response to the FOIA request, and not just omit any possibly incriminating columns?

[deleted]

Re: I Went to SQL Injection Court

#222

Post by skissane »

ptsneves wrote: post #141
skissane wrote: post #90

Earlier quoted context omitted.

I’ve often thought we’d get more sensible results in court cases on computer-related issues if we had specialised courts where the judges were required to have a relevant degree (computer science, software engineering, computer engineering, information systems, etc). But I doubt it is going to happen any time soon.

Civil code law uses that way of thinking, where there are specialised courts for different areas: administrative, civil, labor, family, commercial and so on. I actually am not so sure it is great as these courts increase the depths of the bureaucracy to the point of being self serving. They also serve to segment expertise.

> Civil code law uses that way of thinking, where there are specialised courts for different areas: administrative, civil, labor, family, commercial and so on.

This happens in common law countries too. For example, the US has specialised courts (at the federal level) for bankruptcy, federal government contract disputes (US Court of Federal Claims), taxation (US Tax Court), among others. It also has a nationwide appellate court (Federal Circuit) with jurisdiction limited to certain topics (patents, trademarks, federal government contracts, among others), and another (DC Circuit) which despite being technically geographic in practice also has topical jurisdiction (many-but not all-lawsuits against federal agencies). Many states have specialised courts for various areas of law

It is very common in common law countries to have specialised courts/tribunals (or divisions thereof-there isn’t a big difference between a specialist court and a specialist division of a generalist court) to deal with certain types of cases, especially bankruptcy, family law, probate, child welfare, juvenile crime, patents, taxation, administrative law, military law, immigration, small claims - the exact set varies, but specialised courts/tribunals/divisions are very common.

But I’ve never heard of a specialised court/tribunal/division for computer cases

Re: I Went to SQL Injection Court

#223

Post by dataflow »

IshKebab wrote: post #211
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…

'); 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.

Re: I Went to SQL Injection Court

#224

Post by gerdesj »

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's where the court's technical distinction between the words: "could" and "would", is important. It appears they have reduced the distinction to a risk assessment which is more objective than opining wildly!

For example: I've just re-wired a three gang light switch. I verified power on with my multimeter (test the meter), cut the power and then retested all the circuits to make sure I had got it right.

It turns out that switch three is on a separate ring main. Cool I didn't get to test my body's ability to take a whopper of a shock. In the UK it is common to have upstairs and downstairs rings for light circuits. Our kitchen has quite a few lights in it so it got a separate ring as well. Anyway there are quite a lot of wires in there because all of them are two way switches. Oh and I am allowed to work on them because of the switch location - not kitchen and not bathroom, ie a low risk location

I noted down the connections, and took them all out. I put Wagos over the flying ends to make them safe, turned the power back on and got on with the job in hand.

I then cut the power (both circuits) checked again with my Fluke. Oh bollocks ... enable power, test the Fluke and then cut power again and recheck the circuits.

Now I re-terminated all the connections. There was plenty of additional wire so I decided to cut and re-strip the conductors, to make sure that I avoided potential failures due to "work hardening" from the inevitable pushing and pulling and "gentle" forcing into position. Once all the conductors were screwed down I pulled on them fairly forcefully to make sure they wont fall out.

I screwed down the switch face plate and restored power. Its a brushed metal finish switch so I did test it was not live, because I'm careful. I tested the functionality ie all three switch circuits (three) from all the switches (six).

So, given that description is it possible that the connectors might fall out in the future and short on say, the metal back box. Of course it is possible. It could happen but would it happen?

You could postulate all sorts of scenarios. Perhaps I may be careful but I might be cack handed and forgetful and got something wrong anyway and a wire might still drop out. Now we are at the point of whataboutery! and that wont wash.

The would/could distinction is a powerful one and it is analogous to how we do risk assessments.

I'm certainly not saying you are wrong in your assessment but I think you are fiddling with details to conjure up a "could" and not a "would". I agree that knowing the schema would assist a hacking attempt but would it make a successful crack more likely - no I don't think so. It is a classic case of obscurity despite security but a rather more complicated one than putting the ssh daemon on port 2222.

Cripes - I need to get out more!

Re: I Went to SQL Injection Court

#225

Post by zachrip »

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…

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?

Re: I Went to SQL Injection Court

#226

Post by kmoser »

tptacek wrote: post #129
kmoser wrote: post #126

Earlier quoted context omitted.

I don't understand your logic. Knowledge of the schema can give an attacker an edge because they now know the exact column names to probe. Whether these probes get logged is irrelevant; even if it makes the system more vulnerable for an instant, it's still more vulnerable. Even if logging failed queries is your metric, then knowledge of column names would make it more likely for an attacker to craft correct queries,…

To probe for what? How does knowledge of a column name make it easier for me to discern whether a SQL injection vulnerability exists? I've spent a lot of time in my career probing for SQL injection, and I can't remember an instance where my stimulus/response setup involved the table names. SQL injection is a property of a SQL query , not of the schema itself. To have a meaningful chance of blind-one-shotting a query,…

Knowledge of the column names doesn't give you insight into whether a vulnerability exists. It gives you insight into what you can do with a vulnerability, should it exist. For example, if you want to set your account balance to $1 million, you'd need to know the column name in order to generate a valid query. Without advance knowledge of the column name, your job becomes harder.

Re: I Went to SQL Injection Court

#227

Post by kmoser »

default-kramer wrote: post #206
tptacek wrote: post #202

Earlier quoted context omitted.

Which is why in the ordinary course of a pentest you'd use the SQL injection vulnerability to recover the information in the schema .

Maybe I'm ignorant, but if the account the app is using doesn't have access to the information_schema how do you do this?

Not just that, but perhaps the app is smart enough to lock you out the second it detects an attempt to gather the schema, e.g. by logging and automatically responding to a query that displays the schema. Then you have to look for other ways in (another IP, etc.). But if you know the schema in advance, you have a better chance of a one-shot injection that accomplishes your malicious goal.

In other words, advance knowledge of the schema may make it easier to act maliciously.

Re: I Went to SQL Injection Court

#228

Post by 0x457 »

hot_gril wrote: post #142
kelnos wrote: post #107

Earlier quoted context omitted.

We're talking about "file layout" at the application level, not the filesystem level. But your comment illustrates just how difficult it is to nail these things down, based on inherently imprecise language.

So you mean the filetree and file contents, as seen by userspace program? It's meant to be imprecise, because they didn't want some "gotcha." If they say we won't reveal the disk layout, technically you can't tell that from the filetree. If they won't reveal the filetree, but this is SQLite, it's always a single file. If it's file tree + contents, well the CPU byte endianness might matter for some DBMSes, even though…

We can't FOIA details about how xls file laid out internally, despite that xls file being FOIA'ble itself. That's the file-format we're talking about.

Re: I Went to SQL Injection Court

#229

Post by contravariant »

EMIRELADERO wrote: post #95

Am I the only one slightly perplexed/worried by the point-blank source code exemption? It's easy to imagine a scenario where the city decides to develop a specific software in-house and hide the "biases" in the source code, or any other thing one might not find desirable. Hell, they don't even need to make everything from scratch! Could just patch and use a permissively licensed 3rd-party component. In my opinion, th…

In theory the decision to put those biases in the code should be public information. You can ask for the criteria the software was made to, just not the software itself.

Though rulings like this might have a chilling effect.

Post reply on HN