3 ms·
> You shouldn't rely on the HTTP request parser to save you if you have security issues elsewhere This doesn't make sense. Why should a particular piece of th
by bmm6o 16y ago
> You shouldn't rely on the HTTP request parser to save you if you have security issues elsewhere
This doesn't make sense. Why should a particular piece of the application not be coded with security in mind?
> You should fix the security issues.
One part of this is sanitizing user input. Why would you not do this as early as possible?
- points 16y agoBecause it's inefficient unnecessary overhead for static requests. The place to block application specific hacky looking requests isn't in the general HTTP request parser. It's in the 'application specific' stuff.
- blasdel 16y agoThe headers and such for even the most static requests still get used all over — dispatch, caches, logging, etc. The overhead is minuscule, especially compared to a hand-rolled parser that's literate enough to be maintainable. And the purpose isn't to "block application specific hacky looking requests", it only does that as a side-effect — this isn't some inane IDS bullshit sold to PHBs. It's not looking for exploit signatures, it just sanitizes all input as a consequence of correctness.