WHAT IS CROSS-SITE SCRIPTING (XSS)
Cross-site scripting (XSS) is a type of computer insecurity vulnerability typically found in Web applications, such as web browsers which breach the security that enables attackers to infuse client-side script into Web pages viewed by other users [1]. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Several major websites including Face book, Twitter, MySpace, eBay, Google, and McAfee have been the targets of XSS exploits. XSS is the result of limitations inherent in many Web applications‟ security mechanisms i.e. the lack or insufficient refinement of user inputs. XSS flaws exist in Web applications written in various programming languages such as PHP, Java, and .NET where application WebPages reference unrestricted user inputs. Attackers inject malicious code via these inputs, thereby causing unintended script executions through clients‟ browsers.

Researchers have proposed multiple XSS solutions ranging from simple static analysis to complex runtime protection mechanisms. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities recorded by Symantec as of 2007. Their effect may range from a petty trouble to a significant overhead of security risk, depending on the value of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner. From a development perspective, researchers need to craft simpler, better, and

more flexible security alternatives. Cross-site scripting flaws are web-application vulnerabilities which allow attackers to bypass client-side security mechanisms normally imposed on web content by modern web browsers.

By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf for user. Cross-site scripting attacks are therefore a unique case of code injection . The expression “cross-site scripting” originally referred to the act of inducing the attacked, thirdparty web application from an distinct attack site, in a manner that executes a section of JavaScript programmed by the attacker in the security framework of the targeted domain. The definition gradually expanded to encompass other modes of code injection, including persistent and nonJavaScript vectors (including Java, ActiveX, VBScript, Flash, or even pure HTML, and SQL Queries), causing some uncertainty to newcomers to the field of information security. XSS vulnerabilities have been reported and exploited since the 1990s. Well-known sites affected in the history include the social-networking sites Twitter, Face book, MySpace, and Orkut. In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly-reported security vulnerability, with some researchers in 2007 viewing as many as 68% of websites as likely open to XSS attacks.

TYPES OF XSS EXPLOITS
Persistent or Stored Attacks: The persistent or stored XSS vulnerability is transpired when the attacker is provided the data is saved back by the server, and then returned to other users in the course of normal browsing permanently displayed as “normal” pages, without appropriate HTML escaping. Mostly this type of vulnerability occurs in the Social websites where-in members scan the profiles of other members [2]. For privacy reasons, this site hides everybody’s unique personal identity and email. These are kept secret on the server. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a indirect kind of a client-side worm. Persistent XSS can be more significant than other types because an attacker’s malicious script is turned into automatic nature, without the need to individually target victims or also lure them to a third-party website. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could befall into injection vector. Non-persistent or Reflected Attacks: Non-persistent XSS vulnerabilities in Google could permit malicious sites to attack Google users who visit them whilst logged in. A potential vector is a site search engine, given a search for a string; the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw would result in. A reflected attack is typically delivered via email or a neutral web site. These holes show up when the data provided by a web client, most frequently in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly cleansing the request.

Because HTML documents have a flat, serial structure that blends control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding[5]. This may result in markup injection. In this class of scripting languages are also used, e.g., Action Script and VBScript. Mostly attackers would write the scripting in java language only for common practice of the attack includes a design step. In this context the attacker creates and tests an offending URI(Uniform Resource Indicator), a social engineering step, in which the offender convinces his victims to load this URI on their browsers, and the eventual execution of the offending code[4]. The web application might filter out “

Vulnerability Detection: This type of XSS defenses focus on identifying vulnerabilities in server-side scripts. Static-analysis based approaches can demonstrate the absence of vulnerabilities, but they tend to produce many false positives. Recent approaches combine static analysis with dynamic analysis techniques to improve accuracy.

Static Analysis: Benjamin Livs and Monica Lam used binary decision diagrams to relate points to analysis to server-side scripts. Their approach requires users to specify vulnerability patterns in Program Query Language [6] .Yichen Xie and Alex Aiken proposed a static analysis technique that acquire block and function summary information from symbolic execution Pixy, an open source vulnerability scanner and also includes alias analysis to improve precision. These techniques identify tainted inputs accessed from exterior data sources, track the flow of tainted data, and check if any reached sinks such as SQL statements and HTML output statements. For example, for the program travelerTip it reports the following statements as vulnerable:

Example 2. out.println(“Your Post has been added under Place „” + HTMLencode(place)+“‟”); out.println(“Your Message: „”+ new_tip+ “‟ is too long!”); out.println(“„”+tip+“‟”);

XSS vulnerabilities in source code and are relatively easy for security personnel to implement and adopt. However, they cannot check the correctness of input sanitization functions and, instead, generally assume that unhandled or unknown functions return unsafe data. These approaches also miss DOM-based XSS vulnerabilities as they do not target client-side scripts. Static String Analysis: The enhancement provides more accuracy as it can examine string operations effects on inputs. However, when conducting static string analysis, it is complicated to model complex operations such as string-numeric interaction; thus, this approach can result in false positives if analysts make conventional approximations when handling such operations. Gary Wassermann and Zhendong Su enhanced the original taint-based approaches with string analysis. Their technique uses context-free grammars (CFGs) to signify the values a string variable can hold at a certain program point, which facilitates the checking of blacklisted string values in sensitive program statements. Static string analysis also suffers from the limitations of blacklist comparisons. Runtime attack prevention: In general, these methods set up a proxy between the client and server to capture incoming or outgoing HTTP traffic. The proxy then checks the HTTP data for illegal scripts or verifies the resulting URL connections against safety policies. XSS defenses focus on preventing real time attacks using intrusion detection systems or runtime monitors,
which can be deployed on either the server side or client side. Client Side Prevention: Its main disadvantage is that it requires client actions whenever a connection violates the filter rules. Moreover, this approach addresses all types of XSS attacks, it only detects abuse that send user information to a third-party server, not any other exploit such as those involving Web content manipulation. Noxes acts as a private firewall that allows or blocks connections to websites on the basis of filter rules, which are basically user-specified URL white lists and blacklists. When the browser sends an HTTP request to an anonymous website, Noxes immediately alerts the client, who chooses to allow or deny the connection, and remembers the client‟s action for prospect use. Client-side prevention provides a personal protection layer for clients so that they need not depend on the security of Web applications. Server Side Prevention: Users specify prerequisites of sensitive functions i.e. those that contain HTML outputs and post conditions of sanitization functions. During runtime, instrumented guards ensure for conformance of these user-specified conditions. The WebSSARI (Web Security via Static Analysis and Runtime Inspection) tool, which executes type based static analysis to identify potentially weak code sections and implement them with runtime guards. Other approaches use dynamic taint-tracking mechanisms to monitor the stream of input data at runtime [6]. They ensure that these inputs are syntactically restricted (only treated as literal values) and do not hold unsafe content defined in user-specified security policies. Some server side prevention mechanisms require the collaboration of browsers. One example is BEEP (Browser-Enforced Embedded Policies), a mechanism that modifies the browser so that it cannot execute unlawful scripts. Security policies dictate what data the server sends to BEEP-enabled-browsers.

LEAVE A REPLY

Please enter your comment!
Please enter your name here