3 ms·

Here's why I dislike it. You shouldn't rely on the HTTP request parser to save you if you have security issues elsewhere. The HTTP parser is simple enough to n

by points 16y ago

Here's why I dislike it. You shouldn't rely on the HTTP request parser to save you if you have security issues elsewhere. The HTTP parser is simple enough to not have any concerns in itself if written properly. You should fix the security issues.

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 ago
  Because 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 ago
    The 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.
Kaizyn 16y ago
It's quite simple really. Do you like your compiler? Or would you rather write code and hope for the best? Compilers work because they have a formal grammar of what is and is not acceptable in the programming language. This same principle is being applied to handling web requests. We have a standard - HTTP - and any requests that don't conform to the protocol are immediately rejected by Mongrel2. Since many attacks against web servers involve sending improper web requests, this sort of approach simply rejects those requests and doesn't even begin to process them. This certainly doesn't prevent Mongrel2 from implementing proper security at other appropriate places in the code. It simply stops a whole lot of potential exploits before they start.
- points 16y ago
  Yeah that's not really comparable. HTTP requests come from millions of different browsers. Some with bugs, some with idiot creators, etc etc. My point was that an HTTP request parser is trivial to write correctly. What you do with the headers and request later on are where sometimes you need to be careful. TBH Though I think I'm just in a different world to all of this mongrel stuff.

by points 16y ago

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 ago
Because 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 ago
  The 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.

Kaizyn 16y ago

It's quite simple really. Do you like your compiler? Or would you rather write code and hope for the best? Compilers work because they have a formal grammar of what is and is not acceptable in the programming language. This same principle is being applied to handling web requests. We have a standard - HTTP - and any requests that don't conform to the protocol are immediately rejected by Mongrel2. Since many attacks against web servers involve sending improper web requests, this sort of approach simply rejects those requests and doesn't even begin to process them. This certainly doesn't prevent Mongrel2 from implementing proper security at other appropriate places in the code. It simply stops a whole lot of potential exploits before they start.

points 16y ago
Yeah that's not really comparable. HTTP requests come from millions of different browsers. Some with bugs, some with idiot creators, etc etc. My point was that an HTTP request parser is trivial to write correctly. What you do with the headers and request later on are where sometimes you need to be careful. TBH Though I think I'm just in a different world to all of this mongrel stuff.