3 ms·

I avoid IE almost entirely, so I don't know enough to evaluate his proposed solutions/safeguards, but I'd sure appreciate some evaluation of his proposed protec

I avoid IE almost entirely, so I don't know enough to evaluate his proposed solutions/safeguards, but I'd sure appreciate some evaluation of his proposed protections from someone who does so that I can advise clients about self-protection. Especially I'd like some help regarding his suggestion that one set IE so that "Open files based on their content and not the filename extension". But he then hedges his bets by saying, "However, that could reopen some old holes!" It seems a weak solution merely to await the "better": "better if web service operators took security precautions". What prophylaxis do Hackers that use IE plan to employ, if any?

ratsbane 18y ago
I avoid IE too, but about 52% (and shrinking) visitors to sites I work with still do use IE so we still have to deal with it. This is the first article I've read about this problem (thanks, HN.) Here's a quick summary of what I think I need to do about it: (corrections appreciated) 1) For any situations where you allow users to upload files which may be sent back to the browser as images, run some kind of check to ensure it's a valid image, e.g. ImageMagick "convert" 2) ensure you return content-type headers with the correct image type.
- durin42 18y ago
  In the case of sites that refer to user-specified images by just linking to the image (as with some forum software, at least a couple of years ago last I used such things), they need to change behavior, otherwise the upstream site can change content-type and content at the URL after validation and perform XSS on anyone that ends up seeing the "image." I could be wrong about that, someone please correct me if so.
  - ratsbane 18y ago
    I think you're right. If you embed any image you don't have control over or allow users to do that then js embedded in the supposed image could gank your session cookies. Avoidance strategies(?): 1) Copy embedded images to your server, validate, and substitute link on your server for off-site link 2) To avoid cross-site scripting hacks anyway, store ip address along with session key on your server and validate that with every request. (Won't protect against attackers on the same side of a NAT though.) This would also affect images embedded in emails, assuming user is using Outlook or IE to read mails?

ratsbane 18y ago

I avoid IE too, but about 52% (and shrinking) visitors to sites I work with still do use IE so we still have to deal with it. This is the first article I've read about this problem (thanks, HN.) Here's a quick summary of what I think I need to do about it: (corrections appreciated) 1) For any situations where you allow users to upload files which may be sent back to the browser as images, run some kind of check to ensure it's a valid image, e.g. ImageMagick "convert" 2) ensure you return content-type headers with the correct image type.

durin42 18y ago
In the case of sites that refer to user-specified images by just linking to the image (as with some forum software, at least a couple of years ago last I used such things), they need to change behavior, otherwise the upstream site can change content-type and content at the URL after validation and perform XSS on anyone that ends up seeing the "image." I could be wrong about that, someone please correct me if so.
- ratsbane 18y ago
  I think you're right. If you embed any image you don't have control over or allow users to do that then js embedded in the supposed image could gank your session cookies. Avoidance strategies(?): 1) Copy embedded images to your server, validate, and substitute link on your server for off-site link 2) To avoid cross-site scripting hacks anyway, store ip address along with session key on your server and validate that with every request. (Won't protect against attackers on the same side of a NAT though.) This would also affect images embedded in emails, assuming user is using Outlook or IE to read mails?