Can SID be trusted?

Hi, I'm in the process of securing a PHP/MySQL website by making sure
all strings that can at least possibly be manipulated from the outside
are passed through the appropriate escaping functions and/or validated
against patterns. In the most canonical cases, SQL strings supplied from
the outside are handled by mysql_real_escape_string, HTML snippets by
htmlentities, GET parameters in query strings by rawencodeurl. What I'm
unsure about is whether SID needs to be treated. It's the variable used
most often, so I guess I could improve efficiency a bit by not adding
an escaping functions in snippets such as

">

Is there a known scenario in which an attacker could set SID to contain,
say, HTML that could then be used in an XSS attack?

Thanks for your opinions

Sebastian Lisken

Sebastian Lisken wrote:

Hi Sebastian,

> Hi, I'm in the process of securing a PHP/MySQL website by making sure
> all strings that can at least possibly be manipulated from the outside
> are passed through the appropriate escaping functions and/or validated
> against patterns. In the most canonical cases, SQL strings supplied from
> the outside are handled by mysql_real_escape_string,

Your app accepts complete SQL-commands from the outside?
Are you sure that is allright?
I mean, why bother to escape SQL, if I can simple fire a:
DELETE FROM tblusers;



HTML snippets by
> htmlentities, GET parameters in query strings by rawencodeurl. What I'm
> unsure about is whether SID needs to be treated. It's the variable used
> most often, so I guess I could improve efficiency a bit by not adding
> an escaping functions in snippets such as
>
> ">
>
> Is there a known scenario in which an attacker could set SID to contain,
> say, HTML that could then be used in an XSS attack?

No, not an XSS attack. The PHPSESSID is only used to maintain a session
with some client.
But in case you wrote your own sessionhandlers, you should take precautions.
If you use default sessions (file) don't worry.

Of course you should always worry about sessionstealing.
If person A gets the sessionid of person B, person A can pretend to be
person B for the duration of the session. (For more details see
sessionpages on www.php.net. The scenario is named 'session fixation'.)

Regards,
Erwin Moller

>
> Thanks for your opinions
>
> Sebastian Lisken
>

I wrote:
> > I also know that the session ID can be
> > transmitted via a query string parameter or via a cookie if the browser
> > permits it. I presume you know that SID reverts to an empty string in
> > the latter case.

Captain Paralytic wrote:
> Not what I have seen.

You can read http://php.net/manual/en/ref.session.php íf you need to be
convinced there. Now, could we get back to the subject? If you remember,
I'm wondering if SID can be manipulated by an attacker to contain
something that might need escaping when included in HTML such as in



Any opinions on that particular subject are more than welcome still, but
I'm beginning to believe that no escaping (i.e. "treating" the value with
rawurlencode or htmlentities) is required.

Sebastian

Sebastian Lisken wrote:
> I wrote:
>>> I also know that the session ID can be
>>> transmitted via a query string parameter or via a cookie if the browser
>>> permits it. I presume you know that SID reverts to an empty string in
>>> the latter case.
>
> Captain Paralytic wrote:
>> Not what I have seen.
>
> You can read http://php.net/manual/en/ref.session.php íf you need to be
> convinced there. Now, could we get back to the subject? If you remember,
> I'm wondering if SID can be manipulated by an attacker to contain
> something that might need escaping when included in HTML such as in
>
>
>
> Any opinions on that particular subject are more than welcome still, but
> I'm beginning to believe that no escaping (i.e. "treating" the value with
> rawurlencode or htmlentities) is required.
>
> Sebastian
>
>

You're correct that SID is not set if the session id was stored in a
cookie. However, the question is - why are you even doing this? If
properly configured, PHP handles sessions quite well. All you need to
do is issue a session_start() at the beginning of each page where you
use sessions.

And sure, anything CAN be manipulated - theoretically. But the default
PHP session id is a long alphanumeric string. It would be virtually
impossible to manipulate it unless you were somewhere in the path
between the client and the server. And not even then if it's a secure
connection.

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

Jerry Stuckle wrote:
> You're correct that SID is not set if the session id was stored in a
> cookie. However, the question is - why are you even doing this? If
> properly configured, PHP handles sessions quite well. All you need to
> do is issue a session_start() at the beginning of each page where you
> use sessions.

This was in the code I took over, there are numerous examples like
>>

The obvious purpose is to pass on the session ID from one page
to the other. I hadn't done this before so I'm glad you're asking
about it. I have now read the section "Passing the Session ID" in
http://www.php.net/manual/en/ref.session.php and it says that the ID is
passed on transparently if session.use_trans_sid is enabled. I can only
guess that the code was developed in a context where it wasn't. As it
turns out, on my WAMP 5 installation it is disabled too. I've enabled
it, taken away the part from one of my links, and seen
the effect of the option. Thanks for educating me there, but with that
experience I'd say it's good practice not to rely on the option (I don't
even know what the setting is on the production server that my work will
be transferred to, but the site has switched servers before so I don't
want to rely on the setting there anyway).

