Security

If I have data that I want to be sure can only be seen by specific
users, is there a way to do that in Seaside?

All the previous discussion I've seen on this list concerns session
security.  While that is necessary, it is not sufficient.  My concern is
more that someone with a legitimate session could use it to get at
something unauthorized.

I understand I can write my app to only show the right things; can a
determined client get around that?

Ross Boylan


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

On May 2, 2009, at 5:22 PM, Ross Boylan wrote:

> I understand I can write my app to only show the right things; can a
> determined client get around that?

any security system can be subverted.

i used to make money show people who an authorized user could get
more than the access they were supposed to. there are so many ways
that to attack, you just have to make sure you keep everything secure.

i've seen systems where only certain parts actually verified you had  
access
and others ( messaging ) didnt bother. once you understand the messaging
pattern, you could read other people's mail.

i've seen systems that were plenty secure except oops they only required
a cookie token after login, one that was easily intercepted and copied.

if you have to have a secure app and you don't really know web app  
security,
find someone who does and work with them.

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

>>>>> "Ross" == Ross Boylan <[hidden email]> writes:

Ross> If I have data that I want to be sure can only be seen by specific
Ross> users, is there a way to do that in Seaside?

Ross> All the previous discussion I've seen on this list concerns session
Ross> security.  While that is necessary, it is not sufficient.  My concern is
Ross> more that someone with a legitimate session could use it to get at
Ross> something unauthorized.

There's two levels to this:

(a) the interaction between the browser and server
(b) how the server interprets this data for authentication and authorization

If the session needs to be secure, "a" better be over SSL.  Otherwise, anyone
who can sniff can replay (although for only 10 minutes in Seaside by default,
and even that might not be useful).  And if "a" is secure, standard practices
for "b" will suffice.  The session key is reasonably secure, although you
could increase its length if you're excessively paranoid.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 5/2/09, Ross Boylan <[hidden email]> wrote:
As far as I can see, you would need to take care not to display it to
him as a result of your programming error, and to prevent him from
executing Smalltalk code.

If information is sensitive, you might use some of the tricks of
trenslucent databases:

http://www.oreillynet.com/pub/a/network/2002/08/02/simson.html
http://www.wayner.org/books/td/

rush
http://www,cloud208.com/

>
>  Ross Boylan
>
>
>  _______________________________________________
>  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

Hi Ross,
it sounds very application specific. Session aside, Seaside will not directly
help you on that. Specially on application data. That's responsibility of the
app design.
Of course nothing will prevent you to implement the appropiate additional levels
of security to suffice your app needs as you would in any other framework.
cheers,
sebastian

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

On Sun, 2009-05-03 at 11:44 -0300, Sebastian Sastre wrote:
> Hi Ross,
> it sounds very application specific. Session aside, Seaside will not directly
> help you on that. Specially on application data. That's responsibility of the
> app design.
> Of course nothing will prevent you to implement the appropiate additional levels
> of security to suffice your app needs as you would in any other framework.
> cheers,
> sebastian

I think there is a part that relates to Seaside.  This an other replies
have suggested the issue is the design of my application or web security
in general; this may be because you all know that the stuff at the
Seaside level is OK.  I don't, and would still like info at the level. I
know those other levels matter too.  

Let me be more explicit. A request comes in through the web.  Assuming
an attacker can put anything they want in the request, there are two
concerns.  

First, the attacker could pretend to be someone else.  I need Seaside to
identify accurately who the requestor is or to reject forged requests
before they get to my code.  Previous discussion on the list indicates
that, with suitable precautions, an outsider can not hijack an existing
session.  Can someone with a legitimate session assume another identity?
Can someone without a session assume an identity?

Second, the request could attempt to execute some code that is outside
the normal flow of operations.  I don't know if the latter is possible
with Seaside; in other frameworks such as Zope it is possible (and it
has security systems to keep this in check).  Or they could start
traversing the object graph, even with the debugging interface off.
Again, I'm not clear: are either of these scenarios (access to code or
objects) possible.  Are they?

The possible application involves health information, so the security
requirements are quite strict.

Ross

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

>>>>> "Ross" == Ross Boylan <[hidden email]> writes:

