I created a small application using Electron ( http://electron.atom.io ). I want to add a feature that automatically logs in people on specific websites, on any type of browser.
The way I though of this is if Electron automatically completes the username and password fields of the website OR it sends an ajax request using the website's window context ( inject himself somehow into the content ).
I know that is possible to achieve this if I create extensions for each browser but it will take too long.
Thank you
The problem you will face is all browsers are set to prevent what is known as cross-site scripting. Basically I can create a frame inside a page or within the same domain and manipulate the dom of this externally sourced frame but I can not do this with a source from another domain.
So scripting across to fill and submit the form won't work which leaves you to trying to send a HTTP GET or POST through AJAX. Which the problem we reach here is that the site you are logging into is likely to check the referring URL to ensure the referrer is from it's own domain. While technically jquery has a method of setting the referrer header, unfortunately the browser resets this header in any cross site transactions for security purposes.
So basically there is no way to accomplish this reliably from a browser side script as the browsers are very restrictive when it comes to security measures. You will be able to login via AJAX to any sites that don't check their referrer header, but other than that you would need an arrangement with the websites your logging into, or use a more unrestricted platform that will allow you to manipulate the DOM cross site or spoof the Referrer Headers.
I figured that I will use the following approach:
I've found where most browsers keep their cookies, so I will upload the cookies there. When the user accesses the browser, it will be automatically logged in.
Related
I've made a web app that stores persistent user data in localStorage. I've enabled HTTPS on my site, and I'd really like to flip the switch on HSTS. However, as far as I can tell, localStorage considers http://example.com and https://example.com to be different, so if existing users are redirected to the HTTPS version of my site, they can no longer access their data (though it still exists).
Long term, I want to build a new version of this app that offers more options for data storage. But in the short term, all I can think of is having a transition period where users at the http version are asked to migrate their data via some other (unknown) mechanism that both versions can access.
Is this a fair assessment of my options? Is there a way for https://example.com to access the localStorage of http://example.com? If not, is there anywhere I can put user data such that both versions can access it but other sites can't? Or should I ask them to download their data and re-upload it? That doesn't see ideal from a UX or (user) security standpoint.
Note that this web app doesn't interact with a server at all; everything happens with localStorage and the client.
Unfortunately there does not seem to be any way to directly retrieve localStorage contents for the less secure http copy of the site from the https site. reference
The workaround I have seen is to use an iframe loading a special page on the insecure site similar to this answer. The general theory is to have code in the iframe that sends messages using postMessage with localStorage data back to the secure page.
Unfortunately this approach does not allow you to disable http entirely, because otherwise your iframed http copy would not load.
When building a widget that is designed to be embedded on 3rd party websites, there appear to be two schools of thought as to how to do it:
Use iframes
Use the main page's DOM
When using the iframe method, cross domain requests are not a problem, as the server thinks that the request originates from its own page.
When using the main page's DOM, cross domain requests are an issue, and the server needs to respond with the appropriate CORS headers for it work.
Which of these two methods is more secure, and what security issues should be taken into account in implementing each of these methods?
You might find this post interesting - How to protect widgets from forged requests:
You don't want this [widget] to be vulnerable to CSRF so you write an iframe to the page. Based on the origin inheritance rules the parent site won't be able to read the CSRF token. However what about clickjacking (or likejacking )? Because of CSRF you must be within an iframe and there for the x-frame-options cannot help, and the same holds true for frame-busters
Negatives of IFrame approach
Vulnerable to Clickjacking / Likejacking
Negatives of DOM approach
Vulnerable to CSRF.
CORS headers on your server will be allowing access to either the whole world, or whole sites that are pre-registered with you. While this doesn't in itself present a vulnerability, care must be taken to make sure no sensitive information is made available (such as user data). There is no way to limit access to your widget only - you would be giving access to the whole Origin (i.e. protocol, domain and port).
As you are manipulating the DOM these objects would be accessible from the remainder of the page outside of your widget.
Summary
In the end it depends on the functionality of your widget. What is the consequence of the parent site automatically submitting the form or clicking a button on your widget under the context of the user? If there is a like or +1 button, the hosting page could be fraudulently promoting their site by making the like/+1 be registered with you without the user's knowledge or consent. This would apply to both approaches, only the attack method would differ (i.e. CSRF or Clickjacking).
The accepted answer on the above post has a solution for CSRF vs Clickjacking:
Clicking on the widget needs to open a pop-up window containing a new page -- an iframe is not good enough, it must be a new window -- which is entirely under the control of your web application. Confirm the action, whatever it is, on that page.
Yes, this is somewhat inelegant, but the present Web security architecture doesn't give you any better options.
In summary, the IFrame approach appears to have overall more security and implementing the popup window upon interaction mitigates the Clickjacking risk.
I am trying to load a a page into an iframe. When that page is loaded i wish to edit the contents of the "pre" tag which is inside the loaded document. The loaded doc is from another domain. I am using : resultframe is the iframe
var atag= document.getElementById("resultframe").contentWindow.document.getElementsByTagName('pre');
atag[0].innerHTML="done";
to access the tag.
problem: there seems to be no effect of this statement. I need to know the correct syntax and also that can i access the elements of pages loaded from different domain. I got the syntax from the web and also some variation of it.
Please suggest.
While JavaScript is limited by cross-domain policies that prevent interaction with another domain, there is one potential workaround as long as you can live with certain limitations.
By using something like PHP and it's cURL library you can grab the contents of a page from just about anywhere (even a secure page or one that requires a login, as long as you have credentials). You can then parse the page, edit what you need to, and display it within your own site. It's important to realize, though, that this is simply your own local copy of the page. You won't have the luxury of actually changing the contents of the page itself.
Another possibility, which would require access to all domains you wish to edit, would be to employ a web service that would accept edits in the form of a PUT request. You can achieve a lot more with a web service, but it would have to be available on all target domains that you wish to make changes to.
In the near future, XMLHttpRequest Level 2 might become a reality and will bring Cross-Origin Resource Sharing (CORS) with it. CORS will allow web applications on one domain to make cross domain AJAX requests to another domain. The target domain will have a header giving express permission to allow requests from another. Potentially, this could be used to send edits to another site.
You can't. Browsers have cross-domain policies, for security reasons.
What if I included the facebook page in an iframe, and I can get all your information because you're always connected to it?
using JavaScript, it is much needed to get some pages from the web using without actually moving from the current page and hidden from the user's eyes.
To request a web page without showing it to the user, it is easy to use XMLHttpRequest but it has its own limitations most importantly it does not retrieve cross-domain pages very well. For security reasons the browsers (Mozilla FireFox 3.6+ in my case) retrieve a header from the target site and if the referrer's location is allowed access in that header, only then will the browser continue getting the target web page and JavaScript can only then parse the retrieved info.
This causes the XMLHttpRequest to work with some pages and not work with others if you are trying to access cross-domain pages. Of course it works well if you need to retrieve the information from the same location as the referrer page where the XMLHttpRequest is located.
This is a big problem, when security is not really no 1 priority. For example, imagine writing a script for retrieving live data from a statistics-producing web site or imagine a bot that needs to retrieve data from an online gaming web-site.
Now, how can JavaScript be used to get pages from other domains (cross-domain reference)?
I thought maybe we could find a plug-in that does the job (of course after installation upon user's permission) and then use its properties by JS and eliminate the need for XMLHttpRequest. Do you know any such plug-in or another roundabout for this problem? (ie get cross-domain data by JS without XMLHttpRequest) of course we cannot use XMLHttpRequest as we don't have any control over the target page headers and we obviously want to hide the whole process from the user
You’ll find that it’s the priority that the target site puts on their own security that is most important. If they're unconcerned about JavaScript on other sites accessing their site, they can set the HTTP Access Control headers for cross-domain XMLHTTPRequest, provide a crossdomain.xml file for Flash, provide a JSONP API, or provide some hooks for iframe monitoring.
The second solution is to make the requests to a server on your domain which proxies the request to the target site. In certain circumstances you may be able to use a third party server which supports cross-domain or JSONP requests, like Yahoo! Pipes.
If neither of these is feasible, you'll need to convince the user to allow you to run your own code on their PC. This could be via a signed Java applet which requests special permissions, or your own custom browser plugins or extensions.
There are several ways including using JSONP with XMLHttpRequest, using Flash and using iframes.
Here is some information on this subject. http://snook.ca/archives/javascript/cross_domain_aj
Question originally posted on Webmasters, was recommended to move it here.
I host a webservice, and provide my members with a Javascript bookmarklet, which loads a JS sript from my server. However, clients must be logged in, in order to receive the JS script. This works for almost everybody. However, some users on setups (i.e. browser/OS) that are known to work for other people have the following problem: when they request the script via the javascript bookmarklet from my server, their cookie from my server does not get included with the request, and as such they are always "not authenticated".
I'm making the request in the following way:
var myScript = eltCreate('script');
myScript.setAttribute('src','http://myserver.com/script');
document.body.appendChild(myScript);
In a fit of confused desperation, I changed the script page to simply output "My cookie has [x] elements" where [x] is count($_COOKIE) on http://myserver.example.com. If this subset of users requests the script using the above method encoded in the bookmarklet, the message reads "My cookie has 0 elements". When they access the URL directly in their browser, the message reads "My cookie has 7 elements".
What on earth could be going on?! And more importantly, how would I fix this?
I'm pretty sure this is a privacy setting issue. The affected browsers probably have increased their privacy settings refusing 3rd party scripts from setting cookies.
I've experience similar issues when placing an IFRAME pointing to domain B on a site hosted on domain A. Some browsers refused that my IFRAME set cookies for it's own domain because it triggered a privacy issue.
You might want to store a hash in the script src attribute and have it authenticate users that way.
Edit: This is sort of what I'm talking about: Setting cross-domain cookies in Safari