Session (in)security?

Umm, here's something I wish wasn't happening in the default install of
Seaside. If I go to someplace within the application and email the URL that
shows in the browser, say

https://www.myhost.com/seaside/go/application?_s=lpcPfHSbadvbyIAv&_k=KtOMdks
c

to somebody, that person can currently click on that link and acquire my
session and keep on going. I hope I don't need to explain why this is plain
wrong, but how can I address that?

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Ah!

application preferenceAt: #useSessionCookie put: true

Me wonders why this isn't on by default, we almost deployed with this being
false...

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Boris Popov
Sent: Thursday, June 15, 2006 10:27 AM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: [Seaside] Session (in)security?

Umm, here's something I wish wasn't happening in the default install of
Seaside. If I go to someplace within the application and email the URL that
shows in the browser, say

https://www.myhost.com/seaside/go/application?_s=lpcPfHSbadvbyIAv&_k=KtOMdks
c

to somebody, that person can currently click on that link and acquire my
session and keep on going. I hope I don't need to explain why this is plain
wrong, but how can I address that?

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov wrote:
You can also

initialize
    super initialize.
    self addDecoration: WASessionProtector new

in your root component.  WASessionProtector checks to make sure that
requests come from the same IP address as the original request.  Doesn't
do much good if two requests come from different users behind the same
proxy though.  I use this scheme because AFAIK there are still some
problems with session cookies....maybe they've been fixed though.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Okay, no harm using both though, is there? Could someone else chime in with
their experience with using cookies for session tracking please? I can't
imagine *anyone* passing the session key in the URL in their deployed
applications unless I'm missing something...

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of David
Shaffer
Sent: Thursday, June 15, 2006 10:50 AM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Session (in)security?

Boris Popov wrote:

initialize
    super initialize.
    self addDecoration: WASessionProtector new

in your root component.  WASessionProtector checks to make sure that
requests come from the same IP address as the original request.  Doesn't
do much good if two requests come from different users behind the same
proxy though.  I use this scheme because AFAIK there are still some
problems with session cookies....maybe they've been fixed though.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 15, 2006, at 1:27 PM, Boris Popov wrote:

I think you do need explain why it's wrong. It's a bit like saying,  
"Hey, if I send my password to somebody in an email, they could log  
into my machine and delete my files!"


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Fair enough of a question. Here's one stab at the least argument-provoking
answer :)

If somebody stands over my shoulder, the password fields are (typically)
masked (*****) whereas the address bar of the browser isn't.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Colin
Putney
Sent: Thursday, June 15, 2006 11:01 AM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Session (in)security?


On Jun 15, 2006, at 1:27 PM, Boris Popov wrote:
I think you do need explain why it's wrong. It's a bit like saying,  
"Hey, if I send my password to somebody in an email, they could log  
into my machine and delete my files!"


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks, David, this works well too, I'll definitely use this together with a
session cookie just an extra layer in case anyone tries to brute-force the
session key. Its all about minimizing risk I guess, but I'm still curious
why wouldn't the cookie setting be on by default :)

Michel, attached is VisualWorks extension to Request to make it compatible
with WASessionProtector, good addition to the VW port.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of David
Shaffer
Sent: Thursday, June 15, 2006 10:50 AM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Session (in)security?

Boris Popov wrote:

initialize
    super initialize.
    self addDecoration: WASessionProtector new

in your root component.  WASessionProtector checks to make sure that
requests come from the same IP address as the original request.  Doesn't
do much good if two requests come from different users behind the same
proxy though.  I use this scheme because AFAIK there are still some
problems with session cookies....maybe they've been fixed though.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov wrote:
> Michel, attached is VisualWorks extension to Request to make it compatible
> with WASessionProtector, good addition to the VW port.
>  
Boris -- I didn't see any attachment on what came through to the mailing
list.. Can you check again or send it to
me directly if possible ([hidden email])?  Thanks!

-- Rick

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sigh, indeed I forgot to include it in my original email.

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Rick Flower
Sent: Thursday, June 15, 2006 11:48 AM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Session (in)security?

Boris Popov wrote:
> Michel, attached is VisualWorks extension to Request to make it compatible
> with WASessionProtector, good addition to the VW port.
>  
Boris -- I didn't see any attachment on what came through to the mailing
list.. Can you check again or send it to
me directly if possible ([hidden email])?  Thanks!

-- Rick

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> Michel, attached is VisualWorks extension to Request to make it  
> compatible
> with WASessionProtector, good addition to the VW port.
>

This is now published in the public store,
SeasideForWebToolkit (2.6b1.41.0,mbany)

Michel.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

