Display HTML-mail in Rails and sanitize javascript - ruby-on-rails

I'm working on a webmail alike application.
What ist the best solution to escape 'bad' characters and strings like '' etc.?
Common HTML-Tags such as ul, br, img etc. should still be interpreted by the browser as valid HTML.
I already played arround with rgrove/sanitize but the results weren't promising, besides i need to escape, not sanitize the bad characters.
-e-
i'm using DHTMLX, maybe i can use one of it's components?
-e2-
i now display the mail content in a iframe. But i still need to get rid of javascript in the mails, any help?

Related

Properly Escaping a String inside a View

I've read in multiple places that as of Rails 3 you no longer have to use html_escape "some string" to actually escape a string in a view and that simply writing <%= "some string" %> would escape the string by default. However, I cannot find this information in the docs. I read through the XSS in the Rails guides section that stated this:
https://guides.rubyonrails.org/security.html#cross-site-scripting-xss
As a second step, it is good practice to escape all output of the application, especially when re-displaying user input, which hasn't been input-filtered (as in the search form example earlier on). Use escapeHTML() (or its alias h()) method to replace the HTML input characters &, ", <, and > by their uninterpreted representations in HTML (&, ", <, and >).
Then I see several blogs that state that it is escaped by default. For example: https://www.netsparker.com/blog/web-security/preventing-xss-ruby-on-rails-web-applications/
https://dzone.com/articles/preventing-cross-site-scripting-vulnerabilities-wh
Found it:
https://guides.rubyonrails.org/3_0_release_notes.html
"7.4.3 Other Changes
You no longer need to call h(string) to escape HTML output, it is on by default in all view templates. If you want the unescaped string, call raw(string)."
escapeHTML() (or its alias h()) are from CGI::escapeHTML, which is a Ruby API implementation. If you aren't using Rails you still have a way to escape HTML. Rails may do some automagical handling of HTML in ERB files for display, and that is what you are probably referring to with html_escape "some string" and <%= "some string" %>. I think you are possibly confusing html_escape which you might need when displaying urls and such that are stored in the DB and you want the ERB processor to not mess it up? I know sometimes, particularly in .js.erb files I need to escape some things to get the result I was expecting. This is different than sanitizing. It seems in your example they are referring to something that you might accept and then redisplay, like a search string. If you put <i>hello</i> into a search box you would want to sanitize the input before passing it to the back end, or if you are using some javascript to filter you might want to escape it both for security reasons and to let it re-display correctly in the search box after you've filtered.
Edit: I was not able to find the answer to your comment in the ri doc either. But I tried:
<%= "<b>hello</b>" %>
<%= h("<b>hello</b>") %>
And got the same result in the browser:
<b>hello</b>
<b>hello</b>
So if you are asking if it is true, then I would say yes.

trouble using tinymce using ruby on rails

I am having trouble in using tinymce editor with rails 3. I want to show text in bold letters and having trouble using tags like when I write something in p tags It should go to next paragraphs. in my case this tags is not working. It remains on same lines and display p tags on site page.
The usual suspect when it comes to rails 3 printing raw html output to the site, is that someone forgot to call html_safe on whatever text should be printed.
So if you have a #my_model_instance.description that you edit with tinymce, you might want to make the view look like #my_model_instance.description.html_safe, or as they suggest in the comment on the documentation, raw(#my_model_instance.description).
If the text is coming from user input, however, you might want to be a bit cautious, since it might be possible for users to input all sorts of nasty injection hacks this way.

The PHP HTMLPurifier library, but for Rails?

Anyone who's done anything much with PHP and receiving rich-text input from something like TinyMCE has (probably) used something like HTMLPurifier to keep the nasties out of the HTML you're intentionally allowing the user to submit.
For example, HTMLPurifier will take a string of (potentially malformed) HTML and strip out disallowed elements and attributes, try to fix broken HTML, and in some cases convert things like <i> to <em>.
Does anything equivalent exist for Rails (3)? What's the generally accepted way to sanitize input from rich text editors in Rails so that you can output the unescaped HTML onto a web page and know that stuff like <style> and <script> tags have been taken out of it and it's not going to break your page (or steal your cookies!)?
EDIT | Anybody used Sanitize? Any other options with pro's & con's?
You can use the sanitize method.
sanitize(html)
There is also a Sanitize gem.
Sanitize.clean(html)
I tend to prefer the Sanitize gem because it can be used as a before_save filter in your models instead of having to use the sanitize method in each of your views.

rails 3 internationalization / localization - embeddings links in translated text

I need to embed links in my translated texts. I followed this post, but it doesn't seem to work in rails 3 anymore as the html tags don't get rendered properly.
Anyone knows how to get this done in rails 3?
Update:
Apparently, the html tags can be escaped by using the html_safe method. But does anyone know if there's another way to solve this problem without using html_safe?
I would like to avoid unescaping my html tags if possible, b/c I've encountered a situation where I have to pass in a text field into my translation, and I would like to avoid unescaping any strings that are user inputted.
Change {{url}} to %{url} and you should be good to go.
Update
Ok, thanks, that's important information about what "doesn't work" means :) So, you need to call the html_safe method on your call to link_to, eg.
link_to(t("log_in_href"), login_path).html_safe
This will tell Rails to render the HTML, not escaped.

French characters are not displaying correctly inside javascript grid

We have translated one of our pages to french and all the html within the page displays flawlessly. That said, there is a javascript table (ext js) and the accented characters are not displaying correctly. The page is encoded UTF-8 in the HTML meta tags, but when I look inside FireBug, I see the following:
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
I'm guessing the problem is related to the ISO-8859-1 having worked its way back in. Does anyone know why the page itself would display fine, but the text inside the javascript component wouldn't? Do you somehow specify the encoding separately for the javascript files?
The Accept-Charset tag gives a set of encodings that are accepted -- if all the data sent is encoded UTF-8, then don't worry about it.
Can you elaborate on exactly what is happening?
You say "javascript table" -- I presume you are constructing an HTML table in JS and placing it in the DOM? Please elaborate, especially w.r.t. any character conversions. Are you building HTML text or building with DOM elements with attributes?
Where does the JS get its data? If with AJAX, have you verified the Encoding for that page?
Does the JS use encode() or decode()? Those don't handle UTF-8 correctly.
EDIT:
Type the URL to the JS code in your browser, and look at "Page Info" to see its encoding. I'll bet it is ISO-8859-1, which would explain the header problems.
Next, check the encoding of the AJAX data. If it's dynamically created you can:
Enable "Show XMLHttpRequests" in FireBug's console,
Load on your base HTML page,
Open the FireBug console tab,
Expand the AJAX GET/POST request and open the Response sub-tab,
Check the Encoding for the data, and fix as needed.
BTW, I'm having similar problems and haven't entirely ironed out the issues (still not sure the source data isn't badly encoded).
It's possible that the ext. JS file strips out unrecognised characters as a security precaution.
The "Accept-Charset" header can be specified in a number of places, including as an attribute in certain HTML elements. Have you performed a search for Accept-Charset (case insensitive) in the offending file?

Resources