Re: Digest for wub-discussion@googlegroups.com - 1 Message in 1 Topic
19 views
Skip to first unread message
Tom Krehbiel
Sep 14, 2013, 7:41:10 PM9/14/13
to wub-dis...@googlegroups.com
On 9/12/2013 7:51 PM,
wub-dis...@googlegroups.com wrote:
Hi Colin,Group: http://groups.google.com/group/wub-discussion/topics
mcccol <mcc...@gmail.com> Sep 11 08:45PM -0700
I want to preface my response with "I'm not an expert". With that in mind, I've given some more though to this subject.
OK
Hi Tom,
On Thursday, 12 September 2013 03:12:30 UTC+10, tomk wrote:
> more thoughts on the subject. As I mentioned in our chat, a simple
> table with (session key, keyword, value) record should be good enough
> for storing values.
I've added a subclass of Session, called it SimpleSession, which has these
properties. I haven't tested it, but kept it in lock-step with the Session
class, and expect it'll work pretty easily.
I think we may diverge slightly on the definition of a session. The code that I've written in the past basically associated a connection with a session. This means a session is related to a an IP address. Each browser connection (i.e. window or tab) has its own set of session variables that keep track of the users navigation state for that connection. When the connection is broken then the session is cleaned up. Login management (which is distinct from session management) creates and maintains items that are nonvolatile across sessions (such as user preferences, etc.) When a user logs out then all the sessions on that IP address are cleaned up (even if the windows are open). Note that a session that isn't logged in can also be established and used for the "entry point" into a web site that requires login.
> session table contains one entry per session. The records would look
> similar to this (ip address, session key, serial number, timeout
> value, last transaction).
I get that these fields exist to facilitate security and admin of sessions.
I'm going to suggest ways they could be added to Session in user code
within the session instance. To that end, I will add some lambda
configuration arguments which could be used to provide such functionality.
An ip address is associated with the session
> key to help prevent someone from taking over a session.
I see no reason to suppose that a session can't be continued from multiple
IP addresses, over time. What you suggest might be a particular session
policy, and should be implemented as such. Your point raises the question
of whether sessions can be shared between browser instances simultaneously,
which is really interesting. I think I can see uses for that mode too.
What do you think?
I think you are correct, adding a transaction cookie doesn't buy you enough to make it worth the trouble.
> number value is a random number that is set in a client cookie during
> each transaction. The server checks and modifies this value during
> each transaction.
Ok. The purpose there is to prevent capture/replay of session in the case
that a session cookie is intercepted? What's to stop the hypothetical
interceptor catching this cookie, too, as a man in the middle? I think the
way to implement this would be to insist upon SSL connection for secure
sessions.
I think I was confused when I wrote the above. The time out actually occures relative to login (if no login then not at all except for client side cookie removal). The timeout value is stored with the users login settings. The sweep then checked to see if any of the sessions for an IP/login was active within the timeout period. If so then the check is rescheduled, if not then the users is logged out (from the associated IP address) and all the associated sessions were destroyed.
> how long a session can be idle. A background process sweeps the
> session table periodically and removes sessions that have exceeded
> their timeout value.
This is currently implemented, slightly differently ... there's a last
transaction time array by session, and a couple of methods to collect, and
to close, those sessions which have been idle for more than some period
(specified as in [clock add].) I think this achieves the goal of
controlling idle sessions without requiring per-session persistent storage.
Is per-session idleness useful?
(see above comment)
I have, by design, left as much policy outside Session as I can. I can
provide accessors for all the information Session maintains, and permit a
parallel session management policy object to enforce such policies. I
would be loathe to add policy level facilities where it's not clear that
such policies are universal.
> The last transaction value is a timestamp for the
> last transaction. Note that the session management stuff should all
> happen out side the access scope of the application.
This was also poorly thought out so I think I will with draw the throttling comment.
I think it's ok for a session to close itself, as an example of session
management within the session, and have made provision for that via a
Session method. TImestamp is implemented as above.
I question the virtue of trying to firewall off session management from
session code. The purpose and function of Session is to permit code to run
in a context of its own, which persists over time, and (optionally) between
server restarts, and which all pipelines and requests from a given browser
instance can share. Once one permits arbitrary code to run on the server,
one has no control over what it can do. I have no way to prevent any code
from digging around in the Session instance and wreaking what havoc it will.
I can certainly see the point of stopping per-session code messing with
Session inadvertantly, and have done that, but more than that isn't really
feasible in Tcl, unless you can think of something cool to do it.
> Also note that
> the session manager is a good place to implement throttling, perhaps
> during serial number generation.
Tom K.--
Well that's a good idea. One simple way to do that would be to cause
Session to check throttling, return a Suspend reply, then after some
timeout to actually perform the request processing, and Resume with its
result. Let me mull that over a while, but I think it's a clever use of
the facility.
Thanks, some interesting insights here,
Colin.
You received this message because you are subscribed to the Google Groups "Wub Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wub-discussio...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
mcccol
Sep 15, 2013, 12:57:03 AM9/15/13
to wub-dis...@googlegroups.com
On Sunday, 15 September 2013 09:41:10 UTC+10, tomk wrote:
I want to preface my response with "I'm not an expert". With that in mind, I've given some more though to this subject.
Nor am I. Just bumping along, trying what seems it might work.
I think we may diverge slightly on the definition of a session. The code that I've written in the past basically associated a connection with a session. This means a session is related to a an IP address.I see no reason to suppose that a session can't be continued from multiple
IP addresses, over time. What you suggest might be a particular session
policy, and should be implemented as such. Your point raises the question
of whether sessions can be shared between browser instances simultaneously,
which is really interesting. I think I can see uses for that mode too.
What do you think?
Right, and that could work too. There is a coroutine for current connection, it could be used to stash state in, and that state could be mirrored to a db. I will mull over that approach, too, and see if it could be adapted. One downside is that the connection coro is *replete* with state, and the potential for collision is great. That just argues for a new coro per connection, though.
Each browser connection (i.e. window or tab) has its own set of session variables that keep track of the users navigation state for that connection. When the connection is broken then the session is cleaned up. Login management (which is distinct from session management) creates and maintains items that are nonvolatile across sessions (such as user preferences, etc.) When a user logs out then all the sessions on that IP address are cleaned up (even if the windows are open). Note that a session that isn't logged in can also be established and used for the "entry point" into a web site that requires login.
Taking that approach, though, makes it hard to associate an (admittedly abstract, implied,) 'user' with state. Each browser can have many windows, each window can have many connections. Where does the user abstraction arise/reside in this?
I think I was confused when I wrote the above. The time out actually occures relative to login (if no login then not at all except for client side cookie removal). The timeout value is stored with the users login settings. The sweep then checked to see if any of the sessions for an IP/login was active within the timeout period. If so then the check is rescheduled, if not then the users is logged out (from the associated IP address) and all the associated sessions were destroyed.
> how long a session can be idle. A background process sweeps the
> session table periodically and removes sessions that have exceeded
> their timeout value.
This is currently implemented, slightly differently ... there's a last
transaction time array by session, and a couple of methods to collect, and
to close, those sessions which have been idle for more than some period
(specified as in [clock add].) I think this achieves the goal of
controlling idle sessions without requiring per-session persistent storage.
Is per-session idleness useful?
Right, that's a login timeout. Or a last login value, which is useful in a Login/User subsystem. I'm trying to keep Session and Login distinct.
This was also poorly thought out so I think I will with draw the throttling comment.> Also note that
> the session manager is a good place to implement throttling, perhaps
> during serial number generation.
Well that's a good idea. One simple way to do that would be to cause
Session to check throttling, return a Suspend reply, then after some
timeout to actually perform the request processing, and Resume with its
result. Let me mull that over a while, but I think it's a clever use of
the facility.
No, I reckon it's a corker of an idea. At least per-user throttling is possible ... or per-session, aggregated between windows even. Terrific concept. I'll adopt it even if you're prone to abandon it.
Colin
Tom Krehbiel
Sep 18, 2013, 7:21:08 PM9/18/13
to wub-dis...@googlegroups.com
On 9/15/2013 7:55 PM,
wub-dis...@googlegroups.com wrote:
mcccol <mcc...@gmail.com> Sep 14 09:57PM -0700
On Sunday, 15 September 2013 09:41:10 UTC+10, tomk wrote:
> I want to preface my response with "I'm not an expert". With that in
> mind, I've given some more though to this subject.
Nor am I. Just bumping along, trying what seems it might work.
> I think we may diverge slightly on the definition of a session. The code
> that I've written in the past basically associated a connection with a
> session. This means a session is related to a an IP address.
Right, and that could work too. There is a coroutine for current
connection, it could be used to stash state in, and that state could be
mirrored to a db. I will mull over that approach, too, and see if it could
be adapted. One downside is that the connection coro is *replete* with
state, and the potential for collision is great. That just argues for a
new coro per connection, though.
> address are cleaned up (even if the windows are open). Note that a session
> that isn't logged in can also be established and used for the "entry point"
> into a web site that requires login.
Taking that approach, though, makes it hard to associate an (admittedly
abstract, implied,) 'user' with state. Each browser can have many windows,
each window can have many connections. Where does the user abstraction
arise/reside in this?
> IP/login was active within the timeout period. If so then the check is
> rescheduled, if not then the users is logged out (from the associated IP
> address) and all the associated sessions were destroyed.
Right, that's a login timeout. Or a last login value, which is useful in a
Login/User subsystem. I'm trying to keep Session and Login distinct.
I think the code modules can be separate but the server implementation should always process HTTP transactions through both layers (i.e. login/session). The behavior of the login layer is controlled by the domain. With this structure the login layer can be used to manage stuff that spans multiple sessions which you may want to do even if the user don't do an actual login. For instance I think throttling would be best implemented in the login module. More on this below.
> result. Let me mull that over a while, but I think it's a clever use
> of
> the facility.
No, I reckon it's a corker of an idea. At least per-user throttling is
possible ... or per-session, aggregated between windows even. Terrific
concept. I'll adopt it even if you're prone to abandon it.
I also think the idea is a good one but the implementation will
require some thought.
First the context. I expect a website implemented using wub to contain both a non-login portal domain to the website and one or more login domains. The login domains are of course optional. The non-login portal may be backed by simple static pages or an application that makes use of a session.
Now let me explain what I mean by throttling so we are on the same page. I expect throttling to be implemented as a variable response delay to an HTTP transaction. The amount of transaction delay would be a function of some computed traffic parameter.
So what are the types of denial of service (DOS) attacks that might be mounted against a single host?
First lets assume the attacker is using robots to perform the attack. Each robot runs in its own process. Depending on how the robot is implemented it may support serial HTTP transaction or parallel HTTP transaction (the equivalent of a multi-tab browser).
If the attack is run from a single host, then the following attacks come to mind.
A DOS attack on the website portal.
1) A single serial robot.
2) Multiple serial robots.
3) A single parallel robot.
4) Multiple parallel robots.
A DOS attack with website login.
1) A single serial robot.
2) Multiple serial robots.
3) A single parallel robot.
4) Multiple parallel robots.
The attack could also be mounted from a botnet using one or more of the above scenarios.
With the above in mind, lets take a look at how a simple implementation of login, sessions, an throttling might be done.
First the assumptions:
a) A particular instance of a login is only valid on the host (ipaddr) where it occurs.
b) No use will be made of port numbers which identify separate browser (robot) instances on a host.
c) From a users point of view a session is the state associated with browser tab (or page). There are many different ways to keep track of session state and none of them are explicitly managed by the browser. This means that the website implementer must define how session management will occur. All forms of session management, however, will require the storage of information some where in the DOM associated with each browser tab.
The login layer of the server performs initial processing on all transactions. This module creates and modifies records in a login table that looks similar to this.
== login table ==
1) ip address (KEY)
2) userid (KEY)
3) transaction time
4) transaction count
5) throttling value
6) login flag
When the login layer recieves an HTTP request it increments the transaction count and then delays by the throttling value (which may be zero). After the delay the code proceeds with a login (if necessary) and then passes control to the session module. The throttling value is set by a background task that priodically sweeps table 1 and calculates new throttling values. The table sweep code resets the transaction count value. The background task also checks the transaction time (of the last transcation) against the current time to see if a forced logout should occur. If a logout is to be forced then the login flag is set to false and the next time the user attempts to perform a transaction the login cookie is removed from the users browser and a redirect to the login screen is performed.
The session table will be similar to that shown below.
== session table ==
1) ip address (KEY)
2) userid (KEY)
3) session id (KEY)
4) keyword
5) value
As noted above the session id must be part of each transaction and is stored in the browser DOM for inclusion with the next transaction. The session table key fields are compatible with the login table so all sessions associated with a login can be cleaned up. It is normally recommended that the value of the session key be a random string (i.e. not serialized).
Colin, have you decided on a strategy for storage and recovery of the session key?
Tom K.
First the context. I expect a website implemented using wub to contain both a non-login portal domain to the website and one or more login domains. The login domains are of course optional. The non-login portal may be backed by simple static pages or an application that makes use of a session.
Now let me explain what I mean by throttling so we are on the same page. I expect throttling to be implemented as a variable response delay to an HTTP transaction. The amount of transaction delay would be a function of some computed traffic parameter.
So what are the types of denial of service (DOS) attacks that might be mounted against a single host?
First lets assume the attacker is using robots to perform the attack. Each robot runs in its own process. Depending on how the robot is implemented it may support serial HTTP transaction or parallel HTTP transaction (the equivalent of a multi-tab browser).
If the attack is run from a single host, then the following attacks come to mind.
A DOS attack on the website portal.
1) A single serial robot.
2) Multiple serial robots.
3) A single parallel robot.
4) Multiple parallel robots.
A DOS attack with website login.
1) A single serial robot.
2) Multiple serial robots.
3) A single parallel robot.
4) Multiple parallel robots.
The attack could also be mounted from a botnet using one or more of the above scenarios.
With the above in mind, lets take a look at how a simple implementation of login, sessions, an throttling might be done.
First the assumptions:
a) A particular instance of a login is only valid on the host (ipaddr) where it occurs.
b) No use will be made of port numbers which identify separate browser (robot) instances on a host.
c) From a users point of view a session is the state associated with browser tab (or page). There are many different ways to keep track of session state and none of them are explicitly managed by the browser. This means that the website implementer must define how session management will occur. All forms of session management, however, will require the storage of information some where in the DOM associated with each browser tab.
The login layer of the server performs initial processing on all transactions. This module creates and modifies records in a login table that looks similar to this.
== login table ==
1) ip address (KEY)
2) userid (KEY)
3) transaction time
4) transaction count
5) throttling value
6) login flag
When the login layer recieves an HTTP request it increments the transaction count and then delays by the throttling value (which may be zero). After the delay the code proceeds with a login (if necessary) and then passes control to the session module. The throttling value is set by a background task that priodically sweeps table 1 and calculates new throttling values. The table sweep code resets the transaction count value. The background task also checks the transaction time (of the last transcation) against the current time to see if a forced logout should occur. If a logout is to be forced then the login flag is set to false and the next time the user attempts to perform a transaction the login cookie is removed from the users browser and a redirect to the login screen is performed.
The session table will be similar to that shown below.
== session table ==
1) ip address (KEY)
2) userid (KEY)
3) session id (KEY)
4) keyword
5) value
As noted above the session id must be part of each transaction and is stored in the browser DOM for inclusion with the next transaction. The session table key fields are compatible with the login table so all sessions associated with a login can be cleaned up. It is normally recommended that the value of the session key be a random string (i.e. not serialized).
Colin, have you decided on a strategy for storage and recovery of the session key?
Tom K.
Colin
Reply all
Reply to author
Forward
0 new messages