There's nothing wrong with the session key being in the url, it's fairly
common but often hidden with mod rewrite making the key look like part of
the url itself.  .Net allows this as well, called cookieless sessions, which
was a response to people complaining about cookies being required.  Seaside
offers both cookie and cookieless sessions, and seaside, being aimed at
"complex application" development rather than general web site development,
is more concerned with making application development easier, rather than
general website development, so the defaults may need changing here and
there when doing websites.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 15, 2006, at 2:07 PM, Boris Popov wrote:

> Fair enough of a question. Here's one stab at the least argument-
> provoking
> answer :)
>
> If somebody stands over my shoulder, the password fields are  
> (typically)
> masked (*****) whereas the address bar of the browser isn't.

Well, if you want to password protect your app, you can do that. If  
you want to rely on capability security with session keys, you have  
to be careful about distributing the capability. Seaside gives you a  
range of options for managing the security of your apps. What's wrong  
with that?

Colin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oh I didn't say there was anything wrong with that, it just seemed weird
that one could copy the url from one machine to the other and pick up an
exact same session. By the way, password was just an example, not related to
the session key issue. Obviously our app is password protected as well, but
with url copying, all you need is a url of a logged-in user and you're good
to go whereas with a cookie you have to try much harder. I settled on
basically using both cookie setting and WASessionProtector, but was just
wondering if cookie setting shouldn't be on by default for ignorant seaside
beginners like myself, that's all :)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Colin
Putney
Sent: Thursday, June 15, 2006 1:28 PM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Session (in)security?


On Jun 15, 2006, at 2:07 PM, Boris Popov wrote:

> Fair enough of a question. Here's one stab at the least argument-
> provoking
> answer :)
>
> If somebody stands over my shoulder, the password fields are  
> (typically)
> masked (*****) whereas the address bar of the browser isn't.

Well, if you want to password protect your app, you can do that. If  
you want to rely on capability security with session keys, you have  
to be careful about distributing the capability. Seaside gives you a  
range of options for managing the security of your apps. What's wrong  
with that?

Colin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michel Bany wrote: Thanks for the quick turnaround!
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 15, 2006, at 4:37 PM, Boris Popov wrote:

I guess I should have been more precise. If you use HTTP  
authentication, then you'd need both a session key *and* a valid  
login and password. If you only require login to start a session,  
then yeah, a session key is enough to hijack the session.

Colin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Am 16.06.2006 um 07:37 schrieb Boris Popov:

Security by obscurity is far more dangerous. It's as easy to snoop a  
cookie as a URL, both are plain text going over the wire. IP spoofing  
is harder, but readily available to an attacker, so restrictring the  
IP is not only not a good security measure, it's preventing valid  
access, too (my DSL router reconnects regularily, it gets a different  
IP address each time, poof, session lost).

Anyone starting with Seaside rightfully wonders about those funny  
URLs, and if it is explained thoroughly what these mean, the security  
implications are obvious. If the inner workings are hidden by cookies  
then it becomes much more magical, and people would assume that the  
framework will magically do everything for them.

- Bert -

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 16, 2006, at 11:16 , Bert Freudenberg wrote:

[..]

> Anyone starting with Seaside rightfully wonders about those funny  
> URLs, and if it is explained thoroughly what these mean, the  
> security implications are obvious.

I agree, but are the implications really that obvious (because, as  
usual, they are not explained)...
What nobody mentioned so far is not only the problem when you mail an  
URL to somebody but the much more subtle transfer of an URL by the  
referer field in the HTTP header. If you have links in your  
application that point to some other web site, your URL is disclosed  
to this server (the referer field is typically added to the log files).

Adrian
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Right, so why not pick the least evil of the two? There isn't a perfect
security model out there, but given the choice of a cookie and plain text
url I'd go for cookie 10 times out of 10.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Adrian
Lienhard
Sent: Friday, June 16, 2006 2:58 AM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Session (in)security?


On Jun 16, 2006, at 11:16 , Bert Freudenberg wrote:

[..]

> Anyone starting with Seaside rightfully wonders about those funny  
> URLs, and if it is explained thoroughly what these mean, the  
> security implications are obvious.

I agree, but are the implications really that obvious (because, as  
usual, they are not explained)...
What nobody mentioned so far is not only the problem when you mail an  
URL to somebody but the much more subtle transfer of an URL by the  
referer field in the HTTP header. If you have links in your  
application that point to some other web site, your URL is disclosed  
to this server (the referer field is typically added to the log files).

Adrian
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Right, so why not pick the least evil of the two? There isn't a perfect
> security model out there, but given the choice of a cookie and plain text
> url I'd go for cookie 10 times out of 10.
>
> -Boris

A cookie is plain text as well, and no more secure than the url.
Seasides default prevents it from requiring cookies, a sensible default
considering many peoples irrational fear of cookies and disabling of
such.  It's hardly a cut and dry case that a cookie is less "evil" than
the url, many think otherwise.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside