I made a tool that grabs all html, css, javascript and images from other websites (any kind).
Then i execute this on my own domain name (after modification of links of course).
The javascript also executes, so the page render is identical as on the grabbed website. But all under my domain name.
Is there any method to secure this javascript execution (with uncontrolled code) so that the grabbed site will not be able to get cookies of the users of my website ? (or other potential security breach?)
Thanks.
thought you should never execute random js on your page.
still i think there is one way to do it though it requires huge amount of effort.
onces your pages gets loaded. override all the global variables of javascript that the browser injects to your own implementation and implement security checks in there. this way all the random js being executed in your page will access all the functionalities that way you want them to do
ex. override document.cookie to something else on pageload which then execludes that cookies of your domain.
change the protoype of xmlHttprequest so that ajax requests to your domain are blocked. etc etc
Running the random page on a separate origin (i.e. running it on a separate domain) will at least avoid data leaks (cookies, localStorage, etc) between the random page and your site. To avoid leaks from one random page to an other, maybe also run each random page on its own sub-domain.
I believe this is what google does for the cache; the pages are served from the googleusercontent.com domain: https://webcache.googleusercontent.com/search?q=cache%3Astackoverflow.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a
There is no way to prevent data leaks without running the page on a separate domain.
Related
I was wondering whatever there is way to check in JavaScript that the website was loaded fully securely, and that it was not modified on user's site (for example by malicious addon)
I found that often such malicious addons are breaking SSL by adding adverts or other malicious scripts, therefore I am wondering how could I detect mixed content warning such as displayed on this image:
(the image taken from https://www.ssl2buy.com/wiki/fix-mixed-content-nonsecure-items-error-on-ssl-secure-site )
I have found the following questions, however I believe that those questions do not fully answer my question:
How can I use JavaScript on the client side to detect if the page was encrypted?
How do I determine whether a page is secure via JavaScript?
My question is how to detect if website was loaded insecurely (or modified at user's end), even if protocol used was https://
side note: I know that such script could be easily deleted by an addon that adds the malicious scripts/adverts/etc., however I prefer to have additional layer of security.
I was wondering whatever there is way to check in JavaScript that the
website was loaded fully securely
Well assuming a malicious addon is able to manipulate your DOM content I belive you can't.
You can however check whether the page was loaded fully encrypted.
One approach for doing so is to check the protocol of A) the current URL and B) all href and src attributes in your DOM.
But this cannot proof that your page was loaded fully securely. It may only confirm that all loaded content on your site was encrypted, but an attacker can (and they actually do) get a TLS/SSL certificate (e.g. using letsencrypt) and simply distributes its malicious code using HTTPS.
Furthermore, you would have to check your DOM for iFrames which might also be able to execute malicious code.
The only thing you could do that might addresses the issue is to check all hrefs & src as mentioned above and additionally compare them against a whitelist.
Eventually as you already mentioned, your script can be easily blocked by the malicious addon. Therefore, I am not convinced such a script is worth the time.
I have two scripts. I put them in the same namespace (the #namespace field).
I'd like them to interactive with another.
Specifically I want script A to set RunByDefault to 123. Have script B check if RunByDefault==123 or not and then have script A using a timeout or anything to call a function in script B.
How do I do this? I'd hate to merge the scripts.
The scripts cannot directly interact with each other and // #namespace is just to resolve script name conflicts. (That is, you can have 2 different scripts named "Link Remover", only if they have different namespaces.)
Separate scripts can swap information using:
Cookies -- works same-domain only
localStorage -- works same-domain only
Sending and receiving values via AJAX to a server that you control -- works cross-domain.
That's it.
Different running instances, of the same script, can swap information using GM_setValue() and GM_getValue(). This technique has the advantage of being cross-domain, easy, and invisible to the target web page(s).
See this working example of cross-tab communication in Tampermonkey.
On Chrome, and only Chrome, you might be able to use the non-standard FileSystem API to store data on a local file. But this would probably require the user to click for every transaction -- if it worked at all.
Another option is to write an extension (add-on) to act as a helper and do the file IO. You would interact with it via postMessage, usually.
In practice, I've never encountered a situation were it wasn't easier and cleaner to just merge any scripts that really need to share data.
Also, scripts cannot share code, but they can inject JS into the target page and both access that.
Finally, AFAICT, scripts always run sequentially, not in parallel. But you can control the execution order from the Manage User Scripts panel
I need to be allow content from our site to be embeded in other users web sites.
The conent will be chargeable so I need to keep it secure but one of the requirements is that the subscribing web site only needs to drop some javascript into their page.
It looks like the only way to secure our content is to check the url of the page hosting our javascript matches the subscribing site. Is there any other way to do this given that we don't know the client browsers who will be hitting the subscribing sites?
Is the best way to do this to supply a javascript include file that populates a known page element when the page loads? I'm thinking of using jquery so the include file would first call in jquery (checking if it's already loaded and using some sort of namespace protection), then on page load populate the given element.
I'd like to include a stylesheet as well if possible to style the element but I'm not sure if I can load this along with the javascript.
Does this sound like a reasonable approach? Is there anything else I should consider?
Thanks in advance,
Mike
It looks like the only way to secure our content is to check the url of the page hosting our javascript matches the subscribing site.
Ah, but in client-side or server-side code?
They both have their disadvantages. Doing it with server-side code is unreliable because some browsers won't be passing a Referer header at all, and if you want to stop caches keeping a copy of the script, preventing the Referer-check from taking place, you have to serve with nocache or Vary: Referer headers, which would harm performance.
On the other hand, with client-side checks in the script you return, you can't be sure your environment you're running in hasn't been sabotaged. For example if your inclusion script tag was like:
<script src="http://include.example.com/includescript?myid=123"></script>
and your server-side script looked up 123 as being the ID for a customer using the domain customersite.foo, it might respond with the script:
if (location.host.slice(-16)==='customersite.foo') {
// main body of script
} else {
alert('Sorry, this site is not licensed to include content from example.com');
}
Which seems simple enough, except that the including site might have replaced String.prototype.slice with a function that always returned customersite.foo. Or various other functions used in the body of the script might be suspect.
Including a <script> from another security context cuts both ways: the including-site has to trust the source-site not to do anything bad in their security context like steal end-user passwords or replace the page with a big goatse; but equally, the source-site's code is only a guest in the including-site's potentially-maliciously-customised security context. So a measure of trust must exist between the two parties wherever one site includes script from another; the domain-checking will never be a 100% foolproof security mechanism.
I'd like to include a stylesheet as well if possible to style the element but I'm not sure if I can load this along with the javascript.
You can certainly add stylesheet elements to the document's head element, but you would need some strong namespacing to ensure it didn't interfere with other page styles. You might prefer to use inline styles for simplicity and to avoid specificity-interference from the page's main style sheet.
It depends really whether you want your generated content to be part of the host page (in which case you might prefer to let the including site deal with what styles they wanted for it themselves), or whether you want it to stand alone, unaffected by context (in which case you would probably be better off putting your content in an <iframe> with its own styles).
I'm thinking of using jquery so the include file would first call in jquery
I would try to avoid pulling jQuery into the host page. Even with noconflict there are ways it can conflict with other scripts that are not expecting it to be present, especially complex scripts like other frameworks. Running two frameworks on the same page is a recipe for weird errors.
(If you took the <iframe> route, on the other hand, you get your own scripting context to play with, so it wouldn't be a problem there.)
You can store the users domain, and a key within your local database. That, or the key can be an encrypted version of the domain to keep you from having to do a database lookup. Either one of these can determine whether you should respond to the request or not.
If the request is valid, you can send your data back out to the user. This data can indeed load in jQuery and and additional CSS reference.
Related:
How to load up CSS files using Javascript?
check if jquery has been loaded, then load it if false
I have an environment that doesn't allow server side scripting really (it is extremely difficult to get a script "installed" on the server). I tried using an iframe to violate javascript's same origin poilcy; however, that didn't work. Are there any other workarounds I am not aware of?
Thanks!
As David Dorward mentioned, JSON-P is the simplest and fastest; however, there is another trick, specifically using two iframes.
Two get around this issue without using JSONP, you can do the following. This technique assumes that you have some sort of development access to the parent page.
There are three pages on two domains/sites.
Parent page
Content page
Cross-domain communication page (aka "xdcomm")
Pages the parent and xdcomm pages are hosted on the same domain, the content page is hosted on any other domain. The content page is embedded as an iframe in the parent page and the xdcomm page is embedded as a hidden iframe in the content page.
The xdcomm page contains a very simple script that detects GET parameters in the query string, parses that string for method and args variables (where args is a JSON encoded string), and then executes the specified method with the specified arguments in the parent page. An example can be seen here (view source).
Even though JavaScript's Same Origin Policy restricts code on one domain from accessing that of another, it doesn't matter if domains are nested within each other (domain A, nested within domain B, nested within domain A).
So, in a nutshell, the content page sends messages to the parent page via the xdcomm page by changing the source of the iframe to something like http://domaina.com/xdcomm.html?src=foo&args=[1,2,3,4]. This would be equivalent to executing foo(1,2,3,4) in the parent page.
Also, know that there are already libraries that help you with this, such as easyxdm. What I've explained here is the basis of one of the techniques that they use, and while it might not be as fancy, it is certainly a fully functioning and lightweight implementation.
Hopefully not, as it would be a security hole! :)
But if both your sites are subdomains on the same domain, maybe document.domain can help.
Why do some websites (like facebook) load scripts in an iframe?
Is this to allow the site to load more than 2 resources at a time because the iframe's resources are at different URLs?
What you are seing, might be an application of "Comet" communication, using a hidden iframe as data channel. A short explanation of the technique according to Wikipedia:
A basic technique for dynamic web application is to use a hidden IFrame HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible IFrame is sent as a chunked block, which implicitly declares it as infinitely long (sometimes called “forever frame”). As events occur, the iframe is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received.
This could be used for something like a chat, where messages are expected to appear without noticeable delay, and preferably without periodical "polling" for new data. If this is what you have come across, you should see several <script> elements in the frame, and more should be added as times go by.
EDIT
So to actually address your question... I don't know! The following information might be helpful, however:
Facebook prepends all of the JS variables and functions with your application ID.
var ID;
becomes
var 1262682068026-ID;
This limits the scope of your javascript to only your application so you can't use the DOM to get at their friends, phone number, email, address, etc, unless authorized. It makes a little sub-sandbox for you to play in.
More info on scoping here:
Facebook Docs
javascript loaded in iframe have no access to parent page objects (cross-domain restriction)
They load comet (aka comet, HTTP Push, long-lived, etc) connections in an iFrame because Internet Explorer eventually drops it:
http://cometdaily.com/2007/10/25/http-streaming-and-internet-explorer/
As it is effectively a continuous long poll, this is a blocker, this hack also increases IE's 2 connection limit leading to better responsiveness, background info:
http://alex.dojotoolkit.org/2006/02/what-else-is-burried-down-in-the-depths-of-googles-amazing-javascript/