On Thu, Oct 17, 2013 at 3:30 AM, Jonathan Slenders <
[email protected]> wrote:
> Currently, on python-ideas there is a discussion going on about taint
> tracking in Python. It's tracking data that come from untrusted sources and
> preventing it from being used in sensitive places. This video [1] from last
> year explains the problems very well.
>
> In noticed that we can do better in Django. We already have mark_safe, but
> what does such a SafeText mean? Safe as HTML, javascript, css, SQL or even
> something else? We know it's usually HTML, but that's not always the case.
>
> Some people still have javascript in their templates and they use template
> tags inside their javascript. :(
>
> Some people use the templating engine even for other stuff then generating
> HTML. The point is that we can't assume that "safe" means "safe as HTML".
> We have many languages in the web and HTML is just one of them.
>
> I propose some changes that are backwards compatible for
> django.utils.safestring:
> We should rename SafeText to HtmlText. Further we should not expect people
> to call format_html.
>
> Instead of mark_safe, I propose that we call:
> HtmlText('<p> %s </p>')
> Explicitely annotating a string as HTML.
>
> Instead of format_html, I propose that we do:
> HtmlText('<p> %s </p>') % 'unsafe text'
> Like django.utils.SafeText.__add__, we can implement SafeText.__mod__
>
> I think that string interpolation feels more natural. (Or for those who
> prefer .format(), we can add that method to HtmlText.)
>
> It can also be possible to stack escaping filters in the future:
> HtmlText('<script>%s</script>') % JavascriptText("function() { echo '%s';
> }") % 'hello world'
> (implementing JavascriptText can be hard, as escaping is different in
> different parts of the code.)
>
> Further, I would deprecate mark_for_escaping and EscapeData. [2] There
> should never be a reason to call this function.
>
> Any suggestions?
>
I can't fault your reasoning -- "safe" isn't a universal concept, and we
don't just generate HTML. There's already been a couple of bugs raised
about escaping in JavaScript IIRC.
Your proposed approach certainly sounds like a good starting point. I'm
sure there will be plenty of devil in the detail -- not the least of which,
how do you handle this in templates which can have mixed content (e.g., a
HTML page with JavaScript and CSS content embedded).
>From an implementation point of view, we can't just remove mark_safe
arbitrarily -- we'd need to have a migration plan in place, so that all the
existing code out there that is using mark_safe continues to work
(presumably interpreting safe text as safe HTML in the interim).
The other problem is finding someone to volunteer to actually do the work
:-) What you've described isn't a small undertaking.
Yours
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAJxq848dgvhOXL_FKWbYUd08%2BcdzthHNwNhA25ZEs2Ot_iHmyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
