Cross-site Scripting-xss description and workaround

Cross-site scripting can be a dangerous security issue that you should consider when designing secure Web-based applications. This article describes the nature of the problem, how it works, and outlines some recommended remediation strategies.

Most Web sites today add dynamic content to Web pages, allowing users to enjoy a more enjoyable experience. Dynamic content is something generated by some server processes that can behave differently and produce different displays depending on the user's settings and needs at the time of submission. A Dynamic web site has a threat called cross-site scripting (also known as "XSS") that is not available on static sites.

"A Web page can contain text and HTML markup generated by the server and interpreted by the client browser. Sites that generate only static pages have full control over how the browser user interprets these pages. A Web site that generates dynamic pages does not have full control over how the client interprets its output. At the heart of the problem is that if untrusted content is introduced into dynamic pages, neither the site nor the client has enough information to identify the situation and take protective measures.

Cross-site scripting is being widely favored by attackers because it is easy to find this security issue on the web. Cross-site scripting attacks are found on the commercial site every month, and reports are released every month to explain the threat. Without attention, the ability to run your site safely and your company's reputation can be a victim of these attacks.

Cross-Site Scripting threats

Cross-site scripting puts server applications at risk, including, but not limited to, the following scenarios:

A when users view pages that are dynamically generated based on what the attacker provides, they unknowingly execute malicious scripts.

B before the user's session cookie expires, the attacker can take over the user session.

C An attacker could connect a user to a malicious server that the attacker chooses.

D the attacker induces the user to access the URL provided by the attacker, resulting in the execution of the attacker's chosen script or HTML in the user's browser. By using this technique, an attacker could take action using the privileges of the user who accessed the URL, such as issuing a query to the underlying SQL database and viewing its results, and using a known problematic implementation on the target system.

Attack on the move

When an attacker knows that an application on a Web site is susceptible to cross-site scripting attacks, he can plan the attack. The most common technique for attackers is to use the victim's privileges to insert JavaScript, VBScript, ActiveX, HTML, or Flash on the victim's system and execute it. Once an attack is activated, anything from intercepting accounts, changing user settings, stealing and tampering with cookies to fake ads can happen.

Sample attack scenario

The following scenarios illustrate some of the more typical attacks with diagrams. However, we cannot list all variants of the vulnerability. To learn more about documented attacks, as well as how to defend themselves as a vendor or as a user, please see the Resources section.

Scripting with malicious links

In this scenario, an attacker sends a specially crafted e-mail message to the victim, which contains a malicious link script such as the following:

<A HREF=http://legitimateSite.com/registration.cgi?clientprofile=<SCRIPT>malicious code</SCRIPT>>Click here</A>

When a user who does not suspect this has clicked on the link, the URL is sent to the containing malicious code legitimateSite.com . If a legitimate server sends a page that contains a clientprofile value back to the user, malicious code is executed on the client Web browser, as shown in Figure 1.

Figure 1 via email attack

Stealing user Cookies

If a cookie is used in any part of the site, it is possible to steal these cookies from users of the site. In this scenario, the attacker makes the page containing the malicious script a part of the vulnerable site. When the page is displayed, a malicious script runs that collects the user's cookie and sends a request to the attacker's website containing the collected cookie. By using this technique, attackers can obtain sensitive data such as passwords, credit card numbers, and arbitrary information entered by the user, as shown in Figure 2.

Figure 2 stealing cookies and intercepting accounts

Send an unauthorized request

In this scenario, when a user executes a malicious link in a mail message, it unknowingly executes the script written by the attacker. Because the context in which the malicious script executes appears to originate from a legitimate server, the attacker has full access to the retrieved document and can send the data contained in the page back to their own site. If the embedded script code has the additional ability to interact with legitimate servers and does not warn the victim when interacting, an attacker could develop and exploit those data posted on different pages on a legitimate Web server, as shown in Figure 3.

