We Keep Coding

Ways to protect site from external minified JS code

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.

Using AngularJS in an embedded system without an internet connection

Good morning,
I am looking to implement a single page web application on an embedded system. The catch is that it may not have an internet connection so I can't depend on external sources for features.
I would like to use AngularJS, but the system will not have the Node Package Manager installed. Is it possible to deploy an Angular application through a standard web server?
Thanks in advance.

It is very much possible to run angular without npm on a standard web server. The key here is that AngularJs is a javascript library and doesn't rely on binaries. All you need to do is be able to connect to it from a browser.
If your html contains a link to the address of the file such as:
<script language="javascript" type="text/javascript" src="js/angular.min.js"></script>
As long as the browser has access to http://YourserverAddress/js/angular.min.js it should load angular in the same way as using npm or a CDN

I have a idea.
If the embedded system have a browser, I think it's possible.
The thing you just should to do is let your javascript source run in the browser.
So, customize the browser, let it run your source directly.

Calling externally-located csv data in javascript

I'm trying to get externally-situated csv data to load up in a script, but this fails I think due to browser same origin policy. I've spotted some relevant looking discussion on working around this using cross-document messaging, but to be honest I don't have a clue how to implement this. Grateful for advice on this or another workaround. The script below should print each data line to the browser console but fails.
<html>
<head>
<meta charset='utf-8'>
<script type="text/javascript" src="scripts/d3.v2.js"></script>
<title>CSV reader</title>
</head>
<body>
<script type="text/javascript">
d3.csv("http://www.quake.utah.edu/EQCENTER/LISTINGS/OTHER/Yell_Q32012TT.csv",
function(parseCoords) {
parseCoords.forEach(function(d) {
console.log(d);
});
});
</script>
</body>
</html>

If you are doing something like writing HTML and Javascript in a code editor on your personal computer, and testing the output in your browser, you will probably get error messages about Cross Origin Requests. Your browser will render HTML and run Javascript, jQuery, angularJs in your browser without needing a server set up. But many web browsers are programed to watch for cross site attacks, and will block requests. You don't want just anyone being able to read your hard drive from your web browser. You can create a fully functioning web page using Notepad++ that will run Javascript, and frameworks like jQuery and angularJs; and test everything just by using the Notepad++ menu item, RUN, LAUNCH IN FIREFOX. That's a nice, easy way to start creating a web page, but when you start creating anything more than layout, css and simple page navigation, you need a local server set up on your machine.

I have seen similar problems linking to a file in the drop box public folders area. (specifically https://dl.dropbox.com/u/101577503/D3-Tips-and-Tricks-Latest.pdf). The first time you click on the link from a web page, the downloading of the pdf fails, then refresh and it works. I don't know why it occurs, but I get the same result when I test your 'http://dl.dropbox.com/u/46043231/data/xy.csv' in Chrome. Is it also possible that even if it works first time that you will be stymied by cross domain limitations?

Question abandoned because it seems unanswerable. Will update if I find a solution at a later date.

Silverlight 5 Out of Browser http streaming of JavaScript blocks using webbrowser

Some background: I have inherited a working Silverlight application which behaves as follows:
there is an iframe on the host html page which itself connects to another page.
this page is a long-lived request which returns a series of <script>parent.callFunction(data)</script> blocks
these scripts are executed, call up to their parent, which in turn calls the silverlight app itself using the html bridge.
In this way we have a working streaming data service via the browser into the app, but I can't make this work out-of-browser.
By using a WebBrowser control and window.external.notify I'm able to recreate most of the functionality described, but the script blocks in the long lived request are not acknowledged or executed by the WebBrowser control.
Is there any way I can force the WebBrowser control to execute these script blocks?
Or, is there another way of achieving the goal? I've been chasing this problem on and off with fiddler for over a week before understanding what the problem was, and now can't find any information. Microsoft's idea seems to be to create my own version of IE using WinForms - but this seems like a poor substitute.

Although I haven't tried your exact scenario, my guess is that you are hitting a cross domain policy violation when running OOB.
If you haven't yet, try the OOB elevated trust application route and see if that can solve it.

JavaScript and CouchDB - How do I avoid cross-origin policy errors on GET/POST/PUT/DELETE requests

I am posting this question on Super User as well. In my opinion this question overlaps the two...
I am creating a simple JavaScript wrapper for CouchDB's REST-ful interface, but I am stuck on same-origin policy issues.
So far I've been developing my code to work locally - and only as a proof of concept - on Mozilla FireFox. My server is running on localhost, port 5984.
To disable cross-origin policy in Mozilla FireFox you can use the PrivilegeManager, but it only gets me half-way in the sense that I can't do PUT requests against my server...
/*
* Including this in my JavaScript file only seems to disable cross-origin
* policy checks for POST and GET requests in Mozilla FireFox.
* PUT requests fail.
*/
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead UniversalBrowserWrite"
);
Is there any way that I can configure my server to hide it's location so I won't have to implement browser-specific work-arounds to avoid same-origin policy issues? If not: what browser work-arounds exist to disable same-origin policy completely?

Unfortunately, any browser workarounds to disable same-origin policies are likely to be treated as serious security bugs and fixed as soon as possible.
See if you can come up with a way to work within the same-origin policy without trying to bypass it.
Can you serve your example scripts on the target server? Could you build a reflection script that would load the target script on your server after a local script on the users computer uploaded whatever they modified?
There should be a good solution that doesn't involve bypassing the same-origin policy. Trying to hack your way around it is a good way to ensure that your code doesn't work properly in future browsers.

I strugled with that issue too, trying to run automated tests on a local html file connecting to a virtualized CouchDB server, here's my solution:
I created a small implementation (and open sourced it) of the simplest solution when you can't enable CORS on the server,
you need to upload a .js and an .html file to the target server, (you can use any security mechanism to restrict access to this file if you want). Or you can change some simple parameters on the html file to restrict by domain.
On your page you use the same script to create an invisible iframe where the hosted .html is loaded, and proxy certain methods (sort-of RPC) thru that iframe using window.postMessage(), by default jQuery ajax methods can be proxied without extra configuration.
All this with one line of js code :)
FrameProxy at GitHub
(fell free to use it and fork it!)