Yes, I will talk in this article about why it is not good to leave your session files in /tmp. But first, allow me to follow Jason's lead and talk about the session attacks he discussed in Part 2 of his ASP.NET article. I will keep it short :)
Session fixation isn't really that much of a problem as long as you stick with a few simple principles. Remember we called this blog "App Sec Streetfighter"? It's about simple and reproducible techniques that work while under attack. So lets keep it simple:
- Use only cookies to transport the session token. This considerably raises the bar on session fixation. The attacker now has to set a cookie which isn't easy at all.
- Change the session ID whenever the users state changes (logged in vs. logged out).
- Change the session ID every so ...
In Session Attacks and ASP.NET - Part 1, I introduced one type of attack against the session called Session Fixation as well as ASP.NET's session architecture and authentication architecture. In this post, I'll delve into a couple specific attack scenarios, cover risk reduction, and countermeasures.
Attack Scenario: ASP.NET Session with Forms Authentication
So understanding the decoupled nature of ASP.NET's session management from the authentication mechanisms outlined in the previous post
, let's walk through two different session fixation attempts with Forms Authentication and session management.
Scenario 1: Attacker does not have a Forms Authentication Account
- Attacker browses target web site and fixates a session
This blog is of course inspired by Jason's ASP .Net blog. I figured as the PHP guy in the group, I may as well cover what he did for .Net from the PHP side.
PHP's default session mechanism is rather simple and effective. The php.ini file configures how sessions work. Many of the parameters can be overridden within your PHP code, or .htaccess files can be used to create more fine grained configurations for particular directories. The session module is part of PHP by default, but can be disabled at compile time. By default, the session data is saved in files. The directory the session data is stored in is again configured in php.ini and defaults to /tmp (not the best choice, but more about that in a later blog).
Much of the session module can be adjusted, or custom code can be used to store session data in a database.
Like Jason noted for .Net, sessions and authentication are two different things in PHP as well. It is up to the developer to use sessions to store
I've spent some time recently looking for updated information regarding session attacks as they apply to ASP.NET and am still not completely satisfied with how Microsoft has decided to implement session management in ASP.NET 2.0+ (haven't looked at 4.0 beta yet).
Before illustrating how a specific attack works with some specific countermeasures for ASP.NET (in Part 2), it's important to understand the Session and Authentication architectures in ASP.NET.
ASP.NET Session Architecture
Session state is setup and maintained through an HTTP Module. If the ASP.NET web.config file is setup to enable session stae, the this HTTP Module kicks into gear and the first time the web application uses the session object and the user doesn't already have a session, the ASP.NET Session module will drop a cookie on the client or do some URL rewriting to put the Session ID in ...