5

I am working on developing a secure authentication system with SSO. Until now I have been using the logging framework to generate logs that help in debugging the application. I wonder if there is a guideline to implement logging in a web application.

for example let us say there is an attack on the web app and a security professional comes to analyze the logs then what are the things he will be trying to find out? How to make log analysis easier?

Improve this question

2 Answers 2

Reset to default
4

If it was me, I'd want the following:

  • Precise timestamp (at least 1 second resolution)
  • Source IP address.
  • Source port, if possible.
  • Full set of request headers, if possible.
  • Session ID.
  • Forwarder headers (e.g. X_FORWARDED_FOR) are mandatory for tracing through non-transparent proxies.
  • Full raw requested URL.
  • POST parameters if applicable.
  • Any other data specific to your webapp that might be useful in tracking actions.

In some cases, this information might be bulky. By splitting the logs off daily and archiving them in a compressed format, it should be possible to store a reasonable history of logs. It would also be acceptable to strip out the more verbose information (e.g. full POST data) after a couple of weeks, but that may limit the effectiveness of incident response and forensics for attacks that are detected at a later date.

Improve this answer
2
  • 3
    Note that logging "too much" may imply some usability issues (degraded performance, possibly filling the disk leading to server malfunction).
    – Thomas Pornin
    Apr 9, 2013 at 13:19
  • 1
    I would not include the POST-data. This can include sensitive data, and logging is usually not encrypted while the normal processing of POST-data might encrypt it before saving it to the database. Also note that in some countries there are laws about what you are allowed to store and for which time period. Strictly seen, in the Netherlands you must tell the "College Bescherming Persoonsgegevens" (semi-govt organisation) about storing source IP addresses for anything but security purposes or longer than ~3-6 months.
    – Luc
    Apr 15, 2013 at 12:35
3

In addition to what Polynomial has suggested, I'd recommend paying particular attention to the authentication attempt. i.e. logging the entire request (including the user-agent - not a unique identifier but a useful indicator) perhaps obscuring the password in a machine readable format(*). But also whether the attempt was succesful or not.

Since you should be changing the session id at an authentication attempt, you need to log both of these (regardless if successful). Tracking related content for the authentication page (jss, css, images) is also a useful measure, indeed, you might even consider spiking the page with non-cacheable content. Measuring the dwell time on the page is handy for detecting some kinds of attacks.

Measuring the time to generate the html as well as the time taken to offload it onto the client provides profiling information and detection of sloloris type attacks.

For pages other than the authentication page, then see Polynomial's list, and (where a user id is associated with a session, then the userid - e.g. see mod_auth_memcookie).

(*) i.e. with fields seperated and easily parseable

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .