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 mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
