6

Just wanted to ask.

I have site where each user is linked to an ID in the Database and this Primary Key is included in many tables. The fastest way for me to pull a users information is to have this ID.

Would it be considered bad practice to put this ID in website HTML code? eg id="theIDnumber"

Otherwise i can just use the username and then reference this in the Database for this ID - which is fine but using the ID would be faster I believe.

thoughts?

Adam
  • 19,932
  • 36
  • 124
  • 207
  • you can(rather, you should) access it using ID, since they are primary key – hjpotter92 Jul 12 '12 at 11:44
  • Your intuition was right. What is usually done is a hidden parameter in a form, for instance, with your user ID as a parameter, and you only display relevant infos, such as first, lastname. This way if you have two people named let's say John Doe, you'll precisely know which one you're talking about when communicating with your server. – Nicolas C. Jul 12 '12 at 11:47
  • is it ok to add this key in the HTML code - meaning other people can read it in the source code? or this doesn't really matter... thinking more about security here.. – Adam Jul 12 '12 at 11:47
  • Then that's a matter of choice. You'll have to send your server in a way or another the unique ID (even if not being the database primary key) if your server is protected enough, then sending the ID through a POST (and several other concerns) request should leave no hacking opportunities. I suggest you read this : http://programmers.stackexchange.com/questions/46716/what-should-every-programmer-know-about-web-development – Nicolas C. Jul 12 '12 at 11:49

1 Answers1

6

I'd say no, if your keys are predictable. A trivial example: if you are using sequentially incrementing primary keys users can extract information from data that could be a privacy concern. e.g. they can infer which account was created before their account. Life also becomes easy for those trying to systematically leech information from your site.

Some related reading

  1. https://stackoverflow.com/a/7452072/781695

    You give your end users the opportunity to mess with those variables and pass any data that they like. The counter measure to mitigate this vulnerability is to create indirect object references instead. This may sound like a big change, but it does not necessarily have to be. You don't have to go and rekey all your tables or anything, you can do it just by being clever with your data through the use of an indirect reference map.

  2. https://security.stackexchange.com/a/33524/37949

    Hiding database keys isn't exactly required, but it does make life more difficult if an attacker is trying to reference internal IDs in an attack. Direct references to file names and other such internal identifiers can allow attackers to map the internal structure of the server, which might be useful in other attacks. This also invites path injection and directory traversal problems.

  3. https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet

    An object reference map is first populated with a list of authorized values which are temporarily stored in the session. When the user requests a field (ex: color=654321), the application does a lookup in this map from the session to determine the appropriate column name. If the value does not exist in this limited map, the user is not authorized. Reference maps should not be global (i.e. include every possible value), they are temporary maps/dictionaries that are only ever populated with authorized values.

Community
  • 1
  • 1
user
  • 17,781
  • 20
  • 98
  • 124