php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #17597 user supplied SID is given trust
Submitted: 2002-06-04 11:50 UTC Modified: 2002-06-05 15:11 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: Giancarlo at navigare dot net Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.2.1 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: Giancarlo at navigare dot net
New email:
PHP Version: OS:

 

 [2002-06-04 11:50 UTC] Giancarlo at navigare dot net 
How is it possible that if a user provides a session in the URL, eg. mypage.php?PHPSESSID=spoofme
even though php.ini says 
session.use_cookies =1

The session id is taken from the URL (but wasn't that the supposed behaviour of session.use_cookie=0 ?) and a session named 'spoofme' is created.
Is it possible that is given trust to user input just on a paramount sensitive issue as the session ID?
Would you run a cinema where you have to accept tickets issued by nobody-knows-who?

This gravious security issue has been mentioned more than a year ago in the 'A study in scarlet' classical on php weaknessses, and it leads to nasty url injections and session hijacking.
I am afraid this bus is a great feature for someone.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-05 11:32 UTC] snowgod at snowgod dot org 
IMHO, fixing this does not solve the problem. If a cracker REALLY wants to fake a session, he could fake the cookie as well. 

Perhaps storing two seperate variable (either in the path, or in cookies), a session id and a authentication hash of some kind. I would think that this would make session spoofing lot harder, because the cracker would have to guess both the correct session id, and the correct authentication hash.

Just my 2 cents.
 [2002-06-05 13:13 UTC] Giancarlo at navigare dot net 
This hole does not need a cracker, but any computer illiterate, as my or your boss, can do it.

Why do we use md5 of uniqid of secret words to generate a sid, when anyone can force his own simply opening an URL?
 [2002-06-05 14:15 UTC] Giancarlo at navigare dot net 
You know what? I know had a series ot test on zend site, ad it doesn't quite work like this.
They must have a 'fortified' version of PHP there.
 [2002-06-05 14:36 UTC] sniper@php.net 
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php

Thank you for your interest in PHP.

What use it would be to spoof the session id??
It only would make sense if you know what ids are currently
in use at the site. Of course you could always try the all
possible combinations there can be. :)
 [2002-06-05 15:11 UTC] Giancarlo at navigare dot net 
Someone can induce someone else in clicking on a link, maybe in an email message. And later enter that session. This is the easiest usage, but there can be many others.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 06:01:35 2024 UTC