Secure cookie handling upon https to http downgrade

Peter Naulls peter at chocky.org
Thu Dec 22 09:23:35 PST 2022


Some background.  I have two versions of OpenWrt code:

One is legacy version based upon a mismash of versions, but is approximately 
luci code from mid-2021. The webserver is http only. I'm able to change this 
code for bug fixes, but don't want to pull in anything too large.

The other is based upon very current 22.03 code, and https is set.

The problem is that for some purposes, we may need to downgrade. If the login
is done on the https setup, then the sysauth cookie is set, with the "secure"
flag set on the cookie. All fine.

However, if we go back to the older code, then it's not possible to login in
luci. I've been through dispatcher.lua and what I think is happening is that
the cookie isn't being updated:

http.header("Set-Cookie", 'sysauth=%s; path=%s; SameSite=Strict; HttpOnly%s' %{
				sid, build_url(), http.getenv("HTTPS") == "on" 	and "; secure" or ""
})

Now that would be justified, since you wouldn't want a website to update a 
cookie from an HTTP page with one already set from an HTTPS page. So what
happens is that the authentication "works" but there is another check in
dispatcher.lua for the session ID vs cookie, and this fails, and so no login
can be made until the cookie is cleared from the browser (or the cookie
is manually modified in the browser to be not secure).  Or in practice,
flushing the cache for the page.

I know also there have been significant changes in the dispatcher code between
the legacy OpenWrt code I'm using and the 22.03 code, but it's not clear that
this has been addressed.

Looking for suggestions on work arounds - maintaining the integrity of the 
security of my latest code is important, but if I have to weaken things in the
legacy code, that's probably OK.

Thanks!



More information about the openwrt-devel mailing list