Empathy List Archives

R

romain

Wed, Feb 27, 2013 2:28 AM

Everybody,
We release an XSS cheat sheet for developers today. The document talks
about several contexts (13 combinations right now, but we'll be improving
it).
Some more info are available on Coverity blog:

https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

Our goal is to keep improving this cheat sheet while adding escapers and
sanitizers to our library:
https://github.com/coverity/coverity-security-library

Cheers,
Romain

Everybody, We release an XSS cheat sheet for developers today. The document talks about several contexts (13 combinations right now, but we'll be improving it). Some more info are available on Coverity blog: https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers Our goal is to keep improving this cheat sheet while adding escapers and sanitizers to our library: https://github.com/coverity/coverity-security-library Cheers, Romain

EO

Erlend Oftedal

Wed, Feb 27, 2013 8:31 AM

Hard to tell really as your website blocks IE10 thinking it's IE6 (not
optimizing for old browsers is ok, but blocking is an antipattern -
especially when it's wrong).

Joke aside, the document itself seems decent. It's easy to get an overview
over the context. Did you test your CSS escaping in older browsers? I seem
to remember there were some problems, and that escaping itself was not
enough.

Also, why build your own cheat sheet instead of contributing to the
established free and open OWASP XSS Prevention Cheat Sheet?

Best regards,
Erlend Oftedal

On Wed, Feb 27, 2013 at 3:28 AM, romain r@fuckthespam.com wrote:

Everybody,
We release an XSS cheat sheet for developers today. The document talks
about several contexts (13 combinations right now, but we'll be improving
it).
Some more info are available on Coverity blog:

https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

Our goal is to keep improving this cheat sheet while adding escapers and
sanitizers to our library:
https://github.com/coverity/coverity-security-library

Cheers,
Romain

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Hard to tell really as your website blocks IE10 thinking it's IE6 (not optimizing for old browsers is ok, but blocking is an antipattern - especially when it's wrong). Joke aside, the document itself seems decent. It's easy to get an overview over the context. Did you test your CSS escaping in older browsers? I seem to remember there were some problems, and that escaping itself was not enough. Also, why build your own cheat sheet instead of contributing to the established free and open OWASP XSS Prevention Cheat Sheet? Best regards, Erlend Oftedal On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com> wrote: > Everybody, > We release an XSS cheat sheet for developers today. The document talks > about several contexts (13 combinations right now, but we'll be improving > it). > Some more info are available on Coverity blog: > > https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers > > Our goal is to keep improving this cheat sheet while adding escapers and > sanitizers to our library: > https://github.com/coverity/coverity-security-library > > Cheers, > Romain > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >

R

romain

Wed, Feb 27, 2013 3:45 PM

Argh, sorry about the blog and IE10. Not the first time I hear that...

Concerning the CSS string escaper we did some testing, but not on super old
browsers actually. However, we looked at the how CSS parsers are recovering
from errors, and what characters need to be escaped. That's mostly why our
CSS string escaper will escape new lines chars and more. Still, we have
some more work to do; CSS parsers are a real pain.

Contributing to OWASP XSS prevention cheat sheet is something we talked
about. However, the OWASP document is first of all promoting ESAPI when we
are sorta promoting our lib. We are also talking about HTML contexts at a
more fine grain level and it's difficult to put this in OWASP framework.
The OWASP cheat sheet format doesn't also play well with what we wanted to
do. They are driven by few rules for preventing XSS, we're more about code
example.

Romain

@rgaucher

On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal erlend@oftedal.no wrote:

Hard to tell really as your website blocks IE10 thinking it's IE6 (not
optimizing for old browsers is ok, but blocking is an antipattern -
especially when it's wrong).

Joke aside, the document itself seems decent. It's easy to get an overview
over the context. Did you test your CSS escaping in older browsers? I seem
to remember there were some problems, and that escaping itself was not
enough.

Also, why build your own cheat sheet instead of contributing to the
established free and open OWASP XSS Prevention Cheat Sheet?

Best regards,
Erlend Oftedal

On Wed, Feb 27, 2013 at 3:28 AM, romain r@fuckthespam.com wrote:

Everybody,
We release an XSS cheat sheet for developers today. The document talks
about several contexts (13 combinations right now, but we'll be improving
it).
Some more info are available on Coverity blog:

https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

Our goal is to keep improving this cheat sheet while adding escapers and
sanitizers to our library:
https://github.com/coverity/coverity-security-library

