If lua-resty-session is not behind a reverse proxy the X-Forwarded-Proto header will not come from a trusted source but may instead be user-supplied or injected by MitM. This way the determined scheme might be different from the actual scheme between user and the server.
It is not clear to me if this might lead to the server sending out confidential payload over http in edge cases.
I would propose that the reverse proxy headers should only be trusted, if a corresponding opt-in flag is set.
This is known. Though, it is just a very tiny measure. Everything the library sends is encrypted (unless you forcibly set it to not encrypt). Also the addr check below is flaky. I will fix this soon.
If
session.check.scheme
is enabled, it is expected that the scheme is checked. Currently the code looks at the headerX-Forwarded-Proto
to determine the scheme https://github.com/bungle/lua-resty-session/blob/d006e524feb4d53880461c8c97bf8c7560a4b6c7/lib/resty/session.lua#L270If
lua-resty-session
is not behind a reverse proxy theX-Forwarded-Proto
header will not come from a trusted source but may instead be user-supplied or injected by MitM. This way the determinedscheme
might be different from the actualscheme
between user and the server.It is not clear to me if this might lead to the server sending out confidential payload over http in edge cases.
I would propose that the reverse proxy headers should only be trusted, if a corresponding opt-in flag is set.