> And sure, anything CAN be manipulated - theoretically. But the default
> PHP session id is a long alphanumeric string. It would be virtually
> impossible to manipulate it unless you were somewhere in the path
> between the client and the server. And not even then if it's a secure
> connection.

If you're bringing in direct manipulation of HTTP packets somewhere
between the server and client then of course everything is possible (as
you say, SSL would be the counter-measure of choice but it's not in use
here). So if we have to go that far to construct an attack on SID then
it's probably not something I should worry about. Password sniffing would
be the more likely thing an attacker would do if they could intercept
HTTP communications at all.

Thanks

Sebastian

Sebastian Lisken wrote:

> guess that the code was developed in a context where it wasn't. As it
> turns out, on my WAMP 5 installation it is disabled too. I've enabled

This is what the debian php5.ini says about use_trans_sid:

; trans sid support is disabled by default.
; Use of trans sid may risk your users security.
; Use this option with caution.
; - User may send URL contains active session ID
; to other person via. email/irc/etc.
; - URL that contains active session ID may be stored
; in publically accessible computer.
; - User may access your site with the same session ID
; always using URL stored in browser's history or bookmarks.
session.use_trans_sid = 0

So your opens your application
> to exactly the facts mentioned above as it mimics session_trans_sid.

No, my code doesn't make a difference.

Either cookies are enabled: then SID is an empty string and all that
"my" code (it's not mine) adds is the question mark (this is not
pleasing from a cosmetic point of view, but not the issue you mention)

Or cookies are not enabled: then it's *necessary* to use the HTTP
request to pass on the session ID, with all the risks you mention. If
GET parameters are used, this can be done either with "my" code or with
use_trans_sid, they have the same effect. If you say GET parameters
shouldn't be used, what is your alternative?

I *am* aware of the risks of session fixation and stealing. There's
no simple way to avoid them (cookies instead of GET parameters are not
perfect protection and not always available). I wasn't going to go into
that issue at first - hopefully I've made it clear what my specific
question was, but I'm rather confident about the answer to that by
now. So we can discuss attacks on the session (rather than on the
value of SID for XSS purposes) if you want. But please, let's not make
quick judgements based on short remarks in some php.ini file, but read
http://phpsec.org/projects/guide/4.html (which I had before I embarked
on this task) and move the discussion on from there.

Sebastian

Sebastian Lisken wrote:
> Jerry Stuckle wrote:
>> You're correct that SID is not set if the session id was stored in a
>> cookie. However, the question is - why are you even doing this? If
>> properly configured, PHP handles sessions quite well. All you need to
>> do is issue a session_start() at the beginning of each page where you
>> use sessions.
>
> This was in the code I took over, there are numerous examples like
>>>
>
> The obvious purpose is to pass on the session ID from one page
> to the other. I hadn't done this before so I'm glad you're asking
> about it. I have now read the section "Passing the Session ID" in
> http://www.php.net/manual/en/ref.session.php and it says that the ID is
> passed on transparently if session.use_trans_sid is enabled. I can only
> guess that the code was developed in a context where it wasn't. As it
> turns out, on my WAMP 5 installation it is disabled too. I've enabled
> it, taken away the part from one of my links, and seen
> the effect of the option. Thanks for educating me there, but with that
> experience I'd say it's good practice not to rely on the option (I don't
> even know what the setting is on the production server that my work will
> be transferred to, but the site has switched servers before so I don't
> want to rely on the setting there anyway).
>

I always rely on it. If your hosting company doesn't support it, get a
new hosting company. It's pretty standard in PHP. Every host I know of
has it enabled.


>> And sure, anything CAN be manipulated - theoretically. But the default
>> PHP session id is a long alphanumeric string. It would be virtually
>> impossible to manipulate it unless you were somewhere in the path
>> between the client and the server. And not even then if it's a secure
>> connection.
>
> If you're bringing in direct manipulation of HTTP packets somewhere
> between the server and client then of course everything is possible (as
> you say, SSL would be the counter-measure of choice but it's not in use
> here). So if we have to go that far to construct an attack on SID then
> it's probably not something I should worry about. Password sniffing would
> be the more likely thing an attacker would do if they could intercept
> HTTP communications at all.
>
> Thanks
>
> Sebastian
>
>


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