Ross> First, the attacker could pretend to be someone else.  I need Seaside to
Ross> identify accurately who the requestor is or to reject forged requests
Ross> before they get to my code.  Previous discussion on the list indicates
Ross> that, with suitable precautions, an outsider can not hijack an existing
Ross> session.  Can someone with a legitimate session assume another identity?
Ross> Can someone without a session assume an identity?

Seaside doesn't know "identity".  That's all in your app code.  All seaside is
going to do with the incoming values is reawaken your session-saved state,
including the state of all components.  If one of those values is your
app-defined "identity", that's up to you to manage properly.

Ross> Second, the request could attempt to execute some code that is outside
Ross> the normal flow of operations.  I don't know if the latter is possible
Ross> with Seaside; in other frameworks such as Zope it is possible (and it
Ross> has security systems to keep this in check).  Or they could start
Ross> traversing the object graph, even with the debugging interface off.
Ross> Again, I'm not clear: are either of these scenarios (access to code or
Ross> objects) possible.  Are they?

Not possible, unless you happen to be silly enough to "eval" incoming
arbitrary strings as Smalltalk code.

Of course, if the Smalltalk VM has a buffer overflow problem, all bets are
off. :) But no known bugs at this time on those.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Excellent!  Now I get it.

It looks as if some stuff built on Seaside, e.g., Pier, adds a
user/security layer.

Ross

On Sun, 2009-05-03 at 10:59 -0700, Randal L. Schwartz wrote:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I think there is a part that relates to Seaside.  This an other replies
have suggested the issue is the design of my application or web security
in general; this may be because you all know that the stuff at the
Seaside level is OK.  I don't, and would still like info at the level. I
know those other levels matter too.  

Let me be more explicit. A request comes in through the web.  Assuming
an attacker can put anything they want in the request, there are two
concerns.  

First, the attacker could pretend to be someone else.  I need Seaside to
identify accurately who the requestor is or to reject forged requests
before they get to my code.  Previous discussion on the list indicates
that, with suitable precautions, an outsider can not hijack an existing
session.  Can someone with a legitimate session assume another identity?
Can someone without a session assume an identity?

Second, the request could attempt to execute some code that is outside
the normal flow of operations.  I don't know if the latter is possible
with Seaside; in other frameworks such as Zope it is possible (and it
has security systems to keep this in check).  Or they could start
traversing the object graph, even with the debugging interface off.
Again, I'm not clear: are either of these scenarios (access to code or
objects) possible.  Are they?

The possible application involves health information, so the security
requirements are quite strict.

Ross

  

Your biggest issue (IMO) is going to be the possibility of session hijacking.  And, that is easily solvable, but not without placing some level of limits on your audience.  For example, if you architect the app to require cookies to be turned on in the browser, then of course you limit yourself to only the audience that is willing to have cookies turned on in their browser.

Let me put it another way:  the more "secure" your app is, the more limiting you make your potential audience.  Thus, it is up to you to find the right balance.  For an ecommerce website that doesn't save credit card data at all, security might take a more secondary seat than, say, a banking app.  Thus, for such an ecommerce site, you might make cookies optional, but for a banking app, they might be mandatory.  Likewise, for an ecommerce site, you might choose to only have the checkout process use SSL, and yet for a banking app (like PayPal, for example), you might choose to have the entire site use SSL.

For your app, I'd consider making your entire site use SSL, and I'd consider requiring cookies.  I'd also consider configuring Seaside for using cookies for the session key, plus use a secondary cookie for additional "branding" of your login/logout process.

Other folks may have other ideas, though.

Nevin



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

Ross Boylan wrote:
> Excellent!  Now I get it.
>
> It looks as if some stuff built on Seaside, e.g., Pier, adds a
> user/security layer.
>
> Ross
>
>  
Yes that stuff is pretty much  roll your own, apart from the most
minimal http authentication support.

There are some components for user login/forgotton passwords etc
available in squeaksource.com/Beach.

Keith

To use Beach, load

Installer install: 'Packages'.
Installer ss project: 'Beach-Packages'.

The dependencies are articulated there, but bear in mind this is very
early days as yet.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Now be careful here the squeak VMs don't have known buffer overflow
issue, but possible buffer overflow issues could exist because many of
the primitive and standard plugins are not parnoid about the incoming
parms. The VM folks have never sat down and consider the caller of a
primitive would be unfriendly.

However this would require an attacker to execute arbitrary Smalltalk
code on your server. Of course if they can do that they own you
anyway, especially if you allow FFi or use the OSProcess plugin


