Bug #15170 Clarification Requested

XSS filtering breaks File Upload of PDFs

Version: EE 2.1.3 Reporter: narration

Lots of info on this by now in the support thread, including sample PDFs that do and don’t break with XSS filtering.

Since XSS is now universal default, this gets everyone trying to use the File Manager to upload PDFs which have printer preferance data.

Printer preferance data is a feature of the standardized PDF formats since at least 2002, so they are probably default on most PDF emitters.

  • By the way, there are also problems which arise in File Manager uploads due to various PHP memory allocations - not just the main one. This complicates matters.

    The information is in the thread.

    The suggestion is two-fold:

    • that these relevant memory allocations get documented for System Requirements and in File Manager doc.
    • but also that they get checked and remarked in the System Requirements Wizard - noted that they determine maximum File Upload size.

    This is also one more argument for making the Wizard a first step-and-pause in any installation or upgrade.

    Regards, Clive

    narration
    02nd February, 2011 at 12:32pm
  • I’d like to add I’ve had this problem with a WMV file, it’s a 1.5 mb file that gives the “The file could not be written to disk.” error unless XSS filtering is turned off.

    purple-agency
    02nd March, 2011 at 10:01am
  • Also experiencing this.

    Richard Whitmer
    21st March, 2011 at 2:57pm
  • Im experiencing this issue in 2.2.1 as well. Most pdfs will fail when uploading when XSS filtering is turned on.

    keston
    07th September, 2011 at 4:19pm
  • I just got bit by this in EE 2.3.1. Turning off XSS works around the issue for the moment.

    siffring
    01st November, 2011 at 2:05pm
  • Just a reminder that there are test files in the Support Thread which simply illustrate where the problem apparently is, for EE XSS and contemporary pdfs.

    narration
    01st November, 2011 at 2:22pm
  • I’m still having this problem in EE 2.4.0 Is there a better fix for this now than just turning XSS filtering off?

    h_slr
    02nd April, 2012 at 8:08pm
  • I’m still having this issue in 2.5.2 - I as a SuperAdmin can upload PDF’s however the client in their own member group cannot upload PDF’s unless XSS Filtering is turned off. They can however upload every other file type.

    Can we get an update on this please as turning off XSS Filtering isn’t really a “solution”.

    Ben Lilley
    12th June, 2012 at 7:40pm
  • This is still an issue for us too. Why is the status of this report “Clarification Requested”? It has been open for 18 months! In fact, I’m pretty sure I remember it from the 2.0 beta. Perhaps XSS filter should ignore PDF files by default?

    Adrian Macneil
    21st June, 2012 at 8:00pm
  • Ditto on this remaining a difficult issue as of 2.5.2. I appreciate this may be a tough one to solve, as preventing XSS attacks is important. Right now the only option is to disable file XSS checking entirely, and this needs to be done for any EE site allowing PDF uploads.

    First, the error needs to be more clear. I was spinning for a while determining why certain uploads were failing for certain users.

    Second, the XSS option needs to include a warning regarding this issue (that enabling this option will prevent many PDF uploads).

    Third, a real solution needs to be in place. Perhaps the script can identify properly-formatted PDF’s, and allow scripts within those files. If that cannot be done, then a per-group option to skip the XSS filter on uploads.

    Thanks.

    Mitch Cohen
    01st August, 2012 at 8:02am
  • Adding my experience to this: XSS filtering has to be turned off to allow members to upload audio files (.mp3, .mp4, .oga) via a safecracker form.

    I would love to hear back from the devs regarding this issue.

    Royama Design
    02nd August, 2012 at 11:53am
  • Ditto what everybody else said – I chased a hugely impactful client problem down to this and am surprised to see that it’s been “needing clarification” for so long. Disabling XSS filtering is a pretty shady workaround.

    Matt Stein
    05th September, 2012 at 7:06pm
  • Ditto again (ditto ditto?)

    I believe this issue is a bug in ~/system/codeigniter/system/libraries/Upload.php, near line 871:

    return $CI->security->xss_clean($data, TRUE);

    That TRUE flag is teling the xss_clean function that the uploaded file is an image - shouldn’t this be respecting the file upload preferences for the target upload destination? I temporarily set that to FALSE and the upload succeeded.

    npmi
    06th September, 2012 at 10:00am
  • Hmmm. npmi, I was really excited that you’d found the issue, and went to test it with the pdf test files I put up on the Support Thread link above.

    Thing is, all the test files now upload fine without making your modification.

    I’m on 2.5.2, and wonder what version of EE you’re testing with?

    The force-True image xss_clean call is still there where you located it.

    I had a look at xss_clean itself in 2.5.2, and just operating from memory, it looks a little more thought-out than what it seemed it was in 2.3.1.

    Maybe one of their pre-cleans covers the problem by now? Nice if it had been reported here on the bug thread if so.

    It’s actually safer I think if the xss_clean code works without being told it’s working with an image. Otherwise the crafty could fiddle with file types to get a bad one through. Thus Ellis thinking in how it stands may be good.

    narration
    06th September, 2012 at 5:34pm
  • Any news about this issue? I hope it’s solved in the newest version but who can confirm?

    Ralph (Onstuimig)
    18th December, 2012 at 6:01am
  • I’m very suprised Ellis hasn’t commented on this issue, since it is clearly a biggie. Any updates on this? I’m keen to turn my XSS back on, as having it off makes me nervous.

    Paul Sijpkes
    31st March, 2013 at 11:30pm

You must be signed in to comment on a bug report.

ExpressionEngine News

#eecms, #events, #releases