I'm trying to proxy an PHP api service, but I need to authenticated based on a session token.
Does node-http-proxy has options to forward the cookies to the target ?
Issue is most likely you're accessing the service via http when the proxy is requesting https and the cookie is set to secure. So your browser won't send it when making a http call.
I remember having a problem like this once. In my case what happened was that though the original cookie was sent with the request, the response from the proxy did not have that cookie.
What I ended up doing was saving the cookie before making the proxy request and the adding it to the response coming back from the proxy. You can write to the response vookies doing something like this:
var setCookie = res._headers['set-cookie'].concat(testGroup);
res.setHeader('set-cookie', setCookie);
Related
Introduction
I have a problem with sending cross domain session cookie and after searching I got even more confused.
Originally I had a client (Next app) on foo.vercel.com and the api (Express) on bar.heroku.com.
Sending and saving cookies was working correctly on localhost, but after deployment I got a problem with the sameSite set to lex by default. So I changed it to none. But I found that the sameSite none requires secure flag on the cookie set, so I also changed that.
The problem
After setting secure to true the cookie is no longer being sent.
If secure is set, and you access your site over HTTP, the cookie will not be set.
Both my server and client are hosted on HTTPS. I checked the logs on the heroku and the request protocol is HTTPS... however when I console.log a request.protocol from a GraphQL resolver the protocol is HTTP:
After seeing this
There's no such thing as cross domain cookies. You could share a cookie between foo.example.com and bar.example.com but never between example.com and example2.com
I moved the client to baz.heroku.com but the problem remains.
In order to check if everything still works I disabled the Cookies without SameSite must be secure in chrome://flags and it works correctly.
Questions
Is it even possible to set cookie cross domain?
Why does the POST method have different protocol than request I get in express server.
(I get the request from express and pass it through context to GraphQL resolvers)
And of course how can I send cookie to the client on different domain.
I would appreciate any help.
The problem was Heroku's proxy. I had to add the following to the express server:
app.set("trust proxy", 1);
I am using npm request module to send multiple requests in a session. One of these requests uses the sites mobile domain, m.example.com, rather than www.example.com
At the start of the code, I set cookie jar variable
this.cookieJar = request.jar()
No problem. I make a series of requests on www.example.com and they work fine.
Each request has
jar: this.cookieJar in the options.
But when I make a request to the mobile domain, m.example.com, all of the cookies from www.example.com disappear. I've tried setting the jar idx to mobile endpoint and that's not working either, i.e.
this.cookieJar._jar.store.idx['m.example.com'] = this.cookieJar._jar.store.idx['www.example.com'];
When I run the requests through Charles, all of the cookies are passed as they should up to the mobile request, where they disappear. When I try to make a request to httpbin.org/get, they don't show up. When I log to console before making the request, they show they are still in the jar.
Why is switching to the mobile endpoint not passing the cookies? What's a solution? Again I'm using npm request module + storing the cookies in a variable cookieJar.
My site is using https to transport data,and I scan it by appscan ,it told me that Set-cookie not secure ,but cookie is secure.
so what is the difference between Set-Cookie and cookie .
Your server controls the Set-Cookie header, so if a browser does not provide the Cookie header, the server can decide to send a Set-Cookie.
Then your browser decides to accept the cookie by sending back a Cookie header for the server to use. For example, if you have cookies disabled on the browser, it will not send back the Cookie header to the server.
The "Set-Cookie" header is sent from the web server and the browser sends the cookie back to the server in an HTTP header called "Cookie"
Say that there is a website, it
uses XHR for all of its POST request and only POST requests could trigger write operation on the server.
the server also has proper CORS config, that it does not accept any request but its own
Then is it possible for this website to still be under potential danger of CSRF?
CORS is unrelated to CSRF. For example, form posts are not covered by CORS. CORS is related to reading data. CSRF is writing data.
It doesn't matter if you only use XHR, an evil site could use a regular form post or Flash to do a CSRF against your site.
Just follow OWASP's advice and use the Synchronizer Token pattern: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Synchronizer_.28CSRF.29_Tokens
I'm using express / node js for a simple server.
There's no need for secure https everywhere, but I do want to secure some upload form posts and responses that come back on that to phones.
So far I've setup a standard nodejs server on http with express.js.
I have an app.post('/upload'...)
I'm deployed on heroku, so I changed the app I'm testing to post the form data to https://myapp.herokuapp.com/upload
Is it now posting over https? And will the response be over https?
Or do I need to reconfigure the express server in some way to specifically handle that?
These uploads/responses are the only secure part, and non-visible to users (done by the phone app) - so there's no need to do full http ssl endpoint config for the whole domain/sub domain if the above piggyback solution is ok.
On Heroku, SSL is terminated at the routing layer and a X-Forwarded-Proto: https header is added to the request so your app can know that the request came in over SSL. In other words, from your app's perspective, the request is plain HTTP and doesn't need to do anything special, but you can always check for the X-Forwarded-Proto: https header if you want to make sure the request was made securely. If the request was made over SSL, the response will also be over SSL since it they are both part of the same connection.