Figure 3 Sending an unauthorized request

Avoid attacks

As mentioned above, cross-site scripting attacks are implemented when an attacker can enable a legitimate Web server to send a page that contains a malicious script of the attacker's choice to a Web browser of the victim user. An attacker could then run a malicious script with the privileges of a legitimate script originating from a legitimate Web server.

Now that we know the basics of attack, what can we do to protect ourselves from this vulnerability?

By ensuring that dynamically generated pages do not contain unwanted markup, site developers can prevent their sites from being abused.

From a Web user's perspective, there are two options for reducing the risk of being attacked because of this vulnerability. The first option is to disable scripting languages in a Web browser, and to disable HTML-enabled e-mail clients, which provides the greatest degree of protection, but has side-effects of disabling functionality. The second option is to only perform a link to the main site to view, which significantly reduces the risk that users will be exposed to attackers while still preserving functionality.

However, none of the solutions that a WEB user can adopt is a complete solution. Ultimately, it should be up to the Web page developer to make a decision to modify their pages to eliminate these types of problems. This can be achieved by properly filtering and validating the input received and by properly encoding or filtering the output returned to the user.

Filter

The rationale for this approach is to never trust user input and always filter the metacharacters ("special" characters) defined in the HTML specification. Verifies that each input field, including link parameters, is a script tag. When such an input is found, it is rejected according to the context, which prevents malicious HTML from being provided to the user.

The complexity of this approach is that many Web browsers try to correct common errors in HTML. As a result, according to the specification, when some characters are not special characters, they sometimes treat these characters as special characters. Therefore, it is important to be aware of the individual situations that may guarantee the inclusion of extra characters in the list of special characters. Web developers must examine their applications and determine which characters affect their Web applications.

Filtering on the input is less efficient because dynamic content can be entered into the site database by means other than HTTP. In this case, the WEB server may never treat the data as part of the data entry process, so these data elements may still be contaminated. In addition, it is recommended that filtering be done as part of the data output process before the data is rendered as part of a dynamic page. When executed correctly, this approach ensures that all dynamic content is filtered.

Coding

Cross-site scripting can be avoided when the WEB server is sufficiently sure that the generated pages are properly encoded to prevent unintentional execution of the script.

Each character in the ISO-8859-1 specification can be encoded with its numeric entry value. Server-side encoding is a process in which all dynamic content passes through an encoding function, at which point the scripting tag is replaced with the code in the selected character set.

In general, it is recommended to encode because it does not require you to decide what characters can be legitimately entered, and what characters need to be checked by the encoding function. Unfortunately, coding for all non-trusted data is resource-intensive and can have a performance impact on some WEB servers.

What kind of strategy is right for me?

CGI-based WEB applications or applications that support field editing checks in browsers are likely to be appropriate for filtering policies by extending existing field editing checks to include checking for cross-site scripting weaknesses. Note that while the browser-side field editing checks save several rounds of communication with the server, it is intended for honest users and requires complete code traversal to ensure that all input fields are checked to meet the proposed remediation requirements. However, WEB applications designed with server-side validation in-house can choose to accommodate either of the two strategies, or both.

For the filtering strategy to work correctly, WEB developers need to make sure that the meta-word list characters is up-to-date in accordance with the needs of their applications. In contrast, the coding strategy does not require the above maintenance work, and it has less impact on existing application code and on application functionality. For these reasons, it seems that the coding strategy is a popular implementation choice. The next section describes the sample encoding implementation.

Sample code

For WEB servers, a simple and efficient way to ensure that the generated pages are encoded correctly is to pass each character in the dynamic content through an encoding function, in which the scripting tags in the dynamic content are substituted for the code in the selected character set. This task is best suited for custom tag libraries.

Basics of customizing the tag library

