| ||
When reviewing code for XSS bugs , look for code that reads from some kind of request object, and then passes the data read from the request object to a response object. The author of this chapter likes to scan code for the following constructs:
Language | Keywords to Look For |
---|---|
ASP.NET | Request, Response, <%=, and label manipulation such as *.text or *.value |
Active Server Pages (ASP) | Request, Response, and <%= |
PHP | Accessing $_REQUEST, $_GET, $_POST, or $_SERVER followed by echo, print, or printf |
PHP 3.0 and earlier | Accessing $HTTP_ followed by echo, print, or printf. |
CGI/Perl | Calling param() in a CGI object |
ATL Server | request_handler, CRequestHandlerT, m_HttpRequest, and m_HttpResponse |
mod_perl | Apache::Request or Apache::Response |
ISAPI (C/C++) | Reading from a data element in EXTENSION_CONTROL_BLOCK, such as lpszQueryString, or a method such as GetServerVariable or ReadClient, and then calling WriteClient with the data |
ISAPI (Microsoft Foundation Classes) | CHttpServer or CHttpServerFilter, |
JavaServer Pages (JSP) | getRequest, request.GetParameter followed by <jsp:getProperty or <%= |
Once you realize the code is performing input and output, double check if the data is sanitized and well formed or not. If its not, you probably have an XSS security bug.
Note | The data may not go directly from a request object to a response object; there may be some intermediary such as a database, so watch out for this, too. |
We also want to point out something important. Many people think that Response.Write and the like are the only source of XSS-style issues; in fact, it has come to light that Response.Redirect and Response.SetCookie type constructs can lead to similar vulnerabilities called HTTP Response Splitting attacks . The lesson to be learned from this is that any web input that is unsanitized and then turned into output is a security bug. Refer to the Other Resources section for links to more information about HTTP Response Splitting vulnerabilities.