Hacker News Reader

Comment by victorbjorklund | Hacker News Reader

You can "drop" that request which fails instead of crashing the whole app (and dropping all other requests too).

Sure. You wouldn't want a webserver to crash if someone sends a malformed request.

I'd have to think long and hard about each individual case of running in degraded mode though. Sometimes that's appropriate: an OS kernel should keep going if someone unplugs a keyboard. Other times it's not: it may be better for a database to fail than to return the wrong set of rows because of a storage error.

That's exactly what the attacker wants you to do after their exploit runs: ignore the warning signs.

You don't ignore it. You track errors. What you don't do is crash the server for all users, giving an attacker an easy way to DoS you.

A DoS might be the better option vs. say, data exfiltration.

Most bugs aren't going to create any risk for data exfiltration. In most real application servers (which are very rarely written in C or C++ these days), requests are almost completely isolated from each other except to the extent that they interact with a database. If you detect a bug in one request, you just abort the one request, and there's likely no way it could affect others.

This is part of why something like Rust is usable at all; in the real world a lot of logic has straightforward, linear lifecycles. To the extent that it doesn't, you can push the long-lived state into something like an external database, and now your application has straightforward lifecycles again where the goal of a task is to produce commands to manipulate the database and then exit.

Sure, but i was talking about an individual process. If you don't know what state it's in, you simply can't trust it to run anymore. That's all.

Except you usually can because the state isn't completely unknown. You might not expect some field in a structure to be null, but you still know for example that there's no way for one request to have a reference to another, so you just abort the one request and continue.

No, if you have been compromised, you cannot make these assumptions.

And what does DOS attacker want you to do? Not crashing the whole service to deny others of the service?

That is a valid tradeoff in many situations, yes.

Reply on news.ycombinator.com