In order to use some AJAX calls, we use often some input type="hidden". But these values can be easily changed. So, is it a builtin rails feature than permit to send date to AJAX, withouth being usable by user, or than can't be changed by user ?
In my current rails apps, i'm using filters for discard all malicious actions on my controllers. I am not building a public API, so i don't really need more powerful checks.
But for examples, i have an apotomo widget displaying some data, using some input hidden. But if you change it, you can access to another data set. In my case, it's not really an issue, cause all these users have the right to access these data sets anyway.
But is it some manner to give datas to ajax call, in a secure way ? Or the only security, is about rights management ?
All input that comes from the user is insecure as you do not have control over it! Users even do not need a webbrowser but can use some other program (like curl or wget) to send manipulated data.
As you state, using a whitelist (not a blacklist as you can never be sure of all bad, but of all good!) is a good way to start.
To make sure the hidden fields have not been changed you can use some kind of checksum that is calculated on server side using a fixed secret. This secret must never be exposed to your visitors!
hash = md5(field_1 + field_2 + field_3 + my_secret)
When these four hidden fields (field_1..3, hash) arrive in your form you can recalculate the hash and compare it with the params[:hash] in order to be sure the field_1 to field_3 have not been changed.
Related
I have a form which allows a user to create an unlimited number of fields. If this forms fails validation I want the user to return to this page with the form populated with their previous input values - i.e. I want these fields to persist.
With a normal form I could do this with {{ old 'title' }}, however, these additional fields are being generated through JavaScript and so I cannot add this PHP snippet. What is the best way for me to retrieve these previous input values?
3 ways to do this, cache, sessions and cookies.
cache and sessions are server side which is much better for security, however it will take extra time and effort for setting up, but if the data is not sensible and can be passed within cookies, better to the cookies.
The best thing about cookies for your current situation is: you can set it up directly from your front end JS code.
i was reading about AntiForgeryToken but do not understand the actual use or importance. i saw people wrote a code like in their form as
#using (Html.BeginForm("Create", "Register"))
{
#Html.AntiForgeryToken()
}
so what it does....it will generate a unique token and when form will post then this unique toke will pass and as well as a cookie will pass with same unique token value and two unique data will compare at server end that both are equal or not. if not then some tamper occur.
i just do not understand if other form field value change or tamper then how that tampering can be determine. suppose we often store valuable data inside hidden fields. if i need to secure that hidden fields value then how AntiForgeryToken can help us?
can we use AntiForgeryToken to wrap up those valuable data inside it and later compare at server end.
can anyone give me bit of sample code by which i can put 3 valuable data in my page and if tamper then a friendly message will be show to user. guide me how to do it. thanks
The idea behind the AntiForgeryToken is to prevent data being posted from a "fake" source. An attacker using a fake (forged) form can trick the user to submit any kind of data using their current session context. As you can imagine this can do quite a lot of damage.
A way to prevent this is to have a hidden field on your forms containing user specific data(something random) that is stored in the session, so that the bad guys can't forge it. In this case when a user posts the data, but doesn't have the user specific token, you can treat is as being malicious.
I think you have a misconception that the anti forgery token is about detecting whether the data posted has been "tempered" with, which it is not.
Here is more on this.
As I understand, to update any object with couchdb. I have to send the whole object back since it is actually "inserting" a new revision for the same id. This is all neat and works quite well.
But then I have a problem, I'm not so sure how should I handle that. I have an object that can't be sent to my user completely. I have to hide certain informations such as password hash.
The data is sent to the client, the revision is sent too. Now when I try to update my object I have one problem. Since some data is missing, the update will erase the attributes that are missing from my user.
That said, the easiest way I have is to get the object from couchdb, check if id and rev matches. If it does match, merge the object with the missing attributes. It will work pretty well and I can support deleting attributes too.
Then using this technique, I could add my objects to a cache that will reduce the time to query frequent objects from the database. If the object can be updated, then clear the cache for that id. If the object is newer, then I'll have to handle the error or merge the object.
Is there any better "good way" to handle this problem?
edit
After thinking about it during the night, I think I found a much much better solution. Instead of having my username and password inside my profile. I'll separate the identification object from the use profile.
In other words, I'll have to split up the object as much as possible to keep things isolated... On the plus side, I can add multiple authentication for one profile without messing with the profile itself. I can return profiles and anything necessary without returning any secret object.
It will complicate a bit the logic of insertion but it should be quite easy...
Get 1 id from couchdb using the uuid api "_uuids"
Insert password authentications (username, password, profile_id) using that uuid
If succeed, insert profile using the uuid that we got at 1
If anything wrong happen, rollback and tell the users what's wrong.
Also the nice thing about this method is that I can add access_token for oauth2 using the profile id and the logic will be almost the same as password, the auth type will differ but any auth type should work almost the same.
Yeah, extracting the secret stuff from the profile documents sounds like the way to go.
I am creating a TextBox using the html helper methods in my View.
#Html.TextBoxFor(m => m.Address, new { #readonly = "readonly" })
I would like this textbox to retain its value when posted, even if a malicious user tries to change it.
I am testing my code in IE, and can easily use the developer tools to remove the attribute "readonly".
Is there any implementation in MVC3 to retain values for the textboxes when posting? I am trying to avoid going to the database to get the original value.
Is there any implementation in MVC3 to retain values for the textboxes when posting?
No, there isn't. This is not possible. If you have sent the value up to the client you can no longer trust it. As you have already discovered it is trivial for the user to change the value of hidden and readonly fields. So if those values aren't meant to be modified by the user they should not even be part of the HTML. You should keep them on the server. Well, actually you could display them as readonly fields just for information to the user but when the form is submitted never use this value but use the real value that is stored on your server (maybe in a database or whatever persistent store you are using).
Why not try serializing everything you want to retain, encrypt it using a key only known to the server and store the encrypted value into a hidden input. You can still display the non-encrypted values in the form controllers, but at the server side, you will use the encrypted value send via the hidden input for actual processing. This way if a malicious user changes the standard inputs, it doesn’t matter, coz you will be using the encrypted copy.. A bit of a sidewinder, I know and its similar to how web forms maintains viewstate across posts.. Cheers
A question based on a comment made here:
storing user detail ... session vs cache !
Summary: I mentioned a technique I've used where I populate a model and use hidden fields to keep and pass back that information; Viewstate on the cheap. Simon Halsey said that the information should be encrypted or hashed so it is not tampered with. I'm thinking the added complexity of hashing it is just a form of YAGNI.
I can see that for sensitive information, definitely, but is this a good rule of thumb in general? What am I missing?
I actually have an attribute to do this (something similar) and speak about this exact thing in a security presentation. Yes - you should hash a copy of the value... encrypting it is up to you. if you encrypt it you get no model binding but is more open to attack, although a hash check helps. I'll post the code shortly for it and update this post. Who would ever think Viewstate helped with security : )
but to answer your question - you can encrypt it, but you need a way to at least validate it on the server side, so I hash a value and hash the posted value and then compare hashes in the attribute. encrypting can help - but then you need to implement either your own model binder or manually handle those values
The rule of thumb would be generally for any values that could be maliciously overwritten to attack your data - then you want some protection/validation on those fields. you could compare server side against what you know is a valid option for them (a form of whitelisting) but then you have the same form of rules duplicated on loading the data and on saving the data and that gets a bit messy at times, unless its as simple as limiting a user's get/update to a single userId.
What I mean is.. if you are updating say a user's record. Generally the main thing that matters for security is that the userId is not changed by the user to update a record that isn't theirs. The logic on get/save is easy "where o.UserId == userId"
However in complex role based security the logic becomes trickier and is not as clean to limit record updates like this. In those cases you can really take advantage of encrypted/hashed fields. I always hash the specific fields uses for update. Sure - they can be forged with other valid hashed fields from a previous request, but the scope of potential damage is significantly more limited this way.