Session Security

hashing algorithms--------------------------------------------

---

• A hash algorithim acts as a digital signature for data.
  
  
• Hash alogrithims are programs that read in data and calculate a "score" for that data.
  
  
• Simple example:
  
• I publish the fact that my name is "garth" and tell you that you can verify it by computing it's hash score. It should be 54
• how did i get 54?
• i used a weak hash algorithim that assigns each letter a numerical value.

• g = 7 a = 1 r = 18 t = 20 h = 8 7+1+18+20+8 = 54
• You are told that my name is garth and my hash is 54.
• You can verify yourself whether garth has a hash of 54.

A real hash algorithm is much more advanced, but works on the same principle.

• Hash algorithms are "one way streets". You can't go from 54 to garth.
  
  
• Other strings have the same value. Eg. goyd also = 54. This is called a collision.

• MD5 is a popular hash algorithm http://www.php.net/downloads.php
• for more details: http://www.secure-hash-algorithm-md5-sha-1.co.uk/

Hash Checking Example:


The website asserts the following:

• PHP 5.1.4 (tar.bz2) [6,207Kb] - 04 May 2006
  md5: 66a806161d4a2d3b5153ebe4cd0f2e1c
  
  
• How can we check if MD5 is correct?

1. download the file
2. Run this script
   $string=file_get_contents("php-5.1.4.tar.bz2");
   echo md5($string);

• PHP has a function which allows you to compute the MD5 digest ("hash value"):
• http://www.php.net/manual/function.md5.php
  
  
• The SHA1 (secure hash algorithm) leads to fewer collisions.
• http://www.php.net/manual/en/function.sha1.php

Session Security----------------------------------------

• Most PHP applications use sessions.
  
  
• HTTP is stateless. Sessions maintain state (authentication/remembering previous requests)
  
  
• Client must identify itself
  
  
• Web developers should not blindly trust the clients identification!
  
  
• There is no foolproof solution to guarantee the client is who they claim.
  

Session attacks: impersonation (session hijacking), session guessing, session discovery.

• You cannot uniquely identify visitors using an IP address.
• HTTP proxy: many users have the same IP address
• AOL proxy load balancing: user presents different ip address with each request
  
  
• You must use HTTP information to identify clients.
  
  
• The most common solution is the cookie.

The session id created by PHP by default is very long (32 alphanumeric characters...36^32 combinations = 63340286662973277706162286946811886609896461828096 combinations)

• Hard to "guess". But we can still make it harder, or at least take a long time.
  
  
• We should focus on making the session ID hard to "discover"(since guessing is already so difficult).
  
  
• GET data (in the URL) is more visible that cookie data. It can be cached, bookmarked, emailed or simply seen and captured by an intruder.
  
  
• Cookies may be disabled, stolen (since they are just files stored on a hard drive), or leaked (some older browsers had flaws in their security).
  
  
• Session ID's are more likely to be discovered than guessed.

Consider this example script:

• This session ID is explicitly set to 'HELLO88'. Every visitor to this site knows the session ID and "looks the same" to the PHP script.
  
  
• Web developers want to make sessions as easy and transparent for "the good guys" as possible, and as difficult for the "bad guys" as possible.
  
  
• Make the security as transparent as possible, but security must take precedence over convenience.
  
  
• If extra security is necessary, use it, even if it makes life harder for legitimate users.

Make the following settings in your php.ini file:

• session.use_cookies = 1
• session.name = PHPSESSID
• session.cookie_lifetime=3600 //1 hour
• session.use_trans_sid=0
• session.save_path="c:/windows/temp" or
• session.save_path="/tmp"

The session Id is called "PHPSESSID" for the server setup mentioned above.

• Good guy visits and creates a session (ID is abcd). Stores session information and gets authenticated.
  

• Bad guy guesses/discovers session ID of abcd, visits displaySessionInfo.php?PHPSESSID=abcd with cookies disabled:

• Hacker now has full access to the session. The output for both users is:

???

HTTP overview

• When a web browser send a request to a server, it typically presents the following data to the server:
• Request method (get or post) and protocol (1.0 or 1.1)
• Document name (e.g. index.php)
• Server name (e.g. example.com)
• Request parameters (e.g. firstname = garth)
• Browser type, version, and platform ("user agent") (can be spoofed successfully)
• Cookies previously set by the server
  
  

Session Hijacking

• To prevent guessing of the session ID (e.g. abcd), let PHP create it's own 32 character id, but...
• To prevent faking of the session ID, check MORE that just the ID; check the User Agent and other $_SERVER-accessible variables, in addition to the ID.
  
  
• Visitors presenting the same session ID should also be presenting the same user agent etc... each request too; it should not change between requests.
  
  
• Store the user agent in a session variable and compare it against the $_SERVER version.
  
  
• Can use the Message Digest Number 5 digest or US Secure Hash Algorithm 1 instead of the entire user agent. Both of these "encryptions" are secure; the latter has fewer potential collisions (i.e. use sha1 instead of md5)