Hacker News Reader

Comment by VWWHFSfQ | Hacker News Reader

That PHP code right there at the very top of the page that is supposed to be representative of how great it is has multiple TOCTOU authorization and validation bugs. In fact, nearly every piece of code on that entire page is riddled with transactional bugs

View on HN

Do you mind elaborating? I can see how the user's ability to 'place-order' might be rejected between the access check and the order creation but that would be an extraordinary edge-case that does not need to be accounted for in 99% of applications.

If you're developing an application that needs to account for such an edge case you could easily do so with an insert w/ join method on the Order model. The author isn't trying to show that the code is bulletproof for every scenario.

That's really the point. The code is deceptively simple for a whiz-bang "look how easy this is!" kinda presentation but the reality is that it's not useful for anything but a toy web store. Maybe it's fine that it only works 99% of the time if you're just trading Pokemon points, but not when you're dealing with people's money.

I'd argue that a vast majority of web applications are not "dealing with people's money" so there's not a need to code for such cases.

The right tool for the right job, etc. etc.

I'd argue being able to stop worrying about your code after writing it and not making decisions like these is a good enough reason to just do it right. Especially when it's not much more additional work

https://jacobian.org/2022/sep/9/quality-is-systemic/

If you may, could you point out what are the TOCTOU bugs you have mentioned?

Everything between checking if the user can "place-order", and then validating the inputs, and then finally creating the order.

I don't think the request object can be modified by the end user or that it is modified by the server at that point. If my belief is correct, does this code still contain TOCTOU bugs?

It's the underlying state of the database that will change between these different checks. Not the end-user modifying the request object, which is in PHP memory

Thanks for explaining it.

Reply on news.ycombinator.com