It's possible to have a given order greater than the number of answers;
we don't have any validation rules for that. So the check for the number
of answers isn't enough.
Checking the maximum given order in the answers is safer. Another option
would be to reorder the answers every time we add a new one, but I'm not
sure whether that's the expected behaviour.
Note even after this change the action is not thread-safe, as it is
possible to create two questions with the same given order with two
simultaneous requests.
The page could have "7777" as a content for the poll's name, since that
name is generated using a random hexadecimal number.
Restricting the search to the area of the page where the "7777" used to
be solves the problem.
Using the `_html` suffix in an i18n key is the same as using `html_safe`
on it, which means that translation could potentially be used for XSS
attacks.
Using the `_html` suffix automatically marks texts as HTML safe, so
doing so on sanitized texts is redundant.
Note flash texts are not sanitized the moment they are generated, but
are sanitized when displayed in the view.
Although this translation has HTML, we aren't marking them as HTML safe
since we're using `I18n.t` instead of Rails' helper `t` method. So using
the `_html` suffix is counterintuitive in this case.
Although it's already executed when deploying with capistrano, heroku
installations don't use capistrano for deployment, so we're also
executing it when upgrading.
This isn't a one-time task, so it makes sense to have it executed on
every release.
I was thinking of leaving these tasks empty, so in the future we could
use them again if we rename or remove more settings. But since we
haven't renamed nor removed any settings for more than seven months, and
we've only used these tasks once, I'm simply removing the tasks. It's
easy to add them back if we ever need them.
Using `<%==` is the same as using `raw`. I'm not sure if we meant
`sanitize` in this case, or it's just a typo. I'm assuming the latter
since we don't use anything similar in any other places.
This way we make sure we won't add `html_safe` or `raw` calls in the
future.
I'm excluding `text_with_links_helpers` for this check, because in this
situation the use of `html_safe` is justified: we check the original
input is safe, and we're only adding link tags to raw URLs.
They do the exact same thing; however `html_safe` might confuse
developers into thinking it will make the HTML safe. Using `raw` makes
it clear that we're inserting the text without escaping it.
The difference is `html_safe` allows every HTML tag, including the
`<script>` tag, while `sanitize` only allows tags which are considered
safe. In this case, we want to allow a `<span>` tag in a translation,
and links inside flash messages.
Sometimes we're interpolating a link inside a translation, and marking
the whole translations as HTML safe.
However, some translations added by admins to the database or through
crowdin are not entirely under our control.
Although AFAIK crowdin checks for potential cross-site scripting
attacks, it's a good practice to sanitize parts of a string potentially
out of our control before marking the string as HTML safe.
There's a slight chance an attribute like an author's name might contain
an attempt to perform XSS attacks. So, instead of marking the whole text
as HTML safe, we can sanitize it.
Also note I'm removing the `_html` suffix in the i18n key, since it's
got the same effect as using `html_safe`.
We were using `Rinku.auto_link` the same way twice. And it makes sense
that the method `sanitize_and_auto_link` first sanitizes the text and
then calls `auto_link_already_sanitized_text`.
The name `safe_html_with_links` was confusing and could make you think
it takes care of making the HTML safe. So I've renamed it in a way that
makes it a bit more intuitive that it expects its input to be already
sanitized.
I've changed `text_with_links` as well so now the two method names
complement each other.
There's a case where we would face a Cross-Site Scripting attack. An
attacker could use the browser's developer tools to add (on their
browser) a `<code>` tag with a `<script>` tag inside in the text of the
draft version. After doing so, commenting on that text would result in
the attacker's JavaScript being executed.
It's possible to create a newsletter or a proposed action with
<script> tags by filling in the body using a textarea instead of a
CKEditor. While we trust our administrators not to do so, it's better to
completely eliminate that possibility.
We need to update other gems as well if we update this one. Dependabot
updated it automatically when updating `foundation_rails_helper`, but it
doesn't seem to be necessary.
The name `html_safe` is very confusing, and many developers (including
me a few years ago) think what that method does is convert the HTML
contents to safe content. It's actually quite the opposite: it marks the
string as safe, so the HTML inside it isn't stripped out by Rails.
In some cases we were marking strings as safe because we wanted to add
some HTML. However, it meant the whole string was considered safe, and
not just the contents which were under our control.
In particular, some translations added by admins to the database or
through crowding were marked as safe, when it wasn't necessarily the
case.
Although AFAIK crowdin checks for potential cross-site scripting
attacks, it's a good practice to sanitize parts of a string potentially
out of our control before marking the string as HTML safe.
