What if I have ChangePassword form with hidden ID field of the user.
BadPerson knows id of GoodPerson. He opens Change Password form with FireBug, changes his Id to GoodPerson's Id, so password changes for GoodPerson.
Of course I can create some server logic that will prevent this, but I think there should be some out of the box solution, which throws if hidden field been changed, which I don't know.
EDIT
Ok, Change Password is a bad example. Any edit form where I have id in hidden field has same problem.
I agree with Darin that forms authentication will take care of the specific problem mentioned above (changing a password). This answer is for the more general question of making sure that a hidden field's value is not changed.
The best solution to this is to include another hidden field which contains a hash of the first hidden field's value. That way if the 1st hidden field is changed you will know it. The generated HTML looks something like this:
<input id="productId" name="productId" type="hidden" value="1" />
<input id="productId_sha1" name="productId_sha1" type="hidden" value="vMrgoclb/K+6EQ+6FK9K69V2vkQ=" />
This article shows how to do it and includes source code for an extension Html.SecuredHiddenField which will take care of the logic for you.
There is nothing that will let you know that a value of a hidden field's value has been changed or not. For a user to change his password it means that he needs to be authenticated. When using forms authentication the ID of the currently authenticated user is stored in an encrypted cookie which cannot be modified.
This is to say that you shouldn't use hidden fields for storing the currently connected user. Just use the built-in FormsAuthentication mechanism in ASP.NET and never store such information in hidden fields. The way ASP.NET knows that the value of the cookie hasn't been tampered with is that it signs it with the machineKey specified in the configuration.
There's an important rule that you should follow when dealing with security and authentication: always use built-in security mechanisms, never roll your own.
Related
Say I have the following q-input:
<q-input
v-model="form.email"
inverted-light
color="white"
stack-label="Email:"
type="email"
#blur="$v.form.email.$touch"
:error="$v.form.email.$error"/>
I'd like to be able to make it so that if the domain of the email is mydomain.com that the form action will change to another website (without csrf protection) and the POST will be made to that website instead of the main one.
To do this I was thinking I could use jQuery. eg. $('#email').val().replace(/^.+#/, '') == 'mydomain.com' then change the form action and submit.
The only problem is: I don't know how to set an id attribute on q-input.
Any ideas?
As of early Quasar 1.4.2 (November of this year) you can specify the id value on the resulting html generated by q-input by using the "for" property (see the end of the behavior properties: https://quasar.dev/vue-components/input#QInput-API).
So, for example, you could add for="myInputId":
<q-input
v-model="form.email"
inverted-light
color="white"
stack-label="Email:"
type="email"
#blur="$v.form.email.$touch"
:error="$v.form.email.$error"
for="myInputId"
/>
The id attribute with value "myInputField" will end up on the resulting <input> element in your HTML.
Not using the "for" in the elements gave me a lot of headaches because the Jest snapshot generated random IDs
In Rails, when you go to the edit action, it automatically pulls the information from the models and populates the form. If I had a CRUD that saves sensitive information, for example password or ssn, how can I filter the values so that it doesn't just show it in plaintext when editing the form?
I was going to change the value in the controller by setting it to ****, but the potential risk there is people may submit the form and it will update the SSN to ****.
I'm not referring to filtering the params so it doesn't show up in console (config.filter_parameters).
Changing the input field to type="password" should resolve your problem. Just don't set the fields in the controller if they are blank.
If you are using a form builder, change text_field to password_field.
I have about 20 forms, each with 15-20 textbox inputs each.
Once the user submits the form, all their values need to be confirmed, this is done by replacing each textbox with a label control that shows the entered value.
The user may click on a back button to edit the data, in which case the textboxes re-appear, or they can confirm their data submission.
What would be the best way to handle this in MVC?
Thanks
I would recommend having different views for editing and showing data. This could be useful if you would like to omit or add some extra of the fields, keeping your view logic simple. You could store the form data in the database with some flag indicating that it is not confirmed yet. After confirmation you would only change the flag of the record. Another option is to store form data in tempData or Session and save it after confirmation.
The quickest way would probably be to have both on the page and bound to the same Model properties but wrap them in some simple render logic. an example off the top of my head in razor could be something like
#if (is in edit state){
<field markup>
#}
else{#
<label markup>
#}
Its been a while since I've worked on an MVC app but that's how i would have done it back then i think.
I've started using AntiForgeryToken in some of my forms to prevent cross site request forgery. However I am getting some weird behaviour and just wanted to clarify whether this is a bug or just me doing something wrong. I am using the Html.AntiForgeryToken() call in my form. I then use the [ValidateAntiForgeryToken] attribute in the action method that the form posts to. I'm not using a salt at this point.
My understanding is that Html.AntiForgeryToken() generates a hidden input with a name of __RequestVerificationToken and a cookie named __RequestVerificationToken_Lw__, which should both contain the same value.
The behaviour I am experiencing however is that:
The cookie always has the same value no matter how many times you
GET the page
The hidden input has a different value every time you GET the page
The ValidateAntiForgeryToken validates every time, even from a
different site in a CSRF scenario.
If I change the value of the hidden input in the foreign site, the
token doesn't validate (expected behaviour, but why does it validate
when the hidden input/cookie value is different?)
Anyone got any ideas?
For number 3, are you including the hidden field in your CSRF scenario?
The safety of the AntiForgeryToken is that the hidden input exists only in the page served by your domain, and cannot be copied or captured by another domain. If you have mocked up a test which passes the hidden input, then that is not a valid test.
I suggest you read this article from Phil Haack: Anatomy of a Cross-site Request Forgery Attack
I've got an MVC app that gives the user textarea's to update some description fields. It's strongly-typed to a table object, and the fields are wrapped in a form with a Submit button.
Occaisionally they don't want any data in a field, but when they delete the text and try to save, the blanked-out field comes back with its original text (i.e. the table object passed to the Save action contains other edits, but attempts to blank out fields result in the original text staying in the field).
I'm assuming this is LINQ trying to determine which fields have been edited, but how do you tell it that it's blank on purpose?
UPDATE: It appears this may be a problem with the TinyMCE jQuery plugin. It adds rich-text functionality to textarea controls. If I turn it off, I can remove text with no problems.
UPDATE 2: It seems to be some kind of javascript bug or something. If I put another dummy field after the problem fields, they work. If I move them to another place in my code, they work. They just don't want to work where they are. Very peculiar.
I'm pretty sure that TinyMCE, by default, puts in <p></p> when the control is emptied.
So if you are checking for "" then you may be disapointed.
This initially caused me some issues but never with saving. I was checking if the field was "" and then doing something else. Once I realised that "" was never going to happen, I adapted my validation accordingly.
I just check that on a recent project using TinyMCE editor, but it indeed send "" for an empty input, and during the implementation we had no issues with that.
alt text http://diarioplus.com/files/pictures/tiny.PNG
The body property is the one with a tinyMCE editor on the client side.
I really think it will be something with the modelBinder or the way you set the values back to the model.