Thread

I have a safecracker form. One of the textarea inputs i have has a value which is an html code.

<textarea name="aaa"><div style="left: 385px; top: 137px;" class="aaa"></div></textarea>

When i click on submit, the html is being saved in the database without the inline style. So it’s saving as

<div class="aaa"></div>

. It’s stripping out the inline style. how can i prevent this from happening.

I confirmed this doesn’t happen in EE 2.0. It’s only the case in EE2.2.

alex00,

Just try to replicate and cannot. Can you share your full form tags please?

In EE2.2 SafeCracker is now included in the core as first party so there is no need for those SC folders inside your third-party folder. Can you confirm if they are there or not?

This is my form

{exp:safecracker channel="entry" author_only="yes" url_title="{segment_2}" return="editor/URL_TITLE"}
 <input type="text" name="title" id="title" value="{title}" size="50" maxlength="100">
 <input type="text" name="url_title" id="url_title" value="{url_title}" size="50" maxlength="100" />
 <textarea name="wrapper">{wrapper}</textarea>
 <input type="submit" value="Submit" />
{/exp:safecracker}

Nothing else in the template except this form. I’m using a fresh copy of EE2.2 on localhost. when i type an html tag with inline style in the textarea field, it gets saved in the database without the inline styling. This works in EE2.0 but not 2.2

Also onkeyup does not work.

Hi, Alex - looks like we hashed this out in your bug report.  Moving to Community Help in case others have suggestions on a better approach for now.

Note: This reply is cross-posted from Stack Overflow: stackoverflow.com/questions/6461763

SafeCracker uses the built-in ExpressionEngine XSS Sanitization Method to clean user submitted input from Cross Site Scripting (XSS) and SQL Injection vulnerabilities.

Any front-side user input is sanitized by using $this->EE->security->xss_clean() before being inserted into the database or output to the screen.

Thankfully for us, the Engineers at EllisLab have provided a secret, undocumented way of “whitelisting” fieldtypes and field_ids used in SafeCracker and exempting them from XSS filtering.

To stop SafeCracker from stripping all HTML from a given field, open up the following file, depending on which version of ExpressionEngine you’re running:

EE 2.1.3 or Earlier (SafeCracker installed as Third-Party Add-On)

/system/expressionengine/third_party/safecracker/libraries/safecracker_lib.php

EE 2.2.0 or Later (SafeCracker installed as First-Party Module)

/system/expressionengine/modules/safecracker/libraries/safecracker_lib.php

Note: ExpressionEngine 2.2.0 bundles SafeCracker as a first-party module, so your installation location will depend on what version you’re running or have upgraded from.

Scroll down to around Line 2371 (for EE 2.1.3) or Line 2516 (for EE 2.2) and look for the following:

$this->skip_xss_fieldtypes = array();
$this->skip_xss_field_ids = array();

Here’s where the fun begins. To “whitelist” a field from having the XSS Filter applied, simply add the fieldtype or field_id to either array.

Here’s an example:

$this->skip_xss_fieldtypes = array(
    // This is the fieldtype as specified in the Control Panel
    // Channel Fields, not what you use in your SafeCracker template
    'textarea'
);
$this->skip_xss_field_ids = array(
    // This is the field_id from the exp_channel_data MySQL Table
    'field_id_1',
    'field_id_2'
);

You can either specify a certain type of fieldtype (textarea, input, etc.), or the field_id if you’d rather be more explicit. The former way is more general, while the latter is absolute and is more flexible if a custom field would to ever change its type.

With these changes, any field(s) you exempt from the XSS Sanitization Method will no longer have any filtering applied, and allow any arbitrary HTML to be submitted into the database!

Keep in mind, that any upgrades to ExpressionEngine may overwrite this file, so you may want to change the permissions on the file or keep a backup handy.

Cross Site Scripting should be taken very seriously as you would never want your site to be the source of an attack vector. Always err on the side of caution.

This is really good to know. Based on this I’d like to make a feature request. 😊

EllisLab, can you please provide a hidden config variable to set these values in the config.php file instead of having to modify a core file?

Modifying core files + EE upgrades = big mess.