Web pages contain both text and HTML markup that is generated by the server and interpreted by the client browser. Web servers that generates static web pages have full control over client browser. But servers with dynamic pages do not have complete control over how their output is interpreted by the client. Question is, does the client side browser has enough information to recognize if the script is malicious or legitimate and take proper actions accordingly.
Many web servers generate web pages dynamically. For example, a search engine may do a database search and then build a web page that has the result of the search. Any server that creates web pages by inserting dynamic data into a template should check to make sure that the facts to be inserted does not contain any special characters (e.g., "<"). If the inserted data has special characters, the user's web browser will mistake them for HTML markup. Because HTML markup can introduce programs, the browser could interpret some data values as HTML tags or script and not displaying them as text.
If a web browser is not performing checks for special characters in dynamically generated web pages, then in some cases an attacker can choose the data that the web server inserts into the generated page. The attacker can trick the user's browser into running a program of the attacker's choice. This program will execute in the browser's security context for communicating with the legitimate web server, not the browser's security context for communicating with the attacker. Thus, the program will execute in an inappropriate security context with inappropriate privileges.
Hackers take several steps to cut the risk of having the script identified as malicious, the attacker might encode it with a different encoding method, such as HEX. With this alteration, the Web site displays the malicious content on the page as if the displayed information is the valid content from the site. If the Web application doesn't confirm the comments, all the attacker has to do is to coax the user to select the malicious hyperlink, after which the Web application collects confidential data from the user. This enables the attacker to capture the user's session and steal the user's credentials, redirect to a page on another Web site, and then insert code that can poison cookies, expose SSL connections, access restricted or private sites, or even trigger a number of such attacks.
To stop the XSS, we need to understand the venues that are more prone to XSS attacks. Most obvious venues are
- Banking web page
- Online forum and search boxes
- Email messages with malicious links
- Search engines
- Setting up an account
Banking Web page
For example, let us consider an hacker who wants to gather information on a user of a example banking website, www.example.com. Attacker needs Login ID and password to enter into the web site, as all banking web sites contain secure login. Hacker may try using both username and password as "test". When the resulting error page comes back with a message that says that the user ID and password combination is wrong, the hacker finds himself in an ideal situation for inserting malicious code into the Web page. How?
He first enters the following into the ID text box:
This situation is most probable in couple of scenarios like when a web server does not take adequate steps to ensure that the properly encoded pages are generated. And when inputs are suitably validated.
[ad#Google Adsense-1 Add Links]
[ad#Google Adsense-1 Add Links]
Search Boxes and Online Forums
Search boxes and online forums are most commonly attacked avenue. An attacker inserts malicious code between scripting tags that the Web page accepts and interprets, using
Email messages with malicious links
An attacker can send an e-mail about a banking Web site to a user. Suppose the e-mail contains a link with a malicious script embedded into the URL. The user may be prompted to click on the link and log on to the Web site, whereby the attacker can seize the user's log on information. The same is true on a dynamically generated page if a link has malicious code in it. Consider the example of a malicious URL that might be a part of the page. If the attacker has the application display a set of HTML, trouble may creep in. Both the
IFRAMEtags allow for a new URL to load when HTML is displayed.
Search engines that echo the search keyword that was entered are also vulnerable to such attacks. This is because malicious code can be entered as a part of the keyword search input that is executed when the user submits the search. Dangers can include accessing undesirable or private regions of the Web site.
Setting up an account:
When a user submits a form during e-mail account setup or during submission of a form with data in it, the Web application might show the same information after accepting the information as entered. The input content entered can contain such malicious information that may be executed by the browser. This can lead to leaking of critical information from the session and might expose private avenues of the Web server.
XSS attack consequences: Stolen cookies
What an end user can do to protect from XSS?
Below are the ways that a user can choose to cut the impact of XSS attack.
- Disable scripting when it is not required.
- Do not trust links to other sites on e-mail or message boards. They may contain malicious code with damaging potential.
- Do not follow links from sites that lead to security-sensitive pages involving personal or business information unless you specifically trust them.
- Access any site involving sensitive information directly through its address and not through any third-party sites.
- Get a list of attacks and the sites and boards they happened on and be careful if you need to visit one of them.