I'm testing my current site for XSS vulnerabilities, and I came across
this one on:
http://ha.ckers.org/xss.html
IMG Embedded commands part II - this is more scary because there are
absolutely no identifiers that make it look suspicious other than it is
not hosted on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Oct 06, 2006 at 04:35:22PM +0200, Clinton Gormley wrote:
> I'm testing my current site for XSS vulnerabilities, and I came across
> this one on:
>
> http://ha.ckers.org/xss.html
[...]
> Now this is an interesting one... How would you avoid th
Clinton Gormley wrote:
> How would you avoid this? Only take parameters from the
> POST data?
That's part of it, but it's not a complete solution.
That particular attack vector is called CSRF, cross-site request
forgeries. RSnake's XSS cheatsheet demonstrates using XSS on your own
site to launch
> Users:
> * switch off Javascript (and any other active content)
> * avoid pages unusable without active content
>
> Developers:
> * always offer working alternatives to active content (page
> must be usable with no JS, no Java, no Flash (I won't talk
> about other client-side monst
> That's part of it, but it's not a complete solution.
>
> That particular attack vector is called CSRF, cross-site request
> forgeries. RSnake's XSS cheatsheet demonstrates using XSS on your own
> site to launch the attack, but it can also be launched from any other
> web site where your users v
On Oct 6, 2006, at 10:35 AM, Clinton Gormley wrote:
I'm testing my current site for XSS vulnerabilities, and I came across
this one on:
http://ha.ckers.org/xss.html
well, not MP related but
if you let users embed flash / etc in profile pages, make sure you
strip object tags -- just use th
"mock" talked about XSS at this years YAPC::Europe in Birmingham a few
weeks ago. He had quite a few examples. His slides are at
http://sketchfactory.com/static/mvc.pdf (More Vulnerable Code).
It goes without saying that it would be a bit unwise to test the URLs
mentioned in the talk.
my 2 cents
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Oct 06, 2006 at 05:14:47PM +0200, Clinton Gormley wrote:
> > Users:
[...]
> > OK, now call me names :-)
> >
>
> Neither of these options will work. Consider this scenario.
>
> 1) Joe Bloggs logs into my website and has an active session.
>
On Oct 6, 2006, at 1:04 PM, [EMAIL PROTECTED] wrote:
1) Joe Bloggs logs into my website and has an active session.
2) Clicks on a link (either from an email or from content posted
on my
site) to http://www.malicious-site.com/index.html
3) That index page contains an tag
3) Instead of servin
On Fri, 2006-10-06 at 18:48 +0200, Hendrik Van Belleghem wrote:
> "mock" talked about XSS at this years YAPC::Europe in Birmingham a few
> weeks ago. He had quite a few examples. His slides are at
> http://sketchfactory.com/static/mvc.pdf (More Vulnerable Code).
> It goes without saying that it wou
Clinton Gormley wrote:
> 3) Instead of serving the image, the server at www.malicious-site.com
> issues a 302 HTTP Status code which redirects Joe Bloggs to
> http://my.website.com/change_password?new_password=abcde
>
> So his password gets changed, because this is coming from a live
> session, th
Clinton Gormley wrote:
> Really good article, Chris:
> http://shiflett.org/articles/security-corner-dec2004
>
> I really like the solution of using tokens.
Thanks! :-)
It's worth noting that this safeguard is rendered ineffective if you
have XSS vulnerabilities, thanks to Ajax. Malicious JavaScr
Jonathan Vanasco wrote:
> can't a lot of this be locked down with http referrers?
Until July of this year, checking the Referer was thought to be a pretty
good safeguard against CSRF, because an attacker would have to cause a
victim to send the right Referer, which isn't so easy.
Unfortunately, A
On Fri, Oct 06, 2006 at 07:25:06PM +0200, Clinton Gormley wrote:
> On Fri, 2006-10-06 at 18:48 +0200, Hendrik Van Belleghem wrote:
> > "mock" talked about XSS at this years YAPC::Europe in Birmingham a few
> > weeks ago. He had quite a few examples. His slides are at
> > http://sketchfactory.com/st
> HTML::Scrubber is not really broken. The problem is that the
> documentation leads the user to do broken things, as was shown with
> Planet Plagger. It is possible to make a secure HTML::Scrubber config,
> but you need to default deny everything and then only allow a select
> list of tags and
Clinton Gormley wrote:
> HTML::StripScripts::Parser has a default deny everything approach,
> and reconstructs the HTML fed to it, so unless it makes sense as
> html, it doesn't get passed through and reconstructed.
This sounds like a good approach, but it's worth noting that XSS is
fundamentally
> This sounds like a good approach, but it's worth noting that XSS is
> fundamentally an escaping problem, not a filtering one. Nitesh Dhanjani
> discusses this a bit here:
>
> http://oreillynet.com/onlamp/blog/2005/10/repeat_after_me_lack_of__outpu.html
>
Yes and no. From the article:
---
Clinton Gormley wrote:
> If the input that you are wanting to display is (eg) a surname,
> then certainly, escaping will serve your purposes. However, if
> you are wanting your user to be able to input HTML and then
> view it as HTML, escaping isn't sufficient. The combination is
> required.
That
On Oct 6, 2006, at 4:33 PM, Chris Shiflett wrote:
Until July of this year, checking the Referer was thought to be a
pretty
good safeguard against CSRF, because an attacker would have to cause a
victim to send the right Referer, which isn't so easy.
Unfortunately, Amit Klein published some re
Jonathan Vanasco wrote:
> > Unfortunately, Amit Klein published some research in July that
> > demonstrated how to do this with Flash. So, if your users use
> > clients that support Flash (which most do), this is not a good
> > safeguard.
>
> Do you have a link to that?
http://webappsec.org/lists
On Oct 6, 2006, at 4:33 PM, Chris Shiflett wrote:
Jonathan Vanasco wrote:
can't a lot of this be locked down with http referrers?
Until July of this year, checking the Referer was thought to be a
pretty
good safeguard against CSRF, because an attacker would have to cause a
victim to send
Sorry for the OT ness of this thread---
I spent the better part of the past 2 days trying to do a 1pass
content filtering on xss attacks-- including flash. breaking down
every piece of user input 2x wasn't nice on my server load.
I liked HTML::TagFilter, but it was making broken tags and I
22 matches
Mail list logo
