Ways to protect site from external minified JS code - javascript

I understand the best way would be not to have the external JS at all, but alas, it's not possible.
Situation
The owner of a site wants (no ifs/ands/orButs) to get paid by a company that offers gambling ads. This company states that in order for them to offer said ads the owner of the site must add a JS code to the site. Said JS code is a few lines, but essentially it creates a tag <script> and loads a minified external JS file located in the publicity company's server. They do different kinds of ads (pop-ups, etc) and some other things that require the code.
There's no discussing not going through with this, I wanted to know if there were any kind of layers of security I might be able to add in order to protect site viewers. I know they are still in danger, but there's not much else I can do.
Things to do
Copy the external JS file and serve it from site owner's server (or is that a horrible idea? The thing is, at least this way they can't be changing it to their heart's content, since it's in the site owner's server).
Not loading the JS file in any page that has Login forms.
Only load the JS file where the publicity will be shown.
Not load the JS file is user if signed in
Modify JS file so that it has its own scope (function(){})() .
Anything else I could possibly do? Or am I simply fooling myself in thinking I can offer some feeble protection?

There are a few ways that may allow you to secure your page with external scripts.
First create a content security policy. This basically tells the browser where it can load different types of content from so if the third party starts loading content from new sources without telling you first they will be blocked.
Secondly the script-src tag. This allows you to specify a hash of the script tag and if it changes the browser won't run it.
There is a much better write up on these and more on Troy Hunt blog specifically this page https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/

Things to do:
Use a CDN that supports versions (almost every modern CDNs supports that) so you don't need to host these JS files yourself, and you don't need to worry about the fact that the file might change.
Only run your JS on login pages
For ads, use iframe elements, so the JS code for ads can't access external information
Use Subresource Integrity (SRI) on script tags
Example with jQuery
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
As Karl Graham mentioned, use Content Security Policy (CSP) in an HTTP Header, so content can't leak.
Make sure to use SSL Certificates (HTTPS), and to encrypt content when you do AJAX/Fetch requests so even if an external script listens to FetchEvents, it won't be able to read the data.
I'm almost certain that if you follow these rules, your external script won't be able to get your form content.

Related

Is is possible to style in external domain iframe in 2020?

client push me to change the CSS styles of an external site which is included in an iframe. Is it possible to do that? I found topics from 2011 with a solution, but after I tried to do that with CSS, js, jquery - I think is not possible if the site is not hosted by the same domain.
It's still not possible for security reasons. In order to allow this, you'd need control of both sites, and even then, you'd be potentially opening yourself up to allowing XSS attacks on the target site. Your best bet would see if the target site has an API that you could pull data from and display on your site with whatever styling you want. That's a separate topic altogether though.

Does including all these 3rd party javascript files impose a security risk?

When you have all these various javascript files included on a page for various services like website analytics, click tracking etc., doesn't this create a huge security risk because using javascript they can hijack the persons credit card that is entered on the form?
How is this even considered to be safe currently?
Meaning, your server is security, your payment provider is secure, you have SSL, but if someone was to hack into any of these services people use (I see over 10+ services many sites use to track clicks, ad related, etc) then they can comprise your payment form.
Yes this is a security risk, known as a third party script include.
By including a script on your page hosted by a 3rd party, you are trusting that the external domain is not malicious nor compromised. By using a <script src="//example.com"> tag, the third party domain has full control of the DOM on your site. They can inject whatever JavaScript they wish.
You are right to be concerned. PageFair was recently compromised bringing down every site that it offered its analytics service to with it. You should verify all third party domains that you are referencing for script, and ensure you trust them. For example you are probably OK with the big guys such as Google and Facebook, however any others you should consider either dropping them or reviewing the script code and then hosting locally on your domain instead.
You can mitigate this with subresource integrity:
<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
This will ask the browser to check that the loaded script has the specified cryptographic hash. Any changes to the script, even as much as a single character, would produce a completely different hash enabling any changes to be detected and the script would be rejected from loading and running. As of August 2018, all major browsers support it except for IE and iOS Safari.
EDIT: As has been pointed out to me in the comments, you cannot solve all of your JavaScript security problems by downloading all of the resources over HTTPS, as I asserted in a previous version of this answer. Instead, that simply reduces the problem to how much your end user can safely trust the provider of the JavaScript itself - and if the service gets compromised or is an actively malicious organization, they can't.
There are two primary ways that hosts can solve this problem and make their JavaScript downloads more reliable for their users:
Where it doesn't make sense, don't include the JavaScript component at all. One thing you will notice on Amazon.com, for instance, is that while the normal shopping pages have header bars and are full of extra information and advertising and all that, the actual checkout page, where you enter your payment information, is almost blank - most of the styling and scripting is not included, and there are certainly no ads on the page.
If you need the component, but can host the script yourself, do so. That way, unless you yourself are compromised, you can be confident that any script being downloaded by the user is not, because you are providing it. For offline scripts that don't actively communicate with other services, this is often needed anyway for compatibility reasons, and many online scripts can also be included here without too much loss in functionality.