On 5/3/09, Randal L. Schwartz <[hidden email]> wrote:

--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2009/5/3 Randal L. Schwartz <[hidden email]>:
You might think so. But then try to convert a String to a Boolean and
follow the path of execution. You might be in for a surprise. There is
no telling how many time bombs like this are in Squeak.

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

On Sun, 2009-05-03 at 12:42 -0600, Nevin Pratt wrote:
> For your app, I'd consider making your entire site use SSL, and I'd
> consider requiring cookies.  I'd also consider configuring Seaside for
> using cookies for the session key, plus use a secondary cookie for
> additional "branding" of your login/logout process.
I think also I'd want to add the wrapper that only permits sessions to
use the original IP address.

Are there any hidden problems that my turn up with clients that are
NAT'd or using a proxy?  I suppose a multi-homed client (more likely a
proxy) might randomly start using a different IP address.

I wasn't familiar with branding, but with Google's help I understand.
Thanks for mentioning it.

Thanks to everyone who responded.

Ross

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

Ross Boylan wrote:

On Sun, 2009-05-03 at 12:42 -0600, Nevin Pratt wrote:
  

For your app, I'd consider making your entire site use SSL, and I'd
consider requiring cookies.  I'd also consider configuring Seaside for
using cookies for the session key, plus use a secondary cookie for
additional "branding" of your login/logout process.
    

I think also I'd want to add the wrapper that only permits sessions to
use the original IP address.

Are there any hidden problems that my turn up with clients that are
NAT'd or using a proxy?  I suppose a multi-homed client (more likely a
proxy) might randomly start using a different IP address.

I wasn't familiar with branding, but with Google's help I understand.
Thanks for mentioning it.

Thanks to everyone who responded.

Ross

  

A few weeks ago when I was testing what you are suggesting (only permit sessions to use the original IP address), I found (for example) the following in my log file, all associated to the same session:

CurrentIP=205.188.116.142 LastIP=205.188.116.74
CurrentIP=205.188.116.16 LastIP=205.188.116.142
CurrentIP=205.188.116.73 LastIP=205.188.116.16
CurrentIP=205.188.117.11 LastIP=205.188.116.73
CurrentIP=205.188.116.72 LastIP=205.188.117.11

Look at the sequence, and you can see that somebody was changing their IP with every request.

Now do a reverse IP lookup on any of those IP's, and what do you find? 

205.188.116.142 resolves to
"cache-dtc-ac13.proxy.aol.com"
Top Level Domain: "aol.com"

So, I can confirm that AOL users will typically change their IP with every request.

And, AOL isn't the only ISP I found that does this.

Yes, you certainly can use the wrapper that only permits sessions to use the original IP address.  But that will also *definitely* limit your audience, of who can successfully use your website.

I definitely would *not* do that with an eCommerce site.  I don't think I'd do it with a banking site, either.  But I *might* do it for a specialized web app that I had complete control over the clients, though.

I personally think that the wrapper that ties the sessions to only their original IP is a rather worthless wrapper for the vast majority of Seaside apps.  But their is a very small subset of apps that it is a good idea for, and I think would work well for.  I'm just not sure if your app is one of those.

Nevin




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

Nevin Pratt wrote:
> So, I can confirm that AOL users will typically change their IP with
> every request.
>
I believe this is also the case with anyone using an iPhone.. I noticed
my own page
requests having different IP's for each request.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Nope, that is not the function of the iphone, which is a unix based  
machine, the IP determined
from either a static setting, or DHCP doesn't change on each request.

That is a function of your cell provider, if using cell data  
connection they are doing nat/proxy work
at their gateway. Or your upstream ISP is doing a simular thing if  
connected via WiFi.


On 3-May-09, at 10:45 PM, Rick Flower wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




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

John M McIntosh wrote:
> Nope, that is not the function of the iphone, which is a unix based
> machine, the IP determined
> from either a static setting, or DHCP doesn't change on each request.
>
> That is a function of your cell provider, if using cell data
> connection they are doing nat/proxy work
> at their gateway. Or your upstream ISP is doing a simular thing if
> connected via WiFi.
Correct.. In this case I'm referring to what the cell provider is doing
-- wifi has nothing to do with
it in this case.. And you're probably correct that many phones likely
exhibit this 'feature'.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside