Dear All,

What I was wondering is how safe it is to store user_id or username or
anything like that in session. I usualy store a bunch of info in a
session so I do not need to search the database all the time. However,
is it easy to change a value after being logged in?

For example:
- A user logs in
- Now set is: $_SESSION["user_id"] = 34;
- If he opens his "Profile page", the websites collects all personal
information from table users where user_id = 34

But according to this article:
http://www.governmentsecurity.org/archive/t13901.html

It is easy to change $_SESSION["user_id"] to for example 78.
So, that means that once you are logged in and change your own
user_id, you can see personal information from other users.


Is this really possible? If so, I can imagine I would use a temporary
table with temporary hashes where user_ids will be stored next to a
temporary hash. However, this is much more work and database traffic
which will slow down the system dramatically.

So... Is $_SESSION["user_id"] = 34 safe enough?

Kind regards,


Pim Zeekoers

pim@impulzief.nl wrote:
> Dear All,
>
> What I was wondering is how safe it is to store user_id or username or
> anything like that in session. I usualy store a bunch of info in a
> session so I do not need to search the database all the time. However,
> is it easy to change a value after being logged in?
>
> For example:
> - A user logs in
> - Now set is: $_SESSION["user_id"] = 34;
> - If he opens his "Profile page", the websites collects all personal
> information from table users where user_id = 34
>
> But according to this article:
> http://www.governmentsecurity.org/archive/t13901.html

Hi,

I think you didn't read that article right.

I think you refering to this part. Is that right?
<quote>

2. Bypassing Session

OVERRIDING BASIC SESSION AUTHENTICATION

Most of the time session handling is done with the use of . The
tell the webpage who you are and what you have access to and
what you don't have access to. If the page does not handle session
correctly a hacker might be able to change their identity to
that of another user's. are stored in "window.document.".
With javascript we are able to erase,edit,create for any
website. This task is more complicated than regular types of attacks. I
will not go into great detail about how it's done.

To View the :
javascript:alert(unescape(document.));

<snipped>

So If You are logged in as "John Doe" in www.ima13370h4x0r.net and
your session reads:


SessionData=a:3:{s:11:"SessionUser";s:5:"75959";s: 9:"SessionID";i:70202768;s:9:"LastVisit";i:1078367 189;}

The is actually serialized but you should be able to recognize
"75959" as your user_id. Some of the time you will find a website that
stores data (like user_id) in but does not typecast the data.
This is a serious hole in the site's code because any user is able to
change their user_id to any other user or administrator user_id.

Changing the value is easy once you have declared the window.c
function. First change s:5:"75959" to s:x:"ADMINID" where x is the
length of the new value. So if you want to change 75959 to 1. You must
change s:5:"75959" to s:1:"1" :-) Sometimes you will need to change
75959 to "13 or 1=1" in order to bypass any WHERE statements any sql
session queries used to keep you logged in the website.

</quote>


>
> It is easy to change $_SESSION["user_id"] to for example 78.

No, it is NOT easy.
The article describes the , which is NOT the session.

Only idiots store sensitive information into a . So what is
described in the article only works for bad php scripts.

With Firefox for example, you can view/delete/modify each and every
very simple.

PHP uses the ONLY to pass around a string named PHPSESSID.
That string is used by PHP in subsequent requests to identify the user.
The actual information stored in a file on the server, NOT on the client.

So if my php script decides to put this in your session:
$_SESSION["youneverknow"] = 42;

a visitor has no clue it is there, since this information is NEVER send
to the client. Only the PHPSESSID is send.

So to hijack a session, which IS possible but a lot harder, you need to
know the value of PHPSESSID of somebody else.



> So, that means that once you are logged in and change your own
> user_id, you can see personal information from other users.

Yes, in the stupid setup described, that is possible.
Any PHP programmer with any experience won't do it in that way.

Regards,
Erwin Moller


