I am building a simple web app using nodejs as backend with angularjs front-end.
With nodejs I am setting some cookies after a user logs in.
res.cookie(name,value)
I am creating two cookies each for username and user_id.
and when I see the set cookies, using
res.json(req.cookies)
and the json response have the actual user_id and also with a another key
connect.sid, maybe because I am using connect-flash, I don't know.
But when I access the cookies in angularjs using $cookies.get('user_id')
the value is some encoded value,
For eg :
for actual user_id : 571be8d34666cf69664645d5,
I am getting j%3A%22571be8d34666cf69664645d5%22
How can I get the actual userid ?
I know that the real ID is in between the string and I can get it by using some string manipulation, but is there another way.
I am using passportjs, express-session, connect-flash, connect-mongo,cookie-parser in my app.
Instead of using two different cookies, you can set the object in the cookie from express, and on angular side you can get the cookies by:
$cookies.getObject('cookiename',object)
In your case either write a function for splitting the cookie or use JSON.parse(json) for parsing the cookie coming from express.
I did it other way round and managed to read the cookie object in express by JSON.parse(cookieobj.user_id)
It seems that as of angular 1.4, you should use $cookies.getObject('user_id') for deserialize version of the value. Start with that, if not a solution, check on the console the actual value of the cookie to try to understand where the j:"571be8d34666cf69664645d5" come from.
Related
in one of my project i am getting User identification data from reverse proxy server (Webseal) in httponly cookies and i need to retrive these cookies to retrive data from backend API,I know its not possible to read httponly cookie with any script code.
can it be done using server side renedering using express.Front End Code is written in ReactJS
Thanks
Yes you can read them in your backend make the API requests from your server and then render the response based on that.
Echoing the cookie data inside an script tag, would be also possible, but would be an dirty hack, as it defeats the purpose of the HttpOnly flag.
I'm developing an ReactJS app calling api from my server. After logging in, server returns an authentic-token and I need to store it in cookies (the key is token and value is the authentic-token from server. Now I'm using universal-cookie). But when I assign document.cookie to another value like token=xxx in browser's console, the token in cookies will be modified. Is there any ways to prevent user from modifying the cookie via document.cookie ?
Thank you !
To answer your question, the answer is No. You should never have to trust data from the browser as there are a myriad ways of manipulating it.
Instead you should make sure your backend server validates the cookie.
You cannot prevent a user from modifying the token in the cookies. universal-cookie stores data in a particular way and it shouldn't be altered using document.cookie. Also, you should always validate the data in the cookie with the data in your backend as the user can manipulate the data in any way.
It would be better to use universal-cookie itself to do all the tasks related to cookies you want to do, as you can do almost everything with it. And you can also try out some other packages such as react-cookies
I am working on angular js app,and tried to make a simple login page and tried to request my server API for authenticate my login call.Here what and how i planned to do.
Note: I am assuming that server is responsible for validating my token and request.
Provide username password to server via API call.
On getting authenticated the server will generate a token for my App(through which i made a call).
I stored this in my browser's COOKIE.
This Cookie (auth token) will be further used by app to to make each and every HTTP call to API.
Now this approach is working fine for me,but I believe it is openly available for CSRF attack.
In order to avoid the CSRF attack from my browser,i provide APP id or (version id) to my code which also travel with cookie to the API for http call.
The idea behind using this version id or App id,is this can be treated as a signature of my code,ie request is coming from the signed (verified) app who has alloted token=cookie value.
i just want to know how better my approach is and how much secure it is for my basic app point of view and for my major (wide project) app.
Here i am trying to show via a rough diagram
apologies for this tiny view and bad handwriting of the diagram.
Backend frameworks like Laravel have this pretty built in: csrf-protection.
You can pass the token to Angular by using angular's constant function: $provide#constant.
So after you initialize your app you could say: angular.module('myApp').constant('<?php echo csrf_token(); ?>'); and Laravel would do the rest. If you would want to implement a technique like this yourself, you should look into Laravel's source code: https://github.com/laravel/framework/blob/a1dc78820d2dbf207dbdf0f7075f17f7021c4ee8/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php.
Adding App ID + Version ID to each request won't protect your system from a CSRF attack, unless these are in a custom header - and if they are you might as well just use X-Requested-With because any non standard header is protected going cross domain, provided you haven't enabled CORS with an open policy.
The reason that checking App ID + Version if set in the query string or POST data is that the attacker can readily gain this information to add the App ID + Version ID to their cross site requests. Another method that would work for you is the Double Submit Cookies technique. Generate a random 128 bit string using a CSPRNG and then set this as a cookie value (e.g. CSRFCookie). On each request to your API, also pass this value. e.g. in the query string: CSRFCookie=<generated value>. On the server side you simply check that the values match. An attacker does not know the cookie value, therefore they cannot add the same value to the query string.
This method does have some minor vulnerabilities, only really exploitable in a MITM scenario or if you do not control all subdomains. Short answer: Use HTTPS only for all your subdomains and implement HSTS.
I have an angularJS application whose authentication system is made with an access_token and communicating with a backend server written in Go
Therefore to authenticate the user, I have to add the access_token to each request ?access_token=SomeTokenHere or via a header Access-Token: SomeTokenHere
It works great.
The issue is that my backend serves protected images, and I cannot put the access token in the image src for some security reasons(If the user copy/paste the link to someone else, the access_token would be given too ...)
What I'd like to do is to inject a header containing my access token, but since the request is made from the browser it doesn't possible.
This could probably be possible with a cookie, but I'd to avoid using a cookie especially because the angularApp and the backend are not on the same sub-domain.
Another idea would be to create a directive that would get the raw data, and set the data to the image. First I don't know if this is possible and is it a good idea for hundreds of images in the webpage ?
If you have any idea, I'd be glad to hear from you !
Thanks
It is typical problem, and fortunately it was already solved - for example on Amazon S3.
Solution idea is simple: instead of directly using secret key - you can generate signature with access policy, using that key.
There is good algorithm designed especially to generate signatures for this purpose - HMAC
You can have one secret key on your server and use it to sign every image URL before it would be sent to client, also you can add some additional policies like url expiration time...
I have a problem with communication between angular and laravel.
Its about mobile application that needs to log in to a laravel framework and get some data.
Mobile application is angularjs based, and for login i user standard $httpd function.
Login works fine, and i get expected response from laravel, but when i make another request assuming that im loged in, laravel returns NULL for session and auth. When I upload mobile app to a server where laravel is installed all works like a charm. But my app needs to be on mobile device, so thats not a solution.
I assume that the problem is in cors or cross domain communication. It seems that laravel destroys session made from cross origin requests, because that session is not accessible from another request, and on another request laravel tries to make a new one.
I need help solving that session problem (access session after login or keep session), i hope some of you have some kind of a solution.
i tried :
changing headers in my login controller
changing get to post
adding content type to my angular http req (Content-Type': 'application/x-www-form-urlencoded)
tried requerst with jquery ajax
changed laravels app/config/session.php values of driver, cookie, domain...
setting vendor/laravel/framework/src/illuminate/http/frameGuard.php x-frame options to false
no luck!
Use json web tokens, and simply set it up so that you request a JWT on login, and you can share that token around - the only way it invalidates, is either if you lose the token, or it times out.