Testing for Web Site Vulnerabilities

 
 
By Regina Kwon  |  Posted 2002-11-01
 
 
 

Most organizations only react to security threats, and too often, only after damage has been done. But patching a system won't recover stolen data, recoup competitive advantage or revive consumer confidence. The following links take you to simple tests (provided by security vendor SPI Dynamics) that you can take to ensure your site has its guard up. Each test includes an explanation of the vulnerability, the test and, if necessary, a link to a white paper that explains what to do if your site fails.

  1. SQL injection vulnerability could lead to a site's entire back-end database being downloaded by a hacker.
  2. Cross-site scripting occurs when hackers embed malicious JavaScript code into a site's dynamically generated pages, affecting the machine of any user that views that site.
  3. Unrestricted directory listings can be exploited by attackers to gain access to data that was not intended to be viewable to unauthenticated users.
Before You Start: Dynamic URL Basics

A dynamic Web address shows the Web server, the script's name, the parameter and the value that was sent to the script. SQL Injection and other attacks capitalize on flaws in the way values are handled. For instance, a script may use only numeric values. If a letter is sent instead, the script should reject the request. Not doing so means malicious commands can make it to the database. Below is an example of a typical dynamic address.

http://www.anysite.com/article.asp?id=1

Sometimes you'll see multiple parameters, usually separated by ampersands:

../article.asp?id=1&pageid=34

Testing for SQL Injection Vulnerability
Step 1. Open the Web site in a browser.
Step 2. Find a script.

 align=Look for common scripting-language file extensions--Microsoft Active Server Pages (*.asp) and Macromedia ColdFusion (*.cfm) scripts are usually the most vulnerable. The search field is your best bet; the Uniform Resource Locator (URL) on the results page will likely contain a script. Also try hovering your cursor over links while watching the bottom status bar. If the status bar doesn't display URLs, click on links and watch the address bar until you find a URL that has parameters.

Step 3. Begin testing.

Once you are on a page whose URL contains parameters, you are ready to test for SQL Injection vulnerability. There are two methods. Be sure to test each parameter value, one at a time, with each method.

Method 1. In the address bar URL, highlight a paramter value. Replace it with a single quote.


"
"

Method 2. Instead of highlighting the entire parameter value, click inside the value and type a single quote.


"


Step 4. Send request.

Press the Enter or Return key. This will send your request to the Web server.

Step 5. Look for database error message.

Most will look similar to the examples below.

Example 1.


"

Sometimes the error message does not display on screen. To find it, you may have to search the HTML source of the page. (View | Source in Microsoft Internet Explorer or View | Page Source in Netscape.) A document will open. Use that program's search tool to look for either of these phrases:

Microsoft OLE DB

or

[ODBC]

Step 6. Learn more.

If you see one of the error messages shown or find Microsoft OLE DB or [ODBC] in the source code, then the site is vulnerable to SQL Injection. Read SPI Dynamics' SQL Injection white paper for advice on how to fix this vulnerability.

Testing for Cross-Site Scripting Vulnerability


Cross-site scripting (also known as XSS or CSS) occurs when a Web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink that contains malicious content within it. Dynamic pages that are vulnerable to this hack include search results, error messages and Web-form results pages that echo data entered by the user.

After collecting data from a user, a Web application may create an output page for the user--such a page may contain the malicious data that was originally sent to it, but in such a way as to appear to be valid content from the Web site.

An attacker who uses cross-site scripting successfully might compromise confidential information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user or execute malicious code on the end user's computer.

Step 1. Open the Web site in a browser.

Step 2. Locate a search box or login page.

You'll specifically want to find an interactive page that accepts the data you input and displays it back to you on a results page. Search functions and registration or login pages are likely spots to check.

Step 3. Begin testing.

Once you have located a search engine or login form, type the word test into the search field or login name.

Step 4. Send request.

Press the Enter or Return key. This will send your request to the Web server.

Step 5. Determine possibility of cross-site scripting vulnerability.

Note whether the results repeat the text that you entered, as in the following examples:

  • "Your search for 'test' did not find any items"
  • "Your search for 'test' returned the following results"
  • "User 'test' is not valid"
  • "Invalid login 'test'"


If the word test appears in the result page, then your site offers an entryway for cross-site scripting.

Step 6. Submit an actual script to the Web site.

To test for cross-site scripting, input the string <script>alert('hello')</script> into a submission field, in much the same way you entered test in Step 3. Press the Enter or Return key to send your request to the Web server.

Step 7. Determine whether vulnerability exists.

If the server responds with a popup box that displays the word "hello," then the Web site is vulnerable to cross-site scripting.

Sometimes a popup window may not launch even though the site is vulnerable. You may have to search the HTML source of the page. Go to View | Source in Microsoft Internet Explorer or View | Page Source in Netscape. In the document that opens, search for the phrase

<script>alert('hello')</script>

and click the Find Next button. If the text is found, then the Web server is vulnerable to cross-site scripting.

Step 8. Learn more.

Read about ways to defend your site in SPI Dynamics' Cross-Site Scripting white paper.

Unrestricted Directory Listings


A default page is one that appears when no page is explicitly typed into a browser's address bar. For example, when you visit Yahoo!, you merely type in "www.yahoo.com." Although it isn't written in the address bar, "index.html" is the page you're seeing. Every directory in a Web site defaults--or tries to default--to a particular page.

Many Web sites have directories without a default page, however. A directory of images, for example, would be unlikely to contain such a page. If no default page exists, visitors may receive an "HTTP 404 File not found" error. Or they may receive a peek into the private contents of that directory.

This could pose a security risk for your site. Attackers can use such listings to gain access to data that was not intended to be available to unathenticated users. For example, files that you may have thought unavailable to Web site visitors because no links led to them could now potentially be readily accessed.

Step 1. Open the Web site in a browser.

Step 2. Find a page in a subdirectory.

Start clicking through your site until you've accessed a page within a subdirectory of your site. For example, the following URL:

http://www.site.com/somedirectory/page.html

indicates you have reached a page called page.html located within a subdirectory called somedirectory. (By contrast, the URL http://www.anysite.com/page.html is located within the site's top-level directory, not within a subdirectory.)

Step 3. Browse the directory.

Now that you've located a subdirectory page, place your cursor within the address bar URL and edit the URL to remove the page's filename. If you had been on a page called

http://www.site.com/somedirectory/page.html

then you would shorten the URL to

http://www.site.com/somedirectory/



Step 4. Send request.

Click the "Go" button in the address bar, or press the Enter or Return key. This will send the request to the Web server.

Step 5. Analyze the results.

Examine the page that displays next. If it turns out that the directory does have its own index page, you'll want to continue to click through to find another directory to test, repeating Step 4. But if you see a listing of files under a heading such as "Index of" or "Directory of," then your site's private files can be viewed without authentication.

Step 6. Fix vulnerability.

You could create a default page for every directory in your Web site. Alternatively, you could easily enter your Web server's configuration options and disallow directory listings. This is typically done with a single word or line of code.