{"_id":"55dc79ef6f16451700843e23","githubsync":"","parentDoc":null,"project":"55db8f8f1a91690d007ad975","version":{"_id":"55db8f901a91690d007ad978","project":"55db8f8f1a91690d007ad975","__v":17,"createdAt":"2015-08-24T21:41:36.034Z","releaseDate":"2015-08-24T21:41:36.034Z","categories":["55db8f901a91690d007ad979","55db9856b3d6540d00886426","55dc751b00a8811900c230e3","55dc766255be9f21004ee250","55dc769200a8811900c230ed","55e4c701177b6e0d003330fa","55f4915caf0bc71900a53130","55f491b2be9c2b2100f0635d","560b22739c7be70d00100bd8","57488c53e8c6a420000b729c","574cefd95953e20e00f40f9f","5798edfd7700d30e00ad250c","579ac88234b5fd0e00b9e140","57c81c6d690c200e0047b72e","57d9b8fbda17c30e003897f1","57d9b90e608ea00e00f358d8","57d9b91cda17c30e003897f4"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"user":"55dc702d7fa0290d00559106","__v":12,"category":{"_id":"57d9b8fbda17c30e003897f1","project":"55db8f8f1a91690d007ad975","version":"55db8f901a91690d007ad978","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-09-14T20:54:19.794Z","from_sync":false,"order":4,"slug":"code-protection","title":"Code Protection"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-08-25T14:21:35.147Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"Cross-Site Scripting (XSS) vulnerabilities allow attackers to run arbitrary code on your pages in your customers' browsers. XSS attacks are malicious scripts injected in a web application in such a way that when executed by other users of the site, it will be trusted and executed, giving the attacker access to sensitive information.\n\nSuccessful attackers can get login details, session identifiers, and other personal data about your users. They can also modify the behavior of your site or direct your customers' browsers to participate in a distributed denial of service attack against another party.\n\nThis is an example of an XSS vulnerability in a Ruby on Rails ERB template:​\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<span>Hi <%== :::at:::user.first_name %>!</span>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\nThis example contains an interpolation of a user's first name into the rendered HTML. The `<%==` token allows the string from `@user.first_name` to be passed directly through to the browser without escaping the content. If the first name of a user is `<script>alert('Hi!')</script>`, the following HTML will be rendered on the page:​\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<span>Hi <script>alert('Hi!')</script>!</span>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\nThe alert dialog box that would pop up is harmless, but a much more harmful code could be inserted. The fix fo​r this particular issue is to turn on HTML escaping for this interpolation by changing the interpolation token to `<%=`, which would result in the following HTML being rendered:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<span>Hi &lt;script&gt;alert(&#39;Hi!&#39;)&lt;/script&gt;!</span>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\nHowever, many XSS vulnerabilities are more complex, potentially involving improper escaping in libraries your app depends on.\n\nIMMUNIO protects apps by learning the types of data interpolated into HTML templates during the rendering process, then checking for different data during subsequent renderings. For example, IMMUNIO will trigger an alert if an interpolation in a template usually renders to benign tags, like `DIV` or `P` tags, but the interpolation now renders a `SCRIPT` tag.​\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Mitigation\"\n}\n[/block]\nIMMUNIO will escape improper data from interpolations to ensure vulnerabilities in your app or its dependencies cannot be exploited.​\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"FAQ\"\n}\n[/block]\n## What types of improper data does IMMUNIO look for?\nIMMUNIO can detect and mitigate:\n * Escape from contexts like HTML tags, attribute values, URL parameters, etc.\n \n * Interpolation of potentially malicious tags such as `SCRIPT` or `IFRAME`\n \n * Interpolation of potentially malicious attributes such as \"onload\"\n \n * Interpolation of potentially malicious URLs, including those with `javascript:` or `data:` schemes\n\n * Interpolation of URL attributes, such as an `action` attribute on a form\n\nIt is important to note that IMMUNIO does not prevent the above injections as part of normal operation of an app. It only prevents the injections if they are unusual for a given interpolation in a template.\n\n## How does IMMUNIO learn about interpolations?\nImmunio learns information about interpolations the first time they are rendered to a non-empty string. Interpolations are identified by their template and their position within the template. If the template is modified, the interpolation will be learned anew.​\n\n## What templating engines are supported?\n**Ruby:** ERB and HAML\n**Java:** JSP with Jasper 2\n**Python:** Jinja2 and Django\n**Node:** Jade >= 1.3, Mustache >= 2.1","excerpt":"","slug":"cross-site-scripting-xss","type":"basic","title":"Cross-Site Scripting (XSS)"}

Cross-Site Scripting (XSS)


Cross-Site Scripting (XSS) vulnerabilities allow attackers to run arbitrary code on your pages in your customers' browsers. XSS attacks are malicious scripts injected in a web application in such a way that when executed by other users of the site, it will be trusted and executed, giving the attacker access to sensitive information. Successful attackers can get login details, session identifiers, and other personal data about your users. They can also modify the behavior of your site or direct your customers' browsers to participate in a distributed denial of service attack against another party. This is an example of an XSS vulnerability in a Ruby on Rails ERB template:​ [block:code] { "codes": [ { "code": "<span>Hi <%== @user.first_name %>!</span>", "language": "html" } ] } [/block] This example contains an interpolation of a user's first name into the rendered HTML. The `<%==` token allows the string from `@user.first_name` to be passed directly through to the browser without escaping the content. If the first name of a user is `<script>alert('Hi!')</script>`, the following HTML will be rendered on the page:​ [block:code] { "codes": [ { "code": "<span>Hi <script>alert('Hi!')</script>!</span>", "language": "html" } ] } [/block] The alert dialog box that would pop up is harmless, but a much more harmful code could be inserted. The fix fo​r this particular issue is to turn on HTML escaping for this interpolation by changing the interpolation token to `<%=`, which would result in the following HTML being rendered: [block:code] { "codes": [ { "code": "<span>Hi &lt;script&gt;alert(&#39;Hi!&#39;)&lt;/script&gt;!</span>", "language": "html" } ] } [/block] However, many XSS vulnerabilities are more complex, potentially involving improper escaping in libraries your app depends on. IMMUNIO protects apps by learning the types of data interpolated into HTML templates during the rendering process, then checking for different data during subsequent renderings. For example, IMMUNIO will trigger an alert if an interpolation in a template usually renders to benign tags, like `DIV` or `P` tags, but the interpolation now renders a `SCRIPT` tag.​ [block:api-header] { "type": "basic", "title": "Mitigation" } [/block] IMMUNIO will escape improper data from interpolations to ensure vulnerabilities in your app or its dependencies cannot be exploited.​ [block:api-header] { "type": "basic", "title": "FAQ" } [/block] ## What types of improper data does IMMUNIO look for? IMMUNIO can detect and mitigate: * Escape from contexts like HTML tags, attribute values, URL parameters, etc. * Interpolation of potentially malicious tags such as `SCRIPT` or `IFRAME` * Interpolation of potentially malicious attributes such as "onload" * Interpolation of potentially malicious URLs, including those with `javascript:` or `data:` schemes * Interpolation of URL attributes, such as an `action` attribute on a form It is important to note that IMMUNIO does not prevent the above injections as part of normal operation of an app. It only prevents the injections if they are unusual for a given interpolation in a template. ## How does IMMUNIO learn about interpolations? Immunio learns information about interpolations the first time they are rendered to a non-empty string. Interpolations are identified by their template and their position within the template. If the template is modified, the interpolation will be learned anew.​ ## What templating engines are supported? **Ruby:** ERB and HAML **Java:** JSP with Jasper 2 **Python:** Jinja2 and Django **Node:** Jade >= 1.3, Mustache >= 2.1