Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 44 down vote accepted

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_2231 and your columns column_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 called articles, or if you have some subscription service you'll have tables subscribers or users, 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.

share|improve this answer
8  
+1 for hating LOL, and no I'm not trying to do such query. Thanks mate yours answer made me thinking –  Krystian May 6 '13 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). –  dr jimbob May 6 '13 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.  

share|improve this answer
2  
Point 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"). –  acolyte May 6 '13 at 17:58
    
@acolyte What if there is no gender setting in the application? (dramatic music here) –  ssg May 7 '13 at 10:54
1  
if 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? –  acolyte May 7 '13 at 13:08
1  
...what exactly is your point? –  acolyte May 7 '13 at 14:31
2  
IT 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. –  ssg May 8 '13 at 8:59

More information you expose more vulnerable you are, no matter of his priority in your security policies.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.