Nginx accept set-cookie but hide it from the client?

[Jonathan Matthews]

On 5 May 2013 20:05, nano <nginx-forum at nginx.us> wrote:
> Hello,
>
> 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
> account.

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.

Regards,
Jonathan
--
Jonathan Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html