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.
Related
I am developing a forum like website using php and mysql. A user can ask a question and other users can reply to it. So my database table structure is like below.
Two tables questions and replies:
Now I have designed a page to view the question, replies and post another reply. So when I insert a row into replies table I have to pass the question id too. It can be simply achieved by passing the question id via a hidden element in the form. But this is not secure because a user can change the hidden value and the reply will end up in a wrong question.
Another solution is to use a session variable to store the question id the user is currently viewing. But this is also not possible because user could be opening multiple tabs which will cause problems with session variable.
So how do I solve this problem? I would really appreciate it if you could give me an idea.
PS - How do the famous forum sites solve this problem?
have another hidden element which has a hashed version of the id, on the backend check that the hash matches (the same way you check a password against a db, i'm assuming you know how this works but i can explain if you don't)
Why does it matter if the user edits the request to comment on a different question?
the only reason i can think of, is that some questions are restricted to allow none/certain comments, in that case the you should already be handling that in the backend.
as danblack commented, you should always assume user inputs are untrustworthy, you should always handle validation like this on the backend.
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.
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 am working on a PHP/MySQL messaging application in which a user can see a conversation and reply to it. On the view page of the message I have a reply field. To save the reply I need to know the ID of the message which is being replied to. I have been trying to pass this ID in a way, which is both secure and reliable. A simple hidden field with a POST won't do it, since the user can tamper the data and modify which message he is answering. Creating a session variable with the id of the message on the view page provides the security but causes a highly undesirable side-effect: if the user views another message after opening the one he is replying to, the response will be posted to the other message.
Any one got any alternatives ?
You can encrypt the id with the mcrypt library and pass the encrypted form in the url. If your userbase has the collective IQ of a zucchini, you could probably get away with simple obfuscating as Hex or base64. But otherwise, mcrypt->base64 will be more than enough
Use 2 kind of ID, like: ?id=45sdf6g78g9s7987sd9f87&id_hash=65d4f98s7gsdg54g98dg
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.