W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

[EPR] initial feedback

From: timeless <timeless@gmail.com>
Date: Wed, 1 Jul 2015 11:43:16 -0400
Message-ID: <CACsW8eHhFSbg-dKjKmt6z=v04y35H3+uiP9U2+iC77MTm0ZTzg@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
http://www.w3.org/TR/2015/WD-epr-20150609/

> These attacks all rely on the fundamentally porous nature of the web: any addressible [sic] portion
> while allowing user intent to trumph [sic] brittle filters when possible.
> While thiswould [sic] allow them to sidestep the security concerns inherrent [sic] with the web platform
> Navigations are susceptable [sic] to XSS

> navigational request if its context frame type is one of "top-level", "auxiliary", or "nested".

Note that this document seems to have significant overlap  to the
sorts of inputs/outputs addressed by service workers' frametype [1].

> (POST vs GET, etc)

vs.
etc.

> If there isn’t a similar very specific distinction between attacks that would involve subresource and connection requests than [sic] we should merge them.

then

> It could make sense to split out IMAGE SRC, SCRIPT SRC, etc. requests.

you want a comma after `etc.`

> As no EPR manifest, and therefore no policy, is available for this request, a default EPR policy will apply as described in `§4.2 Default EPR policy `.

pattern:
Please do not underline trailing (or leading) whitespace.

> This means we’ll grab an EPR manifest file, and store it persistently for use in regulating future requests.

This sounds like another source for an evercookie (covered by 3.2.4.
Caching, but perhaps worth a forward pointer).


> This member’s value is an [sic] dictionary adhering to the following IDL:

> The following IDL defines rules' syntax:

rule's

> dictionary EPRRule {

> If true, then matching requests' URLs are allowed to contain non-empty query and fragment properties, and requests' body may be non-null.

This is easier to read if you use `then a matching request's URL is
.... request's body ...`

> If an author can limit incoming traffic to a strict set of well-audited entry points, web applications can reduce the risk these attacks present, and indeed some authors have taken steps to do so via server-side logic, single page application (SPA) frameworks, (and, soon, via Service Workers).

I know you want an Oxford comma, but if the parenthetical is omitted,
you're left with a dangling comma, which is IMO a more serious
offense. If you stashed the parenthetical before the last item in the
list, this wouldn't be a problem.

> The following behaviors are defined (and, if none is explicitly specified, then allowStrippedGET is used as a default):

a => the ??

> Drop cookies and other authentication properties of the request by setting it’s [sic] credentials mode to "omit".

> Note: rules may be the empty set if no rules are specified. In this case, the behavior specified in the policy’s navigationBehavior or subresourceBehavior will be applied to all incoming requests.

I know you're using `incoming` consistently, but from my perspective
(unless you define `incoming to a policy`, which i don't believe
you've done), requests are incoming to a server and not to a
policy/rule -- certainly from the UA's perspective, these requests are
outgoing.

> block
> 1. Cancel the request, and return a network error.
> redirect
>     Do not make the request to the original resource. Redirect the user agent to the redirectURL.

Why isn't this numbered?

> Given matched is false, the user agent should initiate a new background manifest download. It

This `should` should be `SHOULD`.

> An EPR header has been received by the user agent indicating that the site site [sic] has opted-in to EPR.

opted into [2]

> No EPR manifest is currently available. (Possibly because it hasn’t been downloaded yet, it failed to parse, etc.

unclosed `(`

> one or more of the following statements is true:

is => are [3]

> response’s request’s context is manifest

missing `.`

> 4. If rule path list’s length is greater than url path list’s length, return Does Not Match.
> 5. For each entry in rule path list:
> 5.1. Percent decode entry.
> 5.2. Percent decode the first item in url path list.
> 5.3. If entry is not an ASCII case-insensitive match for the first item in url path list, return Does Not Match
> 5.4. Pop the first item in url path list off the list.

Instead of `popping the first item`, could you just use `corresponding item` ?
The lack of parallelism between `entry` and `first item in` is really
dissontant.

> 6. If exact match is true, and url path list is not empty, return Does Not Match

missing `.`

rule: a/b/
input: a/b/c/

I'm pretty sure that 6 could be moved before 5 and written as a length
check (in the direction opposite to 4).

> A regular expression, defining a rule’s scope. See §4.4 Does request match rule? for user agent conformance requirements. One path or regex may be specified for a given rule, but not both.

> Let rule regex be rule’s regex.

say I have:
{
  "epr": {
    "reportURL": "https://example.com/reporting-endpoint",
    "redirectURL": "https://example.com/",
    "navigationBehavior": "allowStrippedGET",
    "subresourceBehavior": "allowStrippedGET",
    "rules": [
      {
        "regex": "[",
        "types": [ "navigational" ],
        "allowData": false
      },
    ]
  }
}

... Where `[` isn't a valid regexp... , what happens? :)

> 6. If rule’s allowData is false, then return Does Not Match if any of the following statements are true:

Surely this is cheaper than 4/5, why not list it after 3 instead of after 5?

> { "epr-report": { "policy-fetch-time": Thu Apr 16 2015 14:23:46 GMT-0700 (PDT) "affected-uri": "http://example.org/page.html", "referrer": "http://evil.example.com/", "type": "navigational", "applied-behavior": "allowStrippedGET", "redirectedTo": "" } }

This isn't valid JSON, your date isn't quoted.

[1] http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/#client-frametype
[2] http://idioms.thefreedictionary.com/opt+in
[3] http://english.stackexchange.com/a/13286
Received on Wednesday, 1 July 2015 15:43:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC