Twig: Activate autoescape mode

Part of meta-issue #1788918: [GTD] [META] Prepare for Twig main engine core inclusion until December 1

Follow-up from: #1696786: Integrate Twig into core: Implementation issue

Motivation

100% of all custom themes are insecure (the rest is rounding error). The reason is often that developers forget to escape their data in the templates.

Problems

• To use twig autoescape every string that has been escaped already needs to be marked as "safe", so that it does not get escaped twice.
• Concatenation of a safe string is an unsafe string
• Different escaping strategies need to be used for different contexts (html, css, js, html attributes)
• Our implementation of auto-render makes the optimized |raw filter usage not possible

Approaches available

• a) Have Twig handle security internally and assume every string in $variables is secure (not true for objects). That would keep backwards compatible options to also have node.tpl.php etc. templates secure while still preventing accidental XSS via node.title or db_query in templates.
• b) Mark things that are secure, as such by utilizing a TypedData SafeString either automatically or manually.

For both variants are two possible implementations: Implicit and Explicit

• a) 1) Preprocess variables before rendering of template and mark every string as secure, needs only is_object check.
• => Has some performance overhead, but simple todo.
• a) 2) Mark strings secure as they are gathered from _context, by overriding getAttribute and getContext and set $this->secure = TRUE in getContext and $this->secure = FALSE in getAttribute if an object is encountered, wrap every encountered String as a Twig_Markup.
• => Compile time overhead, but little less run time overhead.

• b) 1) Do it like we do now and have an escaped string remain secure until it is concatenated.
• => Needs fixing of many tests, change from untyped strings to typed strings.
• b) 2) Explicitly use drupal_mark_safe(check_plain($node->title)) in the preprocess_ and process_ functions and wherever something is rendered to be output in a template.
• => Overhead in preprocess, process, etc. functions. They all need to be adjusted. Still needs typed SafeStrings. Developers need to learn to mark strings as safe for output as well as escaping.

Solution

• Wrap everything that is returned from check_plain, check_markup, etc. in Twig_Markup() objects.
• Tell Developers to wrap the concatenated escaped strings again in a Twig_Markup to mark it as safe again
• Document clearly that developers need to take care of security escaping themselves when using inline-css and inline-script with user input (better not do this at all)
• Fix the raw filter to explicitly return a Twig_Markup object instead of compile time optimizing it away.

Advantages

• Accidental XSS is caught (refer to #1811684: XSS: Bartik's node.tpl.php prone to XSS (prints $title)) as long as twig templates are used
• Strings are not escaped twice

Limitations

Not solved here are (currently?):

• Auto-escaping in different contexts (JS, CSS) though it can be done manually via ({% autoescape js/css %}) tags
• Users putting non-escaped data in #prefix / #suffix or via #theme_wrapper
• The solution is only as secure if all "marked safe" parts are secure (if all theme_ functions are gone and all goes via twig it is secure)
• No auto-escape for .tpl.php files and it needs to handle Twig_Markup objects
• Might need a function like is_twig_string for that

Disadvantages

• Performance: Obviously wrapping in Twig_Markup and doing __toString has overhead. Lets find out how worse it is.

Original report

Right now, we can't autoescape in twig because we are still calling drupal_render as an interim solution. When drupal_render concatenates it's results it loses the metadata containing the information whether a string is already escaped or not.

We need to replace or rewrite drupal_render so that the escaped strings are stored in a Twig_Markup object instead of being lost when flattened. When this is done we can turn autoescaping back on in twig.