This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Practical Logging In Web Applications"
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==The Problem== | ==The Problem== | ||
| − | + | ==Identity Flow Through Application Layers== | |
| − | + | All web application security experts will tell you how important logging is [1][2][3][4]. How else can you detect attacks, successful or otherwise? Logs should allow you to replay a user's request lifecycle. In an enterprise web application, this is a lot of work and I'm not happy to tell you not many people are doing it right. | |
| + | There's generally two things development teams have to figure out when architecting a logging strategy; what to log and when to log. | ||
| + | |||
| + | ===When to Log=== | ||
| + | There's sdfsdf | ||
| + | sdfsdfsdf | ||
| + | sdfsdfsdf | ||
| + | |||
| + | ===What to Log=== | ||
| + | There's a general consensus on what kind of information an application log message should contain: | ||
| + | |||
| + | *date and time | ||
| + | *server IP | ||
| + | *source IP | ||
| + | *URL requested | ||
| + | *module/action/class responsible | ||
| + | *user ID | ||
| + | *description of the event | ||
| + | *severity level | ||
| + | |||
| + | Whether you're investigating your web application's log files as part of a regular monitoring program or incident response, you should be able to follow a user's request lifecycle, all the way from the receival of the request (before the invocation of any HTTP filters). | ||
| + | |||
| + | ===References=== | ||
http://msdn2.microsoft.com/en-US/library/aa302420.aspx#c04618429_004 | http://msdn2.microsoft.com/en-US/library/aa302420.aspx#c04618429_004 | ||
Latest revision as of 02:29, 8 August 2007
The Problem
Identity Flow Through Application Layers
All web application security experts will tell you how important logging is [1][2][3][4]. How else can you detect attacks, successful or otherwise? Logs should allow you to replay a user's request lifecycle. In an enterprise web application, this is a lot of work and I'm not happy to tell you not many people are doing it right.
There's generally two things development teams have to figure out when architecting a logging strategy; what to log and when to log.
When to Log
There's sdfsdf sdfsdfsdf sdfsdfsdf
What to Log
There's a general consensus on what kind of information an application log message should contain:
- date and time
- server IP
- source IP
- URL requested
- module/action/class responsible
- user ID
- description of the event
- severity level
Whether you're investigating your web application's log files as part of a regular monitoring program or incident response, you should be able to follow a user's request lifecycle, all the way from the receival of the request (before the invocation of any HTTP filters).
References
http://msdn2.microsoft.com/en-US/library/aa302420.aspx#c04618429_004
