James Bennett wrote:
> On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> > Some are suggesting that this text should be escaped before being
> > written to the db. It is true that the above text should be rendered as
> > follows in html/xml documents:
>
> I don't think we should escape before stori
Michael Radziej wrote:
[snip]
>
> I assume this is about Jacob's proposal, and it's handling this
> case correctly. Let's go through the steps he specified:
>
[snip]
Whether it is handling this case correctly or not, it still needs to be
escaped in an html or xml template, but not in a plain text
Hi Jacob!
>
> On Jun 21, 2006, at 12:13 PM, Simon Willison wrote:
>> Rather than directly accessing GET and POST data
>> you do it through some mechanism that /guarantees/ the format of the
>> data returned - and raises an exception if it can't make that
>> guarantee. There is no possible way of
Hi,
waylan wrote:
> I've been following this thread since the get-go with interest, but am
> a first time commenter here. Although I think the devs have a clear
> picture, I get the feeling that some participants in this discussion
> are geting input validation and output escaping confused which
On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> Some are suggesting that this text should be escaped before being
> written to the db. It is true that the above text should be rendered as
> follows in html/xml documents:
I don't think we should escape before storing. I think we should
*validate*
I've been following this thread since the get-go with interest, but am
a first time commenter here. Although I think the devs have a clear
picture, I get the feeling that some participants in this discussion
are geting input validation and output escaping confused which is
generating lots of unnes
On 6/22/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> I disagree that it's easy to write that kind of validator function -
> and I think trying to do so is a mistake. What if I want to post a
> comment on a forum like this?
Then you'd get caught by the validator.
Thinking about the implication
Hi Jacob,
Jacob Kaplan-Moss wrote:
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this, but I'm sure a good syntax could be found.
I'm not sure I missed a point; is this, for html, the
Hi, all. Yes, I like this much better, too.
> 1. request.GET['whatever'] returns a ``untrusted_string`` object, not
> a regular string
>
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this,
On 22 Jun 2006, at 08:48, James Bennett wrote:
> For given values of "validate", yes. It is, however, easy to write
> validator functions which will reject anything that looks like HTML,
> and HTML is the most important threat.
I disagree that it's easy to write that kind of validator function -
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, I don't like to put the whole burden into the input validation,
And nobody's really suggesting that we should; we already provide a
template filter for sanitizing on output, and a block tag for doing
the same seems like a decent idea.
Hey,
First, let me note that we're discussing one aspect of Django and
whether or not there is a sensible way to harden it agains XSS
exploits. It is not whether this or the other way is better ...
Now, I don't like to put the whole burden into the input validation,
since I believe
* Ther
I have to agree with these comments.
get the crap out at the 'input'/validation level.. once it has the
database/rendering stage it is too late.
while this submission isn't perfect, this is what I did to protect
against my own laziness on externally facing apps.
http://svn.zyons.python-hosti
On Jun 21, 2006, at 3:31 PM, Jacob Kaplan-Moss wrote:
> [...]
> Another place to start solving the XSS problem is at the input level;
> a policy of "don't trust data from the web" makes a lot more sense to
> me than one of "don't trust the template author".
Modded "+5 Insightful" :) I can attest
On Jun 21, 2006, at 12:13 PM, Simon Willison wrote:
> Rather than directly accessing GET and POST data
> you do it through some mechanism that /guarantees/ the format of the
> data returned - and raises an exception if it can't make that
> guarantee. There is no possible way of invalid data ending
On 21 Jun 2006, at 17:48, James Bennett wrote:
> And while we're at it, let's get serious about input handling. The
> first thing which occurs to me is to add a 'hasNoHTML' validator in
> django.core.validators; possibly this would be accompanied by a
> boolean 'allows_html' argument to TextFiel
16 matches
Mail list logo
