Lucky/Crystal needs object taint/trust

[BrucePerens]

To solve the general issue of sanitizing input from the user before it is saved or rendered, Lucky or Crystal need Object taint/trust, which of course should be copied from Ruby. This is a ton of work because it needs to be preserved across all String operations and all string parsing operations such as to_i. It should then be the case that strings are HTML sanitized before being rendered or saved, unless the programmer insists.

For those unfamiliar with the Ruby implementation, params from the user got a taint bit set, which prevented them from being rendered without being filtered, unless the programmer insisted. I don't remember if the ORM would save tainted objects without first filtering them.

Discussion of the Ruby taint/trust feature

• https://www.linuxtopia.org/online_books/programming_books/ruby_tutorial/Locking_Ruby_in_the_Safe_Tainted_Objects.html
• https://ruby-doc.com/docs/ProgrammingRuby/html/taint.html

[BrucePerens]

Uh, it turns out that Ruby has deleted this feature due to lack of interest. Straight-Shoota has an HTML safe string that might be of interest to us.
https://github.com/straight-shoota/crinja/blob/master/src/runtime/safe_string.cr

[paulcsmith]

Hi @BrucePerens here is a Discord message I posted https://discord.com/channels/743896265057632256/743896265057632259/788097639987413012

Lucky does sanitize automatically when outputting but not on save. This is how many ORMs and frameworks work and it is nice because sometimes you want to have different sanitization rules for different outputs. Maybe some inputs do allow HTML (an admin interface) for example. The other reason we sanitize on output is that doing it on save is less secure in many ways. For example, let's say that you sanitize input on save but turns out there is a security issue in the sanitization code. You can't just update the library. You also would need to go through every column in your database that stores a string, re-sanitize, and save. It also can be problematic because you may need to sanitize differently depending on the context. What if you are building a backend API for a Native macOS app that doesn't need HTML sanitization, or maybe you have a library that sanitizes HTML but allows certain tags and renders them with native code (like a table. These are all things that are possible if you save the raw input, and sanitize on output (preferably automatically)

Lucky sanitizes params, text, and HTML data attributes automatically. You can use raw if you need the raw code otherwise it is sanitized

• All outputted text goes through this method which sanitizes the output

  lucky/src/lucky/tags/base_tags.cr

  Line 100 in 49f1021

  def text(content : String | Lucky::AllowedInTags) : Nil

• HTML attrs are also escaped/sanitized

  lucky/src/lucky/tags/base_tags.cr

  Line 117 in 49f1021

  attrs << HTML.escape(value.to_s)

[paulcsmith]

We may add something like String#html_safe like in ActiveSupport, but this is more of a convenience thing than something that would increase security. I'd argue having to use raw is more secure because it is very clear that you are outputting a raw string. Whereas using html_safe can be scary because someone may add an html_safe somewhere further up the chain and you don't realize it and accidentally output unsafe text 🙁