- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 19 Apr 2010 09:37:35 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Ben Laurie <benl@google.com>, Tyler Close <tyler.close@gmail.com>, Arthur Barstow <Art.Barstow@nokia.com>, ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On 19.04.2010 09:27, Maciej Stachowiak wrote:
>
> On Apr 18, 2010, at 9:56 AM, Julian Reschke wrote:
>
>> On 18.04.2010 14:35, Ben Laurie wrote:
>>> In general, whitelists are bad because they close extension points.
>>> Please consider using a black list instead.
>>>
>>>
>>> In general, blacklists are bad because they open security holes.
>>
>> My experience is that people work around white lists by tunneling
>> information through the parts they are allowed to use. That doesn't
>> help at all, because it makes detecting and blocking the bad stuff
>> even harder (example: tunneling other HTTP methods through POST using
>> a "method override" request header).
>
> The security concern would be about accidental exposure, not deliberate
> tunneling of additional info. It's fine for two cooperating parties to
> send each other more information on purpose.
Please consider this:
Blocking unknown response headers means taking away an extension point.
On the other hand, right now we are actually also discussing *adding* an
extension header ("U", for opt-in). This obviously would be impossible
if another layer (say proxies) would already block that.
Don't do to others what you don't want to be done to yourself.
Blacklist things when there is a problem.
Best regards, Julian
Received on Monday, 19 April 2010 07:38:24 UTC