The Sin Explained

The sin is straightforward: a web application takes some input from a user , perhaps from a querystring, fails to validate the input, and echoes that input directly in a web page. Its really that simple! Because the web server is echoing input, the input might be a script language, such as JavaScript, and this is echoed and interpreted in the destination browser.

As you can see, this is a classic input trust issue. The web application is expecting some text, a name for example, in a querystring, but the bad guy provides something the web application developer never expected.

An XSS attack works this way:

1. The attacker identifies a web site that has one or more XSS bugs for example, a web site that echoes the contents of a querystring.

2. The attacker crafts a special URL that includes a malformed and malicious querystring containing HTML and script, such as JavaScript.

3. The attacker finds a victim, and gets the victim to click a link that includes the malformed querystring. This could be simply a link on another web page, or a link in an HTML e-mail.

4. The victim clicks the links and the victims browser makes a GET request to the vulnerable server, passing the malicious querystring.

5. The vulnerable server echoes the malicious querystring back to the victims browser, and the browser executes the JavaScript embedded in the response.

Because the code is running in the context of the vulnerable web server, it can access the victims cookie tied to the vulnerable servers domain. The code can also access the Document Object Model (DOM) and modify any element within it; for example, the exploit code could tweak all the links to point to porn sites. Now when the victim clicks on any link, he is whisked off to some location in cyberspace he wished he hadnt gone to.

Note 

The output does not need to be visible to lead to an XSS bug; any kind of echo will suffice. For example, the web server might echo the input as an argument in a valid JavaScript block in the web page, or perhaps the data is the name of an image file in an <IMG> tag.

Be wary of blog or product review/feedback web applications because this type of application must read arbitrary HTML input from a user (or attacker) and then echo said text for all to read. In an insecure application, this leads to XSS attacks.

Lets look at some sinful code examples.

Sinful C/C++ ISAPI Application or Filter

This code shows an ISAPI application reading a query string, prepending the word ˜Hello, and then echoing it back to the browser. There is another bug in this code, too, which is far worse than the XSS bug. Can you spot it? Look at the call to sprintf(). Its a buffer overrun (Sin 1) waiting to happen. If the resulting string is longer than 2,048 bytes, the szTemp buffer is overflowed.

 DWORD WINAPI HttpExtensionProc (EXTENSION_CONTROL_BLOCK *lpEcb){  char szTemp [2048];  ...  if (*lpEcb->lpszQueryString)  sprintf(szTemp,"Hello, %s", lpEcb->lpszQueryString);  dwSize = strlen(szTemp);  lpEcb->WriteClient(lpEcb->ConnID, szTemp, &dwSize, 0);  ... } 

Sinful ASP

These examples require little explanation, other than <%= (used in the second example) is the same as Response.Write.

 <% Response.Write(Request.QueryString("Name")) %> 

Or

 <img src='<%= Request.Querysting("Name") %>'> 

Sinful ASP.NET Forms

In this example, ASP.NET treats a web page as a form, and it can read and write to form elements as if they were a Windows form. This can make finding XSS issues problematic because the request and response work is handled by the ASP.NET run time.

 private void btnSubmit_Click(object sender, System.EventArgs e) {  if(IsValid) {  Application.Lock();  Application[txtName.Text] = txtValue.Text  Application.UnLock();  lblName.Text = "Hello, " + txtName.Text;  } } 

Sinful JSP

These examples are virtually the same as the ASP examples.

 <% out.println(request.getParameter("Name")) %> 

Or

 <%= request.getParameter("Name") %> 

Sinful PHP

This code reads the name variable from the incoming request, and then echoes the text from the querystring:

 <?php  $name=$_GET['name'];  if (isset($name)) {  echo "Hello $name";  } ?> 

Sinful CGI Using Perl

This code is almost the same as the PHP code.

 #!/usr/bin/perl use CGI; use strict; my $cgi = new CGI; print CGI::header(); my $name = $cgi->param('name'); print "Hello, $name"; 

Sinful mod_perl

mod_perl often requires a little more code to produce HTML output. Other than some header setting code, this example is the same as the CGI and PHP examples.

 #!/usr/bin/perl use Apache::Util; use Apache::Request; use strict; my $apr = Apache::Request->new(Apache->request); my $name = $apr->param('name'); $apr->content_type('text/html'); $apr->send_http_header; $apr->print("Hello); $apr->print($name);