A custom tag library consists of one or more Java language classes (called tag handlers) and an XML tag library description file (TLD) that describes the new tag names and the valid attributes of those tags. Tag handlers and TLDs determine how these tags and their properties and principals are interpreted and processed from within a JSP page when requested. The Custom tag library provides an architecture that is more flexible than Java beans when encapsulating complex operations.

Customized and suitable tag library

In addition to naming our custom tag library XSS , what better name is there? A tag library is a software component that is inserted into a servlet container. The servlet container creates tag handlers, initializes them, doStartTag() and calls, and methods, in turn doEndTag() release() .

With these interactions, our XSS custom tag library can apply "custom" operations that encode Dynamic Data found on JSP pages. Implementing a custom tag is simple, and the steps are as follows:

• Creates a tag library descriptor () that describes the tag .tld .
• taglibadd a pseudo-directive to the JSP file that uses these tokens.
• Implements doStartTag() a tag handler that inherits TagSupport and overrides or doEndTag() methods.

TLD (Tag library descriptor)

The tag library descriptor is an XML file whose elements describe a particular tag library. Listing 1 shows the XSS TLD file for our custom tag library. A markup element defines an encode action, including a property property . tagclasselement defines the tag handler class EncodeTag .

Listing 1. Xss.tld file

<?xml version= "1.0" encoding= "UTF-8"?> DOCTYPE taglib public "-//sun Microsystems, Inc.//dtd JSP Tag Library 1. 1//en " http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd" ><taglib> <tlibversion> 1.0</tlibversion> <jspversion>1.1</jspversion> <tag> <name>encode </name> <tagclass>dw.demo.xss.EncodeTag</tagclass> <bodycontent>empty</ bodycontent> <attribute> <name>property</name> <required>true</ required> </attribute> </tag><taglib>

Taglib pseudo-directive

The Taglib pseudo-directive identifies the tag library descriptor and defines the tag prefix that associates the successor token with the library. The sample Taglib pseudo-directive that appears in the JSP that uses the XSS custom tag library is as follows:

A tag handler is an object in a Web container that helps evaluate an operation when it executes a JSP page. EncodeTagclass is a token handler for encoding operations. Its doStartTag method encodes the dynamic content into the iso-8859-1 character set, which is shown in Listing 2.

Listing 2 encoding dynamic content

public int doStartTag () throws jspexception { StringBuffer sbuf = new StringBuffer (); char[] chars = Property.tochararray (); for (int i = 0; i < chars.length; i++) { sbuf.append ("" "+ (int) chars[i]); } try{ pagecontext.getout (). Print (Sbuf.tostring ()), } catch (IOException ex) { throw new jspexception ( Ex.getmessage ()); } return skip_body; }

Deployment

XSSA custom tag library is part of a Web application that is packaged as an additional file into a WAR file for a Web application, as follows:

• Web-inf/lib/encodetaglib.jar
• Web-inf/tlds/xss.tld

Application

The following scenarios illustrate how to use the custom tag library. Suppose you have a virtual Web site that receives articles that have a page that reviews the articles you subscribe to. Dynamic content, the article entry that you intend to provide to you, is prepared using syntax in a JSP file <%= expression %> .

Let's assume that the attacker successfully populated a page containing a malicious script into the Web site used by the subscribing member. The effect of this successful attack is that when the page is executed on the user's browser, a pop-up window appears, as shown in Figure 4.

Figure 4 before encoding

In the next scenario, this virtual site ensures that the generated pages are correctly encoded by using a XSS custom tag library and can avoid attacks. Untrusted data is retained for visual viewing in the browser, as shown in Figure 5.

Figure 5 after encoding

Conclusion

In this article, we discuss how an attacker can use cross-site scripting as a technique for launching attacks on a Web site. We also demonstrated that most attacks can be eliminated when a Web site correctly encodes dynamic content using a simple custom tag library. XSSYou can protect your Web applications from this emerging threat by using a custom tag library "as is" or by changing the custom tag library more effectively to suit your Web application needs.

Cross-site Scripting-xss description and workaround