34

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?

Adi
  • 43,808
  • 16
  • 135
  • 167
Krystian
  • 677
  • 1
  • 7
  • 11

4 Answers4

53

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.

Community
  • 1
Adi
  • 43,808
  • 16
  • 135
  • 167
  • 8
    +1 for hating LOL, and no I'm not trying to do such query. Thanks mate yours answer made me thinking – Krystian May 06 '13 at 08: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 06 '13 at 09:27
18

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.  

Trang Oul
  • 124
  • 1
  • 8
Sedat Kapanoglu
  • 721
  • 3
  • 16
  • 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 06 '13 at 17:58
  • @acolyte What if there is no gender setting in the application? (dramatic music here) – Sedat Kapanoglu May 07 '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 07 '13 at 13:08
  • @acolyte exactly :) – Sedat Kapanoglu May 07 '13 at 14:24
  • 1
    ...what exactly is your point? – acolyte May 07 '13 at 14:31
  • @acolyte making a joke? – Sedat Kapanoglu May 07 '13 at 21:51
  • no...am i missing something? – acolyte May 08 '13 at 01:32
  • @acolyte This was upvoted because the question reached the hot questions menu. I agree with you, it doesn't make sense at all. So there's no need to argue with ssg – Adi May 08 '13 at 08:03
  • @acolyte no, I was making a joke with single_female_users? oh my god this is getting more and more awkward. I think I'm slightly being pushed to explain the joke itself. – Sedat Kapanoglu May 08 '13 at 08:45
  • @ssg Table names such as `deteled_messagses` or `profile_views` or `single_female_users` are unrealistic. Even such information is stored, it wouldn't be a table itself. This is not Yahoo Answers, expect to be scrutinized, and if (and it turns out it's the case) the whole premise of your answer is a JOKE, then expect that someone will mention that to your face. – Adi May 08 '13 at 08:50
  • @Adnan my answer isn't a joke. I argued that table names if chosen badly, can put the company at legal/PR risk. It'sa perfectly valid possibility. My example of "single_female_users" was a joke, the rest, claiming that they are unrealistic requires a premise, such as an answer to "why?". – Sedat Kapanoglu May 08 '13 at 08:56
  • 4
    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. – Sedat Kapanoglu May 08 '13 at 08:59
  • And I cannot be more than glad to be reminded of that StackExchange-spawn web sites have a strict policy against humor in valid answers. That's not the first time I was warned about exposing my humane side and even punished for that. I'm sure that with sufficient effort, all SE users will fail Turing test at some point. Good job. – Sedat Kapanoglu May 08 '13 at 09:08
  • o.O i wasn't arguing, i was genuinely confused. i'm sorry for what i seemed to start. – acolyte May 08 '13 at 11:51
  • @acolyte No worries, obviously I should have been more explicit. It's not you I was referring to but the conceited, prejudgemental SE meta-culture partly demonstrated here. – Sedat Kapanoglu May 08 '13 at 12:40
9

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

Paloma Perez
  • 99
  • 3
2

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.

Justjyde
  • 121
  • 1