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.
Related
I'm working on a e-commerce using next.js and sylius API and the API admin routes are secured using JWT. So in order to fetch products (for example), i need to login to the API, get the token and then fetch the products using the token. The most common method to be able to send the token on every new requests to the API is to store it in a HTTP-only cookie.
As the pages are generated statically, i feel i don't need (and want) to expose the API token to the client. So i'm wondering the best way to store the token ?
Here the different options i have in mind right now:
store the token as a http only cookie and use it server side (with a proxy using next js API pages) in order to call the sylius API. Like i said, i'm not confortable to store the API token into the client, it seems risky to me, as it will be exposed to everyone, and with that token you can access the admin API.
configure the API in order to prevent the token from expiring, and store it in the next js app as an environnement variable (.env.local), so that it's not exposed to the client and can be used for fetching the api when generating static pages. The official ecommerce theme of Next.Js seems to use that method (https://github.com/vercel/commerce/blob/f770ad7a91059a2ecfbb9de1bac111dfe7016124/framework/bigcommerce/api/index.ts#L82)
store the token somewhere in the next js structure but not as an environnement variable (maybe a config file?), so that it can be replaced if necessary (if the token expires etc).
get the token and store it in the react state as is it will be used once only for generating all static pages. On each build the token will be asked again by the API and then used for fetching the API for exporting the static pages with the content. It don't need to be saved more time than the building step.
For me the last option seems better but i feel i'm missing something there, i'm kinda new to next, so i'm not sure exactly if its a good solution.
Thanks :)
I get a great answer from a reddit user ("supermaguireray"), so i post it as an answer here:
"First of all, in any session management mechanism the correct information needs to live on the correct domains, what I mean is that your client can only have access to a identification information, but never to data used in the server, these can be applied to a server-side session, when a ID for the user data stored on the server is sent to the client (preferably encrypted), or in a JWT where a encrypted string is sent to the client (identification), and decrypted on the server (Data).
With that said, the only reason you should send the API token to the client is if you need to fetch data directly from a browser. Storing as a httpOnly cookie is the most secure way.
In case you only need the cookie fetch data to the next backend, to render your SSG or ISR pages, there is no need to send a cookie to the client. Just store the token in your server. I would store it as env variable. Use next.config.js->runtime-configuration.
Or, you can keep a expiration date for the token, and store the credentials, maybe even in a DynamoDB or FaunaDB app."
Can you, using fetch or by some other means send request with HttpOnly cookie to server in React ?
I know HttpOnly means you can't access it with JS.
I'm thinking maybe you can't read it but you can send it back? I don't know.
I want this:
Request to server is made from client (ReactJS SPA)
Server responds and sets HttpOnly Cookie.
Client gets response, cookie is automatically set by browser.
With new request to that same server I want to send back that cookie. is this possible using ReactJS ?
or maybe there are some ways to bypass that, like maybe opening new window, with simple HTML, not ReactDOM ?
Thanks for your help.
Ok, I checked it out.
Cookie with HttpOnly set with true, will still be send using ReactJS, fetch or any other Request made with JS, You just Can't read it using JS, but when using HttpPost, HttpGet, or other. Browser still attaches it to request, even if it's HttpOnly.
I guess the lesson here is that browser handles setting cookies to requests, and it doesn't care if request is made by HTML, or JavaScript.
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 need some advice regarding using session tokens to authenticate users. I am building an AngularJS app which uses an API to tie in with the backend. I am only building the front end, not the backend. The documentation states that all calls to the API have a session token attached in the body of the request (POST).
I would like to know about the security of storing this token in localStorage. That is where I am storing it now and retrieving and attaching it to each API request. After login, the server sends the session token in the body and I save it from there.
There is no documentation about an x-access-token header that should be sent with the request made to the server. It is not being checked server side. What are the implications of this? I feel that it is susceptible to attacks without this added layer of security.
My main concern is the security of this setup. I want to know what the best setup is to make sure this app is as secure as possible and recommend changes to the way the backend is setup to facilitate this.
Thanks!
As you tell, you are only working on the UI part and not the backend. It is up to the backend team to ensure headers are properly evaluated and security is enforced (btw request headers do not belong to request body). Just put the token into the x-access-token header as they tell.
Storing the token inside the localStorage gives you a little more control over the cookie: You will not accidentally send it to unnecessary URLs. However, older browsers do not support it - you may need to use a shim for that.
In a case of SPA, you may consider not storing the token at all: It could be fetched each time your application is accessed and then stored within a service in angularjs, but it depends how your fetch/login operation is implemented (is it always interactive, how long does it take, etc).
I would suggest use $cookies rather than localstorage. As localstorage does not support some legacy browser.
I am using cookies to store token in my project
I've read almost every answer on SO and some blog postings, but I can't figure out one simple thing. In a simple token authentication scheme where the server generates a token and sends it back to the user after verifying credentials, how does the client store and then resend that token in each request? I have seen both cookie examples and header examples. I would like to use the HTTP Headers if possible, but I can't figure out the mechanics of how to send the token to the client, where it will sit, and then have it sent back in the header upon requesting a REST resource.
I am using Jersey/Guice with AngularJS on the front end. Here are the resources I started with:
http://porterhead.blogspot.co.uk/2013/01/writing-rest-services-in-java-part-6.html
Session management : How to generate Authentication token for REST service ? (Jersey)
It depends on your needs. You can use HTTP basic or digest auth, if it is appropriate for you. If not, then if you don't need a permanent storage, you can store credentials in memory. If you need a permanent storage, then you can store them in localstorage, or any other client side storage, but aware, that they are considered not secure.
Anyways I think if your client or service is compromised somehow with xss, then you lost, and it does not matter what else you do about it. Otherwise you can send the credentials in plain text securely as long as you use HTTPS with proper settings. (But that's just an opinion, I am not a security expert, at least not in this topic.) So I think you should concentrate on not being xss vulnerable. For example you should use the proper headers and filter the input against js injection (and by firefox data URI injection). And use TextNode in your client instead of innerHTML wherever it is possible.
For example if you are using Javascript you can store the token in localstorage like window.localStorage["token_id"] on the client side.