socket.request and socket.request.res - node.js

I am trying to use session middleware to the socket io server, but cannot understand what the (socket.request) and (socket.request.res) are.
var sessionMiddleWare = session({
secret: 'fastcampus',
resave: false,
saveUninitialized: true,
cookie: {
maxAge: 2000 * 60 * 60
},
store: new SequelizeStore({
db: db.sequelize
}),
});
app.use(sessionMiddleWare);
...
var server = app.listen(port, function(){
console.log('Express listening on port', port);
});
var listen = require('socket.io');
var io = listen(server);
io.use(function(socket, next){
sessionMiddleWare(socket.request, socket.request.res, next);
});
require('./libs/socketConnection')(io);
I`m confusing with the
io.use(function(socket, next){
sessionMiddleWare(socket.request, socket.request.res, next);
});
because when I use the sessionMiddelWare in the local app,
just using
app.use(sessionMiddleWare)
Need some help.. thanks

Here's a breakdown of what's happening in the code that got you puzzled:
You have cookie session middleware running in your express app, just doing what it usually does (adding session data to each HTTP request which is received in your express app). BUT - you are also integrating socket.io into your express app. Websocket data transmission is initiated via the HTTP protocol (where your cookie session middleware is trustfully adding the session info each time), but it then switches to the websocket protocol - where you don't have your session info anymore. You want your session info to carry on from the HTTP request which initiated socket data transmission into the socket data transmission itself. And so you get:
io.use(function(socket, next){
sessionMiddleWare(socket.request, socket.request.res, next);
});
The first line tells socket.io to use a middleware ("io.use"), a function which will be called each time you have data transmission via socket.io. You pass to this function two argument - socket and next. Next is simply a function which tells express.js to move on to the next piece of middleware once the present middleware has done it's thing. It's the "socket" argument which causes the confusion about this code, but here's what it does:
In the second line you are calling the function sessionMiddlWare (remember - it will be called each time an HTTP requests results in initiation of Websocket data transmission) and pass it three arguments: The third and last argument is "next", simply go to the next middleware once this middleware which initializes sessionMiddleWare has done its job.
The first argument (socket.request) is simply a reference to the HTTP request which initiated the socket data transmission (reference: https://socket.io/docs/server-api/#socket-request). This is where you accomplish what you set out to do, because this reference to the HTTP includes the session data - which is now included in your websocket transmission!
The second argument (socket.request.res) is the really puzzling one. It's task is to tell sessionMiddleWare if it should or should not save the session data for the transmission that just happened (reference). Notice that you don't necessarily want sessionMiddleWare to save the session data - you are most probably satisfied if the server and client have the right record of the data and so you can forget about the middle man (the sessionMiddleWare, that is).
Furthermore - This doesn't seem to work! developers trying to save the session data within the sessionMiddleWare report that it doesn't happen anyway (see the reference to the github thread in this paragraph). So you can pretty much just use:
sessionMiddleware(socket.request, {}, next);
and get the same results without the mysterious socket.request.res argument ;)
proof for this in the comment thread to the Answer in this stack overflow discussion.
Hope it's clearer now!

Related

How to secure my react app api with csurf?

I am trying to add csrf protection to my react app but I am getting an error Invalid token all the time
import bodyParser from 'body-parser';
import cookieSession from 'cookie-session';
import passport from 'passport';
import csrf from 'csurf'
import config from '../../config'
import AuthRoutes from "./routes/AuthRoutes";
/* Test only */
import cookieParser from 'cookie-parser';
const session = cookieSession({
maxAge:24 * 60 * 60 * 1000,
keys:[config.COOKIE_KEY],
name:'authentication',
});
export default app => {
app.use(bodyParser.urlencoded({
extended: true
}));
app.use(bodyParser.json());
app.use(session);
app.use(passport.initialize());
app.use(passport.session());
/* Test */
app.use(cookieParser());
app.use(csrf({ cookie: true }));
app.use(function (err, req, res, next) {
if (err.code !== 'EBADCSRFTOKEN') return next(err)
// handle CSRF token errors here
res.status(403)
res.send('form tampered with')
})
/*Passport Config*/
require('../../services');
/* Register, Login these are routes i want to protect */
AuthRoutes(app);
}
You need to:
1. Configure csrf library on the server. This ensures the library will send the first piece of data attached to the server responses.
2. Use csrf library on the server to generate the second piece of data and attach it to the server response (e.g. HTML form sent to the client). After this step is completed the server response will carry two pieces of CSRF data.
3. On the client take the second piece of data and insert it into the request you are about to send (e.g. the form you are about to submit).
Step 1
So far only the step (1) has been completed. You asked the csrf library to send the first piece of data as a cookie. You could have used a better configuration:
app.use(csrf({cookie: {
httpOnly: true,
}}));
It ensures the browser won't allow any JS on the client to touch the first piece of data inside the cookie which is good because there is no legit reason for any script to know what is inside this cookie. Later on, in production and when you use HTTPS, you can optionally add secure: true to the above configuration to make the server refuse to send this cookie over connections that are not secure.
Step 2
To get the second piece of data call csrfToken(). The csrf middleware added another property to Request object for your convenience so it can be called like this: const secondPiece = req.csrfToken(). You can put the second piece of data into the server responce in any way or manner you like: into another cookie with an arbitrary name (except for the _csrf name already taken by the step 1 cookie) or into HTTP header named as you like.
For example this code will put it into another cookie:
res.cookie('XSRF-TOKEN', req.csrfToken());
Step 3
On the client write JS to get the second piece of data and put it into one of the predefined places/locations (inside the request to be sent to the server) where csrf middleware searches for it by default.
Just in case, any solutions doesn't work.
I just had days of debugging caused by incorrect naming of the cookie. Make sure to name your cookie XSRF-COOKIE(take note it uses - symbol) because I incorrectly named mine using underscore XSRF_COOKIE and this bit my ass for days.

Is it okay to not send a response to urls that people are pentesting my node/express site?

I log all 404s on my website. I keep getting them for pages I haven't linked to, and it's clearly someone (a bot) trying to find admin pages / secure files on my site such as /wp-admin.php;
router.get('/wp-admin.php', function(req, res, next) {});
I tried this and it doesn't seem to hold up the server, it just outputs something like this a minute later:
GET /wp-admin.php - - ms - -
Is there any detriment to adding routes such as that, where no response is sent, possibly wasting their time?
router.get('/wp-admin.php', function(req, res, next) {});
This will cause express to time out and close the connection. This will make Denial of Service attack easier for hackers and jam up your node server.
You can always use some kind of rate limiters to prevent continuous request from a certain IP.
express-rate-limit
is a can be used for this. It is simple express middleware
As noted in the already accepted answer, an Express route like that will leave you vulnerable.
I recommend going one step further and tearing down those requests using req.destroy.
I'm not sure of the implications of Express being included, here, though. For example, is the request body being read automatically by a middleware upstream of this request handler you've shown? If so, that would be an attack vector that makes the mitigation I'm suggesting useless.
Regardless, to demonstrate what I am suggesting with a vanilla HTTP server:
var h = require('http')
h.createServer(function(req, res) {
// tear down the socket as soon as the request event is emitted
req.destroy()
}).listen(8888, function() {
// send a request to the server we just created
var r = h.request({port: 8888})
r.on('response', console.log.bind(console, 'on_response'))
r.on('error', console.log.bind(console, 'on_error'))
r.on('timeout', console.log.bind(console, 'on_timeout'))
// abort will be emitted to the caller, but nothing else
r.on('abort', console.log.bind(console, 'on_abort'))
r.end()
})
You could also call socket.destroy in the connection event of the HTTP server if you're able to identify the calling agent as a bot (or whatever) somehow.
var h = require('http')
h.createServer(function(req, res) {
res.send('foo')
}).on('connection', function(socket) {
// pretend this ip address is the remote address of an attacker, for example
if (socket.remoteAddress === '10.0.0.0') {
socket.destroy()
}
}).listen(8888, function() {
// send a request to the server we just created
var r = h.request({port: 8888})
r.on('response', console.log.bind(console, 'on_response'))
r.on('error', console.log.bind(console, 'on_error'))
r.on('timeout', console.log.bind(console, 'on_timeout'))
// abort will be emitted to the caller, but nothing else
r.on('abort', console.log.bind(console, 'on_abort'))
r.end()
})

Node.js variables for current request only?

I am very new to Node.js, and I was wondering if that, except for session(), I could use a "storage" to store variables for the current request?
I have an API which is based on an Authorization header, and a pool of valid tokens stored in Redis.
Therefore I don't have a session and don't want to.
But I would like to store variables for further use during this request. For example, I would like to store the user_id corresponding to the token found in Redis, so that I can use it wherever I want.
If I do something like:
app = express();
app.user_id = 1;
Is it ok, or will my user_id become global to all requests handled by the app? (in short: is the app instanciated for each request handled by the server, or is it persistent?)
If this is not ok, how could I achieve something like this without sessions?
Thank you for any help :)
The app handles all requests, and would only be created once on startup, but req lives for only the lifetime of the request. Keep in mind that the req in Express is just an object, and as such, can be assigned values. So if you wanted to allow the controller to have access to some value (similar to sessions), you could do something like this:
var express = require('express');
var app = express();
// middleware that assigns a value '123' to 'req.user_id'
app.use(function(req, res, next) {
req.user_id = 123;
next();
});
// controller which responds with the 'req.user_id'
app.get('/hello', function(req, res){
res.send('req.user_id: ' + req.user_id); // responds with req.user_id: 123
});
app.listen(3000, function() {
console.log('Listening on port 3000');
});
In the above example, the middleware that I created assigns a value to the request, called user_id. This value lives for the life of the request. You could do a similar thing to assign a dynamic value to the req so that you can access it via your controllers.

Node.js - Trying to avoid globals...how do I keep track of a user object?

Ok, so here is the scenario. I have the user log into my app with facebook. When this happens Passport saves it to the Session (req.user). This works all well and good when I am working in a page that has access to the request object, but I find myself in the situation where I don't have access to request, but I need to check the user object.
Case in point. I am using socket.io and when I am working with the sockets and the methods surrounding them, I don't have access to the request object and therefore I can't get user info.
I keep hearing that I need to stay away from globals whenever possible, but I can't see a way around it.
Thoughts?
Below is an example of me working with sockets. This module is called from my server.js file.
function loadSockets(io)
{
var articleCommand = require('./middleware/ArticleCommand');
io.sockets.on('connection', function (socket) {
socket.on('getArticles', function(){
if (NEED USER INFO HERE !== null){
articleCommand.getArticlesByUser(NEED USER INFO HERE, function(error, articles){
io.sockets.emit('articlesRetrieved', error, articles);
});
}
});
});
}
exports.loadSockets = loadSockets;
Update
Ok, so based on the commenters advice I have installed this: https://github.com/aviddiviner/Socket.IO-sessions and applied it...but my session is always null in my sockets.
Here is what I have.
var socket = sio.enable({
socket: io.listen(server, {'log level': 1, 'heartbeat': false}),
store: mystore, // this is my Redis store
parser: express.cookieParser()
});
later on...when processing my sockets
socket.sockets.on('connection', function (socket, session) { ...
The session is always null...even though my passport has loaded up my session correctly.
Thoughts?
Ok, so for posterity's sake, here is what I did to fix this issue.
You can see from my update above that I tried to use the SocketIO-sessions module, but that didn't work.
After more research I found that I needed to make sure I got the passport session since that is what is doing my authentication.
I found this little gem: https://github.com/jfromaniello/passport.socketio
This worked like a charm. The only thing that took some figuring out is getting the key setup correctly (they assume you know how to do that in the example).
sio.set("authorization", passportSocketIo.authorize({
key: 'MYKEY',
secret: 'SECRET',
store: mySessionStore
}));
Out of the box, your key is not set. To do that simply set it up with your app like so:
app.use(express.session({
secret: "SECRET",
store: mySessionStore,
key: 'MYKEY',
cookie: { secure: false, maxAge:86400000 }
}));
Hope this helps someone.
David

Get SESSIONID in nodeJS

Now, after some hours of playing around with nodejs and socket.io, I'm getting a couple more problems - one being, that I need to get the sessionID inside node.js, whitout using app.get('/' ... - since that event doesnt seem to fire when socket.io connects, it only fires .on('connection', function( ...
var express = require('express')()
express.set('port', process.env.PORT || 8080)
var server = require('http').createServer(express)
var socket = require('socket.io').listen(server)
server.listen(express.get('port'))
// this event is fired, get('/', ... isnt!
server.on('connection', function(stream) {
// ??
} )
The Session is initially created by the PHP application, as the user logs in. Session data is stored in the database, and the key I need to access that data is the SESSION ID. What's the easiest way to get to it? Like mentioned, I found a couple examples that used app.get('/' ... but I couldnt get that event to fire at all.
Thanks.
If the session data is being stored as a cookie (most likely), then you should be able to re-parse that data during the socket handshake. I posted code for that on this answer, but copied the code here as well:
io.configure(function () {
io.set('authorization', function (handshakeData, callback) {
var cookie = handshakeData.headers.cookie;
// parse the cookie to get user data...
// second argument to the callback decides whether to authorize the client
callback(null, true);
});
});
If the session data is being propagated in the URL, then you may be able to gather this information from handshakeData.url or handshakeData.query. You'll probably have to do your own experimentation.

Resources