Author: Scott Shebby
Before proceeding, be aware of potential legal liability you may incur. Only use these procedures on sites for which you have permission; some of the techniques covered can be interpreted as hacking and therefore illegal in some jurisdictions. Additionally, these techniques are only meant to be a starting point and not a replacement for a complete system assessment by an accredited security professional.
Web application input validation problems
Description: Improper input validation is the origin of a wide variety of vulnerabilities. Therefore, it should come as no surprise that it is also the most common Web application vulnerability. Problems occur when a Web application accepts input from a client browser and then passes that input to a database or CGI processor without ensuring the data is valid. A common version of this vulnerability is SQL injection.
Risk: The input data can be manipulated to abuse the data processor and retrieve system information. The worst case scenario is that attackers can extract and manipulate database information, execute commands, or read and write files on a system.
Detection: First identify the input data that you want to test. Form fields, URL parameters, cookies, and HTTP headers are all valid input vectors. Second, identify characters that should not belong, or that have special meaning to databases or CGI processors. Good characters to try are the apostrophe, double quotes, and parenthesis. Third, submit the data to the Web site. Look for any descriptive error messages or abnormal Web site behavior. Error messages containing “ODBC” are database-related. An error message of “Unclosed quotation mark” is one indication of SQL injection.
Example: http://mywebsite.com/search.asp?query=ab’cd
Solution: Define acceptable data and make it as restrictive as possible. If input data is invalid then it should be rejected. Attempting to filter through data and remove illegal characters is not recommended. If you must pass characters with special meanings (such as single quotes or semicolons) to the processor, make sure they are first encoded or properly escaped for the processor. For example, if the processor is a database, use PreparedStatements to encapsulate the data. (For a more detailed coverage on canonicalization see the OWASPGuide to Building Secure Web Applications.) Additionally, you should filter responses from the processor; error messages should avoid disclosing information unnecessarily.
Cross site scripting
Description: Cross site scripting (XSS) occurs when a Web application accepts scripting commands from the client, and then returns them to the client as part of the Web page. This makes the script appear to originate on the vulnerable server, which the user trusts, and gives it access to all the user’s cookie and session information.
Risk: Using XSS vulnerabilities, attackers can trick users into clicking links that contain embedded scripting commands. These scripting commands can then execute malicious scripts, which innocently appear as though they are from the trusted yet vulnerable site. Attackers can then gain access to any of the user’s current session information, including cookies, form, document, and session values.
Detection: Search your Web site for pages with dynamic information that originates from the query string or form values. Cross site scripting often occurs when a Web application reflects invalid input back to the client in an error message (this includes 404 pages that display the requested URL). Once you identify a value that you can manipulate, append <script>alert()</script> to it and submit. For example:
Example: http://mywebsite.com/login.jsp?msg=<script>alert()</script>
When you submit the request, you will see a pop-up box if the page is vulnerable. If you don’t get a pop-up box, inspect the source code of the page for the <script>alert()</script>; if it’s there then you might still be vulnerable. Note: disable any pop-up blockers before doing this.
Solution: The ideal solution is to not reflect values obtained from the browser back to the browser. Embed your messages inside another variable, and refer to it numerically. Alternately, you can also convert the < and > characters to their HTML equivalents > and <. Unfortunately, this will not prevent all XSS attacks. Choose the first solution whenever possible.
Session management problems
Description: When you log into a Web site, the server creates a session that establishes state between your browser’s requests. Web sites use this to track those who are logged in and their access privileges.
Risk: Attackers can access restricted pages without proper authorization, or manipulate session variables to gain access to other users’ accounts. In the case where membership is subscription-based or restricted, attackers may be able to access personal information such as credit card numbers through the account’s interface. This vulnerability can give attackers free access to electronic downloadable products, such as music, resulting in lost revenue.
Detection: This class of Web vulnerabilities can be very complex. A good place to start is to identify the parts of your site where access is restricted. First, check for missing authentication by trying to access the restricted pages directly. Second, identify any cookies or session values that are being set by the server for authentication. Using a Web proxy, manipulate these values to try and gain access to other valid accounts.
Solution: Although not comprehensive, these two items are a good start. First of all, sessions should always be maintained on the server side. Don’t trust cookies and client-side session values, as they can be manipulated. Always use a strong unique identifier such as the ASPSESSIONID instead of an integer or email address. Check for a valid session on each restricted access page whenever the page is requested.
Default/misconfigurations (Sample apps/dir listings)
Description: This class of Web vulnerabilities is a bucket for configuration and installation problems. Items such as sample applications that are installed by default, directory listings and permissions, default software features and configurations, and log and swap files can all provide an attacker with a starting point for breaking into the server.
Risk: Sample applications that are installed by default can contain information-disclosing scripts that may reveal Web site source code. Directory listings can reveal files that would otherwise have been unknown to an attacker. Default software features may have exploitable bugs. Log files and swap files can be left over from developers editing Web application pages.
Detection: Check for directory listings by simply navigating to each directory on the Web server using a Web browser. Look for hidden files, log files, and files that have extensions that are served by the Web server “as is,” such as .txt, .bak, .old, or .zip.
Solution: Always perform a lockdown procedure on the server before it goes online. Remove all example pages and disable default features that you are not using. Disable directory listing on all directories. Do not let developers edit files directly on the Web server. Create and enforce a policy where they must edit on a development server and copy the finished product to the live server.
Dangerous HTTP methods
Description: While this is also a server configuration vulnerability, it is deserving of its own category. HTTP methods are commands that tell your Web server what to do. Many commands, such as PUT and DELETE, and WebDAV commands (which are extensions to the HTTP methods) are not needed on a production server.
Risk: Utilizing the PUT method and a writeable directory, attackers can upload content to your Website. Depending on the permissions of the vulnerable directory, they may be able to execute scripts. Imagine an attacker uploading a fictitious press release, or illegal content and reporting it to the authorities. The DELETE method allows attackers to delete content from your Web site, causing a denial of service. WebDAV methods have been used in the past to perform buffer overflows on Windows servers.
Detection: Sometimes the server supports these methods but they are not enabled. To test the PUT method, use a tool like curl to attempt a file upload:
curl -T test.asp http://www.mywebsite.com/
Next, try to access the file. If you can, then the PUT method is enabled.
To test the DELETE method, connect to the server using telnet and issue the following command:
DELETE /
n
where
Solution: Disable or block these methods on your server. Consult your software documentation for specifics on how to do this.
By following these recommendations, you will be able to eliminate the most common (and arguably serious) vulnerabilities that afflict Web sites.
Scott Shebby, CISSP, is director of customer service for ScanAlert Inc., a security auditing company. Prior to joining ScanAlert, he was a systems administrator for Medave Inc. and a network communications specialist in the United States Marine Corps.
Category:
- Security
