You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Aleksandr Guidrevitch <pi...@tut.by> on 2003/08/14 12:54:07 UTC
Apache::Session
Hi, All
Sorry, this post might be out of scope of this particular list, but
still... don't punch me heavily :) I just think the people here might
have met this problem while deploying big public applications.
I use Apache::Session to identify logged in users. However, the users
are allowed to post html (obviously with javascript) messages viewable
by others. That could create an XSS vulnerability and allow to steal the
sessions (cookies) from other users.
Is it possible to uniquely identify the user by some attributes ?
The only thing I consider now is IP, but what about proxies and NATs ?
User Agent string could also be stolen via javascript. That means I tend
to make stolen session ids non-reusable.
Any thoughts ?
Sincerely,
Aleksandr Guidrevitch
Re: Apache::Session
Posted by Raf <ra...@joshua.dreamthought.com>.
Aleksandr Guidrevitch said:
...
> Is it possible to uniquely identify the user by some attributes ?
> The only thing I consider now is IP, but what about proxies and NATs ?
> User Agent string could also be stolen via javascript. That means I tend
> to make stolen session ids non-reusable.
Went through this many years ago and I assure you that there is 'no'
proper heuristic for identifying that user. UserAgent fails when you have
a building full of people with a standard install. IP fails with proxies
- and even worse - through crappy isp's where each request appears to be
chained through some different proxy. imho, you have to accept some level
of insecurity.
Make the walls higher. Use post, use cookies, make your session id's
short lived, make heuristics for comparing temporaly close subsequent
request's useragent/ip etc. Perhaps there's someone clever out there who
has found a some chaotic fractal which will reveal the mac address from
the combination of everything else, however besides this, I think it a
no-winner.
Well, good luck,
Rafiq
Re: Apache::Session
Posted by O'K Web Design <ok...@rogers.com>.
Hi
I might be missing the point but if you already are tracking with
Apache::Session why not encrypt the session id before giving it to the user
in the first place. You could store a public 'key' for the encryption in a
cookie on the users machine. That way only that user can give you the right
info to decode the session. If this sounds reasonable, you may want to
check out Paul DuBois book "MySQL and Perl for the Web" ISBN 0-7357-1054-6.
He outlines a method to encrypt the apache::session id. Mike
----- Original Message -----
From: "Aleksandr Guidrevitch" <pi...@tut.by>
To: <mo...@perl.apache.org>
Sent: August 14, 2003 6:54 AM
Subject: Apache::Session
> Hi, All
>
> Sorry, this post might be out of scope of this particular list, but
> still... don't punch me heavily :) I just think the people here might
> have met this problem while deploying big public applications.
>
> I use Apache::Session to identify logged in users. However, the users
> are allowed to post html (obviously with javascript) messages viewable
> by others. That could create an XSS vulnerability and allow to steal the
> sessions (cookies) from other users.
>
> Is it possible to uniquely identify the user by some attributes ?
> The only thing I consider now is IP, but what about proxies and NATs ?
> User Agent string could also be stolen via javascript. That means I tend
> to make stolen session ids non-reusable.
>
> Any thoughts ?
>
> Sincerely,
> Aleksandr Guidrevitch
>
Re: Apache::Session
Posted by Patrick Galbraith <pa...@patg.net>.
Aleksandr,
we had our own stripping methods. Just get the source for slashcode
http://slashcode.com and look for
Slash/Display/Display.pm: strip_paramattr => \&strip_paramattr,
Slash/Display/Display.pm: strip_urlattr => \&strip_urlattr,
Slash/Display/Display.pm: strip_anchor => \&strip_anchor,
Slash/Display/Display.pm: strip_attribute => \&strip_attribute,
Slash/Display/Display.pm: strip_code => \&strip_code,
Slash/Display/Display.pm: strip_extrans => \&strip_extrans,
Slash/Display/Display.pm: strip_html => \&strip_html,
Slash/Display/Display.pm: strip_literal => \&strip_literal,
Slash/Display/Display.pm: strip_nohtml => \&strip_nohtml,
Slash/Display/Display.pm: strip_notags => \&strip_notags,
Slash/Display/Display.pm: strip_plaintext => \&strip_plaintext,
and this'll give you an idea of what slashcode does to deal with it.
Hope this helps,
Patrick
Aleksandr Guidrevitch wrote:
> Hi, All
>
> What have you used to stip out that stuff ? I've reviewied
> HTML::StripScripts, but it seems to be very slow. I've also
> considered HTML::Filter to do that but I'm also affraid that
> HTML::Parser is not the fastest thing on the earth, even though
> it will be invoked once during initial submission.
>
> Could you also advise on this "safe" subset of html you use ?
>
> Sincerely,
> Alex
>
> Patrick Galbraith wrote:
>
>> Strip out stuff that could be problematic. This is what we did with
>> Slash. We strip out javascript or any tag that can be problematic, or
>> be used even to break the layout of the page. It'll make you're life
>> much easier ;) Take this from someone who coded tons of features to
>> ward off trolls!
--
----------------------
Patrick Galbraith
Senior Software Developer
patg@patg.net capttofu@slashdot.org
206.719.2461
Re: Apache::Session
Posted by Aleksandr Guidrevitch <pi...@tut.by>.
Hi, All
What have you used to stip out that stuff ? I've reviewied
HTML::StripScripts, but it seems to be very slow. I've also
considered HTML::Filter to do that but I'm also affraid that
HTML::Parser is not the fastest thing on the earth, even though
it will be invoked once during initial submission.
Could you also advise on this "safe" subset of html you use ?
Sincerely,
Alex
Patrick Galbraith wrote:
> Strip out stuff that could be problematic. This is what we did with
> Slash. We strip out javascript or any tag that can be problematic, or be
> used even to break the layout of the page. It'll make you're life much
> easier ;) Take this from someone who coded tons of features to ward off
> trolls!
Re: Apache::Session
Posted by Patrick Galbraith <pa...@patg.net>.
Strip out stuff that could be problematic. This is what we did with
Slash. We strip out javascript or any tag that can be problematic, or be
used even to break the layout of the page. It'll make you're life much
easier ;) Take this from someone who coded tons of features to ward off
trolls!
Aleksandr Guidrevitch wrote:
> Hi, All
>
> Sorry, this post might be out of scope of this particular list, but
> still... don't punch me heavily :) I just think the people here might
> have met this problem while deploying big public applications.
>
> I use Apache::Session to identify logged in users. However, the users
> are allowed to post html (obviously with javascript) messages viewable
> by others. That could create an XSS vulnerability and allow to steal the
> sessions (cookies) from other users.
>
> Is it possible to uniquely identify the user by some attributes ?
> The only thing I consider now is IP, but what about proxies and NATs ?
> User Agent string could also be stolen via javascript. That means I tend
> to make stolen session ids non-reusable.
>
> Any thoughts ?
>
> Sincerely,
> Aleksandr Guidrevitch
--
----------------------
Patrick Galbraith
Senior Software Developer
patg@patg.net capttofu@slashdot.org
206.719.2461
Re: Apache::Session
Posted by Marcel Greter <mg...@swissonline.ch>.
All the information that comes from the user-agent can be faked. So the
session id is as insecure as any other identifier you get from the
Browser. The only thing that could be used is the IP address, and as
somebody said earlier, some ISPs and big company LANs may use different
proxies for different requests (or use random routes for multiple output
interfaces with some NAT gateway). Also the MAC address is not an
option, any routing above layer 2? will loose the MAC address (if I'm
not wrong).
But there is somehow a way to get it more secure. Basically a key/IP
combination would be very secure, it's just not useable for all users.
Therefore you need to allow multiple IPs for the same session key. After
you see that a user from another IP request a session id, you prompt a
login again, and after successfull login you allow both IPs to access
this session ID. Every user then basically has to login for each IP he
uses; but it could be done more tricky, so the whole subnet that those
two IPs are in is allowed. The security risk would be, that any other
user going though the same gateway can steal the session just by knowing
the correct session id.
If the user is coming through proxies (as it IMHO normally is if you
have several IPs for a session), you could even do more fancy stuff.
Proxies should send an x-forwarded-for header, where they will add every
IP that sent the request (can be multiple hosts). This way you could
allow all those proxies for the session, but just for the same end IP
(which should be the last IP from the x-forwarded-for field before any
internal IP). Now we just have the security hole left, if someone is in
control of those proxies, then he could steal the session from the
original user.
IMHO this is really everything you can get out of it; you even get it a
lot securer for proxied users. The only problem are LANs that use random
NAT-Gateways, which IMHO aren't widely spread ??.
If you see anything more to make it secure, or if I'm totally wrong, I'm
glad to hear !?
greets, Marcel Greter
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session
Posted by Perrin Harkins <pe...@elem.com>.
On Thursday 14 August 2003 8:06 am, Joelle Nebbe wrote:
> What i do is store both the remote IP and the user agent HTTP parameters in
> the session when the session is created. Whenever a new request comes in
> with that session I check that those havent changed.
So, you don't care about AOL users then? They can change IPs on every request
as they get routed between proxies.
> I also check referrer to make sure people are coming from a page that makes
> sense.
Not much of a barrier to anyone who cares enough to bother coding up a
cross-site scripting attack.
> If you need even better security there's ssl, or storing unique,
> random'challenge-response' style tokens into pages that have to be sent
> back on the next connection
That's an idea. You could try making every cookie good for only one use, and
send a new one out every time.
Ultimately though, I think the answer is that sites with sensitive information
can't leave themselves open to CSS attacks.
- Perrin
Re: Apache::Session
Posted by Joelle Nebbe <jo...@chaptereight.com>.
Hi
I do a few basic things that improve security - its still not strict security but
What i do is store both the remote IP and the user agent HTTP parameters in the session when the session is created.
Whenever a new request comes in with that session I check that those havent changed. If they havent I allow access and update the 'last access time' (for expiry) - if not they are logged out and the session closed.
This means that any user disconnected from their ISP has to login again, which i consider acceptable. It also means that if they copy an url and paste it into another browser they will end up logged out, again it does not happen often and people should accept it as the price of security.
It does mean that someone on the same proxy and using the same browser could still do something but that is already a lot fewer people.
I also check referrer to make sure people are coming from a page that makes sense. If you wanted to be more sophisticated you could store where an user has been recently (the 5 last URLs maybe) and check that the referrer is one of them. If the referrer is not a page where the user has been then things are fishy and you log them out.
If you need even better security there's ssl, or storing unique, random'challenge-response' style tokens into pages that have to be sent back on the next connection
Probably many people on this list have more sophisticated systems in place. I'd be interested to know too :)
Joelle Nebbe