未加星标

Securing Node.js: Managing Sessions in Express.js

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Every user interaction with your application is an isolated and individual request and response. The need to persist information between requests is vital for maintaining the ultimate experience for the user and the same applies for Node.js web application such as the popular Express.js framework.

A common scenario that most developers can identify with is the need to maintain that a user has authenticated with an application. In addition, it’s quite common to retain various personalized user information that is associated with a session as well.

In the last Securing Node.js article, we looked at enforcing requirements on user accounts. Similarly, we are going to look at how we can securely set up sessions in our application to mitigate risks such as session hijacking. We’re going to look at how we can obfuscate session ID’s, enforce a time-to-live in our sessions, set up secure cookies for transporting sessions, and finally the importance and role of Transport Layer Security (TLS) when it comes to using sessions.

Setting of Sessions in Express.js

We’re going to use the NPM module express-sessions , a very popular session module that has been highly vetted by the community and constantly improved.

We’ll pass our express app object to a function to wire up the express-session module:

"use strict"; // provides a promise to a mongodb connection import connectionProvider from "../data_access/connectionProvider"; // provides application details such as MongoDB URL and DB name import {serverSettings} from "../settings"; import session from "express-session"; import mongoStoreFactory from "connect-mongo"; export default function sessionManagementConfig(app) { // persistence store of our session const MongoStore = mongoStoreFactory(session); app.use(session({ store: new MongoStore({ dbPromise: connectionProvider(serverSettings.serverUrl, serverSettings.database) }), secret: serverSettings.session.password, saveUninitialized: true, resave: false, cookie: { path: "/", } })); session.Session.prototype.login = function(user, cb){ this.userInfo = user; cb(); }; } What’s Going On Here

We're importing the session function from the express-session NPM module and passing the session function a configuration object to set properties such as:

Store.I’m using MongoDB as my backend, and I want to persist the application sessions in my database, so I am using the connect-mongo NPM module and setting the session store value to an instance of this module.However, you might be using a different backend, so your store option could be different. The default for express-session is an in-memory storage.

Secret.This is a value used in the signing of the session ID that is stored in the cookie.

Cookie.This determines the behavior of the HTTP cookie that stores the session ID.

We will come back to some of the elements I didn’t mention here shortly. For now, let’s look at the first change we need to make with securely managing user sessions in our application.

Session Hijacking

The most prevalent risk that user sessions face is session hijacking. Sessions are much like a driver’s license or passport and provide identification for our users. If an attacker can steal the session of another user, they have essentially become that other person and can exploit the user or perform malicious activity on behalf of that user. The risk is even greater when the identity is someone with escalated privilege such as a site admin.

Session Identification

The first step that any attacker will perform is reconnaissance to determine where vulnerabilities lie in your application. Part of that reconnaissance is observing tell-tale signs of the underlying framework, third-party modules and any other software that in itself might contain vulnerabilities that can be exploited.

In the case of our sessions, a tell-tale sign is the name of the session cookie connect.sid,which can help an attacker identify the session mechanism being used and look for specific vulnerabilities.

Tip: Of course we don’t want to use vulnerable software. However, secure software todaycould be vulnerable tomorrow with a faulty update. So, keeping details about our application obfuscated can help make it that much more difficult for an attacker to exploit.

Therefore, the first thing we want to do is make that as hard to determine what session mechanism is used as possible, let’s update our session configuration object with a name property:

app.use(session({ store: new MongoStore({ dbPromise: connectionProvider(serverSettings.serverUrl, serverSettings.database) }), secret: serverSettings.session.password, saveUninitialized: true, resave: false, cookie: { path: "/", } name: "id" })); What Did We Do?

By providing a name property with a value of ID, it will be that much more difficult for any attacker to determine the underlying mechanisms used by our application.

Now that we have provided a level of obfuscation to our sessions, let’s look at how we can reduce the window of opportunity for session hijacking.

Session Time-to-Live

Unfortunately, sometimes the best-laid plans can be undermined. A perfect example is a user who didn’t log off a public computer and an attacker who was able to physically obtain access and operate as the previous user.

Therefore, we can reduce the window that the session is alive and directly impact the chances that an attacker can exploit a user or the system from a hijacked session by limiting the life of a session.

As I mentioned before, the express-sessions NPM module provides a store property where you can set a separate storage mechanism for storing your sessions (the default is in-memory). Therefore, the following change is tied to your backend storage of sessions. In my case, I am storing my sessions in a MongoDB database, and using the NPM module connect-mongo for easily storing sessions in the database.

In this case, I can provide the ttl property a value in seconds in the configuration object provided to the MongoStore, the default is 14 days (14*24*60*60):

app.use(session({ store: new MongoStore({ dbPromise: connectionProvider(serverSettings.serverUrl, serverSettings.database), ttl: (1 * 60 * 60) }), //remaining - removed for brevity })); Cookie Time-to-Live

Not nearly as important as the session’s TTL, we can also set the expiration of the cookie, which is used for transporting the session ID, in the session configuration object.

We can provide a maxAge property and value in milliseconds in the cookie object.

app.use(session({ //..previous removed for brevity cookie: { path: "/“, maxAge: 1800000 //30 mins } })); However, security and user experience is always a balancing act and in this case, reducing the time-to-live of the session will d

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: Node.jsMongoDB
分页:12
转载请注明
本文标题:Securing Node.js: Managing Sessions in Express.js
本站链接:http://www.codesec.net/view/522999.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(33)