Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#10294 closed defect (bug) (invalid)

CSRF through the img tag

Reported by: saltwaterc's profile SaltwaterC Owned by: ryan's profile ryan
Milestone: Priority: normal
Severity: normal Version:
Component: Security Keywords:
Focuses: Cc:


The filtered HTML should be more ... well, filtered. Although Since WordPress 2.8 you can't do CSRF with a link like this: (where holds a WP installation) because the logout requires the _wpnonce parameter to be specified into the GET request (2.7.1 has this issue), the installation is still vulnerable to this type of CSRF against other sites. While this kind of stuff is mostly annoying (as example <img src="" alt="" /> within a blog's post), it can be used for more severe actions.

I didn't started with the "filtered HTML" state by accident. This kind of vulnerability can be triggered by blog users who actually have lower privileges, thus using the filtered HTML feature which turns out to be inefficient for this kind of issue.

Change History (10)

#1 @westi
15 years ago

  • Cc Westi added

#2 @SaltwaterC
15 years ago

Correction: the 2.7.1 'issue' which I discovered (the kind of URL) is actually a plug-in issue (, not a WordPress related issue.

#3 @Denis-de-Bernardy
15 years ago

  • Milestone Unassigned deleted
  • Resolution set to invalid
  • Status changed from new to closed

marking as invalid then

#4 follow-up: @SaltwaterC
15 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

The fact that WordPress is unaffected by this issue, it doesn't mean that WordPress is safe for others. This slip from properly parse the HTML can be used as attack vector against other sites, thus making WordPress kinda useless for creating an open publishing platform where anyone can sign up and provide content. Isn't this one of those Web 2.0 thingy, the user generated content? Well, that user generated content should better be safe for others.

Please do us all a favor: fire up a WordPress instance, create a new article as an unprivileged user who has filtered HTML on, then embed these couple of 'images'. In order to work you need to be authenticated on and

<img src="" alt="" />
<img src="" alt="" />

Then please visit and again. Do you notice something? This demonstration has minimal effects, but the potential is greater. Please remember that WordPress roles can be changed, thus someone with contributor privileges may post content without the approval of an admin/editor if the site is designed for that purpose.

#5 @dd32
15 years ago

SaltwaterC: What is your proposed solution to a 3rdparty issue (Of not having some sort of "are you sure you wish to do this" action

Its impossible.

bb-login.php?logout compared to image.php?image=1234 How is wordpress to know the latter is a image and not a malicious link?

#6 in reply to: ↑ 4 @hakre
15 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to SaltwaterC:

Please do us all a favor: fire up a WordPress instance, create a new article as an unprivileged user who has filtered HTML on, then embed these couple of 'images'. In order to work you need to be authenticated on and

<img src="" alt="" />
<img src="" alt="" />

this is a problem with the used trac as well the used bb version. This is not related to WordPress. You can do this with a static HTML file as well containing these links.

You can prevent such security risks if you configure your browser to not load linked files like images. I guess it is not the web you want to use, but those are the implications of automatically requested URLs in your browser. This is actually how it works (e.g. the html IMG element).

Again: This is not a WordPress Issue. Feel free to report this security related stuff for the other projects, like trac.

#7 @SaltwaterC
15 years ago

I do have a solution. It may not be bullet proof, it depends on ext/curl, but it's quite fast and reliable. Here's a CLI snippet which can be easily converted to a proper procedure for image checking:

This piece of code uses the HEAD HTTP request to take a peek at the headers of a given URI, thus no need for downloading the whole file. This makes the whole checking process much faster.

The HTTP status code should be 200 for a valid image. Any other HTTP status code must be rejected. Don't get fooled by 304.

Also the mime type should be an image mime type. A spoofed script which sends an image type header wouldn't request an action within the browser since the browser expects binary image output.

@hakre: I would if I could configure everyone's browsers, or make them to use proper browsers. Actually the proper solution would be to: a) either patch to WordPress all the right solutions for the wrong usage of the Web (at least for the issues that I know of, and I do know a few); or b) code my own platform which sounds reasonable from all points of view except for the time part. Since I constantly discover flaws in various 3rd party plug-ins, and you can't deny the fact that WordPress was widely adopted because of the availability of such plug-ins, then maybe this second (b) solution sounds reasonable - period.

#8 @dd32
15 years ago

That will work.

But its utterly pointless IMO, Why restrict users from posting it in the first place? Surely it should be looked at why someones posting it in the first place. If someone (or something) wants to post it, they will.

#9 @SaltwaterC
15 years ago

Not all the users. Just the users with 'filtered HTML'.

#10 @westi
15 years ago

  • Version 2.8 deleted

It is not the job of WordPress to try and protect against CRSF issues in other software.

If you find issues in other software you should report them there.

And if you find issues in WordPress please report them.

Note: See TracTickets for help on using tickets.