Two days ago, when writing code, I suddenly received a warning that there was an XSS vulnerability in the project code, then immediately based on the report of the URL to troubleshoot the page code, although quickly repaired, and the same issue two years ago, and generally relatively experienced students should know this point, but still feel the need to write out, Remind other small partners again to avoid stepping on the pit.
The root of the problem
Where the vulnerabilities are found, there are slim code similar to the following:
Input class= ' xxx ' value==params[:account]
The problem is on the double equals = =, because in slim and ERB templates (other templates such as HAML are not clear), the double equals is actually the version of Rails's Raw helper method
To insert something verbatim use the raw helper rather than calling Html_safe:
<%= raw @cms. Current_template%> <%# inserts @cms. Current_template as is%>
or, equivalently, use <%==:
<%== @cms. Current_template%& Gt <%# inserts @cms. Current_template as is%>
That means the code above is equivalent to:
Input class= ' xxx ' Value=raw (Params[:account])
Where the raw method is interpreted in the Rails documentation is this:
This method outputs without escaping a string. Since escaping tags are now default, this can be used when you don t want Rails to automatically escape tags. This isn't recommended if the data is coming from the user ' s input.
The idea is that this method will skip the label filtering and other processing of the incoming string, outputting the string directly into the HTML.
So until now the reason is very clear, because accidentally added an equal sign in the code, become a double equals, resulting in the user's input output directly to the HTML to be rendered, without self-knowledge, leaving an XSS vulnerability. Thus, the fix only needs to remove an equal sign:
Input class= ' xxx ' value=params[:account]
This way, Rails can continue to automatically filter input: Account parameters and automatically filter malicious content.
Raw, String#html_safe, and <%==%>
When you look at the raw method's documentation, by the way, the source code is extremely simple, with only one line:
# File Actionview/lib/action_view/helpers/output_safety_helper.rb, line
def Raw (stringish)
stringish.to_ S.html_safe End
Raw only ensures that the Stringish parameter is converted to a string, and then the String#html_safe method is invoked. And in String#html_safe's documentation, the same emphasis is repeatedly placed on the cautious use of these two methods:
It is inserted into the HTML with no additional escaping performed. It is your responsibilty to ensure the string contains no malicious content. This are equivalent to the raw helper.
So, to sum up, the following three types of code are equivalent, are unsafe:
Input class= ' xxx ' value==params[:account]
input class= ' xxx ' Value=raw (params[:account])
input class= ' xxx ' Value=params[:account].html_safe
How do you guarantee security when you actually need to output content that contains HTML content, such as rich text editor edits?
The scenario is simple, and you only need to use the recommended Sanitize helper method in your document:
It is recommended the use sanitize instead the This method (Html_safe).
(#sanitize) sanitizes HTML input, stripping all tags and attributes that aren ' t whitelisted.
Or use some other third-party gem to do the filtering process.
Summarize
- Do not use the double equals abbreviation to avoid misuse by other people, such as the Rails Novice in the project, without understanding;
- Use #sanitize as much as possible without raw helper or String#html_safe methods;
- Using tools for automatic scanning, such as brakeman, can quickly and efficiently detect multiple security risks including XSS vulnerabilities.