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:
RECOMMENDATIONS FOR MITIGATION OF 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 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 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.
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) yahoo.com or sales (at) gbconcepts.net
Please replace (at) with @ in the email.