I'm developing web application that uses database. I have to do some operations which needs database table names and db table schema. Will it be secure if I send this kind of information to client side (JavaScript via JSON) or should I keep those information on server side of my application?
Add a comment
|
4 Answers
Think about it this way
On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables
table_2231and your columnscolumn_4231(in which case I hate you), it's not gonna be difficult to guess your tables names anyway. If it's a news website, it's very likely you'll have a table calledarticles, or if you have some subscription service you'll have tablessubscribersorusers, and so on. Also, if your server is compromised, an attacker will figure out the table names almost immediately.On the other hand, if there's a way around it, there's no need to disclose it. If your security is taken care of, a layer of obscurity wouldn't hurt in that case. In fact, a layer of obscurity on top of good security measures is often a good thing.
However, I'm afraid you're trying to do something like this
SELECT * FROM $UNTRUSTED_INPUT WHERE blah = 1
In that case, absolutely not. Don't do it.
-
8+1 for hating LOL, and no I'm not trying to do such query. Thanks mate yours answer made me thinking– KrystianCommented May 6, 2013 at 8:44
-
6@Krystian - I agree. Use good names in your application for your own sanity, but there's no reason to expose the name of a table to a client in a web application. It is ok to use the same word (e.g., your table is naturally called 'comments' and your URL and website also naturally has the same word in it). But you are vulnerable to SQL injection if you take a client-side variable (even if its set by your code) that has a table name that eventually makes it to an SQL command as a string for a table name (unless your server side input sanitation is perfect--but this is easy to screw up). Commented May 6, 2013 at 9:27
Exposing table names might have broader consequences than you expect. For instance, you could be putting your company at legal disadvantage by disclosing a table names like deleted_messages, profile_views, single_female_users etc. Retention of that data and user privacy suddenly becomes a topic of discussion and can cost much.
You cannot always control that of course. A hacker can expose your table names as well. So the best practice would be creating tables like they will be public tomorrow but refraining from giving the information away.
-
2Point of order, but "single_female_users" sounds more like the name of a specific querey/view. Keeping information like that as a separate table would tend to be inefficient. for that matter, profile_views would most likely be a field on a specific table (possibly "users").– acolyteCommented May 6, 2013 at 17:58
-
@acolyte What if there is no gender setting in the application? (dramatic music here) Commented May 7, 2013 at 10:54
-
1if there's no gender setting in the app, why would the company/how would the company be separating out a completely distinct table to hold all single female users?– acolyteCommented May 7, 2013 at 13:08
-
1
-
4IT history contains many instances of "code/db goes public and becomes a PR scandal" events (such as Windows code containing swearwords, LinkedIn DB containing unsalted passwords). Table names are no exception. A table named after a joke, or containing EULA-violating information can be a big scandal for a company. If this does not makes sense still I don't know what does. Commented May 8, 2013 at 8:59
More information you expose more vulnerable you are, no matter of his priority in your security policies.
You can segment your tables into sensitive and general. Sensitive tables should not be "Exposed" but "Aliased". In the long run however, your solution is only as secure as the value it holds for the person interested in getting in.
