I am wondering if it is consider good practice to encode user input to database.
Or is it ok to not encode to user input instead.
Currently my way of doing it is to encode it when entering database and use Html.DisplayFor to display it.
No. You want to keep the input in its original form until you need it and know what the output type is. It might be HTML for now, but later if you want to change it to json, text file, xml, etc the encoding might make it look different then you want.
So, first you want to make sure you are securely validating your input. It is a good idea to know what are the requirements for each of your inputs and validate that they are withing the correct length, range, character set, etc. It will be to your interest to limit the type of characters that are allowed as valid characters of an input type. (If using Regular Expressions to validate input ensure you do not use a regular expressions that is susceptible to a Regular Expression Denial of Service.
When moving the data around in your code ensure that you are properly handling the data in a manner that it will not turn into an Injection Attack.
Since you are talking about a database, the best practice is to use paramaterized statements. Check out the prevention methods in the above link.
Then when it comes outputting using MVC, if you are not using RAW or MvcHtmlString functions/calls, then the output is automatically encoded. With the automatic encoding, you want to make sure you are using the AntiXss encoder and not the default (whitelist approach vs. blacklist). Link
If you are using Raw or MvcHtmlString, you want to make sure you COMPLETE TRUST the values (you hard coded them in) or you manually encode them using the AntiXss Encoder class.
No it is not necessary to encode all the user inputs, rather if you want to avoid the script injection either you my try to validate the fields for special characters like '<', '>', '/', etc. else your Html helper method itself will do the needful.
Related
I'm trying to figure out if this code is safe.
Is it at all possible to attack this code?
<script>
data = <%= data.to_json.html_safe %>;
</script>
In other words, what value of data would result in a successful attack?
It kind of depends on what you are doing with the data and the version of Rails you are using. If you are using anything past Rails 3 then no, calling html_safe could make your code vulnerable to XSS.
Basically, what you are doing is telling the app that data.to_json is html safe. However, the application doesn't actually know that for sure.
What html_safe does is it marks a string as safe to be inserted directly into HTML without escaping anything within the string. As described in the method api, it should never be used on user input. Constructed input may be safe, but it is up to you to ensure that it is.
to_json converts a given string into JSON. By default, it does not escape HTML characters like <, / >
Thus, if data is user input, it is entirely possible for someone to insert their own script into it and have it marked as safe (and thus rendered as html) the way it is currently written.
The way this is written, if someone does the following:
data = "</script><script>insert_xss_attack_here</script>"
Your code will not escape the script, resulting in the script being executed by the code.
Many people have described the issues with html_safe and to_json:
This deals specifically with to_json.html_safe
http://jfire.io/blog/2012/04/30/how-to-securely-bootstrap-json-in-a-rails-view/
https://bibwild.wordpress.com/2013/12/19/you-never-want-to-call-html_safe-in-a-rails-template/
http://makandracards.com/makandra/2579-everything-you-know-about-html_safe-is-wrong
I have some easy to read URLs for finding data that belongs to a collection of record IDs that are using a comma as a delimiter.
Example:
http://www.example.com/find:1%2C2%2C3%2C4%2C5
I want to know if I change the delimiter from a comma to a period. Since periods are not a special character in a URL. That means it won't have to be encoded.
Example:
http://www.example.com/find:1.2.3.4.5
Are there any browsers (Firefox, Chrome, IE, etc) that will have a problem with that URL?
There are some related questions here on SO, but none that specific say it's a good or bad practice.
To me, that looks like a resource with an odd query string format.
If I understand correctly this would be equal to something like:
http://www.example.com/find?id=1&id=2&id=3&id=4&id=5
Since your filter is acting like a multi-select (IDs instead of search fields), that would be my guess at a standard equivalent.
Browsers should not have any issues with it, as long as the application's route mechanism handles it properly. And as long as you are not building that query-like thing with an HTML form (in which case you would need JS or some rewrites, ew!).
May I ask why not use a more standard URL and querystring? Perhaps something that includes element class (/reports/search?name=...), just to know what is being queried by find. Just curious, I knows sometimes standards don't apply.
When I allow a user to enter text using s:textfield, he can enter something like <b>Name</b> or something like \Me/. I want that these should be escaped before I am saving them to the database. When we retrieve them, the escaping is done automatically, but I want it to happen also when we are saving it.
I was trying to return a json output from my action class, but due to a name \a/ stored in my database, wrong json was being formed. This would have been avoided if the name had been escaped before being saved into the database.
You can use StringEscapeUtils. You can call escapeJavascript(textfield) in your action and then store it into the database.
#Daud, The problem you explained is called Cross site scripting or XSS.
And I think you should use Filters to clean the request parameters. This is the most sophisticated way. You can call these filters for the actions which are posting some parameters via request.
Visit my blog to see how to avoid XSS threat using Filter approach.
I also faced this issue when our project was tested by well known firm specializing in security testing and they suggested this filter approach.
You can give it a try.
so i would like to expose regular expression queries on a field in my model, such that user could ask for
http://localhost:3000/myview.json?field=^hello, (there|world).*
so i know i'll have to change my routes to recognise the wildcard characters etc, and i can easily do a Regexp.new() inside my controller to convert this to a real regular expression (i'm using mongomapper in the back).
the issue is the potentially huge security hole with XSS.
should i be worried about this? how could i safely enable users to query with regular expression strings.
(i'm not too bothered about the user hammering the database... yet)
Regular expressions won't be able to perform arbitrary code execution unless there is something really wrong with Regexp.new. So if we assume that Regexp.new will either make a valid regular expression or fail or do something else sane you are safe already without having to sanitize the incoming string.
If I have the following data, what is the best option in terms of Database storage.
Here is text<br><br>Here is some more text
I see that I have 3 options:
Store in DB as it is then decode at runtime: <p>hello</p>
Decode and then store in DB: <p>hello</p>
Strip tags completely: Hello
Are there any big "No No's" with any of the above, just looking for some advice on best practice. Also worth noting that I will have absolutely no control over the data that I receive.
Depending on your requirement, I suggest to either strip the tags or store the unencoded version.
If you don't need the tags, the you can strip them and store the plain text.
If you need to preserve the tags and the formatting, then it's easier to save the unencoded version. Dealing with real tags it's much simpler.
Also, it's a view responsibility to encode the output. In fact, it strictly depends on where you are going to print the string.
In the console, for example, tags doesn't create any issue. It's just when you need to print the string into an HTML view. But fortunately Rails takes care of output sanitization for you, so you don't need to store the sanitized version in the database.
Convert the data to canonical form, and store that. That is, you should store <p>Hello</p> or Here is text<br><br>Here is some more text (though I doubt that's the decoding you intended for your example).
Then, you can search without having to worry about how it was encoded (Ö, Ö or Ö, for example?), and just encode it to whatever format is appropriate for display on rendering.