Aerosol Posted December 16, 2014 Report Posted December 16, 2014 Explaining Cross-Site ScriptingCross-site scripting (XSS) vulnerabilities are the most prevalent vulnerability in Web applications. XSS bugs arise when Web applications take data from users and dynamically include it in Web pages without first properly validating the data. Also known as script injection or HTML injection vulnerabilities, XSS vulnerabilities allow an attacker to execute arbitrary commands, written in JavaScript for example, and display arbitrary content in a victim user's browser. A successful XSS attack leads to an attacker controlling the victim’s browser or account on the vulnerable Web application. Although XSS is enabled by vulnerable pages in a Web application, the victims of an XSS attack are the application's users, not the application itself. The potency of an XSS vulnerability lies in the fact that the malicious code executes in the context of the victim's session, allowing the attacker to bypass normal security restrictions.Consider the above form used to reset a password along with its accompanying ASP.NET code. When an invalid email address is entered, it is reflected back to the user as part of an error message. Notice what happens when data that is in the wrong format is entered. Select your entry from the drop-down menu, and click Submit.Categories of Cross-site ScriptingThere are three main categories of cross-site scripting vulnerabilities: reflective, persistent, and DOM-based. 1)Reflective—Reflective cross-site scripting vulnerabilities occur when a Web application reflects part of an HTTP request back to the user without first sanitizing it. A common way this happens is when the malicious code is included as a GET or POST parameter. In order for an attacker to exploit a reflective XSS vulnerability, the attacker must somehow entice a victim into initiating the request from his or her own browser, for example, by clicking on a malicious link in an email. 2)Persistent—Persistent cross-site scripting vulnerabilities occur when a Web application stores user-generated data and then later displays this data back to the users of the application. This is common for many Web applications such as wikis, online forums, and social networking sites. If this data is not properly sanitized before being displayed in the client browser, then any user of the application can potentially become a victim. Persistent cross-site Scripting vulnerabilities are more dangerous than reflective ones since the attacker does not have to entice other users of the Web application into performing any suspicious actions.3)DOM-based—DOM-based cross-site scripting vulnerabilities usually affect applications that perform client-side processing of user input using JavaScript or VBScript. Many applications nowadays rely on pages that contain client-side scripts that dynamically generate HTML content. Based on certain user input, these pages modify their HTML without any interaction with the server. A DOM-based XSS exists when it is possible for an attacker to inject a malicious script through such a page without submitting any data to the server. This time, unlike for other types of XSS, it is the client-side script that is responsible for not properly sanitizing the user input, rather than the server. Although they are less common, these vulnerabilities will become more frequent, as an increasing number of applications push their processing logic to the client browser in an attempt to minimize HTTP traffic.Reflective versus Persistent Cross-site Scripting1)ReFlective XSS:-There are many ways in which an attacker can entice a victim into initiating a reflective XSS request. For example, the attacker could send the victim a misleading email with a link containing malicious JavaScript. If the victim clicks on the link, the HTTP request is initiated from the victim's browser and sent to the vulnerable Web application. The malicious JavaScript is then reflected back to the victim's browser, where it is executed in the context of the victim user's session.2)Persistent XSS:-Consider a Web application that allows users to enter a user name which is displayed on each user’s profile page. The application stores each user name in a local database. A malicious user notices that the Web application fails to sanitize the user name field and inputs malicious JavaScript code as part of their user name. When other users view the attacker’s profile page, the malicious code automatically executes in the context of their session.Identifying the Impact of Cross-site ScriptingThrough successful cross-site scripting, an attacker can gain access to the HTML Document Object Model (DOM) that the browser generates for the vulnerable site. This allows an attacker to significantly control the user's browser and to perform various malicious attacks. Some of the more common ones include:1)Altering the response HTML.Since the malicious code executes in the context of the victim user’s session, it has access to all the DOM elements on the page that is affected by the XSS vulnerability. By altering the DOM, elements of the Web page can be hidden or removed, and new elements can be added, effectively modifying the appearance of the page.2)Hijacking Sessions.An attacker can execute any client-side code, such as JavaScript, within the browser, which allows the attacker to access the victim user’s session token stored in a cookie. This can enable the attacker to hijack the victim’s session on the vulnerable application.3)Instantiating ActiveX Controls.An attacker can manipulate ActiveX controls to gain greater access to a victim user’s local machine than is normally allowed. Note that ActiveX components typically require user approval before running.4)Performing Background HTTP requests.An attacker can cause the victim user to make requests to other pages within the Web application, to other unrelated Web applications, and even to applications located behind the victim’s firewall. Such requests can occur without the victim knowing about them. 5)Arbitary Code Execution.The attacker can inject exploits targeted at unpatched vulnerabilities in Web browsers and their plugins.Implementing Input ValidationInput that is expected to be within a certain format should be validated by an application and consequently accepted, filtered, or rejected. When performing input validation, developers generally have to choose between using a black-list or a white-list approach.1)Black-Lists.When using a black-list approach, a list of inputs that are considered dangerous is created. Dangerous input is then filtered or rejected when found. It may seem simpler to enumerate all the insecure inputs instead of the known secure ones. However, with this approach the list of dangerous inputs for a given application has to be constantly updated as the application evolves and new attacks are discovered. If a single insecure input is forgotten, then the security of the application can be compromised.2)White-List.In a white-list approach, a list of known good inputs is used instead. Input that does not match what is in the list will be filtered or rejected. This approach is more secure than using black-lists, but the downside is that good inputs might be blocked unintentionally.3)Filtering and rejecting.Once input has been categorized as bad, the application can either filter or reject it. Input filtering happens when the application accepts dangerous input and transforms it, for example by removing dangerous characters, so that it does not cause any harm. Input filtering is tricky to get right, and a flaw might allow an attacker to craft input that manages to exploit the application after being filtered. As a result, rejecting dangerous input is generally more secure, but can also be less user-friendly.4)Client Validation.Web applications follow a client-server model, and, as a result, input checking can be done on the client browser and/or on the server. The client-side input checks run in a different system, so it is important to keep in mind that they can be bypassed. For example, it is simple to disable JavaScript in a browser and use it to submit invalid data to the server. As a result, any security-related input validation should be performed by the server, even if it is duplicated client-side.Implementing Output EncodingIt is important to properly encode all user-controlled data before it is outputted to a dynamically generated Web page. If data is not encoded then it will make its way to the browser in its original representation, which could be executable script code, causing the browser to interpret and run it. The most common case is of user-controlled input making its way into plain HTML; in this case it should be HTML-encoded before being inserted into the page. HTML-encoding can be performed using ASP.NET's HttpUtility.HtmlEncode. You should, however, carefully consider other locations, such as dynamic JavaScript, into which data can be outputted, and select an appropriate encoding method.As an example, consider an attacker submitting the following attack string to an application:<script>alert(document.cookie)</script>If this input was processed by an application and not properly encoded before being displayed, an attacker would be able to perform cross-site scripting attacks. If the application HTML-encoded this input before displaying it, then the previous attack string would be rendered harmless and would look like:<script>alert(document.cookie)</script>You should consider using Microsoft’s Anti-XSS library, which offers a more robust HttpUtility.HtmlEncode and other methods for different encodings. This library differs from most encoding libraries in that it uses the principle of inclusions to provide protection against cross-site scripting attacks. The library first defines a set of acceptable characters, and then encodes anything outside this set, including invalid characters and characters that could be used in an attack. The principle of inclusions approach provides a high degree of protection against cross-site scripting attacks.Encode the Output!Consider the following form used to reset a password along with its accompanying ASP.NET code. Use the top drop-down menu to specify the means through which data is presented to the user. Use the bottom drop-down menu to select the input to the application. Notice how different encoding schemas are applied when data in the wrong format is entered.Credit's to : KaMmi Quote
