[prev in list] [next in list] [prev in thread] [next in thread]
List: owasp-dotnet
Subject: Re: [Owasp-dotnet] Insecure APIs,
From: Alex Smolen <me () alexsmolen ! com>
Date: 2008-07-28 21:25:57
Message-ID: 15EA50D6-41A5-443F-BA9A-4B53937EB44E () alexsmolen ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Jason,
This sounds like a much needed improvement to the way that ASP.NET
controls work with respect to encoding.
I'd like to help you adapt your work so it can be used in the
OWASP .NET ESAPI project (https://www.owasp.org/index.php/.NET_ESAPI).
Let me know when you have some stable code - I'm planning to work on
reorganizing the encoding API to shadow the recent changes to the Java
version and I could also base it on your work.
Best of luck,
Alex
On Jul 27, 2008, at 7:13 PM, Jason Axley wrote:
> Very interesting, although I've ran into some "challenges" that
> asp.net presents that may make this simplistic approach probably not
> universally workable. First and foremost is the likely case of
> double-encoding, depending on which asp.net controls you use.
>
> The HtmlControl class items are one example. Under the covers, it
> turns out that they use HtmlWriters that have the "encode" flag hard-
> coded to "true", so if you have already encoded text, it will end up
> being double-encoded when rendered by these controls. And the
> documentation was not very clear IIRC as to which controls did/did
> not auto-encode the output. So, it becomes a complicated set of
> guidelines for developers as to when you have to encode or not.
> There is no way to override this auto-encoding so at first blush
> something that seems to be a nice safe-by-default is actually kind
> of a problem.
>
> Another thing, Microsoft's .net HtmlEncode and UrlEncode are fail-
> open design, meaning they only encode a blacklist of characters--not
> sufficient. And instead of fixing .Net, MS released the AntiXSS
> library that implements fail-closed versions of these. However,
> there is no way in the framework to hook these in instead of the
> Microsoft versions. So, you end up with a mix of good and not-so-
> good. To make it worse, Microsoft's encoders do not canonicalize
> the data prior to encoding so you end up with a lot of double-
> encoding scenarios.
>
> The solution I'm working on is building web controls for display
> that auto-encode data passed to them. And they use an encoding
> routine that actually canonicalizes the data so no double-encoding
> to worry about. And they are even better fail-closed design than
> Microsoft's patched versions. Much of the work is based on the
> ESAPI java versions of similar design.
>
> -Jason
>
> dinis cruz wrote:
> >
> > In my view, the frameworks have a big responsibility in creating
> > environments that create secure applications.
> >
> > Unfortunately, even on very mature frameworks like ASP.NET the
> > default modes are still very insecure. Two good example are 1) how
> > all SQL Data APIs allow SQL injection (although LINQ is a big step
> > on the right direction) and 2) Direct HTML manipulation is easy
> > done (the main culpit here is <%= and Response.Write).
> >
> > Instead of Secure API (like Anti-XSS) and Secure ways to perform
> > security sensite operations (like using parameterized queries),
> > what I want are INSECURE APIs. I.e. Make all default API do the
> > right thing (from a security point of view) and provide specific
> > IAPIs to handle the 'insecure stuff'
> >
> > Here is a great solution from Steve Sanderson that tries to address
> > this problem: http://blog.codeville.net/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html-encoding/
> >
> > This solution dramaticaly reduces the XSS attack surface, since the
> > 'only' exposed methods are the ones of the (RawHtml) type. This
> > means that for example, when doing a source code review those would
> > be the ones one should focus our attention
> >
> > Dinis Cruz
> > !DSPAM:4,488ae6d648841921621314!
> >
> > _______________________________________________
> > Owasp-dotnet mailing list
> > Owasp-dotnet@lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-dotnet
> >
> >
> > !DSPAM:4,488ae6d648841921621314!
> >
>
> _______________________________________________
> Owasp-dotnet mailing list
> Owasp-dotnet@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-dotnet
[Attachment #5 (text/html)]
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; \
">Jason,<div><br></div><div><br></div><div>This sounds like a much needed improvement \
to the way that ASP.NET controls work with respect to \
encoding.</div><div><br></div><div>I'd like to help you adapt your work so it can be \
used in the OWASP .NET ESAPI project (<a \
href="https://www.owasp.org/index.php/.NET_ESAPI)">https://www.owasp.org/index.php/.NET_ESAPI)</a>. \
Let me know when you have some stable code - I'm planning to work on reorganizing the \
encoding API to shadow the recent changes to the Java version and I could also base \
it on your work.</div><div><br></div><div>Best of \
luck,</div><div>Alex</div><div><br></div><div><div><div>On Jul 27, 2008, at 7:13 PM, \
Jason Axley wrote:</div><br class="Apple-interchange-newline"><blockquote \
type="cite"> <div bgcolor="#ffffff" text="#000000"> Very interesting, although I've \
ran into some "challenges" that asp.net presents that may make this simplistic \
approach probably not universally workable. First and foremost is the likely \
case of double-encoding, depending on which asp.net controls you use.<br> <br> The \
HtmlControl class items are one example. Under the covers, it turns out that \
they use HtmlWriters that have the "encode" flag hard-coded to "true", so if you have \
already encoded text, it will end up being double-encoded when rendered by these \
controls. And the documentation was not very clear IIRC as to which controls \
did/did not auto-encode the output. So, it becomes a complicated set of \
guidelines for developers as to when you have to encode or not. There is no way \
to override this auto-encoding so at first blush something that seems to be a nice \
safe-by-default is actually kind of a problem.<br> <br> Another thing, Microsoft's \
.net HtmlEncode and UrlEncode are fail-open design, meaning they only encode a \
blacklist of characters--not sufficient. And instead of fixing .Net, MS \
released the AntiXSS library that implements fail-closed versions of these. \
However, there is no way in the framework to hook these in instead of the Microsoft \
versions. So, you end up with a mix of good and not-so-good. To make it \
worse, Microsoft's encoders do not canonicalize the data prior to encoding so you end \
up with a lot of double-encoding scenarios.<br> <br> The solution I'm working on is \
building web controls for display that auto-encode data passed to them. And \
they use an encoding routine that actually canonicalizes the data so no \
double-encoding to worry about. And they are even better fail-closed design \
than Microsoft's patched versions. Much of the work is based on the ESAPI java \
versions of similar design.<br> <br> -Jason<br> <br> dinis cruz wrote: <blockquote \
cite="mid:60235a7b0807260156p12aed022i1e8f3108641110a5@mail.gmail.com" type="cite"> \
<div dir="ltr">In my view, the frameworks have a big responsibility in creating \
environments that create secure applications.<br> <br> Unfortunately, even on very \
mature frameworks like <a moz-do-not-send="true" href="http://ASP.NET">ASP.NET</a> \
the default modes are still very insecure. Two good example are 1) how all SQL Data \
APIs allow SQL injection (although LINQ is a big step on the right direction) and 2) \
Direct HTML manipulation is easy done (the main culpit here is <%= and \
Response.Write).<br> <br> Instead of Secure API (like Anti-XSS) and Secure ways to \
perform security sensite operations (like using parameterized queries), what I want \
are INSECURE APIs. I.e. Make all default API do the right thing (from a security \
point of view) and provide specific IAPIs to handle the 'insecure stuff'<br> <br> \
Here is a great solution from Steve Sanderson that tries to address this problem: <a \
moz-do-not-send="true" \
href="http://blog.codeville.net/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html- \
encoding/">http://blog.codeville.net/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html-encoding/</a><br> \
<br> This solution dramaticaly reduces the XSS attack surface, since the 'only' \
exposed methods are the ones of the (RawHtml) type. This means that for example, when \
doing a source code review those would be the ones one should focus our attention<br> \
<br> Dinis Cruz<br> </div> !DSPAM:4,488ae6d648841921621314! <pre wrap=""><hr \
size="4" width="90%"> _______________________________________________
Owasp-dotnet mailing list
<a class="moz-txt-link-abbreviated" \
href="mailto:Owasp-dotnet@lists.owasp.org">Owasp-dotnet@lists.owasp.org</a> <a \
class="moz-txt-link-freetext" \
href="https://lists.owasp.org/mailman/listinfo/owasp-dotnet">https://lists.owasp.org/mailman/listinfo/owasp-dotnet</a>
!DSPAM:4,488ae6d648841921621314!
</pre> </blockquote> <br> </div> \
_______________________________________________<br>Owasp-dotnet mailing list<br><a \
href="mailto:Owasp-dotnet@lists.owasp.org">Owasp-dotnet@lists.owasp.org</a><br>https:/ \
/lists.owasp.org/mailman/listinfo/owasp-dotnet<br></blockquote></div><br></div></body></html>
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-dotnet
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic