lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cba0286a0704161449l3c4c96bfs1bd515ce30a9fe6a@mail.gmail.com>
Date: Mon, 16 Apr 2007 17:49:23 -0400
From: "Ryan Barnett" <rcbarnett@...il.com>
To: "pdp (architect)" <pdp.gnucitizen@...glemail.com>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	"WASC Forum" <websecurity@...appsec.org>,
	"webappsec @OWASP" <webappsec@...ts.owasp.org>
Subject: Re: [WEB SECURITY] Persistent CSRF and The Hotlink Hell

I believe that the SecurityFocus "defacement" by FluffiBunni a few
years back would be an example of the defacement attack that Michael
listed in his article.  The concept was that SF had a trust
relationship with the company that was rotating their banners and FB
replaced the expected image with the defaced one.  I don't remember
the exact details on how the banner images were fed in (vs.
Hotlinking, etc...)

Does anyone have specific info from that defacement?

Isn't this somewhat related to the same trust issues with RSS feed attacks?


On 4/16/07, pdp (architect) <pdp.gnucitizen@...glemail.com> wrote:
> http://www.gnucitizen.org/blog/persistent-csrf-and-the-hotlink-hell/
> http://michaeldaw.org/papers/hotlink_persistent_csrf/
>
> I would like to bring your attention to a topic that has been rarely
> discussed. I am going to talk about hotlinks, redirections and of
> course CSRF (Cross-site Request Forgery).
>
> When we talk about CSRF we often assume that there is one kind only.
> After all, what else is in there when CSRF is all about making GET or
> POST requests on behalf of the victim? The victim needs to visit a
> page which launches the CSRF exploit. If the victim happens to have an
> established session with the exploited application, the attacker can
> perform the desired action like resetting the login credentials, for
> example.
>
> However, CSRF can be as persistent as persistent XSS (Cross-site
> Scripting) is and you don't need XSS to support it. Persistent CSRF is
> not dependent on persistent XSS.
>
> I hope that you find the post useful.
>
> --
> pdp (architect) | petko d. petkov
> http://www.gnucitizen.org
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>


-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