17

I quite often see opportunities to optimise server-side code if HTML form names are exactly the same as the database field names they eventually update.

The drawback obviously is that this is exposing information about the database structure in plain sight.

Of course this information is only useful if other weakness exist but it does seem like handing information on a plate.

I'd be interested to know if people think this is low risk and if they do expose field names like this without worrying.

Imag1ne
  • 365
  • 2
  • 5
  • Here is a related question which may add some perspective: http://security.stackexchange.com/questions/108515/benefit-of-randomly-generated-column-names – TTT Jan 07 '16 at 19:42

3 Answers3

23

It is very common to do this. As you've noticed, there is a significant benefit for keeping code simple.

If you do have an SQL injection vulnerability, an attacker can figure out your database structure using INFORMATION_SCHEMA. So hiding your database structure doesn't help you a great deal.

Another concern in this area is Mass assignment vulnerabilities. Perhaps a user is allowed to update their user details - name, email, password, etc. But they are not supposed to be able to update the field "is_admin". With code that automatically routes form fields to SQL statements, sometimes vulnerabilities like this can appear.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • For the attacker to be able to exploit `INFORMATION_SCHEMA`, this particular injection must be able to return ample amount of data back to the attacker, which is not always the case. – Dmitry Grigoryev Jan 07 '16 at 14:17
  • 1
    @DmitryGrigoryev - you can use INFORMATION_SCHEMA in a blind injection. sqlmap does it well – paj28 Jan 07 '16 at 14:18
  • Could you elaborate, or give a link on this? My experience tells me that with a blind injection you often have to guess table and field names char by char, as in [this example](http://www.securityidiots.com/Web-Pentest/SQL-Injection/Blind-SQL-Injection.html). If you don't call your table "users", it may take a while. – Dmitry Grigoryev Jan 07 '16 at 14:29
  • 1
    @DmitryGrigoryev - You could look in the sqlmap manual. If you try sqlmap against a blind injection, it can enumerate tables, columns, data, etc. – paj28 Jan 07 '16 at 14:35
  • 1
    I have learned something today! (c) Updating my answer to make it look less lame. – Dmitry Grigoryev Jan 07 '16 at 14:51
  • I would always include a step that listed expected inputs to avoid the Mass assignment situation, to me not having that is far too risky – Imag1ne Jan 07 '16 at 17:01
4

One common scenario where disclosing DB field names to the attacker ruins the security is SQL injection. In this case, the attacker may not be able to execute show tables, select * from INFORMATION_SCHEMA.TABLES and the like, to get the whole database structure. He may have very limited read access (e.g. blind SQL injection). Figuring out the DB structure in such cases may require some time and knowledge.

If you give the attacker hints about DB tables and fields, he may just try out several injections using the names you provide him. The attack will be much faster, require less qualification from the attacker, and much more difficult to detect in the logs.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
0

I think exposing database fields names is not a good practice but it is not that high risk for the fields themselves, because in order to access those fields, one has to hack your database credentials , and once the credentials are stolen , then it doesn't matter they know the fields already or not , they will explore it themselves what they want.

Having said this , the exposed database fields may be used for some other kind of security attack. (at Information gathering step)

The conclusion is : Never expose the fields names if you don't have to.

Ijaz Ahmad
  • 1,592
  • 1
  • 11
  • 20
  • I agree, though if you ever find an unescaped input and you know the field names....GG – TheHidden Jan 07 '16 at 13:41
  • I don't understand what the low risk is. If you (the defender) and I (the attacker) both know, understand, and follow best practices and I understand your problem domain pretty well, then I can probably come up with a schema (including field names) that is very similar to yours. – emory Jan 07 '16 at 14:59