httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: breach attack
Date Wed, 07 Aug 2013 21:46:38 GMT
Am Dienstag, 6. August 2013, 10:24:15 schrieb Paul Querna:
> 1) Disabling HTTP compression
> 2) Separating secrets from user input
> 3) Randomizing secrets per request
> 4) Masking secrets (effectively randomizing by XORing with a random
> secret per request)
> 5) Protecting vulnerable pages with CSRF
> 6) Length hiding (by adding random amount of bytes to the responses)
> 7) Rate-limiting the requests
> 
> 
> Many of these are firmly in the domain of an application developer,
> but I think we should work out if there are ways we can either
> change default configurations or add new features to help
> application developers be successful:

IMNSO, we are way past the point where we should patch up even more 
issues that are caused by the broken security module of web browsers. 
Instead, browsers vendors should fix this issue, for example by 
offering a way to easily opt out of sending credentials with cross-
domain requests (maybe analogous to Strict Transport Security).

I am against putting any mitigation measures into httpd that adversely 
affect normal use, like adding chunk extensions that will likely break 
lots of clients, or like making mod_deflate much less efficient. 
Though if somebody comes up with a clever scheme that has no negative 
side effects, that would be of course fine. Or if we add some rate 
limiting facility that would be useful for many purposes.


Mime
View raw message