Most existing browsers are capable of interpreting and executing scripts -- created in such scripting languages as JavaScript, JScript, VBScript -- that are embedded in the Web-page downloads from the Web server. When an attacker introduces a malicious script to a dynamic form submitted by the user, a cross-site scripting (XSS) attack then occurs.
An XSS attack leads to undesirable effects. For example, the attacker gains the ability to capture the session information, peer into private user details such as ID, passwords, credit card information, home address and telephone number, social security/tax IDs, and so on. If the targeted Web site doesn't check for this type of malicious code, misuse of the user is probable.
To reduce 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 validate the input, 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.
The first weapon in the arsenal for stopping this type of abuse is recognizing the areas that are prone to the XSS-style of intrusion.
Discovering XSS vulnerabilities
The following examples are intended to help you recognize the areas that are vulnerable to XSS attack.
A banking malady
Suppose that an attacker wants to gather info on a user of a fictional, popular banking Web site, www.simplebank.com. To log into the Web site, the attacker first enters a test user ID ("test") and password ("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: <scrypt>alert('Test')</scrypt>. He submits the form and then sees this JavaScript alert message: "TO BE DONE." Now he knows that the site is prone to an XSS-style attack. He then might introduce scripts like those in Listing 1 into the URL that redirects the submitted user information to malicioussite.com.
This code basically passes the user ID and password information of any user logging into the Web site along to the Web site of the attacker. Now that the script to hack the user ID and password is ready, the attacker sends e-mails and posts with attractive offers to banking Web site users employing this link. Prompted by the attractive offers, users might click on the link and log on to the banking Web site. The malicious script introduced by the attacker is executed by the browser and the data is passed to the hacker's Web site. The rest is a cakewalk for the hacker to log on to the banking Web site with the victim's credentials.
This situation can occur when:
A Web server does not take adequate steps to ensure that the properly encoded pages are generated. An input is not suitably validated.
Online forums and message boards
The most commonly attacked avenues on the Web are search boxes and online forums. An attacker inserts malicious code between scripting tags that the Web page accepts and interprets, using FORM or APPLET tags, depending on the page used. Inserted malicious code can do all sorts of harm by stealing session information or cookies.
Vulnerability of this sort is prevalent given that a Web designer needs to have knowledge of many languages and technologies (to protect against attacks). Many languages -- CGI, JavaScript, ASP, Perl, even HTML tags -- are suitable as a delivery vehicle for such attacks.
Links attached to messages and e-mail
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 URL (see Listing 2) 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 IMG and IFRAME tags allow for a new URL to load when HTML is displayed.
Search engines
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.
For example, Listing 3 shows a code snippet that executes code on the target computer. The attacker just inserts HTML in this fashion.
Error messages
Some Web sites might echo the input along with an error message generated by a business validation. If the input string had some maliciously designed script, the script is executed. Unwelcome effects might include compromise of confidential information and creation of requests that can be mistaken for those from a user.
Setup accounts
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.
Worms
IMG and IFRAME tags in HTML allow for a new URL to load during the display of HTML. Certain worms use the load-on-view feature provided by the IFRAME tag to contaminate systems running browsers.
These are all vulnerabilities when it comes to an XSS-style attack. Next, I'll briefly talk about the prime result of an XSS intrusion
0
comments, (619 reads) All Articles by, GentleGiant