Skip to main content
R
RichardODreamweaver
Inspiring
July 14, 2008
Answered

Hacking Session Variables??

  • July 14, 2008
  • 2 replies
  • 527 views
I have a php MySQL CRM site with plenty of sensitive information..

To protect this, I have a session based login system.

Login page - checks password and assigns Username, UserGroup and Workgroup to session variables.

Restricted pages - checks usergroup access level and workgroup id.

I have heard that, if a hacker re-writes the cookie (didn't know sessions created a cookie) he can fool the server into thinking that he is using someone elses session and could therefore view, edit and delete those records normally protected.

I know that Session data cannot be viewed or amended but this could pose a huge security issue.

It has also been suggested that the user has to re-enter his password on each page but this is both unusual and would be a real pain for the user.

Is there a simple way round this?
This topic has been closed for replies.
Correct answer Newsgroup_User
.oO(RichardODreamweaver)

>I have a php MySQL CRM site with plenty of sensitive information..
>
> To protect this, I have a session based login system.
>
> Login page - checks password and assigns Username, UserGroup and Workgroup to
>session variables.
>
> Restricted pages - checks usergroup access level and workgroup id.
>
> I have heard that, if a hacker re-writes the cookie (didn't know sessions
>created a cookie)

The session ID can also be appended to the URLs, but using a cookie is
the preferred and considered the more secure way.

>he can fool the server into thinking that he is using someone
>elses session and could therefore view, edit and delete those records normally
>protected.

Just some keywords for further reading:

Hijacking a session by stealing the cookie usually requires an XSS
attack (cross-site scripting). Try Wikipedia or Google for details and
how to prevent that problem. This should be the first task, because XSS
vulnerabilities are quite common and often the basis for many other
kinds of attacks, including the following.

Another not so known attack is called session fixation. The following
paper goes quite into detail about it:

http://www.acros.si/papers/session_fixation.pdf

> I know that Session data cannot be viewed or amended but this could pose a
>huge security issue.
>
> It has also been suggested that the user has to re-enter his password on each
>page but this is both unusual and would be a real pain for the user.

Agreed. The user would never come back. But it's quite common in bigger
systems that the user has to re-enter the password before performing a
critical action, for example before placing an order in a web shop or
when changing his personal data.

> Is there a simple way round this?

Security is never simple. It just depends on how much security is
needed.

Micha

2 replies

R
RichardODreamweaverAuthor
Inspiring
July 15, 2008
Thanks Micha - helpful as always.

Couple of questions. I have a friend who knows quite a bit about this and he has shown me an example of entering a javascript command into the address bar and amending the session id; however, he had to know what the session id was before he could do anything with it! - What are the chances? As my session id's are handled server-side, I can't see how this can be accessed.

I have thought of a potential simple solution...

Capture the IP on Login and commit to session variable. This can then be checked against current IP for each page.

if session ip <> current IP - gotcha!

Or are there ways round this?

I'm beginning to think that, for a site my size, this issue probably isn't a problem.
N
Newsgroup_UserCorrect answer
Inspiring
July 15, 2008
.oO(RichardODreamweaver)

>I have a php MySQL CRM site with plenty of sensitive information..
>
> To protect this, I have a session based login system.
>
> Login page - checks password and assigns Username, UserGroup and Workgroup to
>session variables.
>
> Restricted pages - checks usergroup access level and workgroup id.
>
> I have heard that, if a hacker re-writes the cookie (didn't know sessions
>created a cookie)

The session ID can also be appended to the URLs, but using a cookie is
the preferred and considered the more secure way.

>he can fool the server into thinking that he is using someone
>elses session and could therefore view, edit and delete those records normally
>protected.

Just some keywords for further reading:

Hijacking a session by stealing the cookie usually requires an XSS
attack (cross-site scripting). Try Wikipedia or Google for details and
how to prevent that problem. This should be the first task, because XSS
vulnerabilities are quite common and often the basis for many other
kinds of attacks, including the following.

Another not so known attack is called session fixation. The following
paper goes quite into detail about it:

http://www.acros.si/papers/session_fixation.pdf

> I know that Session data cannot be viewed or amended but this could pose a
>huge security issue.
>
> It has also been suggested that the user has to re-enter his password on each
>page but this is both unusual and would be a real pain for the user.

Agreed. The user would never come back. But it's quite common in bigger
systems that the user has to re-enter the password before performing a
critical action, for example before placing an order in a web shop or
when changing his personal data.

> Is there a simple way round this?

Security is never simple. It just depends on how much security is
needed.

Micha
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices