Web application security incident handling

I thought I'd take a moment to post about some web security tools I use pretty often, which help as a security consultant when responding to various web hacking related incidents. These tools have helped me write my own scripts whenever I'm in a jam and

need something good and quick to do the job.

Application Log File Forensics: The Hard Way

The first thing a security professional or administrator usually think of when handling an application security incident is to check the logs for the applications, databases, and other application-tiers involved. Often, these logs are either on the servers

that run the applications themselves, or possibly in a central logging location. If a certain attacker tool can be identified from the log files (or other sources such as full packet-capture), then it may be of interest to run that exact same tool against

your own application-under-target (preferably in a mocked-up lab or test environment, if it mirrors production well enough).

The most popular web servers, Apache httpd and Microsoft IIS, do create local log files by default. According to most compliance regulations and standards (e.g. COBIT, HIPAA, GLB, PCI-DSS, FISMA, EU Directive on Privacy and Electronic Communications, ISO

17799/27002, CA SB1386 and similar), logging must be centrally located, or may have other required provisions. This may include application-layer information, such as the log information from Apache and IIS. It may be very likely that your organization already

has centralized logging where this information is available.

If centralized logging does not exist, it may be a good time to start up a project to enable it.

but this only logs error messages, not authentication/access_log messages. The book gives two prescriptions, one using "AccessLog "|/usr/bin/logger" combined" if your OS supports the logger command properly. The other is to run a custom log message through

a Perl script, as seen below:

Microsoft IIS will need to go through the Event Log, which can be converted to syslog messages using a third-party software package such as

Web Application Incident Handling: The Easy Way

Most of the logfile "digging" takes time, even when consolidated and using expert tools and analysis. There are some very easy approaches that we've come up with, or seen others using and talking about. These tools integrate well at the HTML and Script layers.

Part of the success behind the PHP-IDS project, was the constant testing and attacking of PHP-IDS regex filters, which can be reviewed extensively in this

because Apache logs do not contain POST data. (See PHP-IDS or mod_security for those purposes)

Simply use Scalp by running it as follows (keep in mind there may be false positives with regards to the attack type, though it is very good at pulling attack queries from the log):

Note, one does not require AntiSamy to be implemented in an application to use Scrubbr. Using Scrubbr, you have the capability of validating each and every column capable of holding strings of every row of every table in a database.

Together, Scalp and Scrubbr make for excellent web application security forensic tools. Scalp can help detect attacks in Apache logs, and Scrubbr can help you clean your database of content that does not match your site's policy.