3 ms·
Which is of course part of his point. Anything that processes arbitrary user input should be designed in a way that is abortable in some way. As this particular
by zaphar 10y ago
Which is of course part of his point. Anything that processes arbitrary user input should be designed in a way that is abortable in some way. As this particular case shows even the attempts to sanitize input can be vectors for a DOS against them.
- nickpsecurity 10y agoIt's why you use isolation techniques outside that code as the fall-back. Simplest forms I saw involved while loops counting downward and threads that got interrupted to assess things.
- paulddraper 10y agoEverything processes user input. Whether a numeric user id or some text.
- nickpsecurity 10y agoThat's going a bit far. User input is usually handled by a small percentage of modules. Those should guard against malicious or faulty input where possible. That's not even the issue here, though. The issue is tgat the input is processed via an algorithm thst is easy to hang and/or format that's hard to parse. On top of that, no isolation or monitor to catch the fault. Each of these can be done differently... are in many programs... to avoid or better mitigate such risks. Developers often dont.