Nginx accept set-cookie but hide it from the client?
contact at jpluscplusm.com
Sun May 5 19:42:33 UTC 2013
On 5 May 2013 20:05, nano <nginx-forum at nginx.us> wrote:
> I have a reverse proxy setup on a website and I'm proxying logged in pages.
> Everything works except there is a vulnerability in my setup.
> I login to the site and I can cache the pages. I share these pages with
> everyone else.
> However there is a problem with how the set-cookie is passed onto the user
> when I just want nginx to keep it.
> Is there a way to make nginx stay logged into the site, and hide the
> set-cookie passed onto the client?
I don't think you've fully thought this through.
To help you realise what you've missed, please think this through and answer:
What mechanism do you expect your application to use, in order to know
that a request comes from authenticated client A and not
unauthenticated client B, and hence access to a certain protected page
should be granted?
> I've tried: proxy_hide_header Set-Cookie;
> but that just logs out the session and can no longer access the protected
> pages. When the set-cookie is passed onto the user they can save that cookie
> and load it up into their browser and be able to login and "hack" the
I really don't understand what hacking you think might be going on
here. An authenticated user geting access to the protected resources
that their account /should/ allow them to? What is /wrong/ here?
> Is there a way to keep nginx logged in, without exposing the set-cookie?
In general, cookies (should) render pages uncacheable, except if
you're caching them per-user. Which is nasty.
What you're describing is, as far as I can see, a lossy process,
leading to information being dropped at the nginx->client
communication stage, and will not work.
Of course, if you're mucking around with someone *else's* site, and
only have one login for it which you wish to share amongst multiple
front-end users, you could use
proxy_set_header Cookie "hard-coded logged-in user's cookie"
.. but that's pretty horrible; both technically and morally. Don't do that.
Jonathan Matthews // Oxford, London, UK
More information about the nginx