I am currently working on a chatbot for Facebook Messenger. I am working with the Microsoft bot framework and the code is written in node.js.
I am interacting with a database through an api. With every request I have to pass an access token inside the request header. I have read on the internet that you would usually store such a token inside a cookie or web storage. However I also found out that you can't do that on Facebook Messenger. I was thinking about storing the access token inside a variable, but my concern is that this might not be secure. Is there any other secure way to store the access token?
I am fairly new to node.js and it is my first time working with tokens. Help is much appreciated.
You can use session.userData to hold your database token. If you are concerned about it being secure, then encrypted it before saving.
session.userData.dbtoken = encryptToken(token);
The token can later be retrieved and used when you need it:
var token = decryptToken(session.userData.dbtoken);
var databaseData = getUserDataFromDatabase(token);
https://docs.botframework.com/en-us/core-concepts/userdata/
Or, use a local database like NeDB: https://github.com/louischatriot/nedb This would be the most secure option, since the database would reside on your server.
I would suggest using express-session. for the following reasons.
Create a session middleware with the given options.
Note Session data is not saved in the cookie itself, just the session ID. Session data is stored server-side.
Note Since version 1.5.0, the cookie-parser middleware no longer needs to be used for this module to work. This module now directly reads and writes cookies on req/res. Using cookie-parser may result in issues if the secret is not the same between this module and cookie-parser.
Warning The default server-side session storage, MemoryStore, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.
Assuming this token does not change, you can store it as an environment variable, say TOKEN and access it in nodejs app as process.env.TOKEN.
Related
I'm trying to build a CMS on Node.JS and this far i managed to build everything only by including MySQL module. I would like to continue building all the CMS core modules without the use of extern libraries like Express. I'm working now on the session for Login purposes. By now, i can create cookies with the header Set-Cookie where i store some information of the user to recognize its session when he/she loads all the pages in the site, but i still can't find some way to create session variables without the use of express or some other frameworks.
I'd be thankful if someone could give me some example.
First off, unless you're building things yourself just because you want to learn how to do it all yourself, there's really no reason to re-invent things that have already been well engineered in existing modules. Because this is server-side code, there's really no penalty for using an already tested module that does what you want. So, my first recommendation would be to use Express and express-session. It does all the session management for you and will give you lots more time to work on the aspects of your project that will really help it succeed or fail.
And, THE top benefit of using node.js in the first place is being able to use the huge library of existing code available through NPM and Github.
Conceptually, here's how a session works in the node.js/web browser client/server world.
Incoming request from client to web server.
Server creates some sort of guaranteed unique cookie value and sets that as a cookie on the response.
Server also creates a serve-side session object and puts that object into some data store with the session cookie value as an index into that data store.
Now every time a future request arrives from that same client, it will be accompanied with that session cookie.
On each incoming request, the server can grab the session cookie value, use it as the key to look up the corresponding session object and get it.
Any request handler can then read data from the session object or write data to the session object.
In this manner you can keep data associated with a particular client secure and safe on the server and usable from one request to another.
If you're going to implement your own session system, you have to be able to create these unique session cookies and create some sort of session storage (can be anything from a Map object in memory to a database), implement session expiration and session store cleanup and then provide appropriate middleware or utility functions that makes it easy to use on any individual http request.
Since localStorage data can be changed easily, how can we make access controls and more things secure in the Angular App.
Suppose our localstorage contains:
data - {name:user, account_status:inactive,...}
The user can easily change the account_status from inactive to active and get all access.
I am not just concerned about access control but also the other localstorage data which is used in angular.
Can I encrypt the data from the node server and store it in localstorage and decrypt it back when i want to use with the same secret key. Will this have some adverse effects.
Please suggest some methods which can be used.
You can create a common service for localstorage operation which will perform the encryption when storing data in localstorage and decryption when getting data from localstorage. You should encrypt key and value both so it is not easy to change the value in localstorage. You can use CryptoJS for encryption.
That's execalty what happened back in the time with Spotify. The result ? With a little script, you could have spotify premium for free.
My point is, that you should not store sensitive data in the client side, and if you do so and use it, there should be a doucble checking (one from the client, one from the server) : if the user changes the values of the client, the server will check the validity of the requests anyway, and refuse resources to the user.
To finish, my point is that you don't need to encrypt your data, or to stop using local storage : just be clever and double-check the user permissions.
The type data you are trying to store should never to stored on local-storage, especially for a serious production app. Data should always be hashed/encrypted on the server and then sent to the front end for further manipulation.
I am using node.js. I was thinking of just storing a session id in the session variable, so that every time I make a request for a route, the server checks in the database whether the user with that session id is authorised to access that page.
This seems a bit inefficient, since there will be a database call for every page request. I know I could just store some data in cookies / session variable for this purpose to avoid the database call, but then I am susceptible to tampering..
How do other web developers handle this ?
A server-side session and associated encrypted session cookie used with https is secure. So, just keep a value in the server-side session that tells you whether that user has been authenticated or not and all you have to do is check that variable in the server-side session object. This is how every web-site I know does things.
The NPM module express-session used with a suitable session store will implement most of this for you.
If you have a specific reason why you think this isn't secure, please share those reasons so they can be discussed.
Here's a general article about securing node.js servers and point #6 is about securing session cookies: 9 Security Tips to Keep Express from Getting Pwned.
Super simple question that I'm having trouble wrapping my head around.
When using sessions with nodejs, are the sessions stored in the users browser? Or are the sessions stored on the server?
For example, if I'm using the express-session or passport.session(), where are these session cookies stored?
As #robertklep mentioned, sessions (in the way you're using them) are stored on the client, but only contain a session ID. When your request hits the web server, it'll then look up the session ID to grab the account from some sort of database / cache, then use it for the remainder of the request lifecycle.
If you're interested on learning more about this, you might want to check out this screencast I made a while ago which covers exactly how cookies work, and why -- as well as how to store them securely: https://www.youtube.com/watch?v=yvviEA1pOXw
Furthermore, if you're looking to build a site that doesn't use 'typical' server-side sessions, and works with modern client-side front-end web frameworks like Angular.js / React.js / etc., you might want to investigate JSON Web Tokens (JWTs). These tokens allow you to create 'dumb' cookies that don't require a database lookup on the server, and can speed up your web apps / API services pretty dramatically: https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/
Hope this helps!
The fine manual states:
Note Session data is not saved in the cookie itself, just the session ID. Session data is stored server-side.
express-session sends a cookie to the browser (which stores it), which contains a unique session id. The data itself is stored on the server (depending on which session store you use, this can be in memory, Redis, MongoDB, ...).
The session id in the cookie is merely used as a key to look up the actual data in the session store.
I am developing an express app which serves as a REST api with web client and may be future mobile clients. I am using a Oauth 2.0 token authentication for both clients. This gives a good deal of security against CSRF. I want to know How to provide security against XSS.
*I made the tokens validity period very less, requiring the client to request with refresh_tokens and other client details for access_tokens. This makes it a bit safe but not entirely*.
I am concerned with the with client_id and client_secret being stolen since its present in the front-end javascript code and it being used by other client to validate. I am thinking of using a JWT for the client authentication, will this be helpful?
Data Sanitisation is another which I am confused about. There are modules like validator, express-validator which give regex validation. According to this blog post JSON Schema validations are fast. In the REST Api JSON will used for data exchange so I was wandering why can't I use modules like tv4 or any other JSON Schema validators for data validations?? I am not asking for suggestions to use what, I just want to know the basic difference in the kind of validations each provide and specially from a point of view of XSS protection and sanitisation.
So you have three separate questions here:
1) How to protect against XSS: As long as you use JSON to share data between the client & server and use standard libraries/methods for encoding/decoding JSON, you are mostly protected. After this, you only need to worry about DOM Based XSS, which is harder to be protected. But basically you need to be careful for not using any user supplied input that can be interpreted as anything other than "string" you intended. (please visit https://www.owasp.org/index.php/DOM_Based_XSS for more information)
2) client_id and client_secret being stolen: This does not seem to be possible in the way you require. In your scenario (where you distribute clientid&secret in javascript code) there is no way on server side to know whether the request is coming from your client or a fake one.
3) Data Sanitisation: I see two levels of sanitisation in the libraries you & blogpost mentioned. validator or express-validator is mostly used to validate individual data fields. Whereas others can validate a JSON object structure in addition to what "validator" does. If you require all exchanged data is in JSON format (as suggested for XSS protection as well) then you can use json object validators like tv4. (the only drawback of tv4 seems to be allowing latest json spec, which should not be a problem for you)
BTW: It would be easier if you specified your client application is purely client-side javascript (angularjs). I could not understand your question until I found this info in comments.
I have developed Restful Authentication System same as your case with NodeJS, MongoDB, ExpressJS in order to provide flexible authentication system for multiple clients like web, mobile. Let me summarize you the important points.
I have used html5 localstorage to keep user token after first time login by using login form. When user click login button, username and password sent to server and validated. After successfull validation, unique access token sent to client and stroed in local sotrage. If you have vulnerability on your client application, anyone can get your access token and make request by using your token. In order to prevent this, you need to use ssl connection for your app. This problem does not exists only restful auth systems, this can be happen in server side session storage. Let me explain this. I am using PHP for session. When user logs in, user session saved in to temp file on server and that session id sent to client browser. Somehow, if I can get that id, I can make request with header that contains someone's session id. When you compare, restful auth seems more flexible to me. I suggest you to ;
Use SSL connection prevent your access_token from to be stolen
Generate access token with powerfull encryption methods(SHA-256)
Small expire time for access_token the better
Implement a middleware for token validation for backend service usage. I mean make your requests like;
/use/update/{userid}
with custom headers contains your user token.
Design 5 attempt failed system for your backend. If user cannot success at 5 time try, this means someone tries to send random tokens in order to get in to system. Detect and block that IP
You can also deny requests other than browser clients.
Those are the informations that I have learnt while implementing the project.