Responses below

7/16/05, Christopher Canova <ccanova (AT) reachone (DOT) comwrote:
I'm doing my best to assist a group with an open source project that
uses amavisd-new and spamassassin called Maia Mailgaurd
(). It's a spam and virus management
system written in Perl and PHP.

Before I get to your specific questions, I'd like to point out the
biggest security issue you are going to face in this system. You are
taking completely untrusted input (emails, including those with
viruses, etc) and displaying it to the user in a web browser. You
will need to be very very careful that you don't allow an attacker to
send a specially crafted email that will inject PHP, Perl, etc code
into your server or inject Javascript, Java, ActiveX, etc into your
user's browser (the later is known as cross-site scripting). This is
not impossible, but can be difficult. Look at all the web
applications that have XSS flaws reported every day on mailing lists.
Remember that the attacker may be one of your users who will know a
lot about how the system is set up and that the application is open
source so the attacker can easily trace the application looking for
flaws, so you need to make sure that the code that processes the
emails is airtight.

We are currently in a discussion about
using the PHP Session ID in the URL and whether to strictly enforce
cookies to avoid session hijacking. The fear is that we could possibly
be passing along the referral information to a spammer willing to
exploit such a vuln. Some of the discussion is related closely to this
mailing list, so I wanted to see what everyone thought about it.

What are the risks to enforcing session handling using cookies? Will it
break functionality for many people? Are the risks of including the SID
in the URL worse than cookies?

In short, you are better off putting the session id in a cookie than
putting it in the URL. You are right that referrer headers are one
way that a URL session id can leak. It may also be logged in proxies
or firewalls.

There is also the problem that users do not expect sensitive
information in the URL. They may send the URL to someone in an IM or
email or even post it on a mailing list or blog, not realizing that it
will give whoever follows the URL access to their account (at least
until the session ID expires).

Finally, I don't like the idea of displaying the session ID on the
screen. It makes the user vulnerable to shoulder surfing and again,
they may send someone or post a screenshot of the application not
realizing that the session ID is there in the URL.

As for breaking functionality for some people, I am not sure how many
people that will affect. I dislike cookies as much as anyone (far too
many sites use them that don't need to), but when you have a web site
that you log in to, they are the best solution. There are some people
that surf the web from a "regular computer" with cookies disabled, but
they are usually advanced users that can handle adding the site to
their exceptions list.

The more common problem with requiring cookies is that some
smartphones and other lightweight browsers may not support them (or
support them properly), so if you anticipate users using these devices
this is an issue you should look into further. You can may want to
consider falling back to using the session ID in the URL if cookies
are not enabled on the browser.

I'd recommend you read up on secure coding practices with Perl and
PHP. There are a lot of resources out there and a lot of issues to
consider, including making sure that an attacker / user cannot guess
another user's session ID.

Good luck.

Chuck

Christopher Canova wrote:

>>What are the risks to enforcing session handling using cookies? Will it
>>break functionality for many people? Are the risks of including the SID
>>in the URL worse than cookies?
>
>>
>Stelian Ene wrote:
>The obvious solution is to present the user with a check box "Use
>cookie", checked by default.
>If the user unchecks it, revert to the default, url-based session traking.
>

Many Gov & Corp. users are not allowed to accept cookies by policy.
These users do not have the ability to change their browser settings to
accept cookies. It is also easier (development, support, maintenance
wise) to only have one way of managing session info in your proxy/app.

Andy Bentley

, I meant to say that the application should invalidate session
IDs after some amount of time Sorry
Chuck
I also agree with you that the
application should not invalidate session IDs after some amount of
time to minimize the possibility of session hijacking.

Responses below

7/18/05, Achim Hoffmann <kirke11 (AT) securenet (DOT) dewrote:
!! In short, you are better off putting the session id in a cookie than
!! putting it in the URL.

In short, it is much simpler to steal session ids from cookies than from
URL, exceptions see below.

No, they are both easy. If there is a XSS on the site, then you can
get the URL with window.location.href.

Cookies are unsecure, unfortunately.

I disagree. Cookies are often insecurely used, but they can be a part
of a "secure" application and I think that they are sufficient for the
type of application the original poster was describing. They are not
perfect, but they are better than the alternatives that are available
in browsers today.

And more worse, most application don't take care for example by using FQDN
and proper path= attribute and secure flag.

I agree with this, applications often do not use Cookies properly,
which is part of the problem. I also agree with you that the
application should not invalidate session IDs after some amount of
time to minimize the possibility of session hijacking.

Chuck

Responses below

!! In short, it is much simpler to steal session ids from cookies than from
!! URL, exceptions see below.
!!
!! No, they are both easy.

"both easy" disagreed, explanation see below

In 90% or more of cases XSS is present in a transient form, that is you have to
pass the stealing-code in a link (in an email or another website) to the user.

, that makes sense. I was thinking of stored XSS, but you are
correct that putting the session ID in the URL makes reflected XSS
difficult. You may be able to do it along with session fixation, but
it would depend on the application as to how well it would work.
course, ideally the application won't have any XSS in it in the first
place.

pro-URL-rewriting arguments:
- perhaps the second top most vulnerability after XSS in web applications
today is Session Riding (aka CSRF, aka web trojan, see
)
URL rewriting is safe against Session Riding. With cookies you have to
take further measures.

I agree that CSRF is a common problem, but there are other ways to
solve the problem that don't require URL-rewriting. Basically,
include a random value in a hidden field of each form and when the
form is submitted, if that value does not match what it should be, the
submission is ignored. You could probably use the session ID instead
of a random value, that may be a little easier to implement.
- Session Fixation, although not generelly impossible with URL rewriting, is
much more often encountered with cookie-based session management.

I think that session fixation is much easier with the session ID in
the URL. For example, if I want a user to use session id 1234, I can
easily send them a link to ;sid=1234
while it is more difficult to set a cookie on the victim's browser for
the domain vulnerable.tld. Maybe there is something I am missing
here.

course, there are disadvantages of URL rewriting and it depends on the
application:
- application has to ensure that the session ID is not within other links
- application has to ensure that the page does not contain links to external
websites 'cause it then will send the session ID in the refer(r)er header

I would add the three I mentioned previously:
- Session ID may be logged in proxy, etc
- User may send URL with Session ID to someone
- User may expose Session ID to others on screen / screenshots
(shoulder surfing)

But in general I tend to recommend URL rewriting over cookies.
Best, of course, is to use both: the session ID inside a cookie and an
additional secret inside the URL. But this is much more expensive as it is
not automatically handeled by todays libs and frameworks.

I'd say that each has its own pluses and minuses. I agree that using
two different session IDs in the URL and in a cookie would be best,
hopefully frameworks will support that easily soon.

In response to someone else that mentioned that another option is to
use a hidden form field as a session ID. That has merits, but I am
not sure I like having every click in the application be a form
submission.

Have a good one.

Chuck