Example if you run:
console.log('Connect.sid', req.headers.cookie);
Result of connect.sid value:
connect.sid=s%3A04x6YVZX68nRrhakd3SWuIMakDhuGptO.kyBVHe0HDI4pW1JeOl0xEopRYgQ51ZVlAKdfui7ii18
And if you log the req.sessionID the result is going to be this:
04x6YVZX68nRrhakd3SWuIMakDhuGptO
At the moment I have clear that the first part of the cookie session(connect.sid) is the sessionId. That anyone can build with the genid function that express-session provides us.
To be more in context, I have some WAF rules, some of those rules are for check SQL Attacks or things like that. Some times(fair away), my web application firewall (In Azure) gets fired cause match a pattern in the connect.sid cookie.
I need to handle whole the cookie but I'm only be able to interact with the first section of the cookie value (The sessionID). And here's where I have some questions:
What is this second value?
How can I handle it?
Is possible to delete it and create a new one if the pattern match?
Am I making a lot of trouble with this? Is it better only to add an exception to the WAF?
Just in case, I was reading this very similar question "express-session - the difference between session id and connect.sid?", but I need more detail about it.
Related
I'm giving NestJS a try and am pretty happy with the results so far. Right now I'm struggling with some concepts that aren't clear enough in my head.
My API has an authorization-token in the format of a cookie (NOT A JWT). When the API receives a request, it has to use said cookie to ask another service (async), which user is sending it and what role he has.
This exchange from cookie to user info should prepend any controller logic and should be applied globally.
I think this can be done via a middleware, an interceptor or a pipe, but which of those is considered the better way according to NestJS?
Honestly, I would use a guard for this kind of feature. Check if the cookie exists, if not, there's already a problem, send back a 403 (i.e. return false). Otherwise, the rest of the logic can follow and you can attach the information to your req object, thereby having it available throughout the rest of the request. As guards are the first of the enhancers to fire, this also ensures that the value is available in interceptors and certain pipes.
We modified our Session handling from cookie based to URL Rewriting. By doing this the session id gets transmitted as part of the URL.
Now there is a vulnerability issue, where whoever uses this URL will be able to log in into the system.
To resolve this issue we have done the following
[1] A HTTP Session Listener has been created to maintain list of HTTP sessions.
Listener reacts on the events when session are created or destroyed.
[2] A Session Filter has been created to verify HTTP Session and check its integrity against HTTP Request attributes
Session will be invalidated in case Request attributes (identifying the client origin) do not match original attributes stored with session. (to block the session hijack attempt)
However i think that this has a gap, when you are trying to access over a proxy etc.
Is there any other effective solution for this?
Also we cannot use third party libraries to resolve this because of the nature of the produce.
So you need to be doubly careful with session ID likes this: users share URLs! The definitive advice on the subject comes from OWASP:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
But I think you should consider the following additional controls:
Rotating the session key on each request. This is only practical with simple web applications though. It'll cause problems undoubtedly with AJAX and might be difficult to manage if the user is likely to open a second tab on the application.
Shorter timeouts.
I am presuming that in the 'HTTP Request Attributes' you mention you are already picking up the User-agent, source IP address and invalidating the session if these are inconsistent.
If you are using SSL it might be possible to do a great solution where the session ID is tied to the SSL connection (Apache, for example, exposes this in a SSL_SESSION_ID environment variable). But this information might not be available to your application.
I am working with a remote iPad developer who is using a tool that he says does not allow him to set the "RememberMe=true" value when registering the user. Since we always want to have this value set anyway, I thought I could simply intercept the request on the server side and set it myself. I am using Basic Authentication and I had already overridden "BasicAuthProvider" so I have access to the "TryAuthenticate" and "Authenticate" methods. These methods both provide a parameter of IServiceBase which contains the original Request. I was thinking about modifying the DTO but it is null. So I looked at the cookie values and I could easily add a value for "ss-opt=perm" in there. But I'm not even sure "perm" is right.
My question is this...is this the best way to set the RememberMe flag to true on the server side? My partner says the library he is using is called "afnetworking" but that looks to be a dead end.
Marcus
EDIT: My partner found a way to set the "ss-opt" value with their tool but this does not seem to be helping. He is still experiencing a problem after 6 hours. There is additional information. The first response he gets after waiting 6 hours has the "ss-pid" cookie value but the "ss-id" and "ARRAffinity" cookies are missing from the first response. The subsequent responses has them. Weird.
I am going to switch to using the AzureCache instead of MemCache to see if that helps. But I did not update the server in that 6 hours so shouldn't the memory cache still have the session id values that correlate to the ss-pid value?
EDIT 2: I was under the false impression the "cache" was where the system kept the permanent ss-pid values and all I had to do was to register the cache. How do I keep the ss-pid values around between server updates?
Switching to AzureCache and having the client insert the ss-opt cookie seems to be working.
I have a node.js webserver with express middleware. I am trying to eliminate the need to session stores for performance reasons. I dont track much as of now.
However, I do need to keep track of username and userid when a session is started after loggig in. I have implemented this using express res.cookie( ... ) which works if cookies are enabled. But it will not work if cookies are disabled.
so I was looking at req.session but that again uses cookieSession internally.
Q1: How can I keep track of username (once user has loggedin )
across multiple requests with cookies disabled in browser and NO-SESSION-STORE
(REDIS/MONGO etc)
Q2: In the solution for Q1 above, I want webserver to be stateless,
so it does not grow in memory at any point?
Is it possible? Does my question/requirement even make sense? I am new to this.
Essentially I am looking for an object other than cookie that can be part of request which will communicated every time request is sent/received
Please help
There are multiple avenues you could potentially take, since it sounds like you control the requester as well as the backend service.
HTTP Headers
Query String
Cookies
We know cookies are out.
With HTTP Headers, you can't always count on them unless you're making some kind of AJAX call.
Query strings require you to ALWAYS send back a user name or other identifier manually. However, it would solve Q1 and Q2.
Depending on what your app is, it might make sense to re-architect endpoints so that they are ReSTful and help define actions - that way it makes semantic sense to have a username as part of the request url.
For example:
GET http://example.com/:username => could display a profile
GET http://example.com/:username/friends => could display a list of friends.
Depending on how your app is designed, you might also be able to utilize websockets to handle user connections and auth.
I don't know if the title is clear enough, anyway what I need to do is quite simple: I have some content you can access by an API call on my server; this content is user-related so when you request access to it, you must first wait for the owner to authorize you. Since this content will be probably embedded into blog articles or form posts I want it to be accessible only from the URL the user authorized to.
The only way that came to my mind is to check in some secure way where the request is coming from: the problem with this approach is that anybody could create a fake request, using a valid URL but coming from a non-authorized URL actually.
I'm looking for a way to solve this problem, even if this doesn't involve checking the actual URL but using some other approach or whatever. Feel free to ask any questions if this is not clear enough.
With Sessions:
If you generate a secure token, most languages have libraries to do such a thing, you will have to persist it probably in a session on your server. When you render the page which will access the other content you can add that token to the link/form post/ajax request on the page you wish to be able to access it from.
You would then match that token against the value in the user session if the token doesn't match you return an error of some sort. This solution relies on the security of your session.
Without Sessions:
If you don't have sessions to get around server persistance, you can use a trick that amazon s3 uses for security. You would create something like a json string which gives authorization for the next 30 seconds, 5 minutes, whatever is appropriate. It would need to include a timestamp so that the value changes. You would use a secret key on your sever that you combine with the JSON string to create a hash value.
Your request would have to include the JSON string as one request parameter. You would need to base64 encode it or some other means so that you don't run into special characters not allowed over http. The second parameter would be the output of your hash operation.
When you get the request you would decode the JSON string so it was exactly the same as before and hash it with your secret key. If that value matches the one sent with the request it means those are the two values you sent to the page that ultimately requested the content.
Warnings:
You need to make sure you're using up to date algorithms and properly audited security libraries to do this stuff, do not try to write your own. There may be other ways around this depending on what context this ultimately ends up in but I think it should be relatively secure. Also I'm not a security expert I would consult one if you're dealing with very sensitive information.