[21091] in bugtraq
[Fwd: Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)]
daemon@ATHENA.MIT.EDU (Peter W)
Tue Jun 19 02:27:15 2001
Date: Sun, 17 Jun 2001 12:22:23 -0400
From: Peter W <peterw@usa.net>
To: bugtraq@securityfocus.com
Message-ID: <20010617122223.G29353@usa.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Regarding IMG tags in HTML email, here is a good point I received off-list.
The sender did not wish to post directly, but approved forwarding this note.
-Peter
----- Forwarded message (anonymous, forwarded with permission) -----
Date: Sat, 16 Jun 2001 22:55:41 +0200
To: Peter W <peterw@usa.net>
From: <anonymous>
Subject: Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)
On 2001-06-15 at 09:26 -0400, Peter W gifted us with:
> I wonder how it would work in HTML mail clients, though? You
> could restrict to the sender's domain, but email is the easiest thing in
> the world to spoof. (And an effective attack vector, especially against
> things like messageboards that expose email addresses.) HTML email is just
> evil evil evil. I can't see much need for HTML email to reference *any*
> external documents, or to allow, as Jay Beale suggested, the use of things
> like META refresh tags to effect client-pull CSRF attacks.
Personally, I loath HTML email. However, surely a better approach for
this is simply to restrict IMG links by insisting that the source be
inline to the email.
RFC 2112, multipart/related. Require that email IMG URLs start "cid:"
in order to be automatically rendered. Whether or not to _allow_ the
rendering of other IMGs is a more contentious issue.
(Just one of those ideas which I've had floating around for a while,
mainly to stop tracking of who's reading spam HTML email)
----- End forwarded message -----
