4 ms·

Wasn't the last publicly-released version of Arc even stranger, with everything being a GET request and links containing a URL parameter that corresponded to a

by snazz 6y ago

Wasn't the last publicly-released version of Arc even stranger, with everything being a GET request and links containing a URL parameter that corresponded to a Lisp closure? I'd be interested in hearing some more up-to-date information about how HN is hosted and works today.

ComputerGuru 6y ago
Yeah, that's no longer the case. If your url predated the gc run or was from before a restart, you would get a server 500 message.
- voodootrucker 6y ago
  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 :)

by snazz 6y ago

ComputerGuru 6y ago

Yeah, that's no longer the case. If your url predated the gc run or was from before a restart, you would get a server 500 message.

voodootrucker 6y ago
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 :)