On Thu, Mar 10, 2011 at 12:14 PM, Tom Evans <tevans...@googlemail.com> wrote:
> 2011/3/10 Thiago Carvalho D' Ávila <thiagocav...@gmail.com>:
>> Oh, thanks a lot. That worked, but now I have one more doubt...
>>
>> What are the security issues related to the use of safe variable? When can I
>> consider it safe? Is it possible to make some kind of injection using it
>> this way? Is autoescape a better option?
>>
>
> They are all variants of the same thing. These are all equivalent:
>
> {{ foo|safe }}
>
> {% autoescape off %}
> {{ foo }}
> {% endautoescape %}
>
> from django.utils.safestring import mark_safe
> return render_to_response('...', { 'foo': mark_safe(foo) })
>
> They are all equally vulnerable to injection. If you mark a string as
> safe, it disables automatic output escaping, and if the string or a
> portion of the string is user controlled, then that is an injection
> vector, which is why Gennadiy suggested not building the HTML in the
> view.
>
> Cheers
>
> TomIf this is a field whose content you are allowing users to enter, it's pretty vulnerable. There are products that allow you to restrict html content, but, as far as I know, they are not part of Django, at least by default. Perhaps someone knows something that plugs in. Assuming that this is a model field value, you would want to qualify it on save, which, presumably happens much less often than views. But allowing users to enter HTML is something I try to avoid. (I'm stuck with it on many of our plone sites, but plone has "safe html" controls built in.) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