Cheers,
Romain

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Argh, sorry about the blog and IE10. Not the first time I hear that... Concerning the CSS string escaper we did some testing, but not on super old browsers actually. However, we looked at the how CSS parsers are recovering from errors, and what characters need to be escaped. That's mostly why our CSS string escaper will escape new lines chars and more. Still, we have some more work to do; CSS parsers are a real pain. Contributing to OWASP XSS prevention cheat sheet is something we talked about. However, the OWASP document is first of all promoting ESAPI when we are sorta promoting our lib. We are also talking about HTML contexts at a more fine grain level and it's difficult to put this in OWASP framework. The OWASP cheat sheet format doesn't also play well with what we wanted to do. They are driven by few rules for preventing XSS, we're more about code example. Romain - @rgaucher On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no> wrote: > Hard to tell really as your website blocks IE10 thinking it's IE6 (not > optimizing for old browsers is ok, but blocking is an antipattern - > especially when it's wrong). > > Joke aside, the document itself seems decent. It's easy to get an overview > over the context. Did you test your CSS escaping in older browsers? I seem > to remember there were some problems, and that escaping itself was not > enough. > > Also, why build your own cheat sheet instead of contributing to the > established free and open OWASP XSS Prevention Cheat Sheet? > > Best regards, > Erlend Oftedal > > > On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com> wrote: > >> Everybody, >> We release an XSS cheat sheet for developers today. The document talks >> about several contexts (13 combinations right now, but we'll be improving >> it). >> Some more info are available on Coverity blog: >> >> https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers >> >> Our goal is to keep improving this cheat sheet while adding escapers and >> sanitizers to our library: >> https://github.com/coverity/coverity-security-library >> >> Cheers, >> Romain >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >

ES

Eric Sheridan

Wed, Feb 27, 2013 4:13 PM

At least you admit you're promoting something of your own (i.e. CSL) by
keeping it separate instead of helping OWASP T10 promote their agenda
(ex: ESAPI).

Nice research.

Sincerely,
Eric Sheridan
(twitter) @eric_sheridan
(blog) http://ericsheridan.blogspot.com

On 2/27/13 10:45 AM, romain wrote:

Argh, sorry about the blog and IE10. Not the first time I hear that...

Concerning the CSS string escaper we did some testing, but not on super
old browsers actually. However, we looked at the how CSS parsers are
recovering from errors, and what characters need to be escaped. That's
mostly why our CSS string escaper will escape new lines chars and more.
Still, we have some more work to do; CSS parsers are a real pain.

Contributing to OWASP XSS prevention cheat sheet is something we talked
about. However, the OWASP document is first of all promoting ESAPI when
we are sorta promoting our lib. We are also talking about HTML contexts
at a more fine grain level and it's difficult to put this in OWASP
framework.
The OWASP cheat sheet format doesn't also play well with what we wanted
to do. They are driven by few rules for preventing XSS, we're more about
code example.

Romain

@rgaucher

