W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 3 Mar 2016 10:18:52 +1100
Cc: HTTP WG <ietf-http-wg@w3.org>
Message-Id: <54E9552F-5569-4E79-814A-08A6039FB12C@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>

> 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.


Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 2 March 2016 23:19:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC