Are PDFs still an XSS problem with EE uploads?

Question

I keep running into this and I'm hoping there is a suitable solution - PDF uploads by anyone other than a super admin run into the error "the file cannot be written to disk". This persists unless, as I've spotted in the bug tracker, the "solution" of turning off XSS filtering. But as I understand it, XSS is a good thing when it comes to security. Is there any way around this? Should I be particularly concerned about security if I turn off XSS filtering on file uploads? My clients generally LOVE to be able to simply and easily upload a PDF file through the entries screen, but we don't want to create security holes either.

Answer 1

There is a better solution!

You can change the XSS filtering member group by using some extra directives in your config file.

Add the following, replacing the member group numbers as required;

$config['xss_clean_member_group_exception'] = "1|6";

Using this method you can keep XSS filtering turned ON but remove it just for trusted members.

I think you can do it with member IDs too but can't recall the config key. Maybe try;

$config['xss_clean_member_exception'] = "35|64";

Answer 2

The issue is that certain PDFs falsely trigger the XSS screener's detection routines. And yes, this IS still a bug, although it is fairly difficult to predict which PDFs will be affected. I have had consistent issues with:

• PDFs exported from Microsoft Word on any platform
• PDFs with embedded color profile data

The best way around it if you only need certain member groups to be able to upload PDFs is to use the hidden config variables that @foamcow mentions in a separate answer, as follows:

$config['xss_clean_member_group_exception'] = "1|6";

OR

$config['xss_clean_member_exception'] = '3|14|83';

However, if you need to allow generic users to upload PDFs, such as through an open Safecracker form, I do not know of any solution other than disabling XSS filtering entirely.

Answer 3

This is not a solution, but I am using EE 2.7 and have been able to narrow down the offending code. Simply commenting out these three lines allowed for my offending PDFs to pass. I personally am not using this in production, and I have spent time trying to modify the code to get it to work... with no luck. Maybe someone can use this information to help update the code - I don't want to pollute the bug tracker with this.

/system/codeigniter/system/core/Security.php - xss_clean()

// Near line 345
if (preg_match("/<a/i", $str))
{
    $str = preg_replace_callback("#<a\s+([^>]*?)(>|$)#si", array($this, '_js_link_removal'), $str);
}

// Near line 365
$str = $this->_remove_evil_attributes($str, $is_image);

// Near line 377
$str = preg_replace_callback('#<(/*\s*)('.$naughty.')([^><]*)([><]*)#is', array($this, '_sanitize_naughty_html'), $str);

EDIT:

Rather than commenting out the lines above, you can check whether or not the file is a PDF and wrap each of the above in if( !$is_pdf ) { ... }. Put the following code near the top of xss_clean():

// NOTE: Requires PHP >= 5.3
$finfo = new finfo(FILEINFO_MIME_TYPE);
$is_pdf = $finfo->buffer($str) == "application/pdf";