I have to integrate the commenting section in one of the pages of my website. When a user comments on a particular post, the post id is used to identify the post user is commenting into. The post id is in a input hidden field of the corresponding post. Or, I can also use something like data-id attribute(HTML5) in a tag to store id. But is there a safer way to do so? The post id is open and anyone can inspect and change the value of it even from chrome. This is a big security concern. There can be a huge no of posts in that page and I am using ajax call to insert the comment. What would be the best way to do it?
Frankly, anything can be edited or abused when it comes to JavaScript. In the console, they can send whatever they want as a POST request. There's nothing you can do about it, but you can protect yourself from abuse.
The golden rule is never trust data coming from the user. For example if someone sends you an edit to a post with a given ID, verify that post belongs to the logged in user. If it does, even if they manipulated the ID on the form, it won't matter because it's theirs anyway.
You need to adjust your protection depending on the situation.
Related
Why does people store variables like this:
<input type="hidden" name="id" value="<?php echo $bookid; ?>">
Instead of just accesing the $bookid when it's needed?
Is there any security breaches with this? I thought you could acess and change the value of an input with developer-tools? Not making it safe to store them there.
Apart from the whole client versus serverside thing, the security 'issue' should be non-existent. If someone does make a page with a 'hidden' form field to really hide it from the user as in, the user should never be able to find out the contents, that someone is "going to have a bad time".
The point of hidden fields is to hide them not for security, but because the user doesn't need it.
Random example: Maybe I need to store the id of the Album you are looking at. You don't need to know that, why would you want to know that. But finding out I call this Album 2134125 in the back-end doesn't matter. Even if you change it, the only thing that will happen is you have just selected (bought, started to listen to, whatever your site does) a different Album. Unsellable albums, price, all stuff like that should be based on the ID, not on other stuff, so you can't hack it, you just confused yourself.
If you do need secure hidden fields there is an option btw:
Sometimes we need to send actual data in hidden fields that we don't want to change. This is true for some payment providers where you actually send the amount a person needs to pay from a hidden field. (I'm not making this one up). This is usually securty by adding a second hidden field with a form of hash. This is made with a secret known to the payment provider and the server, but not available in the form. If you do some hash, say sha1(hiddenvalue + secret), add it, and compare after sending the form, you will get a different has (so no equality, so an error) if the hiddenvalue was changed.
You are mixing things. $bookid is PHP variable, only visible in the server. It is stored in the hidden form so it can be used by the browser (either by Javascript, by a new request to the server, or both). $bookid is invisible in the client side, it will be replaced by its value before leaving the server.
I am developing a facebook similar wall, and im a bit corious, is it safe to use a hidden input storing the stream id?
So in my db for comments i have 4 fields, the comment id, stream id, user id, and comment text stream id is for to locate which wall post has comment, and i would store this in a hidden input for the form.
is it safe? or i should think a nother idea?
Thank you
Well, you have to identify somehow what wall user post at, so you have to pass that parameter either in GET parameters or other way (using POST at your case). I don't think anything is wrong with this. If someone can to a damage knowing that data then you have a security problem in your app.
Level of security by passing that data through hidden input or through GET parameter is the same.
The safest way I can think of solving this problem is by using a session store if possible, unless I'm misunderstanding something.
I'm trying to figure out the best practice, as well as safest, way to store a variable with javascript for a web app I'm developing.
I have pages that are generated using php, $_GET and mod_rewrite. They are generated from the id that's given through the url. For example: http://example.com/1125/ (because of mod_rewrite what's actually happening is: http://example.com?id=1125). The php takes $_GET['id'] and retrieves information from the database in accordance the id given, etc... you get the gist.
The problem I'm having is, I have a form on that page where a user can post a question, which is sent via ajax. And I don't know the best way to store the page's id ($_GET['id']).
Right now, I have the id stored in a hidden input within the form (for example: " />). And when the form is submitted to the server and php takes a look a $_POST, it contains ["id"] => 1125. That's how I'm sending the page's id when a question is submitted via the form in the page.
The reason I think that's not secure is, anyone can edit the html (for example through Chrome's inspect element) and change the hidden input's (id) value to any other id.
So my question is, what's the safest way I can store that id with javascript, so when that question form is submitted, It can safely send the correct id to the server? Or any other suggestions thought out with best practice methods?
You only just need to validate the id in the php page that receives the ajax, if the id is valid and the user has permission to use it, then it's ok and it doesn't matter if he changed it through chrome or whatever, but you need to validate because if he changed it for the id that belongs to other user then you have to detect that and error out in that case.
This is just a matter of validate your input according to the priveleges in your application.
I have a form where a user submits data from various text fields on my webpage to mysql database. Is there any code I can use were it will not let them submit/update the data again? e.g it will redirect them to a page saying sorry wwe have already received your data.
I have a unique number for each user if this helps. any help is appreciated.
Use tokens, it will avoid double submits and CSRFs.
Simply add tokens to an array, $_session most likely, and pop them when used.
Also, disable the submit button with JS after a submit.
You can also set a var in the session user that says he already performed an action, exampled uploaded his picture. Unset it if there is an error in your upload script for instance.
When you receive the post, query the database for the unique user number. If you get back a non-empty result, then display the error. Otherwise, save the data to the database.
The biggest thing you need to determine is what your unique identifier will be. It sounds as though you already have one (you mentioned unique user number?) Your unique identifier could be an email address, or even the full set of submitted data.
There are other ways to emulate this, such as setting a cookie on the user's machine, or disabling the submit button, but, none of these are completely under your control. The user could easily get past them if they tried. Therefore, determining a unique identifier and validating server side is probably the best way to do it.
The answer hugely depends on the reason for which user might send the data twice.
in case of an accident, there is one technique, and all other won't help you even a bit.
in case of intentional duplication the technique is completely different and again there is no general solution - everything depends on the certain scenario.
If you care to explain your certain case, you will get a proper solution.
For the most silly case of pressing "Reload" on a page with post results, you have to redirect browser using Location: HTTP header, e.g.
header("Location: ".$_SERVER['REQUEST_URI']);
exit;
I just had this thought, I don't know if I am slow though.
Usually, I store the id of the item I am editing in a hidden field. Then in backend (I am using PHP/Zend Framework btw), I get it to determine which item gets edited. But then I thought, in something more secure, eg. edit profile, the user can somehow edit a hidden field right? Then he can edit someone else's profile. I know for edit profile, I can get the id form the session variable, but what if i got something that requires me to store the id somewhere?
I got ACL (Zend_Acl) I do this. Basically grab the id from the request params
$id = $req->getParam('id');
then check if the logged in user is allowed to edit the item. But the thing is I wonder if the url is something like /users/edit/1 where 1 is the id. But somehow, the hidden field is changed to 2, what will the request param be?
How would you deal with this?
You must store some kind of id at the client-otherwise how would you know which item to edit?
This does not free you from the mandatory check on the server that the current user has privileges to edit/see the edited item.
Other then that, why would you care how he got to edit the item (whether by lawful use of the web tool, or by editing the hidden/whatever field).
Storing ID in hidden value isn't quite safe. Generally, we store ID in session variable.
as ppshein said, storing sensitive ids in a hidden var is NOT safe. Would you store a password in a hidden var? Its really easy for even a novice hacker to get that data.
You need to make sure that all access control is enforced by the server.
in your case, you need to make sure that the user who is logged in (the one on the session) is the owner of the profile being edited. Or that the user who is making the edits has permissions to edit that profile (e.g. is an admin)
It should not be based on anything submitted by the user.
You should always check user permissions on server side.
An attacker can prepare any request to your server.
Agree with all the points above but if you really do need to store something clientside for whatever reason, you can always encrypt the data and decrypt when you need to use it but again, using sessions would be the best way to deal with it as they are not accessible client side.