Re: Entry Point Regulation vs Simpler Solutions (was Re: WebAppSec re-charter status)

Re DOM-based XSS...  EPR can in theory mitigate DOM-based XSS to an extent,
for example when injection is triggered by data in the querystring.  Since
EPR implements policy at the client, it even has visibility into data in
the URL after the hash whereas the server would not.

Browser-based XSS filters should be seen as defense-in-depth features and
do not block all conceivable XSS, by design.  Their efficacy is based in
part on how injection points happen to present themselves on target pages.
So EPR is a way that a web developer could definitively prevent all
reflected XSS / XSRF under foo.com/bar, whereas an XSS filter is more
opportunistic (but active by default).

It's important to understand that for any large body of complex web content
exists a stream of incoming XSS / XSRF bugs.  CSP might be the answer to
this problem one day, but for now it's hard to get bulletproof CSP policies
deployed for practical reasons.  EPR provides a complementary approach that
is useful and justified in some (not all) applications.

For every example we might find that looks like:

https://news-site.foo/an-article-we-all-should-be-able-to-deep-link.html

...I can give a counter-example...

https://admin-control-panel.ImportantCorp.foo/apis/internal.api

...that is intended as internal to the site and should not be exposed to
outside callers.  This endpoint is only exposed to external callers today
as an artifact of the existing web development model.

I want to make EPR more compatible with the priority of constituents HTML
principle as long as we don't subvert the basic purpose of EPR, which is to
protect users from XSS / XSRF.

Dave

On Wed, Feb 25, 2015 at 10:37 AM, Eduardo' Vela" <Nava> <evn@google.com>
wrote:

> On Wed, Feb 25, 2015 at 7:33 PM, Brian Smith <brian@briansmith.org> wrote:
>
>> Eduardo' Vela" <Nava> <evn@google.com> wrote:
>> > Anne asked why EPR solves XSS/CSRF in a way that can't be solved via
>> other
>> > means.
>> >
>> > In specific for XSS. In many situations, CSP is simply undeployable.
>> Even
>> > for applications written from scratch, because of the dependencies on
>> > widgets/controls that aren't compatible with CSP and aren't interested
>> to be
>> > CSP-friendly. As a result, while CSP is a great tool for some sites,
>> it's no
>> > silver bullet.
>>
>> With respect to XSS, which types of XSS does EPR prevent? Reflected,
>> Stored, DOM? I noticed that in the original announcement, David Ross
>> specifically singled out only reflected XSS:
>> https://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0009.html.
>>
>> I can see how EPR would prevent reflected XSS if the EPR policy
>> prohibited the user from navigating to resources of their choosing.
>> But, it isn't clear to me how EPR can prevent XSS without reducing
>> users' ability to navigate to whatever resource they want ("deep
>> linking") and that isn't already covered by "X-XSS-Protection: 1;
>> mode=block".
>>
>
> Yes, it prevents reflected XSS, which for some applications for example
> (Google, in specific) correspond to the vast majority of vulnerabilities.
>
> Additionally, XSS filters are not security controls. It's reasonably easy
> to bypass any of the browser XSS filters, IE, NoScript or Chrome's within a
> couple hours. While they have been getting better over the years, they are
> definitely far from being effective controls, and by the looks of it, they
> won't be in our lifetime.
>
> > For CSRF, first-party cookies resolve the concern quite effectively,
>> > however, it requires modifying application logic, and EPR allows
>> someone to
>> > deploy this on an existing website almost trivially.
>>
>> Great. I'm excited to see Mike West seems to be making progress on
>> first-party cookies now.
>>
>> I appreciate that EPR is very simple to deploy compared to other
>> protective measures. AFAICT, the primary issue is whether that
>> ease-of-deployment justifies decreased user agency, or whether EPR can
>> even work without decreasing user agency and violating the priority of
>> constituents HTML design principle.
>
>
> I agree that's the primary issue being raised. We'll see how it works out
> :)
>
>
>> Cheers,
>> Brian
>>
>
>