Hacker News Reader

Comment by unalone | Hacker News Reader

That would suggest, then, that the comment points and submission points are also controllable within some form, since they were tampered with also. Is that the case? (I'm not asking because I don't believe you - I'm just wondering how those numeric fields were altered.)

View on HN

Any field of any object could be changed this way.

Almost sounds like SQL Injection, perhaps no escaping on fnid?

Edit: I'm wrong, see below.

If I'm not mistaken, that had nothing to do with SQL injection. The fnid basically was the authenticator that allowed a person to edit a page, regardless of who was logged in.

What about other HN-powered Arc sites? Are they vulnerable as well? I won't name names, because I'm guessing they are indeed vulnerable.

Edit: Yes, they are.

Not quite. A fnid is a hash key pointing to a closure on the server.

Ah, okay. Wrong guess. Everyone can downvote me now :)

With hindsight, do you still feel fnids are a good way to go? They present an obvious bottleneck in that the server has to remember many closures for a period of time as opposed to having each client remember their share. I know you drastically reduced the use of fnids some time ago. I wonder if the remainder are a vestige that's OK to live with because life's too short, or there's fundamentally a strong argument for them I'm missing.

Sometimes these closures have more stuff in them than you could conveniently put in a url. For example, they might refer to another closure describing what to do next. When you try to do something that requires you to be logged in, for example, you're given the login page, with a fnid referring to a closure describing what you were in the middle of doing. That's why after logging in you're able to continue doing whatever you were doing.

Agreed. How about making the fnid a signed cache of often used environment variables(instead of a random string), which could also be looked up via a more time consuming method if needed. Depends really on your traffic profile how much data could reasonably and cost-effectively be cached, but it could be a very sizable portion saved by retrofitting the current method.

Indeed. fnid = function id

I think I've found and fixed for hnacademic.com, thanks to the wonderful details here.

It's very much like the "mass assignment" bugs that hit Rails servers when people forget to limit the writeability of Active Record attributes.

Escaping is needed when you pass strings to a program that parses and interprets them. That's not part of HN's architecture AFAICT. There shouldn't be any opportunity to introduce a vulnerability similar to SQL injection.

Reply on news.ycombinator.com