Security

All,

I think that it is important that an Ajax/Comet protocol
well addresses 
security and I'd like to put my hand up to write the first
draft of this.

So before doing this in a formal way, I'd like to float
some ideas about
security and have a general discussion about it.

As it stands, the protocol is pretty open - (authenticated)
users 
can create and subscribe to arbitrary channels and the
contents of 
these channels may be anything (including nasty scripts and
other 
tricks). A naive chat room implemented on cometd is a recipe
for 
security attacks.  DOS attacks need only create channels
until
the server runs out of memory.

The protocol already supports authentication, which is a
good
start. 

But I would like to see a server side framework for
declarative 
and programmatic security policy.  At the very least we need
to 
control for given channels  (specified by globbed paths):

* What roles of authenticated users can
create/subscribe/send 
* client-only or server-only status for
create/subscribe/send
* Permit send only by subscribers
* scope of the channel (session, context, server, cluster?)
* SSL only
* Allowable data content (eg allow html, but prohibit
scripts) 
* data transforms (escape/remove html and/or scripts).
* max data size

These declarative constraints could be specified in JSON on 
the server: eg (not much thought yet into the specific
format or all the 
enumerations)

 { 
   "/secret/**" : { "create" :
"role:superuser",
                    "subscribe" :
"authenticated",
                    "send" : "
"any",
                    "content" :
"text/html;scriptless" },
   "/other/**"  : { .... } ,
 }

Actually that sux... but you get the idea....


This sort of approach can be very good at forbidding actions
and good security often starts with forbidding everything
then selectively granting permissions.

We could extend the protocol with the ability to issue and
check 
security tokens.  A client and/or server that has created a 
channel that is protected by a declarative constraint may
request
a grant token from the channel and give that to another user
who can then subscribe and/or send to that channel using the
token.

Tokens could be single use, usable only a particular user, 
globally applicable and/or revocable.  This would be server
specific and the protocol would just need the ability to
request
and pass tokens.

Alternately, we could protect channels by having highly
random channel names.  In effect the channel name would be
a less flexible token.   I think this is a good idea even if
we 
have tokens.  So I think we need a way to create a channel
but specify 
only a partial path and the server will insert a highly
random/unique 
element in the path.  This could be the mandatory level of
support
and then servers could optionally support token grants


thoughts?


With all the concern about Ajax security, I think that if we

can make cometd have good declarative and programmatic
security
mechanisms, then there will be a big driver to push all
Ajax/Comet
communications over cometd 

cheers















--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-dev" group.
To post to this group, send email to cometd-devgooglegroups.com
To unsubscribe from this group, send email to
cometd-dev-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/cometd-dev

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---

Security isn't in the scope of cometd.  To send data from
the browser
to Cometd, the request must first hit a web server.  All
validation
and security checks are done there, and therefore not
cometd's
responsibility.  This is where the web server should check
if the
client is authorized, and if they're allowed to subscribe
to that
channel, or send that message.

If we embed the security in cometd, then we can't leverage
existing
authorization methods like cookie based session auth,
digest/basic
auth, etc.

We'll speak about this on irc and come up with a
resolution.

David

On 8/8/06, Greg Wilkins <gregw.webtidegmail.com> wrote:
>
> All,
>
> I think that it is important that an Ajax/Comet
protocol well addresses
> security and I'd like to put my hand up to write the
first draft of this.
>
> So before doing this in a formal way, I'd like to
float some ideas about
> security and have a general discussion about it.
>
> As it stands, the protocol is pretty open -
(authenticated) users
> can create and subscribe to arbitrary channels and the
contents of
> these channels may be anything (including nasty scripts
and other
> tricks). A naive chat room implemented on cometd is a
recipe for
> security attacks.  DOS attacks need only create
channels until
> the server runs out of memory.
>
> The protocol already supports authentication, which is
a good
> start.
>
> But I would like to see a server side framework for
declarative
> and programmatic security policy.  At the very least we
need to
> control for given channels  (specified by globbed
paths):
>
> * What roles of authenticated users can
create/subscribe/send
> * client-only or server-only status for
create/subscribe/send
> * Permit send only by subscribers
> * scope of the channel (session, context, server,
cluster?)
> * SSL only
> * Allowable data content (eg allow html, but prohibit
scripts)
> * data transforms (escape/remove html and/or scripts).
> * max data size
>
> These declarative constraints could be specified in
JSON on
> the server: eg (not much thought yet into the specific
format or all the
> enumerations)
>
>  {
>    "/secret/**" : { "create" :
"role:superuser",
>                     "subscribe" :
"authenticated",
>                     "send" : "
"any",
>                     "content" :
"text/html;scriptless" },
>    "/other/**"  : { .... } ,
>  }
>
> Actually that sux... but you get the idea....
>
>
> This sort of approach can be very good at forbidding
actions
> and good security often starts with forbidding
everything
> then selectively granting permissions.
>
> We could extend the protocol with the ability to issue
and check
> security tokens.  A client and/or server that has
created a
> channel that is protected by a declarative constraint
may request
> a grant token from the channel and give that to another
user
> who can then subscribe and/or send to that channel
using the token.
>
> Tokens could be single use, usable only a particular
user,
> globally applicable and/or revocable.  This would be
server
> specific and the protocol would just need the ability
to request
> and pass tokens.
>
> Alternately, we could protect channels by having highly
> random channel names.  In effect the channel name would
be
> a less flexible token.   I think this is a good idea
even if we
> have tokens.  So I think we need a way to create a
channel but specify
> only a partial path and the server will insert a highly
random/unique
> element in the path.  This could be the mandatory level
of support
> and then servers could optionally support token grants
>
>
> thoughts?
>
>
> With all the concern about Ajax security, I think that
if we
> can make cometd have good declarative and programmatic
security
> mechanisms, then there will be a big driver to push all
Ajax/Comet
> communications over cometd
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-dev" group.
To post to this group, send email to cometd-devgooglegroups.com
To unsubscribe from this group, send email to
cometd-dev-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/cometd-dev

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---

