Read Part 1 of this post here

2. THE NON-PERSISTENT VULNERABILITY This is referred to as a reflected vulnerability, and is by far the most common type.
It is usually characterized by holes which show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If the user data are unvalidated and included in the resulting page without HTML encoding, it enables an attacker to inject a client-side code to the dynamic page.

Wikipedia cites this example:
A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If any occurrence of the search terms is not HTML entity encoded, an XSS hole will result. At first blush, this does not appear to be a serious problem since users can only inject code into their own pages. With a small amount of social engineering, however, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page’s content. Due to the general requirement of the use of some social engineering in this case (and normally in Type 0 vulnerabilities as well) many programmers have disregarded these holes as not terribly important. The methods of injection can vary a great deal, and an attacker may not need to use the web application itself to exploit such a hole. Any data received by the web application (via email, system logs, etc) that can be controlled by an attacker must be encoded prior to re-display in a dynamic page, else an XSS vulnerability of this type could result. 3. THE DOM-BASED VULNERABILITY The DOM (Document Object Model)-based XSS vulnerability, also referred to as local cross-site scripting. DOM is the standard object model for representing HTML or XML In this type of vulnerability, the problem exists in the client-side script of the page How to Ascertain If You Are Vulnerable XSS vulnerabilities can be difficult to identify and remove from a web application. Experts say the best way to identify these vulnerabilities is to perform a security review of the code and search for all places where input from an HTTP request could possibly be injected into the HTML output. It is rather disheartening to know that quite a variety of different HTML tags can be used to transmit a malicious JavaScript. There are tools to scan websites for these vulnerabilities.


XSS attack prevention or mitigation requires action on the part of the user, which may be a hard call in reality. Web and Application developers as well as browser vendors are also responsible.
Users can usually disable scripting, several best practices exist for content developers, web applications can be tested and reviewed before release, and some browsers today implement a few access-control policies.

Input validation

Input validation for all potentially malicious data sources is one way to mitigate XSS. This is a useful method in application development.
For instance, if a form accepts some field, which is supposed to contain a phone number, a server-side routine could remove all characters other than digits, parentheses, and dashes, such that the result cannot contain a script.
This type of validation also helps to mitigate other injection attacks such as SQL injection. However, if  an application MUST accept special HTML characters, then HTML encoding MUST also be used.

Cookie security

Cookie security is  another way of mitigating XSS. As many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, it is therefore possible for simple XSS exploits to steal these cookies.

To mitigate this particular threat many web applications tie session cookies to the IP address of the user who originally logged in, and only that IP is permitted to use that cookie.

Escaping and filtering

This is another way to eliminate some XSS vulnerabilities. In this scenario all untrusted data is escaped (either locally or at the server) based on where those data are to be placed in the HTML document.
This escaping prevents the data from being interpreted and executed.
Some of these escaping schemes include HTML numeric entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding

Scripts Elimination

Although Javascript is favoured by Web 2.0 and Ajax designers, some web applications are sometimes written to operate completely without the need for client-side scripts like Javascript. This gives users the option to enable or disable javascript.
This way, even potentially malicious client-side scripts could be inserted without escaping on a page, and users would not be susceptible to XSS attacks.

Do you need tools to control or mitigate XSS attacks, give us a call today (+234-803-724-5018) or send us mail: gbconceptsonline (at) or sales (at)
Please replace (at) with @ in the email.