[web-devel] questions about ResponseEnumerator

[Kazu Yamamoto ( 山本和彦 )]

Hello,

> I think we need to be clear about what "vulnerability" means here.

If you don't like the word vulnerability, sorry for that.

But the following DOS is possible. A bad guy can open massive HTTP
connections to Warp and send partial bodies and keep the connections.
The connections will not time out. If the limit of open-file reaches,
Warp cannot accept a new connections from a good guy.

If my understanding is correct, this happens not only for CGI but also
for other services.

> From Warp's perspective, there is no need to defend against the
> application: if an application wants to spend five hours responding to
> a request, that's the application's prerogative. I understand that in
> the CGI case, you want to prevent something like that from happening,
> but that's beyond Warp's purview. The question is can we expose enough
> primitives to make it possible for you to implement this at the
> Mighttpd level.

Yes, applications are our friends. What I pointed out is that a bud
guy can spend five hours. And during that, applicatons cannot spend
even one second to do their service.

> So from that perspective, I'm not sure if 96311d would really be
> considered a vulnerability in Warp. Isn't your patch making it
> impossible for an application to run in unbounded time? It might make
> more sense to add a specific timeout each time the CGI app is called
> (possibly via timeout[1]) to ensure it responds appropriately. But if
> I'm not mistaken, this isn't even necessary in the CGI case, as the
> Response value will be returned by your code and will not be affected
> by the response time of the CGI app itself.

The patch is just in a "proof of concept" level. We probably should
prepare an option to let applications control time out by themselves.

Warp should be secure by default. And an application should be able to
open the door to the self-responsibility world if it wishes.

--Kazu