[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [WEB SECURITY] XSS/injection/... evading technique

------_=_NextPart_001_01C8EE5A.4B988254
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Inline:

>> which are often
>> legitimate (for example, they're used to wrap JSON objects).
>
>> While that may be true, why on earth would untrusted users be allowed =
to be
>> submitting HTML comments or submitting JSON objects that need to be
>> depantsed before processing? As an author of a rich content =
validation tool,
>> I can say that this is categorically a bad idea. Consider the IE5+ =
XSS
>> vector:

> On the other hand, consider a content management system where users
> are allowed to edit HTML templates in a browser. HTML comments,
> including IE's conditional comments, are legitimate content in that
> situation.

Why would you have a WAF to protect this functionality? It's bound to =
set off red alerts 24/7, and if users are trusted to send in malicious =
content, same question?

>> It's definitely going to be slower than simple pattern matching, but
>> that still doesn't mean that it's going to slow, because what's slow
>> for one deployment might not be slow for another. Either way, I think
>> we should first focus on how to secure things and then (if we need =
to)
>> how to scale the security measures.

Well, if you know what the rules are for a parameter, it's pretty easy =
to secure it. In the case of all the original emailer where the rule for =
the parameter appeared to be "any printable character" the right choice =
would've been to apply that rule simply output encode all =
non-alphanumeric in their data on the way out (assuming it didn't end up =
inside an event handler, <script> tag or CSS definition).

------_=_NextPart_001_01C8EE5A.4B988254
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [WEB SECURITY] XSS/injection/... evading technique</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Inline:<BR>
<BR>
&gt;&gt; which are often<BR>
&gt;&gt; legitimate (for example, they're used to wrap JSON =
objects).<BR>
&gt;<BR>
&gt;&gt; While that may be true, why on earth would untrusted users be =
allowed to be<BR>
&gt;&gt; submitting HTML comments or submitting JSON objects that need =
to be<BR>
&gt;&gt; depantsed before processing? As an author of a rich content =
validation tool,<BR>
&gt;&gt; I can say that this is categorically a bad idea. Consider the =
IE5+ XSS<BR>
&gt;&gt; vector:<BR>
<BR>
&gt; On the other hand, consider a content management system where =
users<BR>
&gt; are allowed to edit HTML templates in a browser. HTML comments,<BR>
&gt; including IE's conditional comments, are legitimate content in =
that<BR>
&gt; situation.<BR>
<BR>
Why would you have a WAF to protect this functionality? It's bound to =
set off red alerts 24/7, and if users are trusted to send in malicious =
content, same question?<BR>
<BR>
&gt;&gt; It's definitely going to be slower than simple pattern =
matching, but<BR>
&gt;&gt; that still doesn't mean that it's going to slow, because what's =
slow<BR>
&gt;&gt; for one deployment might not be slow for another. Either way, I =
think<BR>
&gt;&gt; we should first focus on how to secure things and then (if we =
need to)<BR>
&gt;&gt; how to scale the security measures.<BR>
<BR>
Well, if you know what the rules are for a parameter, it's pretty easy =
to secure it. In the case of all the original emailer where the rule for =
the parameter appeared to be &quot;any printable character&quot; the =
right choice would've been to apply that rule simply output encode all =
non-alphanumeric in their data on the way out (assuming it didn't end up =
inside an event handler, &lt;script&gt; tag or CSS =
definition).</FONT></P>

</BODY>
<!--[object_id=3D#aspectsecurity.com#]--></HTML>
------_=_NextPart_001_01C8EE5A.4B988254--
Brought to you by http://www.webappsec.org
Search this site