David,

I agree that standard server authentication can/should
be used to work out who a client is.

But that does not help us control what that user does,
because
all cometd requests go to the same URL and multiple sends
and 
subscriptions can be batched into a single HTTP request.

So something is going to need to know about the internals 
of a cometd requests to either permit or deny each message
in a bundle.

I'd really like this to be part of the cometd scope.
At least a minimal mechanism (eg something that would 
permit Mark Smith to say "only server-side may create
channels")
with some optional extensions.

I'll try to stay on IRC longer so we can chat about this.

cheers



David Davis wrote:
> Security isn't in the scope of cometd.  To send data
from the browser
> to Cometd, the request must first hit a web server. 
All validation
> and security checks are done there, and therefore not
cometd's
> responsibility.  This is where the web server should
check if the
> client is authorized, and if they're allowed to
subscribe to that
> channel, or send that message.
> 
> If we embed the security in cometd, then we can't
leverage existing
> authorization methods like cookie based session auth,
digest/basic
> auth, etc.
> 
> We'll speak about this on irc and come up with a
resolution.
> 
> David
> 
> On 8/8/06, Greg Wilkins <gregw.webtidegmail.com> wrote:
>> All,
>>
>> I think that it is important that an Ajax/Comet
protocol well addresses
>> security and I'd like to put my hand up to write
the first draft of this.
>>
>> So before doing this in a formal way, I'd like to
float some ideas about
>> security and have a general discussion about it.
>>
>> As it stands, the protocol is pretty open -
(authenticated) users
>> can create and subscribe to arbitrary channels and
the contents of
>> these channels may be anything (including nasty
scripts and other
>> tricks). A naive chat room implemented on cometd is
a recipe for
>> security attacks.  DOS attacks need only create
channels until
>> the server runs out of memory.
>>
>> The protocol already supports authentication, which
is a good
>> start.
>>
>> But I would like to see a server side framework for
declarative
>> and programmatic security policy.  At the very
least we need to
>> control for given channels  (specified by globbed
paths):
>>
>> * What roles of authenticated users can
create/subscribe/send
>> * client-only or server-only status for
create/subscribe/send
>> * Permit send only by subscribers
>> * scope of the channel (session, context, server,
cluster?)
>> * SSL only
>> * Allowable data content (eg allow html, but
prohibit scripts)
>> * data transforms (escape/remove html and/or
scripts).
>> * max data size
>>
>> These declarative constraints could be specified in
JSON on
>> the server: eg (not much thought yet into the
specific format or all the
>> enumerations)
>>
>>  {
>>    "/secret/**" : {
"create" : "role:superuser",
>>                     "subscribe" :
"authenticated",
>>                     "send" : "
"any",
>>                     "content" :
"text/html;scriptless" },
>>    "/other/**"  : { .... } ,
>>  }
>>
>> Actually that sux... but you get the idea....
>>
>>
>> This sort of approach can be very good at
forbidding actions
>> and good security often starts with forbidding
everything
>> then selectively granting permissions.
>>
>> We could extend the protocol with the ability to
issue and check
>> security tokens.  A client and/or server that has
created a
>> channel that is protected by a declarative
constraint may request
>> a grant token from the channel and give that to
another user
>> who can then subscribe and/or send to that channel
using the token.
>>
>> Tokens could be single use, usable only a
particular user,
>> globally applicable and/or revocable.  This would
be server
>> specific and the protocol would just need the
ability to request
>> and pass tokens.
>>
>> Alternately, we could protect channels by having
highly
>> random channel names.  In effect the channel name
would be
>> a less flexible token.   I think this is a good
idea even if we
>> have tokens.  So I think we need a way to create a
channel but specify
>> only a partial path and the server will insert a
highly random/unique
>> element in the path.  This could be the mandatory
level of support
>> and then servers could optionally support token
grants
>>
>>
>> thoughts?
>>
>>
>> With all the concern about Ajax security, I think
that if we
>> can make cometd have good declarative and
programmatic security
>> mechanisms, then there will be a big driver to push
all Ajax/Comet
>> communications over cometd
>>
>> cheers
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> > 
> 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-dev" group.
To post to this group, send email to cometd-devgooglegroups.com
To unsubscribe from this group, send email to
cometd-dev-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/cometd-dev

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---