>
>
> Is this really possible? If so, I can imagine I would use a temporary
> table with temporary hashes where user_ids will be stored next to a
> temporary hash. However, this is much more work and database traffic
> which will slow down the system dramatically.
>
> So... Is $_SESSION["user_id"] = 34 safe enough?
>
> Kind regards,
>
>
> Pim Zeekoers

> For example:
> - A user logs in
> - Now set is: $_SESSION["user_id"] = 34;
> - If he opens his "Profile page", the websites collects all personal
> information from table users where user_id = 34
>
> But according to this article:
> http://www.governmentsecurity.org/archive/t13901.html
>
> It is easy to change $_SESSION["user_id"] to for example 78.
> So, that means that once you are logged in and change your own
> user_id, you can see personal information from other users.


I did not see that example. The part of that page is very
unspecific, and has little to do with session .

Google for "session hijacking" and "session fixation" to find out more.

In short, it is possible to pass another session id, thus changing to
another session. There is one thing that prevents it:

Session IDs are rather large, and sessions do not live that long. So
switching over to a random other session requires an absurd quantity of
luck.

However, if you can intercept the http traffic, you can mess up as much
as you like. You can send regular requests to the webserver with a
to keep that session open.
If you build the site on https instead of http, the will be
encrypted also.

A "real" session only has an ID to a session, not live data. That
data remains on the server if you do not send it to the client. In fact,
I think the session is safe to store real IDs, but parameters are not.
So I usually hash all IDs before using them for client communication.

Best regards

pim wrote:

> But according to this article:
> http://www.governmentsecurity.org/archive/t13901.html
>
> It is easy to change $_SESSION["user_id"] to for example 78.

That article is a bunch of crap. PHP does not keep track of session data
in a manner anything like the one described there.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 17 days, 22:28.]

Gnocchi all'Amatriciana al Forno
http://tobyinkster.co.uk/blog/2008/0...llamatriciana/

On 17 jan, 12:01, Dikkie Dik <dik...@nospam.org> wrote:
> > For example:
> > - A user logs in
> > - Now set is: $_SESSION["user_id"] = 34;
> > - If he opens his "Profile page", the websites collects all personal
> > information from table users where user_id = 34
>
> > But according to this article:
> >http://www.governmentsecurity.org/archive/t13901.html
>
> > It is easy to change $_SESSION["user_id"] to for example 78.
> > So, that means that once you are logged in and change your own
> > user_id, you can see personal information from other users.
>
> I did not see that example. The part of that page is very
> unspecific, and has little to do with session .
>
> Google for "session hijacking" and "session fixation" to find out more.
>
> In short, it is possible to pass another session id, thus changing to
> another session. There is one thing that prevents it:
>
> Session IDs are rather large, and sessions do not live that long. So
> switching over to a random other session requires an absurd quantity of
> luck.
>
> However, if you can intercept the http traffic, you can mess up as much
> as you like. You can send regular requests to the webserver with a
> to keep that session open.
> If you build the site on https instead of http, the will be
> encrypted also.
>
> A "real" session only has an ID to a session, not live data. That
> data remains on the server if you do not send it to the client. In fact,
> I think the session is safe to store real IDs, but parameters are not.
> So I usually hash all IDs before using them for client communication.
>
> Best regards

Thanks for your reply!
I now understand I must have confused and session.

How does your suggestion on hashing ids work?

Like this: profilepage.php?uid=7sy6fsnyfm984oym3oyowiuyrowr43 2
and server side: SELECT * FROM users WHERE md5(users.user_id) =
$uid;

Or more like this: SELECT * FROM users WHERE users.uidhash = $uid;


Kind regards,


Pim

> How does your suggestion on hashing ids work?

I keep a list of known hashes in the session, say $_SESSION['known_hashes'].

If I have an ID that the user has to choose from, I pass the hash of
that ID and store it along with the ID in that list. So if a user can
choose from a set of bank accounts to work on, the HTML shows something
like:
<select ...>
<option value="sKbSKHgrsjbrvsrb2497wkj">First account</option>
...
</select>

When I process the result, I look up the hash in
$_SESSION['known_hashes'] to find what ID belongs to it.

