I'm not sure what is meant by cache hijacking.
Re. session hijacking we might be talking about at least two things:
- vulnerability inside nsec.app such that someone gets access to your "session" in nsec.app
- vulnerability inside nostr app connected to nsec.app that exposes the app's session/connection info so that hackers can access keys on behalf of the app
The first part doesn't have much surface with nsec.app - we only use server to store encrypted keys and to subscribe to notifications for the signer to wake up. There's basically no "session". And any server-side auth is based on nip-98 which requires a new token signed by your nostr keys for every request, so again there's no "session" - you can only sign those tokens if you steal the main key.
The second part doesn't depend on the signer (online or offline) - no matter which signer you use, it's the app that's connected to the signer that needs to be hardened against session hijacking. That's why it's super-important to not give excessive permissions to any (even trusted) app in your signer, so that potential hackers' access to keys was as limited as possible. Also when connection is established using bunker-url or nostrconnect url we use a one-time "secret" so make sure the connection can't be spoofed and url can't be reused.
I'm not a security specialist, and I agree that a formal security audit would be beneficial. We'll get there eventually.
brugeman
npub1xd…mntxy
2024-09-26 07:52:30
in reply to nevent1q…shma
Author Public Key
npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxySeen on
wss://relay.damus.ioPublished at
2024-09-26 07:52:30Event JSON
{
"id": "b0345f60d73284a9551406881ad0929a8d5bfc4309882ee77c9527c8afa716fa",
"pubkey": "3356de61b39647931ce8b2140b2bab837e0810c0ef515bbe92de0248040b8bdd",
"created_at": 1727337150,
"kind": 1,
"tags": [
[
"e",
"cbf076e853ccfdb3f4328db7be58ba1ecf57bed1de445df8b9bdb30b7ce5a607",
"",
"root"
],
[
"e",
"64e712a974186cd070df49f4b3c4c1860d249fd624c7e1d5ffc03ff902113f33",
"",
"reply"
],
[
"p",
"4eb88310d6b4ed95c6d66a395b3d3cf559b85faec8f7691dafd405a92e055d6d",
"",
"mention"
],
[
"p",
"5729ad991a7e0cb88971ced2348758105790d51160a09b22d0d8f39ca762de11",
"",
"mention"
]
],
"content": "I'm not sure what is meant by cache hijacking. \n\nRe. session hijacking we might be talking about at least two things:\n- vulnerability inside nsec.app such that someone gets access to your \"session\" in nsec.app\n- vulnerability inside nostr app connected to nsec.app that exposes the app's session/connection info so that hackers can access keys on behalf of the app\n\nThe first part doesn't have much surface with nsec.app - we only use server to store encrypted keys and to subscribe to notifications for the signer to wake up. There's basically no \"session\". And any server-side auth is based on nip-98 which requires a new token signed by your nostr keys for every request, so again there's no \"session\" - you can only sign those tokens if you steal the main key. \n\nThe second part doesn't depend on the signer (online or offline) - no matter which signer you use, it's the app that's connected to the signer that needs to be hardened against session hijacking. That's why it's super-important to not give excessive permissions to any (even trusted) app in your signer, so that potential hackers' access to keys was as limited as possible. Also when connection is established using bunker-url or nostrconnect url we use a one-time \"secret\" so make sure the connection can't be spoofed and url can't be reused.\n\nI'm not a security specialist, and I agree that a formal security audit would be beneficial. We'll get there eventually. ",
"sig": "118c5c60f7f883ad542c894400fc4621b193a3e015faa151ef903bbbcc9afa1e28bdc445697b656d5b6511bbd1fb175684bee2d1f78d8596d01b403e4017122e"
}