Cross-site scripting
on a web browser, then content from any URL with the same (1) URI scheme (e.g. ftp, http, or https), (2) host name, and (3) port number will share these permissions.
When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system.
[4][non-primary source needed] The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability).
[7] Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability,[8] with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.
[10] These holes show up when the data provided by a web client,[11] most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content.
If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping.
Her script is run automatically by the browser and steals a copy of Bob's real name and email directly from his own machine.
Persistent XSS vulnerabilities can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website.
Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm.
[14] The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole.
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.
As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting.
[18] Self-XSS is a form of XSS vulnerability that relies on social engineering in order to trick the victim into executing malicious JavaScript code in their browser.
[20] Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.
[21][22][23] Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup.
There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS Another popular method is to strip user input of " and ' however this can also be bypassed as the payload can be concealed with obfuscation.
In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.
Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective.
[34] Content Security Policy (CSP) allows HTML documents to opt in to disabling some scripts while leaving others enabled.
As long as the policy only allows trustworthy scripts and disallows dynamic code loading, the browser will not run programs from untrusted authors regardless of the HTML document's structure.
