[Bug]: Decryption fails even with valid session key
Closed this issue · 21 comments
NetBox Secrets plugin version
v1.8.1
NetBox version
v3.5.1
Steps to Reproduce
I just upgraded our Netbox installation to v3.5.1 with the newest release of the plugin.
Previously we were running on Netbox 3.4.10 with the plugin at 1.7.6 - that worked fine.
Expected Behavior
I should be able to decrypt secrets
Observed Behavior
When i attempt to display a secret, i get asked to create a session key using my private key. When i do that i get a success message, but when i try to decrypt, i get the prompt again.
Make sure you have cleared the cache from the browser and have successfully run collectstatic command.
I can confirm this issue. I tried incognito mode and it didn't help.
"Collectstatic" was executed successfully under build docker image stage. Docker image was built with "--no-cache" opt.
To also ensure that your browser is getting the correct cookie value, go to the User Key page and delete any exsting session key and create a new one. Then open you browser developer tools and navigate to the console view. Run the following command and share a screenshot of the same.
document.cookie.indexOf("netbox_secrets_sessionid")
it will take me some time to repro this, because we went back to the old version to have a working setup again.
when it happens i did a little bit of investigation and followed the minified JS code. it looks like it wanted to take the plaintext secret value from a property of the API call response - that property existed, but was null in the response. i didn't see any client side decryption code.
There is no client side decryption code for a reason, but the JS code contains a ref to the new cookie value. The key is called netbox_secrets_sessionid. If you JS file which is loaded from collectstatic does not have a reference to this key, that means the command did not pick up on the new file which is causing the issue.
The first key created is added to the sessional successfully
The second created key could not be added
secret.js, HAR files from POST requests are included in the gist
https://gist.github.com/bsv9/014fec6ef939da62a2c1435f406239ae
@bsv9 Based on what you have provided, there is no indication why the UI should not be working for you. The JS file is identical with the packaged version and the HAR suggests that you have everything in the browser cookies needed to make things work.
Please take a look to the debug.log. I see to many exceptions while rendering 'netbox_secrets/userkey.html'
https://gist.github.com/bsv9/014fec6ef939da62a2c1435f406239ae
@bsv9 Simply enabling DEBUG does not throw any of the errors that your logs have. Could you also share your logging configuration?
Also, on the quick look most of those errors seems to be harmless because the template is inherited from the generic object.html which expects a NetBoxModel but UserKey does not inherit from it.
This is my logging configuration
LOGGING = {
"version": 1,
"disable_existing_loggers": False,
"handlers": {
"file": {
"level": "DEBUG",
"class": "logging.FileHandler",
"filename": "/tmp/debug.log",
},
},
"loggers": {
"django": {
"handlers": ["file"],
"level": "DEBUG",
"propagate": True,
},
},
}
The template errors can be safely ignored and does not have any bearing the on issue reported here. As I suspected, they are due to not inherting from NetBoxModel and using non-standard views.
@bsv9 I have reverted the change in a separate branch. Give that a try and let me know if that fixes the problem. You will have re-create your session key
pip install git+https://github.com/Onemind-Services-LLC/netbox-secrets/tree/fix/decrypt --force
This fix does not solve the issue.
I saw "session_key" cookie instead of "netbox_secrets_sessionid" on updated version.
In that case, I'll dig further and see if this is reproducible in any way.
Is there a way that @bsv9 and @mraerino you guys are behind a proxy and the setup causes the issue with the cookie SameSite=Strict option? That's the only option I can think of could be causing the issue if the static files are loading correctly.
If you can confirm if changing the SameSite=Lax in the cookies for netbox_secrets_sessionid fixes this. If it does, I can provide a configurable option to manage this, however, that loosens up the security on the cookie which is not a good idea if we want to avoid XSS attacks.
i can't imagine why the SameSite cookie attribute should be a problem here. my setup is behind a reverse-proxy, but as far as the browser is concerned, the cookie is only ever used with a single hostname, there is no cross-origin cookie use at all in my setup.
Upon successful retrival of the session key, the only other thing that IMO can cause this issue is incorrect static file (probably still from v1.7.6) because the cookie name has been changed. Or, the request cannot access the cookie for some reason causing a failure, which will retrigger the private key model to appear.
I've tried to reproduce this issue 10 different ways and I cannot seem to replicate it at all in my setup. Without more information to go on, this is quite difficult to figure out.
Hi, I encountered the very same issue in my 3.5.1/1.8.1 setup as above.
One user can decrypt secrets fine, all others can't. We compared our netbox_secrets_sessionid cookies and noticed, that everybody got the same value for the cookie.
I hope this will help you with further bug hunting.
@kprince28 Looks like the changes were reverted in the PR. That should not be done. Instead if the issue is with the session key filtering, then get_querset should be looked into
@bsv9, @mraerino @kpurrucker You guys can run it and see, hope everything will work properly now. Use this branch
https://github.com/Onemind-Services-LLC/netbox-secrets/tree/fix/session-key