From 87ca0391c0a846272307563f36809f51583130ae Mon Sep 17 00:00:00 2001 From: Javier Eguiluz Date: Fri, 19 Apr 2024 17:12:54 +0200 Subject: [PATCH] Add a better example of the dangers of XSS attacks --- html_sanitizer.rst | 4 ++-- reference/configuration/framework.rst | 2 +- reference/configuration/twig.rst | 3 +-- .../forms/types/options/sanitize_html.rst.inc | 4 ++-- reference/forms/types/textarea.rst | 2 +- templates.rst | 24 ++++++++++++------- 6 files changed, 23 insertions(+), 16 deletions(-) diff --git a/html_sanitizer.rst b/html_sanitizer.rst index d5b28b0afb8..a1318e87a3e 100644 --- a/html_sanitizer.rst +++ b/html_sanitizer.rst @@ -15,8 +15,8 @@ that the returned HTML is very predictable (it only contains allowed elements), but it does not work well with badly formatted input (e.g. invalid HTML). The sanitizer is targeted for two use cases: -* Preventing security attacks based on XSS or other technologies relying on - execution of malicious code on the visitors browsers; +* Preventing security attacks based on :ref:`XSS ` or other technologies + relying on execution of malicious code on the visitors browsers; * Generating HTML that always respects a certain format (only certain tags, attributes, hosts, etc.) to be able to consistently style the resulting output with CSS. This also protects your application against diff --git a/reference/configuration/framework.rst b/reference/configuration/framework.rst index ace6989c882..968e7fd5771 100644 --- a/reference/configuration/framework.rst +++ b/reference/configuration/framework.rst @@ -1855,7 +1855,7 @@ cookie_httponly This determines whether cookies should only be accessible through the HTTP protocol. This means that the cookie won't be accessible by scripting languages, such as JavaScript. This setting can effectively help to reduce -identity theft through XSS attacks. +identity theft through :ref:`XSS attacks `. gc_divisor .......... diff --git a/reference/configuration/twig.rst b/reference/configuration/twig.rst index efab3adb2d6..8a8e21dbea0 100644 --- a/reference/configuration/twig.rst +++ b/reference/configuration/twig.rst @@ -49,7 +49,7 @@ individually in the templates). .. danger:: Setting this option to ``false`` is dangerous and it will make your - application vulnerable to `XSS attacks`_ because most third-party bundles + application vulnerable to :ref:`XSS attacks ` because most third-party bundles assume that auto-escaping is enabled and they don't escape contents themselves. @@ -441,5 +441,4 @@ attribute or method doesn't exist. If set to ``false`` these errors are ignored and the non-existing values are replaced by ``null``. .. _`the optimizer extension`: https://twig.symfony.com/doc/3.x/api.html#optimizer-extension -.. _`XSS attacks`: https://en.wikipedia.org/wiki/Cross-site_scripting .. _`__invoke() PHP magic method`: https://www.php.net/manual/en/language.oop5.magic.php#object.invoke diff --git a/reference/forms/types/options/sanitize_html.rst.inc b/reference/forms/types/options/sanitize_html.rst.inc index d5525674815..06e41eecdca 100644 --- a/reference/forms/types/options/sanitize_html.rst.inc +++ b/reference/forms/types/options/sanitize_html.rst.inc @@ -9,8 +9,8 @@ sanitize_html When ``true``, the text input will be sanitized using the :doc:`Symfony HTML Sanitizer component ` after the form is -submitted. This protects the form input against XSS, clickjacking and CSS -injection. +submitted. This protects the form input against :ref:`XSS attacks `, +clickjacking and CSS injection. .. note:: diff --git a/reference/forms/types/textarea.rst b/reference/forms/types/textarea.rst index 0460bca6942..cf56d3067de 100644 --- a/reference/forms/types/textarea.rst +++ b/reference/forms/types/textarea.rst @@ -22,7 +22,7 @@ Renders a ``textarea`` HTML element. .. caution:: When allowing users to type HTML code in the textarea (or using a - WYSIWYG) editor, the application is vulnerable to XSS injection, + WYSIWYG) editor, the application is vulnerable to :ref:`XSS injection `, clickjacking or CSS injection. Use the `sanitize_html`_ option to protect against these types of attacks. diff --git a/templates.rst b/templates.rst index b2769d34dd4..70c19c9fa97 100644 --- a/templates.rst +++ b/templates.rst @@ -1306,17 +1306,25 @@ and leaves the repeated contents and HTML structure to some parent templates. Read the `Twig template inheritance`_ docs to learn more about how to reuse parent block contents when overriding templates and other advanced features. -Output Escaping ---------------- +.. _output-escaping: +.. _xss-attacks: + +Output Escaping and XSS Attacks +------------------------------- Imagine that your template includes the ``Hello {{ name }}`` code to display the -user name. If a malicious user sets ```` as -their name and you output that value unchanged, the application will display a -JavaScript popup window. +user name and a malicious user sets the following as their name: + +.. code-block:: html + + My Name + -This is known as a `Cross-Site Scripting`_ (XSS) attack. And while the previous -example seems harmless, the attacker could write more advanced JavaScript code -to perform malicious actions. +You'll see ``My Name`` on screen but the attacker just secretly stole your cookies +so they could impersonate you in other websites. This is known as a `Cross-Site Scripting`_ +(XSS) attack. To prevent this attack, use *"output escaping"* to transform the characters which have special meaning (e.g. replace ``<`` by the ``<`` HTML entity).