Just trying to do some security on my website and trying to figure out the best route to secure an ID.
EXAMPLE: localhost/page.php?user_id=1 TO: localhost/share/df9sdf87423498asf9
That's not security, that's security by obscurity.
Proper security requires that on your server side in page.php, verify that the currently authenticated user has access to the given ID.
If you don't use authentication and pages are only intended to be viewed once, check the answers to this question for a random number generator.
You can look into using UUID instead of auto-increment user ids.
Edit:
To be clear, this is by no means "encryption". It is simply an alternative way to using 1,2,3,4... as primary key for users' table. Bare in mind that using UUID instead of incremental numbers will result in higher I/O because insertions are going in random locations in the index tree, not sequentially as the incremental ids.
Related
I have a collection called Vouchers. A user can, if they know the unique number ID of a Voucher, "claim" that voucher, which will give it a user_id attribute, tying it to them.
I'm at a point where I need to check a user's ID query against the existing database, but I'm wondering if I can do so on the client instead of the server (the client would be much more convenient because I'm using utility functions to tie the query form to the database operation.... it's a long story). If I do so on the client, I'll have to publish the entire Vouchers collection with correct user_id fields, and although I won't be showing those ids through any templates, they would be available through the console.
Is there an inherent risk in publishing all of the IDs like this? Can they be used maliciously even if I don't leave any specific holes for them to be used in?
First, in general it sounds like a bad idea to publish all user_ids to the client. What would happen if you have 1 million users? That would be a lot of data.
Second, in specific, we cannot know if there is inherent risk in publishing your user_ids, because we do not know what could be done with it in your system. If you use a typical design of user_ids chosen by the user themselves (for instance email), then you MUST design your system to be safe even if an attacker has guessed the user_id.
Short Version: not so good idea.
I have a similar setup up: user can sign-up, if she knows the voucher code. You can only publish those vouchers where the user_id is identical to the logged in user. All other checks like "does the user input correspond to a valid voucher?" must be handled on the server.
Remember: client code is not trusted.
I could not come up with any better title, after reading the question you can suggest a better one. Also you can suggest some better tags, I could not find web-development.
I am a student so I don't know the standard way to achieve the following issue.
I usually set the IDs of elements (div,span,tr,etc) according to the database primary key to reference it later easily.
For example on page having some rows of entries having their id set to the sno in the DB which is primary key and on click on any row checking the id and display the result from database using that id.
But I think its a bad idea as anyone can use Inspect Element or Dev Tools and change the ID.
What is the standard way to achieve this?
EDIT 1
I know that web browser wont enforce the security policy for me that's why I am asking for the standard way, or standard practices to use for this matter.
Anyway, you must assume that any request that comes to the back end may be forged, any any data sent to browser (visible or hidden) is public.
If you considere the the id are private (rather uncommon requirement), you could instead simply use a row order and keep on server session a table row_order <-> id.
If you simply want to ensure that the id are correct, just control them (server side) before updating the database, or at the time of the database write if you cannot control them before.
If you want to enforce any other policy (users have roles and depending on roles are allowed or not to update some values) all those controls have to be done server side.
I am developing an HTTP server application (in PHP, it so happens). I am concerned about table IDs appearing in URLs. Is it possible to encrypt URL variables and values to protect my application?
oh ok, so for sensitive information best to use sessions then, are table Ids etc safe to throw in the GET var?
Yes, sensitive information must not leave your server in the first place. Use sessions.
As for "are table ids safe in the URL": I don't know, is there anything bad a user could do knowing a table id? If so, you need to fix that. Usually you need to pass some kind of id around though, whether that's the "native table id" or some other random id you dream up usually doesn't matter. There's nothing inherently insecure about showing the id of a record in the URL, that by itself means absolutely nothing. It's how your app uses this id that may or may not open up security holes.
Additionally think about whether a user can easily guess other ids he's not supposed to know and whether that means anything bad for your security.
Security isn't a one-off thing, you need to think about it in every single line of code you write.
Sounds like you want to pass sensitive information as a GET param.
Don't do that - use $_SESSION if you can.
However, if you want your params encoded (i.e. => +) use urlencode().
$a = 'how are you?';
echo urlencode($a); // how+are+you%3F
You can encrypt what you pass before you transmit, or you can run the entire communication over an encrypted channel (https or ssh for instance).
Your GET variables are called whatever you choose to call them, and assigned whatever values you choose to give them. So, yes: they can certainly be encrypted or, if you'd rather, simply obscured. If you're planning to encrypt variables, then PHP has quite a few options available.
For the above, I'd recommend using something like urlencode.
In general I'd suggest using POST instead of GET, assuming you're getting your variables from a form element. On the other hand it might be even wiser to use session variables.
Maybe this article can give you more ideas...
http://www.stumbleupon.com/su/1nZ6bS/:1PcFQMI0:6oJD.Hd1/www.ibm.com/developerworks/library/os-php-encrypt/index.html/
I'm using ASP.Net but my question is a little more general than that. I'm interested in reading about strategies to prevent users from fooling with their HTML form values and links in an attempt to update records that don't belong to them.
For instance, if my application dealt with used cars and had links to add/remove inventory, which included as part of the URL the userid, what can I do to intercept attempts to munge the link and put someone else's ID in there? In this limited instance I can always run a check at the server to ensure that userid XYZ actually has rights to car ABC, but I was curious what other strategies are out there to keep the clever at bay. (Doing a checksum of the page, perhaps? Not sure.)
Thanks for your input.
The following that you are describing is a vulnerability called "Insecure Direct Object References" And it is recognized by A4 in the The OWASP top 10 for 2010.
what can I do to intercept attempts to
munge the link and put someone else's
ID in there?
There are a few ways that this vulnerability can be addressed. The first is to store the User's primary key in a session variable so you don't have to worry about it being manipulated by an attacker. For all future requests, especially ones that update user information like password, make sure to check this session variable.
Here is an example of the security system i am describing:
"update users set password='new_pass_hash' where user_id='"&Session("user_id")&"'";
Edit:
Another approach is a Hashed Message Authentication Code. This approach is much less secure than using Session as it introduces a new attack pattern of brute force instead of avoiding the problem all togather. An hmac allows you to see if a message has been modified by someone who doesn't have the secret key. The hmac value could be calculated as follows on the server side and then stored as a hidden variable.
hmac_value=hash('secret'&user_name&user_id&todays_date)
The idea is that if the user trys to change his username or userid then the hmac_value will not be valid unless the attacker can obtain the 'secret', which can be brute forced. Again you should avoid this security system at all costs. Although sometimes you don't have a choice (You do have a choice in your example vulnerability).
You want to find out how to use a session.
Sessions on tiztag.
If you keep track of the user session you don't need to keep looking at the URL to find out who is making a request/post.
I have a list of books obtained from the database. When a user selects a book, I'd like it to retrieve the information for that book and display it on screen. However, I'd like to keep the ID of the book hidden from the client-side, so what would be the best way to transfer the ID of the selected book? I think my brain has melted, so I'm probably missing something obvious. Sessions seem to be the only way to not have any ID information transferred, but I'm not sure how to implement a system where an item is selected (from whichever control type is most suited) and the ID of the item is somehow picked up by the server and the relevant information retrieved. (Using ASP.NET + SQL Server).
Thanks for any advice
Do you really want to hide the database id from the user, as in a scenario where the user has some alternate access to the database and you want him to search for the book the hard way?
Usually the requirement is not to keep the ID secret, but to prevent the user from figuring out IDs of other items (eg. to enforce a certain funnel of navigation to reach an item) or from sharing the ID with other users. So for example is ok to have an URL http://example.com/books/0867316672289 where the 0867316672289 will render the same book to the same visitor, but the user cannot poke around the value, so 0867316672288 or 0867316672290 will land 404s. It may also be required that another user entering 0867316672289 gets also a 404.
Keeping the ID truly 'secret' (ie. storing it in session and having the session state keep track of 'current book') adds little value over the scheme described above and only complicates things.
One solution is to encrypt the IDs using a site secret key. From a int ID you get a 16 bytes encrypted block (eg if AES block size is used) that can be reverted back by the site into the original ID on subsequent visits. Visitors cannot guess other IDs due to the sheer size of the solution space (16 bytes). If you want also to make the pseudo-ids sticky to an user you can make the encryption key user specific (eg. derived from user id) or add extra information into the pseudo-id (eg. encrypt also the user-id and check it in your request handler).
Is exposing the IDs a risk? (SO question)
How about using a "pseudo id" for each book? I am assuming you need something on the client side to tell the server which book the client chose.
Generate a Guid for each book to use as the web side "pseudo id", that should keep the real id fairly secure.
I am not sure I understand your question, because the answer seems too obvious: just don't send the entity's id to the client. Use it on the server side to compose the ASP.NET page, but don't include the id itself on the output page that is sent to the client.
Does this make sense? :-)