Hi.
While working on an HTML-escaping filter for my evhttp_send_reply_html()
something came to me...
The purpose of evhttp is to build something around a really minimalistic
httpd, possibly in the embedded world; so you want to report error
messages beyond the HTTP status code - and on the other hand you don't
want to participate your web-server in cross-site-scripting attacks, so
any HTML response must be properly escaped.
The only place where you have such a situation currently is in your 404
handler where you manually escape it, but even that is somewhat
unfortunate; low-memory conditions could make the escaping fail and you
could no longer actually report the first failure.
Now, it's a reasonable assumption that an application built on top of
evhttp will also have lots of cases where something went wrong and they
want to get out with an error-message. In my application there are lots
of code fragments like:
if(stm == NULL) {
evhttp_send_reply_html(req, 404,
"Stream %"PRIxPTR" not found", stream_id);
return;
}
if(stm->bev == NULL) {
evhttp_send_reply_html(req, 400,
"Stream not connected");
return;
}
if(bufferevent_write_buffer(stm->bev, req->input_buffer) < 0) {
evhttp_send_reply_html(req, 500,
"Writing to buffer failed");
return;
}
Granted, in these cases escaping is not an issue, but I have other
fragments where I put part of the input in the response - thereby
opening the world to XSS unless the response is escaped.
So my idea is - why not stick to text/plain in both evhttp_send_error
and my envisioned evhttp_send_reply_html? (which obviously would need
another name).
To further discourage developers to introduce format-string-related
vulnerabilities the functions should probably split into:
evhttp_send_reply_text(struct evhttp_request *req,
int code, const char *msg);
evhttp_send_reply_textf(struct evhttp_request *req,
int code, const char *fmt, ...);
As for the status phrase - I think it would be nicest to only include
it for non 2xx codes like:
$ curl http://127.0.0.1:8080/stream?action=foo
ERROR 400: Bad Request
Invalid action 'foo' specified
$
But:
$ curl http://127.0.0.1:8080/stream?action=create
20e7cf0
$
Just thinking out loud here... tell me what you think.
Cheers,
Felix
***********************************************************************
To unsubscribe, send an e-mail to [email protected] with
unsubscribe libevent-users in the body.
