Thread

This question may be related to a resolved thread.

I am having the same problem as above.

The only fix seems to be turning off XSS Filtering.
This doesn’t seem to be a real fix in my eyes.

The PDF’s I am trying to upload are nothing special.
No embedded javascript they are simply menu’s with images - see for yourself - http://mamma.honeyweb.com.au/images/uploads/unley_menu_food.pdf

Thoughts..??

HoneyWeb,

What version and build of EE are you using?

It is true that turning off XSS filtering means that anyone who can upload images to your site (including photos, avatars, gallery, file attachments, etc.) might intentionally or inadvertently upload a malicious file that allows an XSS attack to be executed on your site.

You can however upload the files as a SuperAdmin.

Does that help?

I am using Build#20091201

No. Uploading as Super Admin doesn’t help coz I strip down the admin for my clients giving them very limited access.

The upload problem has been around for a while, since 2007 I believe, and doesn’t seem to have been addressed properly.

Thoughts..? Solution..?

HoneyWeb,

Take a look at Adam’s response here which may be a solution for you.

Hmmm.

Adam has found something useful for sure.

In my case the client is the user so I guess it is not a big deal to turn off Filtering…true???

But the case in point is still not truely resolved.

Come a day when I create a fully fledged blog site where there are tonnes of users and anyone can sign up, you can’t simply turn filtering off or create an exception.

So the issue still needs resolving, would you agree?

If you can supply a solution to my blog scenario, I will be happy.

Thoughts..?

HoneyWeb,

In my case the client is the user so I guess it is not a big deal to turn off Filtering…true???

No its not as you know your client and you aren’t allowing membership of your site.

Come a day when I create a fully fledged blog site where there are tonnes of users and anyone can sign up, you can’t simply turn filtering off or create an exception.

And 99% of the time they will have no problem uploading files. In the case where a file is blocked you as an admin will be able to upload it for them.

In your example you have a PDF which may contain JS and HTML which is causing it to be blocked. PDF’s in general is a popular one to be caught by the filters because of what can be embedded. Do you see that as a filetype that will be used a lot by users of your blog?

At the end of the day you are responsible for your own site’s security in your decision making. If it was me I would leave the filtering on and in the rare case when a blog user is stopped from uploading a possible malicious file then I would deal with it personally.

Does that help?

Helps to a degree.

All your points are valid and on track, however.

The PDF’s we were struggling with today have nothing fancy in them.
They are both here for you perusal
- http://mamma.honeyweb.com.au/images/uploads/unley_menu_food.pdf
- http://mamma.honeyweb.com.au/images/uploads/glenelg_menu_food.pdf

We have had problems in the past and recreating them from original word docs etc solved the problem. We couldn’t do that in today’s case which lead us to learn the real problem to our struggles.

I guess I would be happy if you can point out what is wrong with the PDF’s in question above, otherwise I feel the filtering is too sensitive.

Thoughts..?

HoneyWeb,
At the end of the day you are responsible for your own site’s security in your decision making. If it was me I would leave the filtering on and in the rare case when a blog user is stopped from uploading a possible malicious file then I would deal with it personally.

Does that help?

Actually, I’d say no. Let’s face it, in case an upload fails neither the user not the admin get any clue what particular aspect of the file made EE think it ought to deny it.
So, based on what shall the admin decide whether EE was wrong and the file can safely be uploaded?

That said, I tried to identify why the menu linked by the OP fails the XSS-check and the result was rather surprising. It seems that currently EE treats any uploaded file regardless of its type as images in the xss-clean()-function but I don’t know whether this is intentional. If it didn’t do that that particular PDF would pass the check. Should I file a bug report in order for this to be investigated?

The underlying problem remains: It would be nice if EE was more verbose when a file is not accepted. Either directly to the user or admins should be included into the XSS-check (they can upload any files but get a clear warning that something is fishy with the file and - most important - what raised the flag).

Silenz, it should like more of a Feature Request. As fr as the xss-clean goes, it may be a false positive. EE errs on the side of caution.

Verbose output is a feature request, yes.
The other part might actually be a bug.

I’m not sure I necessarily agree with that assessment, but we’ll just have to leave this to the devs. I see you made a report here.

Yep, as I said, might be but it’s not clear so someone might want to take a look at it.

I’m sure we’ll hear something back about this.

In the mean time, HoneyWeb, do you have a work around for the moment?

Yes I do thanks.
=)

Excellent. Let’s clear this one out then, with a link to the bug report silenz made. Please don’t hesitate to start a new thread in case anything else comes up.