Nostr Web Client

It should indeed return false, but what the library does is it stores a thing in the object saying it is verified. You are not supposed to edit it afterwards.

nostr:nprofile1qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcprfmhxue69uhhyetvv9ujuumgd96xvmmjvdjjummwv5hszxthwden5te0dehhxarj9e3k76twve6kuepwv9c8qtcqypuu9jhpzn4z32vpua2eknl8s49ywdfp4rfz5e4m4w06yj8tsg8lvxxqdcn this is your fault! Can we fix it using TypeScript magic or better not even try?

Do you have an actual use case here or were you just playing with the library and saw this craziness nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsqgy7r0g9a4q7023dmg0fke9chfytdxasl266yt2y9fy4kxlef2dsxqpm0qt2 ?

Daniele 1y ago

I was giving for granted that it behave that way, then today I made an integration test over my signup API to see taht it would fail under an "attack" with a modified event.

The test failed and I got scared so I did dig deeper and wrote that test.

The whole library assembles in the "finalized event" both the original event and the sig/pub/hash properties. So when you call verifyEvent it uses the hashes that one pass as "id" rather than recalculate the hash from scratch from the original event properties.

I am no security expert but that look *very* bad to me.

Reply to this note

Please Login to reply.

Discussion

Daniele 1y ago

TBC: the integration test "failed" means that the signup HTTP worked despite the modified event being sent through, while it should have returned 401.

fiatjaf 1y ago

What? No. "verifyEvent" checks that the actual hash matches the id. What is bad there?

Daniele 1y ago

If it does that, as one would expect, why the check returns true while it should be false?

fiatjaf 1y ago

I just explained it three notes above.

Daniele 1y ago

The note starting with "It should indeed return false"? :)

My point is that the library should not assume that everything has been done properly, quite the opposite.

"You should not change the event" is one thing. Assuming that will not happen and returning that an altered event is verified is another.

The semantic of "verified" here becomes: there is a property set as verified: true in the json. While it should not what it should be or at least what I was expecting.