Christian Welzel wrote:
> Sebastian Lisken wrote:
>
>> guess that the code was developed in a context where it wasn't. As it
>> turns out, on my WAMP 5 installation it is disabled too. I've enabled
>
> This is what the debian php5.ini says about use_trans_sid:
>
> ; trans sid support is disabled by default.
> ; Use of trans sid may risk your users security.
> ; Use this option with caution.
> ; - User may send URL contains active session ID
> ; to other person via. email/irc/etc.
> ; - URL that contains active session ID may be stored
> ; in publically accessible computer.
> ; - User may access your site with the same session ID
> ; always using URL stored in browser's history or bookmarks.
> session.use_trans_sid = 0
>
> So your Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Sebastian Lisken wrote:
> Christian Welzel wrote:
>> This is what the debian php5.ini says about use_trans_sid:
>>
>> ; trans sid support is disabled by default.
>> ; Use of trans sid may risk your users security.
>> ; Use this option with caution.
>> ; - User may send URL contains active session ID
>> ; to other person via. email/irc/etc.
>> ; - URL that contains active session ID may be stored
>> ; in publically accessible computer.
>> ; - User may access your site with the same session ID
>> ; always using URL stored in browser's history or bookmarks.
>> session.use_trans_sid = 0
>
>> So your > pleasing from a cosmetic point of view, but not the issue you mention)
>
> Or cookies are not enabled: then it's *necessary* to use the HTTP
> request to pass on the session ID, with all the risks you mention. If
> GET parameters are used, this can be done either with "my" code or with
> use_trans_sid, they have the same effect. If you say GET parameters
> shouldn't be used, what is your alternative?
>

And if PHP is configured correctly, it will do this for you. No need to
do it yourself. All of my PHP sites work fine whether cookies are
enabled or disabled.

> I *am* aware of the risks of session fixation and stealing. There's
> no simple way to avoid them (cookies instead of GET parameters are not
> perfect protection and not always available). I wasn't going to go into
> that issue at first - hopefully I've made it clear what my specific
> question was, but I'm rather confident about the answer to that by
> now. So we can discuss attacks on the session (rather than on the
> value of SID for XSS purposes) if you want. But please, let's not make
> quick judgements based on short remarks in some php.ini file, but read
> http://phpsec.org/projects/guide/4.html (which I had before I embarked
> on this task) and move the discussion on from there.
>
> Sebastian
>
>


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

..oO(Sebastian Lisken)

>Christian Welzel wrote:
>> This is what the debian php5.ini says about use_trans_sid:
>>
>> ; trans sid support is disabled by default.
>> ; Use of trans sid may risk your users security.
>> ; Use this option with caution.
>> ; - User may send URL contains active session ID
>> ; to other person via. email/irc/etc.
>> ; - URL that contains active session ID may be stored
>> ; in publically accessible computer.
>> ; - User may access your site with the same session ID
>> ; always using URL stored in browser's history or bookmarks.
>> session.use_trans_sid = 0
>
>> So your >pleasing from a cosmetic point of view, but not the issue you mention)
>
>Or cookies are not enabled: then it's *necessary* to use the HTTP
>request to pass on the session ID, with all the risks you mention. If
>GET parameters are used, this can be done either with "my" code or with
>use_trans_sid, they have the same effect. If you say GET parameters
>shouldn't be used, what is your alternative?

Cookies. For sessions I _always_ require a cookie, I don't use URL-SIDs
anymore for the reasons mentioned above. Cookies are enabled by default
in most browsers, and people who are able to configure their browser as
they want should know enough to at least accept session cookies. If they
don't even do that, then it's their own problem, not mine.

Micha

On Jan 15, 7:24 am, Sebastian Lisken deletethis.de> wrote:
> Hi, I'm in the process of securing a PHP/MySQL website by making sure
> all strings that can at least possibly be manipulated from the outside
> are passed through the appropriate escaping functions and/or validated
> against patterns. In the most canonical cases, SQL strings supplied from
> the outside are handled by mysql_real_escape_string, HTML snippets by
> htmlentities, GET parameters in query strings by rawencodeurl. What I'm
> unsure about is whether SID needs to be treated. It's the variable used
> most often, so I guess I could improve efficiency a bit by not adding
> an escaping functions in snippets such as
>
> ">
>
> Is there a known scenario in which an attacker could set SID to contain,
> say, HTML that could then be used in an XSS attack?

1. mysql_real_escape_string() is again broken. Use prepare statements
2. Disable trans sid--always use cookies based session
3. Possibly use DB based session handler
4. Some versions of PHP has XSS issues with $_SERVER['PHP_SELF']. So,
use $_SERVER['SCRIPT_NAME']
5. Session Ids can be "fixed". So, if you're concerned use DB based
sessions and use session_regenerate_id()

--

Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/