views:

958

answers:

3

I have a rich-text editor on my site that I'm trying to protect against XSS attacks. I think I have pretty much everything handled, but I'm still unsure about what to do with images. Right now I'm using the following regex to validate image URLs, which I'm assuming will block inline javascript XSS attacks:

"https?://[-A-Za-z0-9+&@#/%?=~_|!:,.;]+"

What I'm not sure of is how open this leaves me to XSS attacks from the remote image. Is linking to an external image a serious security threat?

The only thing I can think of is that the URL entered references a resource that returns "text/javascript" as its MIME type instead of some sort of image, and that javascript is then executed.

Is that possible? Is there any other security threat I should consider?

+1  A: 

Another thing to worry about is that you can easily embed PHP code inside an image and upload that most of the time. The only thing an attack would then have to be able to do is find a way to include the image. (Only the PHP code will get executed, the rest is just echoed). Check the MIME-type won't help you with this because the attacker can easily just upload an image with the correct first few bytes, followed by arbitrary PHP code. (The same is somewhat true for HTML and Javascript code).

Jasper Bekkers
I'm not letting users upload images. Users are only allowed to link to images on other sites for reasons such as what you mentioned.
Dan Herbert
Wouldn't a simple filename filter prevent this?
AaronSieb
@AaronSieb, no because you could, for example, embed PHP code in a GIF pallet and upload a perfectly valid GIF image with the correct filetype and mime type. Problem is, as long as I can manipulate the website to do include("my_uploaded_gif.gif") you're in trouble. Also, the watch the %00 thing.
Jasper Bekkers
That should've said filename.
Jasper Bekkers
I guess I don't know enough about PHP :) If you have enough access to do execute the include("my_uploaded_gif.gif") statement, why would you need to embed the malicious code in the GIF in the first place?
AaronSieb
Having someone that does include($_GET['p] . '.php') is enough to include arbitrary files (index.php?p=some_image.gif%00 or whatever). Uploading them as an image is one way to get those files on the server.
Jasper Bekkers
+1  A: 

In that case, look at the context around it: do users only supply a URL? In that case it's fine to just validate the URLs semantics and MIME-type. If the user also gets to input tags of some sort you'll have to make sure that they are not manipulatable to do anything other then display images.

Jasper Bekkers
+1  A: 

If the end-viewer is in a password protected area and you're using RESTful Urls, it's possible to request a Url on their behalf. Example:

src="http://yoursite.com/users/1234/delete"

or even if you're not using Restful Urls:

src="http://yoursite.com/pagethatdoessomething.xxx?vars=badvars"

Corbin March
Would I really be vulnerable to that? My Regex only allows http/https at the start of the URL, so Javascript (or any encoding of it) shouldn't be able to get through, or am I wrong?
Dan Herbert
Whoops, forgot about the 'https?://'. I'll edit my answer.
Corbin March