This has e a few advantages:
- No unnecessary database info is ever sent to the client,
- Only hashes are known that belong to that user, so even a brute force
guesswork will only yield the possibilities that the user would have anyway.

My hashing system hashes per table, so you cannot abuse a userID as an
accountID, for example.

> Like this: profilepage.php?uid=7sy6fsnyfm984oym3oyowiuyrowr43 2
> and server side: SELECT * FROM users WHERE md5(users.user_id) =
> $uid;
>
> Or more like this: SELECT * FROM users WHERE users.uidhash = $uid;


No. More like:

if(isset($_SESSION['known_hashes'][$accountParameter])):
$query = 'SELECT * FROM users WHERE user_id=' .
FromHash($accountParameter);
endif;

Regards

..oO(pim@impulzief.nl)

>Thanks for your reply!
>I now understand I must have confused and session.

It's not your fault. The entire article is just crap.

Micha

On Jan 17, 3:32 pm, p...@impulzief.nl wrote:
> Dear All,
>
> What I was wondering is how safe it is to store user_id or username or
> anything like that in session. I usualy store a bunch of info in a
> session so I do not need to search the database all the time. However,
> is it easy to change a value after being logged in?
>
> For example:
> - A user logs in
> - Now set is: $_SESSION["user_id"] = 34;
> - If he opens his "Profile page", the websites collects all personal
> information from table users where user_id = 34
>
> But according to this article:http://www.governmentsecurity.org/archive/t13901.html
>
> It is easy to change $_SESSION["user_id"] to for example 78.
> So, that means that once you are logged in and change your own
> user_id, you can see personal information from other users.
>
> Is this really possible? If so, I can imagine I would use a temporary
> table with temporary hashes where user_ids will be stored next to a
> temporary hash. However, this is much more work and database traffic
> which will slow down the system dramatically.
>
> So... Is $_SESSION["user_id"] = 34 safe enough?

1. Client machine's will contain only the session id--not
the data. So, directly accessing the session values by just looking at
the won't
2. But, can fix the session id by stuffing to . This way,
someone can use some other user's session id and can access to the
page--only if the default session handlers is used. Solution is to use
DB based session handler
3. If the files handler is used, one can access to the session
files (on shared host). So, for all shared host the solution is DB
based session handler

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

R. Rajesh Jeba Anbiah wrote:
> On Jan 17, 3:32 pm, p...@impulzief.nl wrote:
>> Dear All,
>>
>> What I was wondering is how safe it is to store user_id or username or
>> anything like that in session. I usualy store a bunch of info in a
>> session so I do not need to search the database all the time. However,
>> is it easy to change a value after being logged in?
>>
>> For example:
>> - A user logs in
>> - Now set is: $_SESSION["user_id"] = 34;
>> - If he opens his "Profile page", the websites collects all personal
>> information from table users where user_id = 34
>>
>> But according to this article:http://www.governmentsecurity.org/archive/t13901.html
>>
>> It is easy to change $_SESSION["user_id"] to for example 78.
>> So, that means that once you are logged in and change your own
>> user_id, you can see personal information from other users.
>>
>> Is this really possible? If so, I can imagine I would use a temporary
>> table with temporary hashes where user_ids will be stored next to a
>> temporary hash. However, this is much more work and database traffic
>> which will slow down the system dramatically.
>>
>> So... Is $_SESSION["user_id"] = 34 safe enough?
>
> 1. Client machine's will contain only the session id--not
> the data. So, directly accessing the session values by just looking at
> the won't
> 2. But, can fix the session id by stuffing to . This way,
> someone can use some other user's session id and can access to the
> page--only if the default session handlers is used. Solution is to use
> DB based session handler

A DB based session handler will not solve this problem.

> 3. If the files handler is used, one can access to the session
> files (on shared host). So, for all shared host the solution is DB
> based session handler
>

Not as big of a problem as someone else getting the session ID and
getting access to the user's session. Just getting a user ID from a
session in a file isn't going to do much good. And you shouldn't be
storing passwords in the session, anyway.

