Can't use Cookie Security Option

[dateno1]

BEFORE

• Are you using a reverse-proxy, like nginx?
  • Check if your problem is caused by your proxy, try without it.

To Reproduce Steps to reproduce the behavior: After add proxy_cookie_path ~(.*) "$1; SameSite=strict; secure; httponly"; on Site Config

Can't login with any account

Some of browser can't get FileList

Describe the bug Add Security Option on reverse proxy -> not work

Expected behavior ID/Password is correct but can't login

Can't get filelist

Screenshots

Environment (please complete the following information):

• OS: hfs@Windows 10 x64/nginx@Linux
• HFS Version : 0.46.1
• Browser : Chrome, Firefox

Additional context Add any other context about the problem here.

[rejetto]

hey! there's a cookie that cannot work with the httponly. I guess you cannot make that change.

[dateno1]

Old delphi version is work well with that setting

I has many sub-domains and i don't want to use setting for hfs only

httponly will protect login info from XSS

[rejetto]

i've studied a bit the same-site thing. Apparently, same-site alone on 1 cookie would be enough, but doesn't work on older browsers, and most of all doesn't work without httpS, and HFS supports http too. For this reason, HFS is using 2 cookies to prevent CSRF attacks, as described here. Your problem is probably caused by the second cookie.

I don't remember if I can enable same-site without disrupting http, I'll see. I'm also going to try this other method, that's an alternative to the 2-cookies method for older browsers that don't support same-site. I have to see if it causes no problem.

httponly will protect login info from XSS

session cookie is already httponly

[dateno1]

I checked 'httponly is enabled' by browser

I can't understand 'Set same attribute by hfs is OK. but Reverse proxy is not'

Also hfs using some of inline-script (maybe using style)

It not compatible with CSP setting

I don't think it dangerous but not work with strong security setting

[rejetto]

I can't understand 'Set same attribute by hfs is OK. but Reverse proxy is not'

You were setting attributes to both cookies. What I said is different: setting on one, and also trying to removing the other. The csrf cookie will never work with httponly.

If those attributes were always ok, they wouldn't be optional at all. They are because sometimes they are not compatible with the way applications use them.

[rejetto]

in 0.48 i will experiment this new way

[rejetto]

this preview version should be compatible with what you was trying to do hfs-windows.zip please let me know if it works good for you.

Anyway, my suggestion is that you don't make any change to the new cookie, that is set to "lax". After studying the "samesite", I think "strict" is not the best option for HFS, and it will prevent some use cases. It's likely that you don't need these use cases, so you may still opt to go for it, but if you are changing stuff without full understanding you may have unwanted side effects.

[dateno1]

this preview version should be compatible with what you was trying to do hfs-windows.zip please let me know if it works good for you.

New version tested

I can connect to hfs server by reverse proxy (with/without 'httponly')

but Can't login (normal/admin page same result)

It not work with/without 'httponly' (Old version (maybe 0.46.1) work with 'without httponly')

Current option : proxy_cookie_path ~(.*) "$1; SameSite=strict; secure;

Anyway, my suggestion is that you don't make any change to the new cookie, that is set to "lax". After studying the "samesite", I think "strict" is not the best option for HFS, and it will prevent some use cases. It's likely that you don't need these use cases, so you may still opt to go for it, but if you are changing stuff without full understanding you may have unwanted side effects.

'Lax' will not protect some of type (a href, form method...)

and If you want to set to 'lax' you don't need to do anything (Almost browser's default option is 'lax')

'lax' is good for multi-domain server (It has high compatible)

but I'm running standard-alone server (It has sub-domains but It for single domain only)

[rejetto]

I'm not totally sure the error you are seeing is caused by you changing the cookie. I wonder if this version is incompatible with your proxy at all. Can you check, please, by disabling the proxy_cookie_path?

And, if it is indeed your proxy_cookie_path, it would be interesting to know if the problem is caused by "strict" or by "secure".

---

Lax is there to allow you to click on a link and still have your session working. Example: your user is logged in, complains about not finding a file, you answer by giving a direct link. With "strict" he will click the link but it will be asked to login again (or worse), even if he is already logged in. Of course you may not care about this, but some will.

Anyway "strict" exists because there's nothing to prevent a software from doing "actions" (like deletion) with a simple link (or a form). This release of HFS is specifically designed to not allow "actions" with links/get requests. It also will prevent any action (or form) coming from another domain (or subdomain, or port).

Lax is default, yes, but there are edge cases where no-setting is actually different than setting it.

[rejetto]

I'm not totally sure the error you are seeing is caused by you changing the cookie. I wonder if this version is incompatible with your proxy at all.

I just tested with a nginx and indeed it's not working. I'll let you know.

[rejetto]

ok, here is a fixed version: hfs-windows.zip

should no longer identify as a teapot 🙃

[dateno1]

ok, here is a fixed version: hfs-windows.zip

should no longer identify as a teapot 🙃

Thanks for help

Now worked (list file, download, upload, show, login, admin page login tested)

I want strong security option as possible for my site and i don't want to many setting file for web server (I has over 20 sub domain, domains)

[rejetto]

cool, thanks for your feedback