I know I must use HtmlEncode() on everything that's displayed (Labels, etc.)
Do I also need to use it in my data-bound buttons' CommandArgument ? (even though I can't, on input, trust them to still be so)
I finally found my answer here:
https://stackoverflow.com/a/20791870/1455631
The CommandArgument, as well as the CommandName are not sent from the client side to the server. They are Stored on the LinkButton's Viewstate and retrieved on the server side. In this case, the __EVENTARGUMENT Form Key will be empty.
Which means, there's no need to sanitize CommandArgument.
Related
I am having a similar problem to the one described in this previously asked question, but I am looking for a bit more detail in the answer as my lack of experience in this area doesn't allow me to fill in some of the blanks:
Tag Outlook MailItem with ID number before send without causing TNEF (RTF) send
Like the asker of that question, I would like to set a User Property, say it's named "XXXX", to a MailItem while the user is composing it, so that when the user later revisits that same MailItem in his or her Sent Items folder I could read the "XXXX" property's value again.
My additional questions would be as follows:
Dmitry Streblechenko suggests using MailItem.PropertyAccessor.SetProperty, but wherever I see that used I see people using a schema link to represent the property. What would be the correct schema link to use if I want my property still to be known as "XXXX"? In other words, what would be the correct syntax to use in Dmitry's suggestion?
I gather I could use a ".GetProperty" call to read the property later from the Sent Items, but the problem is that our add-in has been around for years, and users sent items are already full of MailItems with the original UserProperty "XXXX" in them. Will I still be able to use UserProperties to get property "XXXX" even if I use .PropertyAccessor.SetProperty to set them?
Alternatively, if I kept using the original code to set UserProperties while composing the message, but I then used .PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/id/{00062008-0000-0000-C000-000000000046}/8582000B", false) during the ItemSend, like the original poster is suggesting, then I understand the UserProperties are not sent out with the message, which is fine by me, but will they still be available when revisiting the message in the Sent Items folder? Eugene Astafiev suggests that it's safe to use that .SetProperty call, but he doesn't clarify whether it affects what happens to the message at the Sender's end.
My personal preference would be a solution that would a) allow me to send the item without having to force Outlook in any way to send the message in any particular format and b) be able to continue to access the properties in the users' inboxes as we always have through the MailItem's UserProperties, but I am aware that I may be asking for something impossible here.
You need a property in the PS_INTERNET_HEADERS namespace. E.g. http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/x-my-prop.
Yes if you specify the full DASL name.
Yes, the user property will still be there in the Sent Items folder.
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
The specific case I've got in mind is as follows: an AjaxFormComponentUpdatingBehavior("onchange") is added to a TextField in a form. The behavior verifies the text for certain conditions (either the model object or the form component model, doesn't matter), based on which it might display a message (or hide it, if it has already been shown).
The problem is, there are also validators added to the TextField. One of the possible (and likely) scenarios consists of the user typing in, first, a value that causes the message to be displayed by the AJAX request. If, then, he/she types in a value that doesn't pass validation, the message should disappear, but it does not.
Apparently, either the onUpdate() method for the AJAX behavior is not called at all, or I am failing in my attempts to insert a check for non-validated entries (I have tried to test for both null values and empty strings, to no avail; I have no idea what exactly Wicket's validators do to models when data is invalid).
I am wondering if someone who actually understands validators (or AJAX, actually) has any ideas on where the problem could be.
I can post edit and post code if someone tells me this is not a general issue tying validators and AJAX, but most likely a programming mistake. I still believe the former and thus I'll refrain from posting code sections, in order to keep the discussion on an API/theoretical frame.
Thanks.
When using an AjaxFormComponentUpdatingBehavior, if any of the IValidators fail their validation, onError() will be called instead of onUpdate(). Wicket will effectively prevent invalid user input from reaching the IModels in your components, so the component's ModelObject will not be changed at all. The invalid input will probably remain available by means of getInput()/getConvertedInput() (not sure if it will in an AJAX scenario, it sure is in a traditional form submission).
However, take into account that IFormValidators are not executed when using this mechanism. If you've got any, you might be interested in overriding getUpdateModel() so that AjaxFormComponentUpdatingBehavior will not bring maybe-invalid user input into your IModels, and set modelobjects manually when you're certain user input is valid.
Regarding your specific case, you could perform all the required logic in onError() (or rely on Models that will grab data from somewhere else), and just add the components that need refreshing to the AjaxRequestTarget. This is probably what's missing in your scenario.
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.
Okey, this might seem a bit strange question so I will explain.
Do I really need to create a postback that explains what is wrong with form if it's not validated if I also use JS for it?
I am of course validating user input and I use somewhat "general" approach. For instance if something is not validated it will just show "Some error occurred, check your input bla bla..". I am not creating postback for every input so that it will shot "Your username is suppose to be at least 3 characters long etc.." and I don't do this because JS is doing that on the fly.
My server-side validation only is like a guard against stupid/wrong entries where name is empty or something along that, rest is up to jQuery. Form will always be valid if client is running JS. I am doing it to save my time.
My question is - is it a bad idea? I just don't see why because everyone is running JS anyway and my server is not allowing bad/invalid entries to be put in DB even with JS off.
I don't think that's a bad idea, data validation can be client side. If something goes wrong, i just throw a generic error.
I only validate server side the business rules