Web Application Security Basics — Logging , Error Handling and Intrusion Detection

When a security breach occurs, one of the first things you will want to do is pull your logs and investigate what happened. The mission of logging in secure software is to make it as easy as possible for investigators to answer these questions:

■ What happened?

■ Who did it?

■ When did it happen?

■ How was our security circumvented?

■ What data was viewed or modified?

■ How can we prevent this from happening again

When security-critical events are not logged properly, such as a failed login attempt, this can make malicious behavior more difficult to detect and may hinder forensic analysis after an attack succeeds.

If you log too much on a highly hit web application, disks will fill and performance may be impacted. Even worse, this will make it more difficult to find the truly meaningful data in the event of a breach. You need to log with meaning.

Many developers will recognize the need to log the timestamp, a criticality level (warning, error, fatal, and so on), what feature is being requested, and what state the application is in. For auditing and accountability purposes, you also need to log the username, IP address, and some way to tie all log entries from a particular session together.

Tip : Do not log the user’s session ID because this could leak critical authentication data to insiders! Instead, log a hash of the session ID so you can reference multiple log entries to the same session without exposing the session ID itself.

Security related log events

■ Successful logins

■ Failed logins

■ Logouts

■ Password or security question changes

■ Profile changes, such as a change of email address

■ Password reset attempts

■ New user registration

■ User de-registration

■ Authorization failures

■ Changes to access levels, such as granting admin or superuser access

■ Operational activities, such as backups (for example, exporting my Twitter feed)

■ Any system administration activity

■ Significant input validation failures

■ Any other sensitive operation

What not to log

According to item 8.10 in OWASP ASVS Error Handling and Logging Requirements ( https://code.google.com/p/owasp-asvs/wiki/Verification_V8):

Verify that the application does not log application-specific sensitive data that could assist an attacker, including user’s session ids and personal or sensitive information.

You also need to be careful about the types of information you do not want to log. As part of debugging an application, developers frequently log sensitive data, a practice that allows (at least) insiders to steal large amounts of sensitive data with just the theft of a few text files.

A good data protection strategy must also take care to not output any sensitive data to log files, code comments, and error messages. Any one of these code artifacts could expose critical data to an attacker.

Tip : Don’t forget to remove your HTML code comments before you go live. This very often leaks sensitive information such as developer contact information, system passwords, and other sensitive technical information.

Safe Error Handling

When Java web applications error in unrecoverable ways, it is not uncommon to see an exception stack trace in your browser.

One way to prevent stack traces from displaying in a user’s browser is to handle uncaught exceptions via configuration in web.xml.

In addition to using generic error pages when Java exceptions occur, it is also prudent to define custom error pages for HTTP error codes to prevent the server’s default pages (which often reveal server version numbers) from displaying.

App Layer Intrusion Detection

If someone is attempting to conduct offensive operations against your web application, you want to know as soon as possible. Monitoring logs for anomalous events can often help to detect hacker activity as it happens.

Traditional network-based intrusion detection systems (IDS) typically focus on attacks below the HTTP layer and don’t provide context within the application environment. However, adding meaningful intrusion detection logic with your application (that is, logging events that are received inside of your application framework) yields significant visibility into attack activity that traditional tools cannot see.

Detecting Input Validation Violation of Immutable Form Components

A fairly simple yet powerful way to detect early malicious activity against your web application is to detect when immutable form components submit data to your browser that is otherwise impossible to do via normal browser use.

For example, what possible values can a user submit from a radio button group?

A normal user of your website would only be able to submit yes or no as the possible radio button value. There is absolutely no way for one of your users operating a standard browser in a non-malicious way to submit a radio button with another value. If you received anything else, that would indicate that an attacker is using an intercepting proxy tool such as OWASP ZAP, Burp Proxy, Paros Proxy, WebScarab, Tamper Data, or a similar tool.

Defending Against Automated Attacks

The Web Application Security Consortium (WASC) considers it a vulnerability when your web application is vulnerable to these turnkey, automated attacks.

Most of these anti-automation techniques are not perfect security. Although this category of defenses does not include deep security controls, a few simple anti-automation techniques will at least allow you to filter out some threats easily so you can reduce the “noise” entering your application.

CSRF Tokens

The most fundamental anti-automation defense is Cross Site Request Forgery tokens. CSRF tokens not only
stop the threat of request forgeries, but also make it difficult for stateless automations to conduct attacks against your application.

Form Polymorphism

Another form of anti-automation is a programming technique called form polymorphism. The point of form polymorphism is to randomize the names of the input parameters with each request in order to trip up automated scanners. Each time a polymorphic login form is requested, the server will reply with random names for the form fields:

Honey Token Form Component

Another technique that may help stave off automated attacks is to use a honeytoken. The goal of a honeytoken is to trick automated scripts into filling form fields that normal humans would not be able to see or populate in any way.

This is similar to the goal of a CAPCHTA without the annoying usability hit that users must endure when faced with CAPTCHAs.

For example, you could add an additional form component, such as a text field, to your sensitive forms and then hide it with CSS by positioning the component off-page.

Further reading: OWASP AppSensor , ESAPI Logging .

Originally published at http://neatrick.wordpress.com on October 6, 2015.