Is there any alternative to iframe, object or embed?

I want to include an external (external domain) html page into my page. For SEO reasons iframe, object or embed are not useful, there are just a link in my source file. PHP's include function is very helpful but it causes many problems for UI. I want contents of include function and view of iframe.
How can I do that?
Thanks.
There's no reasonable alternative to <iframe>.
Who knows if you could extract the markup from the site from the server-side and print that HTML inside a <div> in your own site, but I doubt that this could ever work, because if the whole target site does AJAX requests, WebSockets or whatever, it should be secure enough to block you from performing them from other domains than allowed ones by themselves (i.e. their official domains).
If you are adding content from an external source the it should really have 0 impact on your SEO. Needs to be your own content as far as I am aware. You could try scraping the external source and using Ajax add it to your page using $().load() or similar... Wouldn't recommend though!

Link stylesheets and scripts to our website

Is there any difference between linking a stylesheet or script to our website from EXTERNAL servers and uploading the stylesheet to our server and link to it? What are the benefits of uploading to our server?
Usually the external ones are served by a CDN server, that's means that your users probably have them cached ( for example jquery or other popular library )
If you store something on your server it will mean your server will have to process more data, that is send your scripts or CSS together with every request. That will add some extra work for your server which may mean extra costs or slower responses.
The advantage of using links to external servers is less load on your server and also most of the popular frameworks like jQuery for example, they have your file available all over the world, so if user opens your website based in europe for example and he is based in USA he will not have to wait for file to be delivered across the world, but instead will most likely get that file from a location closer to him. Less traffic, less load on server and faster response times.
Yes, There is lots of difference:
If you will include stylesheet or script from external source then it will take time to load the page.
If you will include stylesheet or script from external source then it may causes not to load all due to firewall(I have faced this situation).
In future if there will change in the files then it will also reflect your site.
The security issue, anyone can add the code to track your data.
So always recommend to download and add these file from your on server instead of including stylesheet or script from external source.

How to offer a webapp to other sites. (div with javascript, iframe or..?)

I am quite new to web application development and I need to know how would I make other sites use it.
My webapp basically gets a username and returns some data from my DB. This should be visible from other websites.
My options are:
iframe. The websites owners embed an iframe and they pass the userid in the querystring. I render a webpage with the data and is shown inside the iframe.
pros: easy to do, working already.
cons: the websites wont know the data returned, and they may like to know it.
javascript & div. They paste a div and some javascript code in their websites and the div content is updated with the data retrieved by the small javascript.
pros: the webside would be able to get the data.
cons: I could mess up with their website and I don't know wow would I run the javascript code appart from being triggered by a document ready, but I wouldn't like to add jquery libraries to their sites.
There must be better ways to integrate web applications than what I'm thinking. Could someone give me some advice?
Thanks
Iframes cannot communicate with pages that are on a different domain. If you want to inject content into someone else's page and still be able to interact with that page you need to include (or append) a JavaScript tag (that points to your code) to the hosting page, then use JavaScript to write your content into the hosting page.
Context Framework contains embedded mode support, where page components can be injected to other pages via Javascript. It does depend on jQuery but it can always be used in noConflict-mode. At current release the embedded pages must be on same domain so that same-origin-policy is not violated.
In the next release, embedded mode can be extended to use JSONP which enables embedding pages everywhere.
If what you really want is to expose the data, but not the visual content, then I'd consider exposing your data via JSONP. There are caveats to this approach, but it could work for you. There was an answer here a couple of days ago about using a Web Service, but this won't work directly from the client because of the browser's Same Origin policy. It's a shame that the poster of that answer deleted it rather than leave it here as he inadvertently highlighted some of the misconceptions about how browsers access remote content.

Categories