| 1 |
lars |
1 |
03 July 2004
|
|
|
2 |
|
|
|
3 |
TODO
|
|
|
4 |
* Session fixation attack (BUG #2021)
|
|
|
5 |
* Fix multiple open windows and challenge responce cookies (use a list of cookies which are allowed)
|
|
|
6 |
|
|
|
7 |
Since Auth 1.3 new security functionality has been added.
|
|
|
8 |
The main purpose for these advanced security checks is to avoid man-in-the-middle attacks and
|
|
|
9 |
session hijacking.
|
|
|
10 |
|
|
|
11 |
|
|
|
12 |
Session hijacking example
|
|
|
13 |
- Login to an Auth protected page. Write down the session id (should be something like PHPSESSID=36916b0aa1180386010f304b6160e3e8)
|
|
|
14 |
- Open a different browser (FireFox <> IE), or a browser on a different computer
|
|
|
15 |
- Type down the address of the secure page and add ?PHPSESSID=36916b0aa1180386010f304b6160e3e8 where
|
|
|
16 |
PHPSESSID is the php session name and 36916b0aa1180386010f304b6160e3e8 is the valid session id which you wrote down earlier
|
|
|
17 |
- You should be logged in with the same creditentials
|
|
|
18 |
|
|
|
19 |
|
|
|
20 |
|
|
|
21 |
To enable the advanced scurity checks you have to call
|
|
|
22 |
$auth->setAdvancedSecurity();
|
|
|
23 |
|
|
|
24 |
If this has been enabled the following security checks will be performed
|
|
|
25 |
|
|
|
26 |
- Login screen will use md5 when submitting the password if java script is enabled in the browser
|
|
|
27 |
- If user ip address has been changed betwin requests the user will be logged out
|
|
|
28 |
- If user User-Agent string has been changed the user will be logged out
|
|
|
29 |
- If user does not provide a valid auth challenge cookied he will be logged out (read below for explanation)
|
|
|
30 |
|
|
|
31 |
Limitations
|
|
|
32 |
* Challenge responce cookies would not allow a user to open multiple windows of the same page (Open in new window/tab). If
|
|
|
33 |
the user accesses the protected area from two browser windows he will be logged out. It can also create a problem if you
|
|
|
34 |
create dynamic images with php and that code passes through the auth layer. One way to avoid it is to disable advanced security for
|
|
|
35 |
those pages only selectively.
|
|
|
36 |
* Password saving does not work with login screens which use challenge responce (md5 hashing) of password
|
|
|
37 |
* Challenge responce on login only works with DB container and plain or md5 hashing
|
|
|
38 |
|
|
|
39 |
|
|
|
40 |
|
|
|
41 |
|
|
|
42 |
Challenge Responce cookies
|
|
|
43 |
|
|
|
44 |
|
|
|
45 |
The challenge responce cookies provide a way to avoid most of the session hijacking problems. Since User-Agent headers
|
|
|
46 |
and IP address can be spoofed, or in the case of IP a proxy can be used an extra security step has been added using a
|
|
|
47 |
challenge cookie.
|
|
|
48 |
|
|
|
49 |
After the user is authenthicated by Auth he is presented with a challenge cookie. For his next request to be succesfull
|
|
|
50 |
he must present that cookie on his next request. If that is successfull he will be presented with a new
|
|
|
51 |
challenge cookie. This will be reapeated for each request the user makes.
|
|
|
52 |
|
|
|
53 |
While this method is not fool proof it does limit the possibilities for an attack.
|
|
|
54 |
First the attacker must must obtain the challenge cookie and use it before the user does.
|
|
|
55 |
If the user makes a request after the attacker the session will be logged out and both of them
|
|
|
56 |
will need to login again.
|
|
|
57 |
|
|
|
58 |
A problem which this scheme does not address well is users leaving their sessions without preforming a logout
|
|
|
59 |
in this case the attacker is free to abuse the user session (provided he has met all the prerequisites).
|
|
|
60 |
|
|
|
61 |
Ideas and sujestions for improvements are more than welcome.
|
|
|
62 |
send to yavo@siava.org
|
|
|
63 |
|