You also neglect that if you're on a shared host, chances are you will
not be able to implement db based sessions. At least not without a lot
of work. And if you're on a dedicated or virtual server, no one else
can access the file based sessions, anyway.

DB based sessions add little, if any, security.

> --
> <?php echo 'Just another PHP saint'; ?>
> Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
>


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Jan 19, 6:35 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> R. Rajesh Jeba Anbiah wrote:
<snip>
> > 2. But, can fix the session id by stuffing to . This way,
> > someone can use some other user's session id and can access to the
> > page--only if the default session handlers is used. Solution is to use
> > DB based session handler
>
> A DB based session handler will not solve this problem.

I mean, custom session handler with DB. It is easy to add
additional user agent, IP checks in dB based session handler.

> > 3. If the files handler is used, one can access to the session
> > files (on shared host). So, for all shared host the solution is DB
> > based session handler
>
> Not as big of a problem as someone else getting the session ID and
> getting access to the user's session. Just getting a user ID from a
> session in a file isn't going to do much good. And you shouldn't be
> storing passwords in the session, anyway.

Getting the real session ID's alone is sufficient for the session
fixation. Knowing the user ID is more useful to fix the session for
the particular user.

> You also neglect that if you're on a shared host, chances are you will
> not be able to implement db based sessions. At least not without a lot
> of work.
<snip>

No, you don't require any setting change. It's damn easy or just
find nice open source scripts.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

R. Rajesh Jeba Anbiah wrote:
> On Jan 19, 6:35 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> R. Rajesh Jeba Anbiah wrote:
> <snip>
>>> 2. But, can fix the session id by stuffing to . This way,
>>> someone can use some other user's session id and can access to the
>>> page--only if the default session handlers is used. Solution is to use
>>> DB based session handler
>> A DB based session handler will not solve this problem.
>
> I mean, custom session handler with DB. It is easy to add
> additional user agent, IP checks in dB based session handler.
>

Yes, I know what you mean. And on a shared host, you probably will not
be able to implement a db based session handler.

Additionally, IP checks are invalid. Many corporations have one proxy
to access the internet; all computers behind the firewall have the same
external address.

Additionally, some larger corporations and ISPs use multiple proxies;
each request can come from a different IP, even though it's a single
computer. AOL is famous for this.

>>> 3. If the files handler is used, one can access to the session
>>> files (on shared host). So, for all shared host the solution is DB
>>> based session handler
>> Not as big of a problem as someone else getting the session ID and
>> getting access to the user's session. Just getting a user ID from a
>> session in a file isn't going to do much good. And you shouldn't be
>> storing passwords in the session, anyway.
>
> Getting the real session ID's alone is sufficient for the session
> fixation. Knowing the user ID is more useful to fix the session for
> the particular user.
>

That's true. But it's only good for the life of the session.

>> You also neglect that if you're on a shared host, chances are you will
>> not be able to implement db based sessions. At least not without a lot
>> of work.
> <snip>
>
> No, you don't require any setting change. It's damn easy or just
> find nice open source scripts.
>

Yes, and then you need to implement additional code on each of your
pages - code which will be very server-dependent.

If the session information is that critical, get a VPS or dedicated
server. Don't use shared hosting.

> --
> <?php echo 'Just another PHP saint'; ?>
> Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
>


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:

> Additionally, some larger corporations and ISPs use multiple proxies;
> each request can come from a different IP, even though it's a single
> computer. AOL is famous for this.

Our office has about 70-80 workstations, hardly a large corporation, but
we have two ADSL lines (with different ISPs, for redundancy) and one SDSL
line coming into the building, all connected to a load-balancing router.
So requests from a single visitor in the office may well be distributed
between three IP addresses.

And that load-balancing router wasn't bespoke for us -- it's mass-produced.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 20 days, 11:00.]

Ham vs Bacon vs Pork
http://tobyinkster.co.uk/blog/2008/01/17/pork-etc/