Re: #144: Attacks from Same Host (OppSec)

> On 2 Mar 2016, at 4:44 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 2 March 2016 at 16:27, Mark Nottingham <mnot@mnot.net> wrote:
>> 1) Is this roughly what people had in mind?
> 
> Yes, this seems fine.
> 
>> 2) Do we need to get a positive indication from both the origin and the alternative, or just the origin?
> 
> If the alternative is actually an alternative, the .well-known
> solution should produce files in both places.  So checking both won't
> just especially.

parse error


>> 3) Do we need a more solid indication than a 200 OK? E.g., media type?
> 
> 200 OK seems a bit weak, but I think that it would suffice if we
> didn't want to extend in any way.
> 
> Including the actual origin (or maybe origins) in the document would
> prevent accidents, I think.

A JSON file containing an object like this:

HTTP/x 200 OK
Content-Type: application/json
{
  'origin': 'https://foo.example.com:443'
}

would answer a few questions here, I think...


>> 4) What should be in the well-known URI's representation, if anything?
> 
> I'm a fan of JSON for this sort of thing.
> 
>> 5) Should we tie the validity period of the well-known URI to its cache freshness lifetime?
> 
> I think not.  I'd prefer an explicit indication in the JSON itself.
> An expired document will mean that the value might be refreshed more
> often than the real validity period.

What's the benefit here? It just seems like an opportunity to have a mismatch between the real validity period and how long it lives in intermediary caches, etc.


> If we do this part right, we can ditch the new header field, which was
> never that nice.

+1


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 2 March 2016 23:19:20 UTC