Cross-site scripting: Difference between revisions

Revision as of 09:55, 9 February 2023

Revision as of 14:23, 5 March 2023

Line 64:

|width=30%

|title=Example of a DOM-based XSS flaw

|Before the bug was resolved, Bugzilla error pages were open to [[Document Object Model|DOM]]-based XSS attacks in which arbitrary HTML and scripts could be injected using forced error messages.<ref>{{cite web |title=Bug 272620 – XSS vulnerability in internal error messages |url=https://bugzilla.mozilla.org/show_bug.cgi?id=272620 |year=2004 |publisher=Bugzilla@Mozilla |access-date=May 29, 2008}}</ref>

}}

XSS vulnerabilities were originally found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in [[JavaScript]]) working on the client-side that pulled data, on-demand, from the server using [[AJAX]].

Line 135:

===Safely validating untrusted HTML input ===

Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. When accepting HTML input from users (say, <code>&lt;b&gt;very&lt;/b&gt; large</code>), output encoding (such as <code>&amp;lt;b&amp;gt;very&amp;lt;/b&amp;gt; large</code>) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "'''very''' large", instead of "&lt;b&gt;very&lt;/b&gt; large"). Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an [[HTML sanitization]] engine to ensure that it does not contain XSS code.

Many validations rely on parsing out (blacklisting) specific "at risk" HTML tags such as the following<syntaxhighlight lang="html5">