..:: jwall.org ::..

Auditing Web-Applications

The first step in protecting network applications is a thorough observation of the communication data. This is often referred to as network auditing and closely connected to network intrusion detection. Both approaches monitor traffic on network-level to detect malicious packets or attack patterns.
This article is about auditing web-applications using ModSecurity, a popular module for the apache web-server which provides detailed logs of web-traffic.

Problem statement

Web applications like web-shops or even bulletin boards are a valuable attack target. Why on earth are bulletin boards valuable? Just consider that they provide the possibility to save a users message. Saving malicous code in a message might also be possible. Firewalls, working on network-level are defenseless in preventing nifty http-request to reach these applications since in general they do not filter the network-packets contents (hence the name network-level firewall).

To achieve better protection an application-level analysis of the network-traffic needs to be done. ModSecurity provides detailed logging facilities - the audit-log engine - which can be used to analyse traffic on the application level.

Logfile format

The audit-log file format of ModSecurity provides an adjustable level of details that can be logged on each request. Each request is parted into a set of sections that hold a specific part of the request data. Each of these sections is assigned an upper-case letter that identifies it. Using the directive SecAuditLogParts you can select which section are to be written to disk by mod_security by listing the appopriate letters. The following table holds a description of each section.

Name	Section	Description
Audit log header	A	This section holds all the information about the tcp-connection and date when the request has been received. The use of this section when defining the log-parts is mandatory.
Request headers	B	Section B contains the complete header of the request
Request body	C	If the request has had a request-body it will be saved in this section, otherwise this section is missing.
Intermediary response headers	D	Reserved for future use. Not yet implemented.
Intermediary response body	E
Final response body	F	This section contains the response headers sent back to the client (it does not contain date and server-headers as these are added to the response immediately before apache starts transmitting the response).
Actual response body	G	Reserved for future use, not yet implemented.
Audit log trailer	H	This part of the log entry holds data generated by mod_security (messages, rule-id,...)
Mime-data	I	This section is a replacement part for C in case the request body contained multi-part form-data. The form-data is broken down and converted into a normal query string.
Uploaded-file data	J	This is also not implemented yet. Reserved for holding information about files, being uploaded using multipart/form-data encoding.

Because especially the response body or file-content of uploads could become quite big you need to be careful when selecting which parts to log. ModSecurity provides a simple way to filter which requests to log in this detailed fashion by specifying the status of the responses you consider to be relevant for logging:

   SecAuditEngine On
   SecAuditLogParts ABCZ
   SecAuditLogRelevantStatus ^[45]

The first line starts the audit log engine. The second one specifies the parts that shall be logged by ModSecurity and the last one tells ModSecurity to log all requests that have a status of 4xx or 5xx. Another way to log a request is by specifying the auditlog action in a rule. That way, whenever a rule matches a request, it will log the request to the audit log:

   SecAuditEngine On
   SecAuditLogParts ABCZ
   
   SecRule REQUEST_URI php "auditlog"

This rule will log all requests that have "php" in their request-line to the audit log.

Logging response bodies

To make ModSecurity log the response body to the audit log you need to specify it in the audit-log parts and make it access the body by using the directive SecResponseBodyAccess. This depends on the RuleEngine so you need to enable that, too. For logging the response body you need

   SecAuditEngine On
   SecAuditLogParts ABCFHZ
   
   SecRuleEngine On
   SecRequestBodyAccess On
   SecRequestBodyLimit 524288

It is also a good idea to limit the amount of data of the response body that should be accessed. This is done by using the directive SecRequestBodyLimit and SecResponseBodyLimit and specifiying the number of BYTES (!!!) that you want the response to be limited to. You can even specify which response bodies to log to the audit-log depending on the mime-type of the response. This is done using SecResponseBodyMimeType:

   SecAuditEngine On
   SecAuditLogParts ABCFHZ
   SecRuleEngine On
   SecRequestBodyAccess On
   SecRequestBodyLimit 524288

>> Part 2