Simple Question: Session Security
Moderator: General Moderators
Simple Question: Session Security
I'm storing a few things in a session. My question is, do I have to sanitize this data?
Is it possible to corrupt or poison a session?
(Assume that I'm using this in a DB query.)
Is it possible to corrupt or poison a session?
(Assume that I'm using this in a DB query.)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
If the data comes from an untrusted source, then yes. It does not matter by which route the data gets to where there an exploit can occur. Indirect routes, such as from the request to the session and then into a SQL statement, are the hardest to trace. That is why Defense in Depth is the best practice.
(#10850)
No, you don't.
Your session handling code should take care of that - whether it's the default file-based sessions (which can take anything, so no additional measures are needed) or your custom DB-based code.
While arborint is correct in depicting some of the dangers, he is not correct in the solution. I'll give you an easy explanation: how would you prevent SQL injection and XSS by pre-sanitizing the data kept in the session. Would you first mysql_real_escape_string() and then htmlentities() or the other way around? Would John O'Brian be inserted in the database as John O'Brian, or would his name be displayed as John O\'Brian?
When you need to put the data - any data - in the database, escape it as appropriate for database usage.
When you need to put the data - any data - in the output html, escape it as appropriate for html usage.
Anything else is not defense in depth, but a data flow bug, not any different than using magic_quotes.
Your session handling code should take care of that - whether it's the default file-based sessions (which can take anything, so no additional measures are needed) or your custom DB-based code.
While arborint is correct in depicting some of the dangers, he is not correct in the solution. I'll give you an easy explanation: how would you prevent SQL injection and XSS by pre-sanitizing the data kept in the session. Would you first mysql_real_escape_string() and then htmlentities() or the other way around? Would John O'Brian be inserted in the database as John O'Brian, or would his name be displayed as John O\'Brian?
When you need to put the data - any data - in the database, escape it as appropriate for database usage.
When you need to put the data - any data - in the output html, escape it as appropriate for html usage.
Anything else is not defense in depth, but a data flow bug, not any different than using magic_quotes.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Hmm, I may be wrong in calling it a "solution" then, but you did give an answer.
I challenge your oppinion that you need to sanitize session data, and I explained that in my view it is a bug. I can't see a sensible way in which to escape the data without causing a problem somewhere. Can you give an example what would you do to session data?
Edit: Oh, wait, maybe we have a terminology disagreement. Does "sanitize" mean "escape" (like in mysql_real_escape_string()) or "validate" (like in "if (strlen($_GET['a'])>56) ...")
I challenge your oppinion that you need to sanitize session data, and I explained that in my view it is a bug. I can't see a sensible way in which to escape the data without causing a problem somewhere. Can you give an example what would you do to session data?
Edit: Oh, wait, maybe we have a terminology disagreement. Does "sanitize" mean "escape" (like in mysql_real_escape_string()) or "validate" (like in "if (strlen($_GET['a'])>56) ...")
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I used the OP's term sanitize, by which I meant filter and validate. Escaping would be done only at the point that the SQL was being created -- (and possible filtering and validating as well). That is assumed to be just before the query, but you could technically save the SQL in the session for some reason.
The point of Defense in Depth is that at every level and in every subsystem you take appropriate security measures, and do not assume that a higher level has done them. That would help against untrusted values going to the session and then to the database ... with the programmer assuming that data in the session was ok (e.g. not an untrusted superglobal).
The point of Defense in Depth is that at every level and in every subsystem you take appropriate security measures, and do not assume that a higher level has done them. That would help against untrusted values going to the session and then to the database ... with the programmer assuming that data in the session was ok (e.g. not an untrusted superglobal).
(#10850)
feyd | Please use
The default allowed characters are pretty lenient, but strip things like quotation marks and double quotes. The others are when I'm expecting to get specific data back.
This is good for most things, IMO, but can be annoying for users writing into a 'Notes' section. That's fine for my current application.
feyd | Please use
Code: Select all
,Code: Select all
and [syntax="..."] tags where appropriate when posting code. Your post has been edited to reflect how we'd like it posted. Please read: [url=http://forums.devnetwork.net/viewtopic.php?t=21171]Posting Code in the Forums[/url] to learn how to do it too.[/color]
This is the function I use most of the time:Code: Select all
define('NUMBERS_ONLY', "[^0-9 ]");
define('LETTERS_ONLY', "[^a-zA-Z ]");
define('NUMBERS_AND_LETTERS', "[^0-9a-zA-Z ]");
function FxSanitize($original_string, $allowed_chars = "[^a-zA-Z0-9_,. -]")
{
return ereg_replace($allowed_chars, "", $original_string);
}This is good for most things, IMO, but can be annoying for users writing into a 'Notes' section. That's fine for my current application.
feyd | Please use
Code: Select all
,Code: Select all
and [syntax="..."] tags where appropriate when posting code. Your post has been edited to reflect how we'd like it posted. Please read: [url=http://forums.devnetwork.net/viewtopic.php?t=21171]Posting Code in the Forums[/url] to learn how to do it too.[/color]- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
Session Fixation PDF is an interesting read.