I'm very disappointed to see Johannes Ullrich @ the Internet Storm Center lead off the SANS Software Security Institute blogging effort at appsecstreetfighter.com by providing a software security recommendation that will significantly increase application risk!!
http://appsecstreetfighter.com/2009/05/24/logging-cookies-in-apache/
To quote Johannes, "The cookie typically includes the session ID, which then links to a particular user. So this way, you can figure out which user caused a particular action."
Never log session ids. If you need to uniquely identify each session in your log files for debugging or other purposes, then hash your session id's before logging them. Only transmit session ids over well configured https. Keep session ids out of urls. Make sure session ids are cryptographically random and long. Reduce idle timeout. Enforce absolute timeout. Invalidate session ids at logout.
http://appsecstreetfighter.com/2009/05/24/logging-cookies-in-apache/
This is absolutely positively bad application security advice. Logging a session id will actually increase application risk! Never log session ids!
To quote Johannes, "The cookie typically includes the session ID, which then links to a particular user. So this way, you can figure out which user caused a particular action."
An insider could hijack all active sessions by simply having access to a live application log file.
Never log session ids. If you need to uniquely identify each session in your log files for debugging or other purposes, then hash your session id's before logging them. Only transmit session ids over well configured https. Keep session ids out of urls. Make sure session ids are cryptographically random and long. Reduce idle timeout. Enforce absolute timeout. Invalidate session ids at logout.
But really, if you think you need to log a session id or ANY credentials, think again.
Make sure your Web Application Security educator utilizes OWASP principles!
11 comments:
This looks like sound advice...where can I learn more ...
1. OWASP Legal Project (Secure Software Contracts for Developers and their Clients) http://www.owasp.org/index.php/Category:OWASP_Legal_Project
2. OWASP Live CD! FREE TOOLS! http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project
3. OWASP Application Security Verification Standard http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
4. OWASP Code Review Guide http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
5. OWASP Developers Guide http://www.owasp.org/index.php/Category:OWASP_Guide_Project
6. OWASP Coders Security Library in Java, PHP, .NET, ASP and Haskel (ESAPI) http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
Jim,
While I agree that, in principle, one should avoid logging sensitive data whenever possible, in this case you need to explain to us exactly how will the risk increase.
For example, in a typical Apache installation logs will be only available to root. If you have untrusted insiders with root access then not logging session IDs is not going to help you.
In addition, the application engine will itself keep session data somewhere, which means that you don't gain anything by not logging the session IDs. The asset remains elsewhere on the server.
Finally, if you're logging session IDs you are presumably doing that because they are needed. Your security policy should ensure that the information is only made available to the personnel that really needs it.
Ivan,
There are always exceptions to the rule. But as a "general recomendation" session id's should be treated as credential information and therefor not logged. If you need to track session information, then simply hash the session id before logging it. Session id's are so long that a hashed version of the session id will be fairly immune from rainbow attacks.
Sure, there are exceptions. But you really need to think twice before logging credentials such as the session id.
Jim,
You're talking theory, but we have real life to deal with.
Since Apache does not provide a facility to sanitise session IDs, our choices are to log or not to log. By not logging we give up a valuable security features (the ability to associate requests into sessions, the ability to perform per-session anomaly tracking, the ability to block sessions, etc.). If you want us to give that up you need to give us a good reason. Just saying that something is a general recommendation is not good enough.
If, on the other hand, you design and implement an Apache module that identifies session IDs and produces hashed versions that can be used for logging, we'll be more than happy to use it. :)
In "real life" the circle of trust regarding WHO has access to your log file data is a lot larger than you expect. What happens when a developer needs to review the production log file? Or you get audited and the auditors need to review your logs? Or a new admin gets hired to assist you?
I advise that you do NOT log session id's in Apache. Let the application-level logs do it - via hashed session ids.
This is not theory, this is how I run in production.
Sure we can debate this recommendation. But at the very least, Ivan, do not start a application security blog and recommend logging session ids.
I see what Ivan is getting at, logging sessionIDs would enable things like anomaly tracking and blocking users. However, the reality is that most applications are not performing these types of advanced security analysis. In addition, logs are often accessible by other users than just root (cron jobs archive logs elsewhere, backup data etc).
So I think we should go with the message of secure by default and not log the sessionIDs. The exception is if your application is taking advantage of these advance features, you understand the risk of a compromised session ID, and you have good steps in place to control who can access the logs.
Rock on, Mr. Coates.
As a side note, I know Johannes personally and dropped him a line to get his personal reaction to my blog post. His answer made me smile, big time.
"it was shot from the hip in true street fighter style. No harm done and I can take it :)"
+1 Johannes!
Selectively logging the session ID if required for legal (where is the bar for non-repudation?) or forensics purposes is probably okay. In many environments this can be done on [app] servers that are not directly exposed to application users, which is an important risk mitigating control I think. web servers logs tend to get used for all sorts of other stuff (marketing, etc) and not treated as confidential generally.
Perhaps it be lower risk if this information was logged by the application to a database instead? I don't mean a database running on the same web server, although I do believe that this is still better than writing to log files that tend to have other uses.
Hi Friend,! Congratulations for this nice looking blog. In this post everything about Web Development. I am also interested in latest news, Great idea you know about company background. Increasing your web traffic and page views Add, add your website in www.directory.itsolusenz.com
фото галерея порно малолетки http://free-3x.com/ порно онлайн с молодыми free-3x.com/ порно онлайн молоденькие подростки [url=http://free-3x.com/]free-3x.com[/url]
Post a Comment