Right now I have a Django-tornado-sockjs stack and want to be able to pass the session id from the site into a sockjs cnnection. What is the most secure way to pass the Django session id to my tornado backend? It sounds like people are recommending I store the session id in cookies and then send the data over when sockjs opens a connection. But isn't this less secure? It doesn't seem like Sockjs supports passing http-only cookies.
Any alternatives? At some point do I just have to accept I will have pass the encrypted session id though html or cookies and is there a real danger to this?
I'm far from a security expert but AFAIK requiring SSL for all auth requests is a baseline requirement to keep things secure if security is important.
We don't use session ids but instead generate an auth token on login, store it in redis which acts as the message queue between django and sockjs-tornado, and also pass it into the rendered page that establishes the sockjs connection via https. Then our sockjs-tornado process checks for the correct auth token in redis as part of the payload in a connection event.
We use haproxy to handle SSL uniformly across all the requests and dispatch to the appropriate backend which has been working great.
Related
I am trying to implement simple slack bot. So I have configured hubot which will take inputs from slack and passing it to my webapp (django app) and it will take whatever the response from django-app and will reply to slack.
In this process I am trying to store session in django using request.session but that is not reflected in slack. If I am accessing the django-url in browser it is able to store sessions and getting proper response with session.
So does the problem lie with slack or my approach and is there a way to store sessions in hubot when requesting to django-app ??
I can not speak to the specific technologies you use (hubot, django), but I am using server sessions with my Slack apps all the time and can give you a general answer on how it works. Note that my Slack apps are build with PHP, but I think its safe to assume that the principles are the same.
Slack does not support sessions
In general Slack does not support sessions or context. Instead everything is request based. So if you want to have sessions to keep a functional context between requests you need to organize that by yourself in your Slack app.
Challenge for using server sessions with server requests
One challenge is that most server sessions are designed to work with a client that uses a browser. e.g. a PHP server session will store a cookie in the browser, so the server knows, which requests belong to the same session. This does obviously not work with Slack, since all Slack requests are coming from a server and and there is no browser involved.
Approach for using server sessions with Slack
But you can use severs session with Slack with these two tricks:
Manually set the session ID
Usually the ID of a session is chosen automatically by the server, but you can also set it manually. This allows you to tell the server to continue an existing session that was started with a previous request.
Include session ID in Slack control
The functional session of a user is tied together by the Slack controls he uses. (e.g. an interactive button). Its possible to include custom data in those controls (see this answer for details) and that allows you to include the current session ID in it.
Full approach
You include the ID of your current session in the Slack controls, that you create with your app (e.g. an interactive button). Once the user clicks a button Slack will send a request to your app, which will include the session ID. That allows your app to continue an already started server session.
I am going to write a tool, which authorizes on AD server, sends some data(objectID for example) to the backend server. Backend checks this data. If the client has enough rights, backend will send some data back to the client.
It doesn't look secure for me, to send an objectID or something like this, because it is too easy to still it and use again.
How can i make it more secure? Is it possible to send some session id to the backend and on the backend side verify the user, using this id, his ip and something else?
Thanks.
You can't authorize on the client. Anyone can examine the protocol and hack it. You send your request and credentials securely to the server which does the AD authentication. It then creates a session for which auth is approved.
I'm struggling to understand how flask_login or django knows when a user logs in that they retain access?
If I were to use ReactJs or Angular with flask-restful or django/tastypie, what is being added to the header/body of future json requests to ensure that my user stays logged in?
This is done via sessions, which is based on cookies. From the Flask documentation:
In addition to the request object there is also a second object called session which allows you to store information specific to a user from one request to the next. This is implemented on top of cookies for you and signs the cookies cryptographically.
and the Django docs:
Django provides full support for anonymous sessions. The session framework lets you store and retrieve arbitrary data on a per-site-visitor basis. It stores data on the server side and abstracts the sending and receiving of cookies. Cookies contain a session ID – not the data itself (unless you’re using the cookie based backend).
So, the requests to the server automatically include a cookie that indicates some ID that the server then uses to figure out what the session data should be for the given user. In general, when Ajax requests are made from client-side applications to the server, this cookie is included and so ensures that the user is considered to be logged in for those requests.
In some cases, you can also (optionally) manually add a special header to HTTP requests to indicate which user is logged in.
See also Securing RESTapi in flask for some more information.
If you use REST service then you should take a look at oAuth. In other words it uses token which you attach to every request from client to server and the last can determine which user sent this request by this token.
On the other hand, you can use cookie or session to determine a user status. And in this case you don't need to add any headers to your request.
Also I recommend you this package for Django - Django Rest Framework (there you can read more about token and auth via REST) and this extension for Flask.
I need to come up with a scheme for remote devices running linux to push data to a web service via https. I'm not sure how I want to handle authentication. Can anyone see any security risks by including some kind of authentication in the body of the request itself? I'm thinking of having the request body be JSON, and it would look like this:
{
'id':'some unique id',
'password':'my password',
'data':1234
}
If the id and password in the JSON don't match what is in my database, the request gets rejected.
Is there a problem with this? Is there a better way to ensure that only my clients can push data?
That scheme is primitive, but it works.
Usually a real session is preferred since it offers some advantages:
separation of authentication and request
history of requests in a session
credentials get sent only once for multiple requests
flexible change of authentication strategy
...
I have this one question in mind that in login sessions does client have to maintain anything so that server uniquely identify client and in multiple client requests response to correct client. I don't understand this sessions and cookies. I asked many about this some say that its server job to maintain sessions and client just send normal request.
Yes, the client must keep track of something, called a session ID. Most commonly, it is a cookie. However, a less used approach is to rewrite all links to pass the session ID in the URL.
Example ID names are ASP.NET_SessionId and PHPSESSID.
Matthew's answer is correct.
It is the server's job to keep track of login sessions, and it's the client web browser's job to keep track of cookies. When you provide username & password on a site, a cookie is provided by the web server to your browser, which will automatically be provided along with subsequent requests to the web server. This cookie uniquely identifies a session which belongs to a particular user on the site (even the "guest" user). So, the server keeps track of all client sessions, and each client remembers its session cookie & provides it along with all its requests. It's a simple scheme. Using Firebug for example, you can see what the web requests look like when you log into a site. You might find that interesting to look at.
It is the server which will maintain the sessions. And it is the server responsibilty to allow session tracking happen. Clients need not bother about sending any information explicitly. As Cliens also sends Cookies saved on the client along with every request, server might use Cookies for sesssion tracking.
Note: Cookies are just one of the way to implement Session Tracking. It is also the best way
So server Cookies as one of the ways to handle session tracking.
It can also be done in other ways:
URL rewriting - the application/server should append the session id in all URL's/Links. When those are invoked from the client the session comes to the server along with the URL.
Hidden Form Fields - The forms may contain hidden input type with session id as field value. When the form is posted, the session id comes along with the form data.