Re: [AC] Helping server admins not making mistakes

Thomas Roessler wrote:
> On 2008-06-09 17:56:17 -0700, Jonas Sicking wrote:
> 
>> There is in fact already a standardized header that falls into the third 
>> category. The "Range" header currently does allow attacks. Consider the 
>> following:
> 
>> In our bug management system anyone can write comments about any bug. 
>> Occasionally some of these comments get marked as "security private" since 
>> they mention security sensitive things, only people in the "security group" 
>> can read these private comments.
>>
>> An attacker could write a comment containing the text
>> <?Access-Control allow="*"?><foo>
>>
>> The attacker would then set up a website that performed a cross-site XHR 
>> request to the bug page with a "Range" header stating that the part starting 
>> at the text he wrote, to the end of the document should be downloaded. The 
>> Access-Control implementation would see a document starting with the 
>> Access-Control PI followed by an element tag. 
> 
> Interesting example.  Three thoughts on it:
> 
>  - There needs to be a security consideration about Range, and not
>    getting fooled by it -- since, frankly, the implementation you
>    describe above is flawed.

Which implementation is flawed?

>  - Can we get rid of the processing instruction already?

I would actually be ok with that. But I know others have expressed a 
strong opinion to keep it.

>  - Wouldn't be a problem if we went for a model in which the amount
>    of flexibility in the client is minimal, effectively forcing
>    developers to put the enforcement into the server.

How is that?

>> However we could obviously not apply the same fix if other custom
>> headers have the same problem.
> 
> Indeed.  But maybe the fix here is really to drop the processing
> instruction and rely on headers only.

Right, but that would still only solve some of the dangerous server 
features I described. It wouldn't solve a header that stitches two 
resources together, or that allowed insertion of a custom header in the 
reply.

>> Also, for what it's worth, this is a good example of when it
>> would be useful to be able to specify that you want to support
>> Access-Control, but only support it without cookies. That way we
>> could allow mashups with our bug database, without worrying about
>> leaking private comments.
> 
> If you're really concerned about private comments, you'd probably
> want to actually check Access-Control-Origin on the server and set
> appropriate Vary headers, no?

Yes, we could ignore the cookies whenever the Access-Control-Origin 
header is sent. Or strip out the sensitive parts of the page. But that 
is much harder than simply not opting in to getting cookies.

/ Jonas