Shay Rojansky <r...@roji.org> writes: >> I don't think that's true - schema information (table, column names) >> definitely seems like it's in a different category than table contents. > > You're not visualizing this with the appropriate amount of paranoia: just > because the database thinks that something is a table or column name > doesn't mean that that's what it actually is. A screw-up in query syntax > could lead to reporting back something that was really a data value. > Admittedly, that's not very likely given a well-debugged application > issuing the queries, but it's not something to ignore either.
Good point, thanks. I guess the main thing I'm trying to say is that in the standard, "default" scenario we should consider doing our best to avoid data leaks, rather than approaching this as a 100% all-or-nothing problem.. >> First, there are many lazily-written applications out there which simply >> show exception/error messages to users. So user A could interact with a >> website in a way that triggers a unique constraint violation, and thereby >> get access to the data in the row which caused the violation. > > Well, that's just bad webapp design ... True, but as this is a potentially critical security/privacy concern it seems reasonable to do what we can to prevent these leaks, even if ultimately they are the app developer's fault/responsibility. Basically at the moment there's a "pit of failure" where an inexperienced dev doing a standard application has a high chance of encountering this issue, and unfortunately most of the Internet is made up of this scenario. I'm only proposing to protect against the obvious/easy data leak scenarios via an opt-in.
