Note: the patch has been rebooted from ground up at #70 therefore reading anything before that is at most a historical curiosity and does not pertain to the approach detailed in this issue summary.
The patch is nowhere near complete. Crucial documentation is missing and there are a lot of testing failures. The development is ongoing in https://drupal.org/sandbox/chx/1857558 branch autoescape.
Problem/Motivation
Noone can write XSS safe code. Nor core contributors, nor contrib developers, noone.
Proposed resolution
Switch on Twig autoescape. Implement "taint" support: we consider normal PHP strings "tainted", insecure for HTML. They can be "untainted" by htmlspecialchars and Xss:filter and check_markup (it is the responsibility of the filter system to return safe things). Safe strings are stored in a SafeMarkup object.
Some functions, most notably t, l, drupal_renderdrupal_render_children and the new SafeMarkup::implode always return safe strings now. We also consider everything in #markup to be safe and treat every theme function as returning safe markup. While these are not necessarily true, wrapping the hundreds of #markup in core is off topic here and would make both the effort and the patch huge. In a followup we might want to rename #markup to #safe_markup even and then check_plain everything put into plain #markup .
The patch mostly contains these kinds of fixes:
- Some functions concat or manipulate safe strings in other ways. These need to be re-wrapped.
- strpos blows up if needle is SafeMarkup; needs to be cast back to string.
- array indexes blow up with SafeMarkup; needs to be cast back to string.
- assertIdentical doesn't work quite well for SafeMarkup -- the expectation can be a plain string but even if it's not then === only passes when the two objects are the same instance of the class. So, there's a lot of assertIdentical string casts and when there are arrays or objects involved then we switch to assertIdenticalObject which is in HEAD or assertIdenticalArray which is new.
The last three are mostly tests, the last obviously is just test.
Remaining tasks
Make the patch pass. File followups for the two "dicey" SafeMarkup::create() calls (marked cleanly by @todo) and one to add inline comments to each SafeMarkup::create explaining why it's safe.
User interface changes
If we do this right, then none. If we don't then you will see a new kind of bug: double escaping.
API changes
new SafeMarkup class, and SafeMarkup::concat and SafeMarkup::implode helpers. Remove html => TRUE from l
You are not allowed to put unsafe user data in #attached. This can be relaxed in a followup but it truly gets gnarly. You are advised to not use #type => html_tag if at all possible or at least not with unsafe user data. This is not something I want to waste an effort on making it work.
Original report by @catch
Part of meta issue
follow-up from #1696786: Integrate Twig into core: Implementation issue
Twig as it stands introduces a fair bit of overhead into the theme system. Fabianx indicated that a lot of this is from marking $variables as secure so they're not double escaped later.
Ideally, if Twig autoescape is going to be enabled, then we should just pass raw variables to it and let it do the work. This way, if a template doesn't print the date, or a link, or whatever might currently be check_plain()ed in preprocess, we're not spending all this time creating it for it to be never used. In general, we should be able to remove a large chunk of preprocess work, and just let Twig sort out variables on demand.
Doing this means that a PHPTemplate engine in contrib is going to have to add back a way to securely format variables, but I don't see a way around this if we don't want a serious performance regression.