bugtraq - Re: [WEB SECURITY] Persistent CSRF and The Hotlink Hell

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]

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