Automated Web Tools & Quality Control Issues | Web Application Vulnerability Assessments

Automated Web Tools
Automated Web site vulnerability tools look for vulnerabilities in CGI scripts and other exploitable areas. Network vulnerability tools sometimes have utilities testing Web site weaknesses. They may simulate attacks in the fashion of Nessus having modules that test areas such as password strength and CGI vulnerabilities.

Whisker
Whisker is a PERL language-based CGI scanner and it is one of the most comprehensive CGI vulnerability tools. It scans a target Web site and compares it against a database of known vulnerabilities. Applicable vulnerability database files are updated from the Whisker Web site. It is configurable and has a default database of script files that is fairly comprehensive. It is available from: http://sourceforge.net/projects/whisker/.

Basically, it is a universal tool and can be used in a UNIX or a Windows environment if PERL is downloaded on the scanning computer. To use Whisker, execute it from the command line and provide a target IP address or host name of the target Web server. It is a bit difficult for someone not comfortable programming in PERL; however, it is considered as one of the best CGI vulnerability scanners available. Using Whisker is run from the command line like this:

C:\nt\whisker\v1.4>whisker.pl -h 127.X.X.6
whisker/v1.4/rain forest puppy/www.wiretrip.net —
= - = - = - = - =
= Host: 127.X.X.6
= Server: Apache/1.3.0 (Linux 6.2)
200 OK: HEAD/cgi-bin/creditcards
200 OK: HEAD/clearinghouse/
In this case, Whisker identified the Web server as Apache version 1.3.0 running on Linux version 6.2. Whisker identified two important links that could provide temptations for an attacker interested in obtaining credit card information or information about the clearinghouse.

SiteScan
SiteScan is a fairly useful tool for finding Web site vulnerabilities. [10] It is a Windows-based tool and is easy to install, configure, and launch. There is a bit of a downside in that this tool is dated. However, many of the exploits identified by this tool are relevant for auditing purposes as Web site administrators frequently fail to keep their systems updated with the latest patches.

Brutus
This is essentially another password brute-force testing tool. [11] It is a fairly simple tool to use and delivers an easy way to test authentication mechanisms via brute-force attacks. Brutus is Windows-based and is a tool that is not restricted to HTTP. Brutus can attack FTP, telnet, POP3, and SMB password accounts. Because Web servers were intended to handle large numbers of requests, it is one of the easier areas on which to force an intrusion and gain access.

Experience Note Automated vulnerability tools are effective and for the most part efficient. However, they should not be used as the sole means of assessing systems. Automated tools are limited to the vulnerabilities listed in their database or the potential passwords located in their dictionaries. They cannot examine policies, procedures, and standards. They are merely tools, among all the tools, available to the auditor and should not be allowed to replace experience and good judgment.


Quality Control Issues
There are quality matters about which auditors should be concerned. Assessments of Web-enabled applications are important and generally require a significant amount of work. Evaluating Web applications is much easier while in the testing phase before they enter the production environment. Web application assessments should be completed after the Quality Assurance Unit has done their job, and before actual User Acceptance Testing, UAT, is commenced especially if real customers are going to be used. It is possible that real customers have malicious intent or they accidentally discover a security flaw during the UAT. Auditors should remember the following:

  • Test sign-on processes

  • Test sign-off processes

  • Test modified user-supplied input

  • All user input must be filtered at the Web server for proper size and content type before being accepted and acted on by the CGI scripts

  • All CGI Output in the form of HTML and HTTP must be scrubbed of comments, error messages, sensitive information, and hidden tags that identify the Web server's version and any third-party products

  • All CGI defaults must be removed or secured before going into a production environment

  • Test error messages for degree of information

  • Test logical sequences

  • Test HTML in Web page content assuring that it does not contain any sensitive information

  • Web application assessments are dependent on the knowledge and expertise of real people; using a manual and automated approach generally assures accuracy

  • Popular Posts