Do keep in mind- turning off the image filter has implications for security. It means none of the images uploaded are run through the cross site filter- so that means signatures, avatars- pretty much everything. I personally will only turn it off if the only folks who have access to upload anything are staff. And even then I prefer to leave it on, just as a check.
So that’s a long way of saying- if you want me to poke more on why those images trip the filter, let me know. I doubt we can make them not trip it- unless 1.6.4 is being overzealous. But we might can figure out why they are.
Make sense? Of if all is well, say the word and I’ll close this one out.
We are having the same issue, Robin. Before upgrade, the appropriate people could upload images with no problem. After 1.6.4, people are getting this mime type error, and I totally don’t want to turn off filtering. I just want it to work like it was in 1.6.3!
It looks like the EE email system doesn’t allow attachments, so I will just link you to a couple that my writers asked me to upload for them yesterday:
Same problem here Robin, and it only occurred after the upgrade to 1.6.4. It worked for super admins, not for members, and was fixed when I changed the XSS security pref with the same files.
But tightened to the point where normal, authorized users cannot upload files? I suppose I should ask, what is the purpose of the XSS security measure in the first place?
I know you said you’d update when there was a fix, but I just figured I’d throw in a nudge and ask for a status update. This issue is slowing down our publishing time, which in the long run, hurts the bottom line a bit
Some false-matches on the files can be alleviated, and indeed internally I have that fix ready for the next build. The issue at hand, though, is how much leniency can safely be given. If it helps you have some perspective, the characters tripping it up are patterns such as:
<a blahblahblah >
And I think it’s safe to say that if you have selected that file uploads be sanitized against XSS attacks, that finding what appears to be a link inside one is suspect. The problem is that certain browsers ::cough:: IE6 ::cough:: when they perceive HTML tags within an image, will just serve that image’s “contents” as HTML, ignoring the MIME type that the server sends.
So we’re taking an extremely cautious stance before adding further leniency.
*edit* a bit more info: After turning off XSS filtering I was able to upload the image as a non logged in user of the site. Now I am worried about security implications…
I had this very same problem with my forums. And it came out that with certain imagehandling softwares when saving the file, it makes some “bad” 101010’s to file what keeps them be “against” the rules of XSS with EE.
If i remember right, one sofware in my case was photoshop elements and when saving as. I dont remember anymore was it cleared when people saved their files “for web”. But this was/is known issue for me too, or should i say, to my forum users!
Ingmar you replied to me? You mean there were updates for “better handling”? I updated my forums some days ago! As you can always see what versions or builds i run with, from my sig.
*edit* a bit more info: After turning off XSS filtering I was able to upload the image as a non logged in user of the site. Now I am worried about security implications…
What build are you running docflo? Examining that file in a text editor, nothing jumps forward as setting off a false positive in the latest filter.
