RE: [Moderator Action] #144: Attacks from Same Host (OppSec)

My biggest issue was that saying Alt-Svc filtering was the answer imposed a new requirement on existing servers that haven't seen the spec. The well-known URI could simply signal that the server is aware of the specification and blocks user generated Alt-Svc headers.

-----Original Message-----
From: Kari Hurtta [mailto:hurtta-ietf@elmme-mailer.org] 
Sent: Sunday, March 13, 2016 10:49 AM
To: HTTP WG <ietf-http-wg@w3.org>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; Martin Thomson <martin.thomson@gmail.com>; Mark Nottingham <mnot@mnot.net>; Mike Bishop <Michael.Bishop@microsoft.com>
Subject: Re: [Moderator Action] #144: Attacks from Same Host (OppSec)


https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0394.html


| The only thing remaining then is Kari's suggestion that the 
| .well-known file also include the alternatives, to mitigate the case 
| when an attacker has 1) the ability to inject response headers, 2) the 
| ability to listen on a port on the same host, and 3) doesn't have the 
| ability to modify .well-known (AKA "shared hosting w/ shell access").

( I mentioned this earlier, but not to: HTTP WG <ietf-http-wg@w3.org> )

Yes, I like that browser can defend against this attack also.
Mike Bishop described that attack:

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0064.html


| http://users.example.com is a shared server which hosts user home 
| pages.  Eve places a config file in her wwwpages directory to add an 
| Alt-Svc header to pages served out of http://users.example.com/~eve 
| announcing an alternative service for http://users.example.com on port 
| 23412.  Bob is using an Alt-Svc-capable browser.  After Bob has 
| visited http://users.example.com/~eve, he visits 
| http://users.example.com/~alice.  His browser, obeying Eve's Alt-Svc 
| header, accesses the alternative service on port 23412, where Eve is 
| running a forward proxy that replaces all pages except her own with 
| dancing hamsters.

I also have home page on my hosting provider like  http://home.hosting.provider/~account/


(where 'account' is user id used on shell access. )

My hosting provider ssh access (that is how pages are modified.)

There also seems to have over 5000 other accounts, so there is probably quite many home pages like that.

These are Apache Per-user web directories https://httpd.apache.org/docs/2.4/howto/public_html.html


I suspect that shell access is not be as rare than you imagine. At least search for "web host provider with shell access" tells that this feature is provided.

I do not know if these accounts on these providers share same origin (aka http://home.hosting.provider/~account/ or http://home.hosting.provider/account/).


This is fine when http://home.hosting.provider/.well-known/http-opportunistic

does not exists.

Also I have sites http://account.hosting.provider/, https://account.hosting.provider/ and http://www.elmme-mailer.org/ but these does not share same origin with other accounts on here.
So on these sites sharing is not a problem.

And documentation on my hosting provider says that users can run application servers which listen ports between 30000–40000.

This is allowed but not not recommended – Using of FastCGI or CGI is recommended.

If hosting provider wants provide Opportunistic Security for HTTP for http://home.hosting.provider/, it needs add

http://home.hosting.provider/.well-known/http-opportunistic


with content

{
 "origins": [ "http://home.hosting.provider/" ] }



But now any of 5000 users can also run listener on home.hosting.provider and inject

Alt-Svc: h2=":30000"

header field on his pages http://home.hosting.provider/~username/ when using CGI.

home.hosting.provider can defend this with filtering Alt-Svc:
from UserDir -pages generated with CGI or FastCGI

Alternatively home.hosting.provider can defend this attack with NOT publishing http://home.hosting.provider/.well-known/http-opportunistic

but instead using valid certificate (RFC for "HTTP Alternative Services").

There exists wildcard certificate for *.hosting.provider -name.

But then home.hosting.provider can not use "commit" either because that requires http://home.hosting.provider/.well-known/http-opportunistic



But there is little what browser can use to defend against that attack:

1) Browser can just ignore Alt-Svc: if there is not valid certificate
2) Browser can ignore Alt-Svc: if there is ~ on URL
3) Browser can ignore Alt-Svc which gives port > 1023
4) Browser can ignore Alt-Svc for all other paths except 
  '/' , '/.well-known/…' and '*' (OPTIONS)

But these 2) and 3) does give much guarantee to browser.

Then browser is just ignoring Alt-Svc: if there is not valid certificate
so no "Opportunistic Security for HTTP" -support, just support for
"HTTP Alternative Services". 

Perhaps option 4) makes sense for browser (i.e. look that 
/.well-known/http-opportunistic ALSO returns same 
Alt-Svc: -header field). However this is not actually specified.
This is effectively also same than that .well-known also 
lists alternatives. And this does not work if several 
alternatives are rotated on Alt-Svc: -header field.

Browser is easier to defend for this attack (and support
Opportunistic Security for HTTP") if there is
"alternatives" member in the http-opportunistic 
well-known resource.

That "alternatives" member lists valid alternatives which 
are allowed for given in Alt-Svc: -header filed.
I do not have suggested exact syntax for this member. 

Alternatively browser can defend for this attack
if there is "valid-ports" member in the http-opportunistic 
well-known resource. This is enough when origin and alternative 
service’s hostnames are the same.


This is perhaps over-engineering here:

Alternatively browser can defend for this attack
if "origins" member in the http-opportunistic is
not list of strings but if "origins" is
a object where member names are origins
and member values are either list of
alternatives or list of valid-ports.

That is: every origin lists which are alternatives
for it. But I think that this is too complicated:

HTTP/1.1 200 OK
Content-Type: application/json
Connection: close

{
 "origins": { "http://example.com": [ 88 ],
              "http://www.example.com:81":  87 ] },
 "commit": 86400
}



(( And then it makes sense to move "commit" also 
  to be per-origin:

{
 "origins": { "http://example.com": {
      "valid-ports":  [ 88 ],
      "commit": 86400 },
     "http://www.example.com:81": {
 "valid-ports":  [ 87 ],
      "commit": 86400 },
  }
}


This is too complex.  So just keep it simple:

{
 "origins": ["http://example.com", "http://www.example.com:81"],
 "commit": 86400,
 "valid-ports": [ 88, 87 ]
}

or "alternatives" instead of "valid-ports".

))


There is no so many different browsers, so I think 
that makes sense them defend against this attack (if 
they support "Opportunistic Security for HTTP").

Getting origins / sites correct is harder, I think.
It is quite easy to add Alt-Svc: header field
to some places but harder to filter Alt-Svc: 
header field from all unwanted outputs. 

/ Kari Hurtta

Received on Monday, 14 March 2016 17:30:35 UTC