• Choose a category
• All
• Classic-Fiction

Learn about the application architecture.

Discover how session management is implemented.

Examine the access control mechanisms.

Learn about the way the application interacts with other components.

Read through the source code (if available) for vulnerabilities.

Research whether there are any known vulnerabilities.

The remainder of this section continues with the review under the assumption the source code is unavailable. The principle is the same, except that with the source code you will have much more information to work with.

Using a spider to map out the application structure

Map out the entire application structure. A good approach is to use a spider to crawl the site automatically and review the results manually to fill in the blanks. Many spiders do not handle the use of the HTML tag properly. If the site uses it, you will be likely to do most of the work manually.

As you are traversing the application, you should note response headers and cookies used by the application. Whenever you discover a page that is a part of a process (for example, a checkout process in an e-commerce application), write the information down. Those pages are candidates for tests against process state management weaknesses.

Examining page elements

Look into the source code of every page (here I mean the HTML source code and not the source of the script that generated it), examining JavaScript code and HTML comments. Developers often create a single JavaScript library file and use it for all application modules. It may happen that you get a lot of JavaScript code covering the use of an administrative interface.

Enumerating pages with parameters

Enumerate pages that accept parameters. Forms are especially interesting because most of the application functionality resides in them. Give special attention to hidden form fields because applications often do not expect the values of such fields to change.

For each page, write down the following information:

Target URL

Method (GET/POST)

Encoding (usually application/x-www-form-urlencoded; sometimes multipart/form-data)

Parameters (their types and default values)

If authentication is required

If SSL is required

Notes

You should note all scripts that perform security-sensitive operations, for the following reasons:

File downloads performed through scripts (instead of directly by the web server) may be vulnerable to file disclosure problems.

Scripts that appear to be using page parameters to include files from disk are also candidates for file disclosure attacks.

User registration, login, and pages to handle forgotten passwords are sensitive areas where brute-force attacks may work.

Examining well-known locations

Attempt to access directories directly, hoping to get directory listings and discover new files. Use WebDAV directory listings if WebDAV is available.

If that fails, some of the well-known files may provide more information:

robots.txt (may contain links to hidden folders)

.bash_history

citydesk.xml (contains a list of all site files)

WS_FTP.LOG (contains a record of all FTP transfers)

WEB-INF/ (contains code that should never be accessed directly)

CVS/ (contains a list of files in the folder)

_mm/contribute.xml (Macromedia Contribute configuration)

_notes/.mno (Macromedia Contribute file notes)

_baks (Macromedia Contribute backup files)

Mutate existing filenames, appending frequently used backup extensions and sometimes replacing the existing extension with one of the following:

~

.bak

.BAK

.old

.OLD

.prev

.swp (but with a dot in front of the filename)

Finally, attempting to download predictably named files and folders in every existing folder of the site may yield results. Some sample predictable names include:

phpinfo.php

p.php

test.php

secret/

test/

new/

old/

Attacks Against Access Control

You have collected enough information about the application to analyze three potentially vulnerable areas in every web application: