Lighttpd

but some bad code lighty return 200,some return 400,I want know why?

What bad request does lighty return 200 for, do you have an example?

200:

400:

I found a place where status 400 is set. In request.c starting at line 1047:

default:
  if (*cur >= 0 && *cur < 32 && *cur != '\t') {
    if (srv->srvconf.log_request_header_on_error) {
      log_error_write(srv, __FILE__, __LINE__, "sds",
                      "invalid char in header", (int)*cur, "-> 400");
    }

    con->http_status = 400;
    con->keep_alive = 0;

    return 0;
  }
  break;
}

In my case *char equals to ASCII char with code 5. I excluded it from <0, 32> condition. No 400 now.
Can someone tell me is there any exposure in my solution?

What is the reason to reject control character from header value field?
Is there some specification that disallow it, or is it because the server can't handle control characters in futher processing?

stbuehler wrote:

The RFCs are pretty clear: CTL chars are not allowed. The current draft is also easy to read.

Being compliant with specification is good but despite the specification there is also a normal life.
If saving special chars in cookies is possible and all browser allows for it lighttpd should handle such cookies.
There are some clever things that lighttpd may do. It may simply delete such chars or delete this one header containing this char etc.

But it is very bad idea to simply send "Bad Request" and ban a website for many many users. Maybe there should be some configuration directive telling what to do in such situation?

I checked other web servers and they accept cookies with special chars and there i no error.

So just stop tracking your users with google analytics, or tell google to fix it (or both). It might also be a good idea to tell browser vendors not to accept broken cookies.

Hahaha... I want to see when Google, Mozilla, Microsoft, Apple, Opera etc. will listen to this advice.

We need to exploit it and then report critical security bug to Google, Mozilla etc. :)
Or add some option to lighttpd configuration to allow CTL chars in cookie values if we can't exploit it.

kamil.chm@gmail.com wrote:

We need to exploit it and then report critical security bug to Google, Mozilla etc. :)

Yeah, Lets start today :-)

http://www.allkpop.com/?utm_source=test&utm_medium=test&utm_campaign=te%05st
http://www.chefkoch.de/?utm_source=test&utm_medium=test&utm_campaign=te%05st
http://eztv.it/?utm_source=test&utm_medium=test&utm_campaign=te%05st

All this sites comes from the list of websites powered by lighty (http://redmine.lighttpd.net/projects/lighttpd/wiki/PoweredByLighttpd)

I think that owners of this websites wouldn't be happy if they have been banned for millions of visitors.

I tried some weeks ago and couldn't reproduce it with any of those links - perhaps analytics got fixed.
With JavaScript I still could set broken cookies (funny enough they don't like "\r" or "\n", so there seems to be some kind of check already).

stbuehler wrote:

I tried some weeks ago and couldn't reproduce it with any of those links - perhaps analytics got fixed.

The links work. You must go to these websites and then reload them :-)

I sent it to oss-security (http://thread.gmane.org/gmane.comp.security.oss.general/9864) and got:

In general the web browser vendors are CNAs (CVE Numbering
Authorities) so they would handle this on their own end. You should
probably email this to the various web browser security teams/etc.

Someone forwarded it to the mozilla tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=858215

Just an FYI, we have fixed this in tip of the tree Chromium:
https://src.chromium.org/viewvc/chrome?revision=224268&view=revision
https://code.google.com/p/chromium/issues/detail?id=238041