full-disclosure - 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] [day] [month] [year] [list]

Date: Mon, 16 Apr 2007 18:09:46 -0700
From: Blue Boar <BlueBoar@...evco.com>
To: Ryan Barnett <rcbarnett@...il.com>
Cc: "webappsec @OWASP" <webappsec@...ts.owasp.org>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	"pdp \(architect\)" <pdp.gnucitizen@...glemail.com>,
	WASC Forum <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Persistent CSRF and
 The	Hotlink Hell

He compromised the server(s) at the ad network we were using at the
time, and simply served up his ad instead of the usual ones.

					BB

Ryan Barnett wrote:
> 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]
>>
>>
> 
> 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/