Stefan Fritsch wrote: > 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. > >
+1. Well put. Regards Rüdiger
