Comment by lyu07282
2 months ago
> You can "always" do that? Well I just did that. My database said: no such table: information_schema.columns
Don't expect attackers to give up after one try. It depends on the database software, not everyone implements this exact ANSI standard for reflection but every database supports reflection. That's why the first step after finding a SQLi is to fingerprint the database software and go from there.
> And what if my database had disabled this capability entirely?
You can't disable it, lots of software, database features, ORMs and clients rely on reflection. If a client can query a table they also can retrieve metadata about that table.
You can definitely disable it, in a variety of ways, for whatever role, user, etc. you wish to.
Absolutely, we have very strict lockdowns on the tables and views available to the users that our application uses. The permissions system in Postgres (for example) are very extensive. We even deny delete and update permissions for most tables so they become append only.
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.