Control re-use of Bokeh session IDs

I am running a Bokeh server app with --session-ids=external-signed. The secret key used to generate valid signed session IDs is only known to my Django application in which I have embedded the Bokeh server. The reason for this is that I want only users that have authenticated through my Django app to be able to access the Bokeh app.

However, once the Bokeh page is loaded, I can use e.g. Chrome’s developer console to find the - tag in the HTML document and simple copy-paste the session ID out of there. This session ID is still valid, and could thus be passed on to any third party who will be able to bypass authentication by simply constructing an URL like https://mydomain.com/bokeh/main?bokeh-session-id=[session_id_here].

Are there any control mechanisms available to disable re-use of Session IDs, and if not, how could this be done?

I’m thankful for any ideas and pointers.

Hi,

Isn’t this true of almost any auth scheme? Usually the way you login to a website is that the site sets a cookie (often a signed cookie). Anyone can then copy that cookie out of their browser and use it in another browser, as far as I know. They could also of course tell someone else their password. The security relies on the user of the logged-in browser not sharing their credentials/cookie/token with someone else.

It might be nice if bokeh embedded a timestamp in its signed id, to enable expiration. Right now the only way to expire these is to change the secret afaik.

I may be missing something though.

Havoc

···

On Fri, Dec 9, 2016 at 12:07 PM, Florian Pieront [email protected] wrote:

I am running a Bokeh server app with --session-ids=external-signed. The secret key used to generate valid signed session IDs is only known to my Django application in which I have embedded the Bokeh server. The reason for this is that I want only users that have authenticated through my Django app to be able to access the Bokeh app.

However, once the Bokeh page is loaded, I can use e.g. Chrome’s developer console to find the - tag in the HTML document and simple copy-paste the session ID out of there. This session ID is still valid, and could thus be passed on to any third party who will be able to bypass authentication by simply constructing an URL like https://mydomain.com/bokeh/main?bokeh-session-id=[session_id_here].

Are there any control mechanisms available to disable re-use of Session IDs, and if not, how could this be done?

I’m thankful for any ideas and pointers.

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225c5f0-f231-45fb-bc97-98eaa2786da6%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Havoc Pennington

Senior Software Architect

It’s my first foray into handling sessions, but I got onto this topic as I’m trying to secure my Bokeh server and I’m already using social authentication through Django. Embedding the server into another framework is the only way I’ve found so far to add a proper authentication layer, and signed session IDs the best idea I have to make the Bokeh server accessible only to the web app. So basically I’m just lookin for the strongest user control while embedding the Bokeh server in a framework with autoload_server.

Automatic session ID expiration would be nicer, I think, than having to update the secret keys in both my web application and my Bokeh server process. Otherwise, are there any examples of work where a Session ID is checked against previous Session IDs on the side of the Bokeh app? This is something I would try to implement.

···

On Fri, Dec 9, 2016 at 6:16 PM, Havoc Pennington [email protected] wrote:

Hi,

Isn’t this true of almost any auth scheme? Usually the way you login to a website is that the site sets a cookie (often a signed cookie). Anyone can then copy that cookie out of their browser and use it in another browser, as far as I know. They could also of course tell someone else their password. The security relies on the user of the logged-in browser not sharing their credentials/cookie/token with someone else.

It might be nice if bokeh embedded a timestamp in its signed id, to enable expiration. Right now the only way to expire these is to change the secret afaik.

I may be missing something though.

Havoc

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE0qEZbsbrOjWxcLiqEbxZxkFyf%2BCK%2BN-VuYnm4ZTQdggw%40mail.gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

On Fri, Dec 9, 2016 at 12:07 PM, Florian Pieront [email protected] wrote:

I am running a Bokeh server app with --session-ids=external-signed. The secret key used to generate valid signed session IDs is only known to my Django application in which I have embedded the Bokeh server. The reason for this is that I want only users that have authenticated through my Django app to be able to access the Bokeh app.

However, once the Bokeh page is loaded, I can use e.g. Chrome’s developer console to find the - tag in the HTML document and simple copy-paste the session ID out of there. This session ID is still valid, and could thus be passed on to any third party who will be able to bypass authentication by simply constructing an URL like https://mydomain.com/bokeh/main?bokeh-session-id=[session_id_here].

Are there any control mechanisms available to disable re-use of Session IDs, and if not, how could this be done?

I’m thankful for any ideas and pointers.

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225c5f0-f231-45fb-bc97-98eaa2786da6%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.


Havoc Pennington

Senior Software Architect

Florian Pieront
Düsseldorfer Straße 27
10707 Berlin
0176 3914 6345

Another idea (not completely sure it is relevant or workable, this is not my area of expertise), but the app code has access to the complete HTTP request. So if the Django Auth layer can set cookies, etc. then I believe the app could check for those.

Bryan

···

On Dec 9, 2016, at 11:30 AM, Florian Pieront <[email protected]> wrote:

It's my first foray into handling sessions, but I got onto this topic as I'm trying to secure my Bokeh server and I'm already using social authentication through Django. Embedding the server into another framework is the only way I've found so far to add a proper authentication layer, and signed session IDs the best idea I have to make the Bokeh server accessible only to the web app. So basically I'm just lookin for the strongest user control while embedding the Bokeh server in a framework with autoload_server.

Automatic session ID expiration would be nicer, I think, than having to update the secret keys in both my web application and my Bokeh server process. Otherwise, are there any examples of work where a Session ID is checked against previous Session IDs on the side of the Bokeh app? This is something I would try to implement.

On Fri, Dec 9, 2016 at 6:16 PM, Havoc Pennington <[email protected]> wrote:
Hi,

Isn't this true of almost any auth scheme? Usually the way you login to a website is that the site sets a cookie (often a signed cookie). Anyone can then copy that cookie out of their browser and use it in another browser, as far as I know. They could also of course tell someone else their password. The security relies on the user of the logged-in browser not sharing their credentials/cookie/token with someone else.

It might be nice if bokeh embedded a timestamp in its signed id, to enable expiration. Right now the only way to expire these is to change the secret afaik.

I may be missing something though.

Havoc

On Fri, Dec 9, 2016 at 12:07 PM, Florian Pieront <[email protected]> wrote:
I am running a Bokeh server app with --session-ids=external-signed. The secret key used to generate valid signed session IDs is only known to my Django application in which I have embedded the Bokeh server. The reason for this is that I want only users that have authenticated through my Django app to be able to access the Bokeh app.

However, once the Bokeh page is loaded, I can use e.g. Chrome's developer console to find the <script> - tag in the HTML document and simple copy-paste the session ID out of there. This session ID is still valid, and could thus be passed on to any third party who will be able to bypass authentication by simply constructing an URL like https://mydomain.com/bokeh/main?bokeh-session-id=[session_id_here].

Are there any control mechanisms available to disable re-use of Session IDs, and if not, how could this be done?

I'm thankful for any ideas and pointers.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a225c5f0-f231-45fb-bc97-98eaa2786da6%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

--
Havoc Pennington
Senior Software Architect

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE0qEZbsbrOjWxcLiqEbxZxkFyf%2BCK%2BN-VuYnm4ZTQdggw%40mail.gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

--
Florian Pieront
Düsseldorfer Straße 27
10707 Berlin
0176 3914 6345

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAHmY%3DBLQJ5RxdKHwFFEJjH6C5nWse8%3DVKnC9FbfS48nuQ_dVOg%40mail.gmail.com.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.