On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no
mailto:erlend@oftedal.no> wrote:

 Hard to tell really as your website blocks IE10 thinking it's IE6
 (not optimizing for old browsers is ok, but blocking is an
 antipattern - especially when it's wrong).

 Joke aside, the document itself seems decent. It's easy to get an
 overview over the context. Did you test your CSS escaping in older
 browsers? I seem to remember there were some problems, and that
 escaping itself was not enough.

 Also, why build your own cheat sheet instead of contributing to the
 established free and open OWASP XSS Prevention Cheat Sheet?

 Best regards,
 Erlend Oftedal


 On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com
 <mailto:r@fuckthespam.com>> wrote:

     Everybody,
     We release an XSS cheat sheet for developers today. The document
     talks about several contexts (13 combinations right now, but
     we'll be improving it).
     Some more info are available on Coverity blog:
       https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

     Our goal is to keep improving this cheat sheet while adding
     escapers and sanitizers to our library:
       https://github.com/coverity/coverity-security-library

     Cheers,
     Romain
       

     _______________________________________________
     The Web Security Mailing List

     WebSecurity RSS Feed
     http://www.webappsec.org/rss/websecurity.rss

     Join WASC on LinkedIn
     http://www.linkedin.com/e/gis/83336/4B20E4374DBA

     WASC on Twitter
     http://twitter.com/wascupdates

     websecurity@lists.webappsec.org
     <mailto:websecurity@lists.webappsec.org>
     http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

At least you admit you're promoting something of your own (i.e. CSL) by keeping it separate instead of helping OWASP T10 promote their agenda (ex: ESAPI). Nice research. Sincerely, Eric Sheridan (twitter) @eric_sheridan (blog) http://ericsheridan.blogspot.com On 2/27/13 10:45 AM, romain wrote: > Argh, sorry about the blog and IE10. Not the first time I hear that... > > Concerning the CSS string escaper we did some testing, but not on super > old browsers actually. However, we looked at the how CSS parsers are > recovering from errors, and what characters need to be escaped. That's > mostly why our CSS string escaper will escape new lines chars and more. > Still, we have some more work to do; CSS parsers are a real pain. > > Contributing to OWASP XSS prevention cheat sheet is something we talked > about. However, the OWASP document is first of all promoting ESAPI when > we are sorta promoting our lib. We are also talking about HTML contexts > at a more fine grain level and it's difficult to put this in OWASP > framework. > The OWASP cheat sheet format doesn't also play well with what we wanted > to do. They are driven by few rules for preventing XSS, we're more about > code example. > > Romain > - @rgaucher > > > On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no > <mailto:erlend@oftedal.no>> wrote: > > Hard to tell really as your website blocks IE10 thinking it's IE6 > (not optimizing for old browsers is ok, but blocking is an > antipattern - especially when it's wrong). > > Joke aside, the document itself seems decent. It's easy to get an > overview over the context. Did you test your CSS escaping in older > browsers? I seem to remember there were some problems, and that > escaping itself was not enough. > > Also, why build your own cheat sheet instead of contributing to the > established free and open OWASP XSS Prevention Cheat Sheet? > > Best regards, > Erlend Oftedal > > > On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com > <mailto:r@fuckthespam.com>> wrote: > > Everybody, > We release an XSS cheat sheet for developers today. The document > talks about several contexts (13 combinations right now, but > we'll be improving it). > Some more info are available on Coverity blog: > https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers > > Our goal is to keep improving this cheat sheet while adding > escapers and sanitizers to our library: > https://github.com/coverity/coverity-security-library > > Cheers, > Romain > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > <mailto:websecurity@lists.webappsec.org> > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > > > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >

JM

Jim Manico

Wed, Feb 27, 2013 4:29 PM

Romain,

If you are willing to donate some of your (most excellent) content to OWASP and help collaborate on the OWASP XSS Prevention Cheatsheet, I would be super happy to drop ESAPI from it and make the guide more vendor and product neutral. I would also be happy to add you as a core contributor.

The invitation is there, it would be a great pleasure to work with you on this for the community at large.

Aloha,

Jim Manico
OWASP Board Member
jim@owasp.org

At least you admit you're promoting something of your own (i.e. CSL) by
keeping it separate instead of helping OWASP T10 promote their agenda
(ex: ESAPI).

Nice research.

Sincerely,
Eric Sheridan
(twitter) @eric_sheridan
(blog) http://ericsheridan.blogspot.com

On 2/27/13 10:45 AM, romain wrote:

Argh, sorry about the blog and IE10. Not the first time I hear that...

Concerning the CSS string escaper we did some testing, but not on super
old browsers actually. However, we looked at the how CSS parsers are
recovering from errors, and what characters need to be escaped. That's
mostly why our CSS string escaper will escape new lines chars and more.
Still, we have some more work to do; CSS parsers are a real pain.

Contributing to OWASP XSS prevention cheat sheet is something we talked
about. However, the OWASP document is first of all promoting ESAPI when
we are sorta promoting our lib. We are also talking about HTML contexts
at a more fine grain level and it's difficult to put this in OWASP
framework.
The OWASP cheat sheet format doesn't also play well with what we wanted
to do. They are driven by few rules for preventing XSS, we're more about
code example.

Romain

@rgaucher

On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no
mailto:erlend@oftedal.no> wrote:

 Hard to tell really as your website blocks IE10 thinking it's IE6
 (not optimizing for old browsers is ok, but blocking is an
 antipattern - especially when it's wrong).

 Joke aside, the document itself seems decent. It's easy to get an
 overview over the context. Did you test your CSS escaping in older
 browsers? I seem to remember there were some problems, and that
 escaping itself was not enough.

 Also, why build your own cheat sheet instead of contributing to the
 established free and open OWASP XSS Prevention Cheat Sheet?

 Best regards,
 Erlend Oftedal


 On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com
 <mailto:r@fuckthespam.com>> wrote:

     Everybody,
     We release an XSS cheat sheet for developers today. The document
     talks about several contexts (13 combinations right now, but
     we'll be improving it).
     Some more info are available on Coverity blog:
       https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

     Our goal is to keep improving this cheat sheet while adding
     escapers and sanitizers to our library:
       https://github.com/coverity/coverity-security-library

     Cheers,
     Romain
       

     _______________________________________________
     The Web Security Mailing List

     WebSecurity RSS Feed
     http://www.webappsec.org/rss/websecurity.rss

     Join WASC on LinkedIn
     http://www.linkedin.com/e/gis/83336/4B20E4374DBA

     WASC on Twitter
     http://twitter.com/wascupdates

     websecurity@lists.webappsec.org
     <mailto:websecurity@lists.webappsec.org>
     http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Romain, If you are willing to donate some of your (most excellent) content to OWASP and help collaborate on the OWASP XSS Prevention Cheatsheet, I would be super happy to drop ESAPI from it and make the guide more vendor and product neutral. I would also be happy to add you as a core contributor. The invitation is there, it would be a great pleasure to work with you on this for the community at large. Aloha, Jim Manico OWASP Board Member jim@owasp.org > At least you admit you're promoting something of your own (i.e. CSL) by > keeping it separate instead of helping OWASP T10 promote their agenda > (ex: ESAPI). > > Nice research. > > Sincerely, > Eric Sheridan > (twitter) @eric_sheridan > (blog) http://ericsheridan.blogspot.com > > On 2/27/13 10:45 AM, romain wrote: >> Argh, sorry about the blog and IE10. Not the first time I hear that... >> >> Concerning the CSS string escaper we did some testing, but not on super >> old browsers actually. However, we looked at the how CSS parsers are >> recovering from errors, and what characters need to be escaped. That's >> mostly why our CSS string escaper will escape new lines chars and more. >> Still, we have some more work to do; CSS parsers are a real pain. >> >> Contributing to OWASP XSS prevention cheat sheet is something we talked >> about. However, the OWASP document is first of all promoting ESAPI when >> we are sorta promoting our lib. We are also talking about HTML contexts >> at a more fine grain level and it's difficult to put this in OWASP >> framework. >> The OWASP cheat sheet format doesn't also play well with what we wanted >> to do. They are driven by few rules for preventing XSS, we're more about >> code example. >> >> Romain >> - @rgaucher >> >> >> On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no >> <mailto:erlend@oftedal.no>> wrote: >> >> Hard to tell really as your website blocks IE10 thinking it's IE6 >> (not optimizing for old browsers is ok, but blocking is an >> antipattern - especially when it's wrong). >> >> Joke aside, the document itself seems decent. It's easy to get an >> overview over the context. Did you test your CSS escaping in older >> browsers? I seem to remember there were some problems, and that >> escaping itself was not enough. >> >> Also, why build your own cheat sheet instead of contributing to the >> established free and open OWASP XSS Prevention Cheat Sheet? >> >> Best regards, >> Erlend Oftedal >> >> >> On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com >> <mailto:r@fuckthespam.com>> wrote: >> >> Everybody, >> We release an XSS cheat sheet for developers today. The document >> talks about several contexts (13 combinations right now, but >> we'll be improving it). >> Some more info are available on Coverity blog: >> https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers >> >> Our goal is to keep improving this cheat sheet while adding >> escapers and sanitizers to our library: >> https://github.com/coverity/coverity-security-library >> >> Cheers, >> Romain >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn >> http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> <mailto:websecurity@lists.webappsec.org> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >> >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

JP

Jon Passki

Wed, Feb 27, 2013 4:41 PM

Constructive criticism is always appreciated.

CSL is released under a BSD license and is open source. Feel free to incorporate whatever makes sense for ESAPI.
CSL solved an immediate need for Coverity that wasn't solved by existing projects.

I dunno why the Internet rage machine is pointed at CSL today. I think the community is better served if we can move the discussion back to constructive criticisms, quantified results, and actionable feedback instead of snide comments. Alas, it's a free world so carry on as you see fit.

Regards,

Jon

p.s. Happy to move this discussion into meat space too. I think a lot of us are in SF for RSA. Happy to keep it to email too.

On Feb 27, 2013, at 8:13 AM, Eric Sheridan eric.sheridan@owasp.org wrote:

At least you admit you're promoting something of your own (i.e. CSL) by
keeping it separate instead of helping OWASP T10 promote their agenda
(ex: ESAPI).

Nice research.

Sincerely,
Eric Sheridan
(twitter) @eric_sheridan
(blog) http://ericsheridan.blogspot.com

On 2/27/13 10:45 AM, romain wrote:

Argh, sorry about the blog and IE10. Not the first time I hear that...

Concerning the CSS string escaper we did some testing, but not on super
old browsers actually. However, we looked at the how CSS parsers are
recovering from errors, and what characters need to be escaped. That's
mostly why our CSS string escaper will escape new lines chars and more.
Still, we have some more work to do; CSS parsers are a real pain.

Contributing to OWASP XSS prevention cheat sheet is something we talked
about. However, the OWASP document is first of all promoting ESAPI when
we are sorta promoting our lib. We are also talking about HTML contexts
at a more fine grain level and it's difficult to put this in OWASP
framework.
The OWASP cheat sheet format doesn't also play well with what we wanted
to do. They are driven by few rules for preventing XSS, we're more about
code example.

Romain

@rgaucher

On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no
mailto:erlend@oftedal.no> wrote:

Hard to tell really as your website blocks IE10 thinking it's IE6
(not optimizing for old browsers is ok, but blocking is an
antipattern - especially when it's wrong).

Joke aside, the document itself seems decent. It's easy to get an
overview over the context. Did you test your CSS escaping in older
browsers? I seem to remember there were some problems, and that
escaping itself was not enough.

Also, why build your own cheat sheet instead of contributing to the
established free and open OWASP XSS Prevention Cheat Sheet?

Best regards,
Erlend Oftedal


On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com
<mailto:r@fuckthespam.com>> wrote:

    Everybody,
    We release an XSS cheat sheet for developers today. The document
    talks about several contexts (13 combinations right now, but
    we'll be improving it).
    Some more info are available on Coverity blog:
      https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

    Our goal is to keep improving this cheat sheet while adding
    escapers and sanitizers to our library:
      https://github.com/coverity/coverity-security-library

    Cheers,
    Romain


    _______________________________________________
    The Web Security Mailing List

    WebSecurity RSS Feed
    http://www.webappsec.org/rss/websecurity.rss

    Join WASC on LinkedIn
    http://www.linkedin.com/e/gis/83336/4B20E4374DBA

    WASC on Twitter
    http://twitter.com/wascupdates

    websecurity@lists.webappsec.org
    <mailto:websecurity@lists.webappsec.org>
    http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Constructive criticism is always appreciated. * CSL is released under a BSD license and is open source. Feel free to incorporate whatever makes sense for ESAPI. * CSL solved an immediate need for Coverity that wasn't solved by existing projects. I dunno why the Internet rage machine is pointed at CSL today. I think the community is better served if we can move the discussion back to constructive criticisms, quantified results, and actionable feedback instead of snide comments. Alas, it's a free world so carry on as you see fit. Regards, Jon p.s. Happy to move this discussion into meat space too. I think a lot of us are in SF for RSA. Happy to keep it to email too. On Feb 27, 2013, at 8:13 AM, Eric Sheridan <eric.sheridan@owasp.org> wrote: > At least you admit you're promoting something of your own (i.e. CSL) by > keeping it separate instead of helping OWASP T10 promote their agenda > (ex: ESAPI). > > Nice research. > > Sincerely, > Eric Sheridan > (twitter) @eric_sheridan > (blog) http://ericsheridan.blogspot.com > > On 2/27/13 10:45 AM, romain wrote: >> Argh, sorry about the blog and IE10. Not the first time I hear that... >> >> Concerning the CSS string escaper we did some testing, but not on super >> old browsers actually. However, we looked at the how CSS parsers are >> recovering from errors, and what characters need to be escaped. That's >> mostly why our CSS string escaper will escape new lines chars and more. >> Still, we have some more work to do; CSS parsers are a real pain. >> >> Contributing to OWASP XSS prevention cheat sheet is something we talked >> about. However, the OWASP document is first of all promoting ESAPI when >> we are sorta promoting our lib. We are also talking about HTML contexts >> at a more fine grain level and it's difficult to put this in OWASP >> framework. >> The OWASP cheat sheet format doesn't also play well with what we wanted >> to do. They are driven by few rules for preventing XSS, we're more about >> code example. >> >> Romain >> - @rgaucher >> >> >> On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no >> <mailto:erlend@oftedal.no>> wrote: >> >> Hard to tell really as your website blocks IE10 thinking it's IE6 >> (not optimizing for old browsers is ok, but blocking is an >> antipattern - especially when it's wrong). >> >> Joke aside, the document itself seems decent. It's easy to get an >> overview over the context. Did you test your CSS escaping in older >> browsers? I seem to remember there were some problems, and that >> escaping itself was not enough. >> >> Also, why build your own cheat sheet instead of contributing to the >> established free and open OWASP XSS Prevention Cheat Sheet? >> >> Best regards, >> Erlend Oftedal >> >> >> On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com >> <mailto:r@fuckthespam.com>> wrote: >> >> Everybody, >> We release an XSS cheat sheet for developers today. The document >> talks about several contexts (13 combinations right now, but >> we'll be improving it). >> Some more info are available on Coverity blog: >> https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers >> >> Our goal is to keep improving this cheat sheet while adding >> escapers and sanitizers to our library: >> https://github.com/coverity/coverity-security-library >> >> Cheers, >> Romain >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn >> http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> <mailto:websecurity@lists.webappsec.org> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >> >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

JM

Jim Manico

Wed, Feb 27, 2013 4:55 PM

Jon,

My opinion is that the work Romain is doing on XSS defense (including
their XSS cheat sheet and CSL library) is work that is clearly raising
the bar in terms of a Java based XSS encoder and XSS defense in general.

I would love to work with you to integrate some of this work in the
various OWASP resources and projects.

I'm also very willing to re-write a large portion of the XSS Prevention
Cheat Sheet with you in an effort to make it more vendor neutral. I
think your critique about the current XSS Prevention Cheatsheet at OWASP
is "right on".

Aloha Jon and Romain,
Jim

Constructive criticism is always appreciated.

CSL is released under a BSD license and is open source. Feel free to incorporate whatever makes sense for ESAPI.
CSL solved an immediate need for Coverity that wasn't solved by existing projects.

I dunno why the Internet rage machine is pointed at CSL today. I think the community is better served if we can move the discussion back to constructive criticisms, quantified results, and actionable feedback instead of snide comments. Alas, it's a free world so carry on as you see fit.

Regards,

Jon

p.s. Happy to move this discussion into meat space too. I think a lot of us are in SF for RSA. Happy to keep it to email too.

On Feb 27, 2013, at 8:13 AM, Eric Sheridan eric.sheridan@owasp.org wrote:

At least you admit you're promoting something of your own (i.e. CSL) by
keeping it separate instead of helping OWASP T10 promote their agenda
(ex: ESAPI).

Nice research.

Sincerely,
Eric Sheridan
(twitter) @eric_sheridan
(blog) http://ericsheridan.blogspot.com

On 2/27/13 10:45 AM, romain wrote:

Argh, sorry about the blog and IE10. Not the first time I hear that...

Concerning the CSS string escaper we did some testing, but not on super
old browsers actually. However, we looked at the how CSS parsers are
recovering from errors, and what characters need to be escaped. That's
mostly why our CSS string escaper will escape new lines chars and more.
Still, we have some more work to do; CSS parsers are a real pain.

Contributing to OWASP XSS prevention cheat sheet is something we talked
about. However, the OWASP document is first of all promoting ESAPI when
we are sorta promoting our lib. We are also talking about HTML contexts
at a more fine grain level and it's difficult to put this in OWASP
framework.
The OWASP cheat sheet format doesn't also play well with what we wanted
to do. They are driven by few rules for preventing XSS, we're more about
code example.

Romain

@rgaucher

On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no
mailto:erlend@oftedal.no> wrote:

Hard to tell really as your website blocks IE10 thinking it's IE6
(not optimizing for old browsers is ok, but blocking is an
antipattern - especially when it's wrong).

Joke aside, the document itself seems decent. It's easy to get an
overview over the context. Did you test your CSS escaping in older
browsers? I seem to remember there were some problems, and that
escaping itself was not enough.

Also, why build your own cheat sheet instead of contributing to the
established free and open OWASP XSS Prevention Cheat Sheet?

Best regards,
Erlend Oftedal


On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com
<mailto:r@fuckthespam.com>> wrote:

    Everybody,
    We release an XSS cheat sheet for developers today. The document
    talks about several contexts (13 combinations right now, but
    we'll be improving it).
    Some more info are available on Coverity blog:
      https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

    Our goal is to keep improving this cheat sheet while adding
    escapers and sanitizers to our library:
      https://github.com/coverity/coverity-security-library

    Cheers,
    Romain


    _______________________________________________
    The Web Security Mailing List

    WebSecurity RSS Feed
    http://www.webappsec.org/rss/websecurity.rss

    Join WASC on LinkedIn
    http://www.linkedin.com/e/gis/83336/4B20E4374DBA

    WASC on Twitter
    http://twitter.com/wascupdates

    websecurity@lists.webappsec.org
    <mailto:websecurity@lists.webappsec.org>
    http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Jon, My opinion is that the work Romain is doing on XSS defense (including their XSS cheat sheet and CSL library) is work that is clearly raising the bar in terms of a Java based XSS encoder and XSS defense in general. I would love to work with you to integrate some of this work in the various OWASP resources and projects. I'm also very willing to re-write a large portion of the XSS Prevention Cheat Sheet with you in an effort to make it more vendor neutral. I think your critique about the current XSS Prevention Cheatsheet at OWASP is "right on". Aloha Jon and Romain, Jim > Constructive criticism is always appreciated. > > * CSL is released under a BSD license and is open source. Feel free to incorporate whatever makes sense for ESAPI. > * CSL solved an immediate need for Coverity that wasn't solved by existing projects. > > I dunno why the Internet rage machine is pointed at CSL today. I think the community is better served if we can move the discussion back to constructive criticisms, quantified results, and actionable feedback instead of snide comments. Alas, it's a free world so carry on as you see fit. > > Regards, > > Jon > > p.s. Happy to move this discussion into meat space too. I think a lot of us are in SF for RSA. Happy to keep it to email too. > > On Feb 27, 2013, at 8:13 AM, Eric Sheridan <eric.sheridan@owasp.org> wrote: > >> At least you admit you're promoting something of your own (i.e. CSL) by >> keeping it separate instead of helping OWASP T10 promote their agenda >> (ex: ESAPI). >> >> Nice research. >> >> Sincerely, >> Eric Sheridan >> (twitter) @eric_sheridan >> (blog) http://ericsheridan.blogspot.com >> >> On 2/27/13 10:45 AM, romain wrote: >>> Argh, sorry about the blog and IE10. Not the first time I hear that... >>> >>> Concerning the CSS string escaper we did some testing, but not on super >>> old browsers actually. However, we looked at the how CSS parsers are >>> recovering from errors, and what characters need to be escaped. That's >>> mostly why our CSS string escaper will escape new lines chars and more. >>> Still, we have some more work to do; CSS parsers are a real pain. >>> >>> Contributing to OWASP XSS prevention cheat sheet is something we talked >>> about. However, the OWASP document is first of all promoting ESAPI when >>> we are sorta promoting our lib. We are also talking about HTML contexts >>> at a more fine grain level and it's difficult to put this in OWASP >>> framework. >>> The OWASP cheat sheet format doesn't also play well with what we wanted >>> to do. They are driven by few rules for preventing XSS, we're more about >>> code example. >>> >>> Romain >>> - @rgaucher >>> >>> >>> On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no >>> <mailto:erlend@oftedal.no>> wrote: >>> >>> Hard to tell really as your website blocks IE10 thinking it's IE6 >>> (not optimizing for old browsers is ok, but blocking is an >>> antipattern - especially when it's wrong). >>> >>> Joke aside, the document itself seems decent. It's easy to get an >>> overview over the context. Did you test your CSS escaping in older >>> browsers? I seem to remember there were some problems, and that >>> escaping itself was not enough. >>> >>> Also, why build your own cheat sheet instead of contributing to the >>> established free and open OWASP XSS Prevention Cheat Sheet? >>> >>> Best regards, >>> Erlend Oftedal >>> >>> >>> On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com >>> <mailto:r@fuckthespam.com>> wrote: >>> >>> Everybody, >>> We release an XSS cheat sheet for developers today. The document >>> talks about several contexts (13 combinations right now, but >>> we'll be improving it). >>> Some more info are available on Coverity blog: >>> https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers >>> >>> Our goal is to keep improving this cheat sheet while adding >>> escapers and sanitizers to our library: >>> https://github.com/coverity/coverity-security-library >>> >>> Cheers, >>> Romain >>> >>> >>> _______________________________________________ >>> The Web Security Mailing List >>> >>> WebSecurity RSS Feed >>> http://www.webappsec.org/rss/websecurity.rss >>> >>> Join WASC on LinkedIn >>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA >>> >>> WASC on Twitter >>> http://twitter.com/wascupdates >>> >>> websecurity@lists.webappsec.org >>> <mailto:websecurity@lists.webappsec.org> >>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >>> >>> >>> >>> >>> >>> _______________________________________________ >>> The Web Security Mailing List >>> >>> WebSecurity RSS Feed >>> http://www.webappsec.org/rss/websecurity.rss >>> >>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >>> >>> WASC on Twitter >>> http://twitter.com/wascupdates >>> >>> websecurity@lists.webappsec.org >>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

IR

Ivan Ristic

Wed, Feb 27, 2013 7:08 PM

There isn't anything to "admit". They used their resources in the way
they saw fit.

Just because they are releasing their research to the public does not
give us the right to question their choices.

On Wed, Feb 27, 2013 at 4:13 PM, Eric Sheridan eric.sheridan@owasp.org wrote:

At least you admit you're promoting something of your own (i.e. CSL) by
keeping it separate instead of helping OWASP T10 promote their agenda
(ex: ESAPI).

Nice research.

Sincerely,
Eric Sheridan
(twitter) @eric_sheridan
(blog) http://ericsheridan.blogspot.com

On 2/27/13 10:45 AM, romain wrote:

Argh, sorry about the blog and IE10. Not the first time I hear that...

Concerning the CSS string escaper we did some testing, but not on super
old browsers actually. However, we looked at the how CSS parsers are
recovering from errors, and what characters need to be escaped. That's
mostly why our CSS string escaper will escape new lines chars and more.
Still, we have some more work to do; CSS parsers are a real pain.

Contributing to OWASP XSS prevention cheat sheet is something we talked
about. However, the OWASP document is first of all promoting ESAPI when
we are sorta promoting our lib. We are also talking about HTML contexts
at a more fine grain level and it's difficult to put this in OWASP
framework.
The OWASP cheat sheet format doesn't also play well with what we wanted
to do. They are driven by few rules for preventing XSS, we're more about
code example.

Romain

@rgaucher

On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no
mailto:erlend@oftedal.no> wrote:

 Hard to tell really as your website blocks IE10 thinking it's IE6
 (not optimizing for old browsers is ok, but blocking is an
 antipattern - especially when it's wrong).

 Joke aside, the document itself seems decent. It's easy to get an
 overview over the context. Did you test your CSS escaping in older
 browsers? I seem to remember there were some problems, and that
 escaping itself was not enough.

 Also, why build your own cheat sheet instead of contributing to the
 established free and open OWASP XSS Prevention Cheat Sheet?

 Best regards,
 Erlend Oftedal


 On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com
 <mailto:r@fuckthespam.com>> wrote:

     Everybody,
     We release an XSS cheat sheet for developers today. The document
     talks about several contexts (13 combinations right now, but
     we'll be improving it).
     Some more info are available on Coverity blog:
       https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers

     Our goal is to keep improving this cheat sheet while adding
     escapers and sanitizers to our library:
       https://github.com/coverity/coverity-security-library

     Cheers,
     Romain


     _______________________________________________
     The Web Security Mailing List

     WebSecurity RSS Feed
     http://www.webappsec.org/rss/websecurity.rss

     Join WASC on LinkedIn
     http://www.linkedin.com/e/gis/83336/4B20E4374DBA

     WASC on Twitter
     http://twitter.com/wascupdates

     websecurity@lists.webappsec.org
     <mailto:websecurity@lists.webappsec.org>
     http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

--
Ivan Ristić

There isn't anything to "admit". They used their resources in the way they saw fit. Just because they are releasing their research to the public does not give us the right to question their choices. On Wed, Feb 27, 2013 at 4:13 PM, Eric Sheridan <eric.sheridan@owasp.org> wrote: > At least you admit you're promoting something of your own (i.e. CSL) by > keeping it separate instead of helping OWASP T10 promote their agenda > (ex: ESAPI). > > Nice research. > > Sincerely, > Eric Sheridan > (twitter) @eric_sheridan > (blog) http://ericsheridan.blogspot.com > > On 2/27/13 10:45 AM, romain wrote: >> Argh, sorry about the blog and IE10. Not the first time I hear that... >> >> Concerning the CSS string escaper we did some testing, but not on super >> old browsers actually. However, we looked at the how CSS parsers are >> recovering from errors, and what characters need to be escaped. That's >> mostly why our CSS string escaper will escape new lines chars and more. >> Still, we have some more work to do; CSS parsers are a real pain. >> >> Contributing to OWASP XSS prevention cheat sheet is something we talked >> about. However, the OWASP document is first of all promoting ESAPI when >> we are sorta promoting our lib. We are also talking about HTML contexts >> at a more fine grain level and it's difficult to put this in OWASP >> framework. >> The OWASP cheat sheet format doesn't also play well with what we wanted >> to do. They are driven by few rules for preventing XSS, we're more about >> code example. >> >> Romain >> - @rgaucher >> >> >> On Wed, Feb 27, 2013 at 12:31 AM, Erlend Oftedal <erlend@oftedal.no >> <mailto:erlend@oftedal.no>> wrote: >> >> Hard to tell really as your website blocks IE10 thinking it's IE6 >> (not optimizing for old browsers is ok, but blocking is an >> antipattern - especially when it's wrong). >> >> Joke aside, the document itself seems decent. It's easy to get an >> overview over the context. Did you test your CSS escaping in older >> browsers? I seem to remember there were some problems, and that >> escaping itself was not enough. >> >> Also, why build your own cheat sheet instead of contributing to the >> established free and open OWASP XSS Prevention Cheat Sheet? >> >> Best regards, >> Erlend Oftedal >> >> >> On Wed, Feb 27, 2013 at 3:28 AM, romain <r@fuckthespam.com >> <mailto:r@fuckthespam.com>> wrote: >> >> Everybody, >> We release an XSS cheat sheet for developers today. The document >> talks about several contexts (13 combinations right now, but >> we'll be improving it). >> Some more info are available on Coverity blog: >> https://communities.coverity.com/blogs/security/2013/02/26/fixing-xss-a-practical-guide-for-developers >> >> Our goal is to keep improving this cheat sheet while adding >> escapers and sanitizers to our library: >> https://github.com/coverity/coverity-security-library >> >> Cheers, >> Romain >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn >> http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> <mailto:websecurity@lists.webappsec.org> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >> >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org -- Ivan Ristić

PJ

Paul Johnston

Mon, Mar 4, 2013 2:34 PM

Hi,

I dunno why the Internet rage machine is pointed at CSL today. I think the community is better served if we can move the discussion back to constructive criticisms, quantified results, and actionable feedback instead of snide comments. Alas, it's a free world so carry on as you see fit.

It's a thankless task doing anything constructive! Mailing lists seem to
be full of people with plenty of time to pick holes in whatever you do.

Having said that, I do have two comments, which are intended to be
constructive:

For some obscure contexts (you mention CSS is very tricky) it may be
better to simply never put user-supplied data in these contexts. We
don't know what wacky behaviour might be in obscure old browsers, or
even in future browsers. Providing an escaping function for these
contexts may be encouraging people to do a bad thing. For example, it's
not uncommon to see user-supplied data with a <script> block. One option
is to escape it, perhaps using your library, but I have always advised
people to side-step the issue and put the user-supplied data in a hidden
field, which is then accessed by JavaScript.
A programmer still has to correctly identify the context they are in,
and use the correct escaping function. There is still plenty of
opportunity for programmer error here. I've not used it, but Google have
a templating system that does automatic context-aware escaping:
http://googleonlinesecurity.blogspot.co.uk/2009/03/reducing-xss-by-way-of-automatic.html

Paul

--
Pentest - The Application Security Specialists

Paul Johnston - IT Security Consultant / Tiger SST
PenTest Limited - ISO 9001 (44/100/107029) / ISO 27001 (IS 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

Hi, > I dunno why the Internet rage machine is pointed at CSL today. I think the community is better served if we can move the discussion back to constructive criticisms, quantified results, and actionable feedback instead of snide comments. Alas, it's a free world so carry on as you see fit. It's a thankless task doing anything constructive! Mailing lists seem to be full of people with plenty of time to pick holes in whatever you do. Having said that, I do have two comments, which are intended to be constructive: 1) For some obscure contexts (you mention CSS is very tricky) it may be better to simply never put user-supplied data in these contexts. We don't know what wacky behaviour might be in obscure old browsers, or even in future browsers. Providing an escaping function for these contexts may be encouraging people to do a bad thing. For example, it's not uncommon to see user-supplied data with a <script> block. One option is to escape it, perhaps using your library, but I have always advised people to side-step the issue and put the user-supplied data in a hidden field, which is then accessed by JavaScript. 2) A programmer still has to correctly identify the context they are in, and use the correct escaping function. There is still plenty of opportunity for programmer error here. I've not used it, but Google have a templating system that does automatic context-aware escaping: http://googleonlinesecurity.blogspot.co.uk/2009/03/reducing-xss-by-way-of-automatic.html Paul -- Pentest - The Application Security Specialists Paul Johnston - IT Security Consultant / Tiger SST PenTest Limited - ISO 9001 (44/100/107029) / ISO 27001 (IS 558982) Office: +44 (0) 161 233 0100 Mobile: +44 (0) 7817 219 072 Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy Registered Number: 4217114 England & Wales Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK