3 ms·

How are those closures identified uniquely? I'm not super familiar with lisp, but I do get closures and memory addresses and am suspicious.

maxbond 6y ago
This was the case when I was poking at Hacker News. I think it may still be the case to some extent. Here's an example of an HN password reset link: hxxps://news.ycombinator.com/x?fnid=<long-random-value>&fnop=passwd-reset `fnid` identifies a closure. Presumably there's a hashmap of `fnid` values to closures in memory. It used to be that this was how any action on the site was represented. I poked around for a minute though, and it's evidently not the case for upvotes any more: hxxps://news.ycombinator.com/vote?id=<integer>&how=up&auth=<long-random-value>&goto=<return-url>
- snazz 6y ago
  They had to stop using GET requests for upvotes after this issue: https://news.ycombinator.com/item?id=3742902 https://news.ycombinator.com/item?id=3742902 I'm interested in whether the password reset link is a potential issue still.
  - maxbond 6y ago
    Well, that URL doesn't have an `fnid` in it. It looks to me like they just guessed their `id`, which is simply an incrementing identifier. They're still using GET for upvotes, but they include a CSRF token. Using GET to change state, like they're discussing in that thread, is really more of a style issue than a security issue. You need a CSRF token, whatever verb you use. And that was a few years before my recollection of upvotes using an `fnid`. (I could also be misremembering.) In the case of password resets, I don't think there's a functional difference between using a map of closures with random tokens and comparing random tokens stored in a database, as is the more conventional approach. If you can guess the random token, or if you can extract them via a side channel, then you can reset passwords. And if you can't, you can't. Which isn't to say it's not worth having a look :)

maxbond 6y ago

This was the case when I was poking at Hacker News. I think it may still be the case to some extent. Here's an example of an HN password reset link: hxxps://news.ycombinator.com/x?fnid=<long-random-value>&fnop=passwd-reset `fnid` identifies a closure. Presumably there's a hashmap of `fnid` values to closures in memory. It used to be that this was how any action on the site was represented. I poked around for a minute though, and it's evidently not the case for upvotes any more: hxxps://news.ycombinator.com/vote?id=<integer>&how=up&auth=<long-random-value>&goto=<return-url>

snazz 6y ago
They had to stop using GET requests for upvotes after this issue: https://news.ycombinator.com/item?id=3742902 https://news.ycombinator.com/item?id=3742902 I'm interested in whether the password reset link is a potential issue still.
- maxbond 6y ago
  Well, that URL doesn't have an `fnid` in it. It looks to me like they just guessed their `id`, which is simply an incrementing identifier. They're still using GET for upvotes, but they include a CSRF token. Using GET to change state, like they're discussing in that thread, is really more of a style issue than a security issue. You need a CSRF token, whatever verb you use. And that was a few years before my recollection of upvotes using an `fnid`. (I could also be misremembering.) In the case of password resets, I don't think there's a functional difference between using a map of closures with random tokens and comparing random tokens stored in a database, as is the more conventional approach. If you can guess the random token, or if you can extract them via a side channel, then you can reset passwords. And if you can't, you can't. Which isn't to say it's not worth having a look :)