Prevent unsecure HTTP requests - javascript

I have a blog on tumblr, and I am trying out the website with SSL. Now with Chrome and possibly other browsers, any images and scripts that are not loaded using HTTPS are automatically blocked, and I lose the happy little green lock icon in the address bar. I am able to edit the HTML of the theme, however there are too many external scripts that are used to load images (and other scripts) to be able to weed out and fix every HTTP request. Obviously, I don't have access to the web server settings for tumblr.com or I could have easily configured HTTPS redirects or something.
I was wondering if there would be any way to prevent the HTML and other included scripts from making HTTP requests through the use of javascript. The website appears and functions just fine without the blocked elements, and I just want the lock icon to show my visitors that it's a safe website.
I have no intention of advertising my blog here, as I'm sure it is against the user policy on this forum. That being said, if it is helpful for troubleshooting reasons, I can post the link if requested.

Related

Improve the usability of 3rd party application

A 3rd party application we use is causing a great deal of issue because the user isn't clicking a Register button prior to clicking the Launch button or if they do click Register first, this Details page with both Register and Launch buttons refreshes and goes to their portfolio. They have to then re-find that item in their protfolio list.
The 3rd party application I believe is a .NET and is using knockout.js and does not allow embedding in Frames.
What are some options for providing guidance to the user or ideally make this process less painful?
I was hoping to provide an internal webpage that could send both Request and Launch actions with a single button click. I posted an earlier question Knockout data-bind click but couldn't get something to work.
There seems to be a bunch of similar questions on SO but I am not sure if these questions/answers are for automating button clicks on self contained applications as I want to do it if from outside the 3rd party application (do I even have access to their view model?). This app prevents embedding it in Frames.
Auto-click button element on page load using jQuery
How to auto click button in knockout js
Currently I have a link from internal website that opens two browser windows side by side. One goes to 3rd party and 2nd window with instructions. This is OK but we found people don't want to read. I really want to have a single button click or at least be able to send one request at a time from the internal webpage. Or perhaps overlay a joyride type guidance onto their site, if possible.
Here is the 3rd party button code
<a class="btn btn-large btn-blue" href="javascript:void(0);"
data-bind="click: $root.clickAction.bind($data, ActionType)">
<span data-bind="text: Title">Register</span></a>
You basically want to hack the 3rd party app, but you control the environment, so it doesn't sound impossible. (I won't talk about whether I think it's a good idea, I will just list a few options you may have.)
Removing the X-Frame-Options header
You are saying the 3rd party app does not allow to be embedded in a frame. That is done by a response header, most probably X-Frame-Options (or it can be Content-Security-Policy: frame-ancestors, but it doesn't actually matter). All you have to do is remove that header and voila, the app can be loaded in a frame.
To remove the header, you will need some kind of a proxy. If the app is served on plain http, it is really easy, any kind of http proxy can remove the appropriate response header. If it is served on https, you have to do a few things to actually make it work (create a certificate authority, add the root cert to clients as trusted root, use the proxy to connect to the app and besides removing the header, replace the https cert with your own, which will then be trusted on your clients).
Note that this will weaken the security of the 3rd party app and it will make it vulnerable to attacks similar to clickjacking (and also pixel perfect timing and so on, all frame related attacks).
Inject custom script via proxy (edit: added this later)
With a proxy as described above, you don't need to remove X-Frame-Options. It's much better to inject your own javascript into the 3rd party application page, which can do whatever you want on the original page as it has full access to the application DOM. For instance it can change behaviour so that the appropriate buttons are clicked. :) I would do this if I wasn't able to install a browser extension on clients (see below).
Using a custom client
Instead of using the browser as the client, you could make a custom client that in practice acts as a browser, but disregards the above headers. This could also do the clicks you want without much hassle. The drawback is your users would have to start the custom client instead of using their browser to use the application. This is probably easier to do in a mobile environment where you have things like Xamarin and WKWebView.
Browser extension
An easier and probably more feasible variation on the custom browser idea is a browser extension. It could activate on the application url, and it could very easily do the clicks you want on the appropriate pages (browser extensions can request full access to pages regardless of headers). You would only have to install the extension once on clients. I would probably do this if I had to.

Can HTTP Access Control (CORS) prevent other domains from running my scripts?

I know by default the HTML page on other domains can't access my images, videos. They can only show them. But sadly, they can still run my scripts. If my script exposes some variables to the global scope, then the internal logic may be known by others.
I have a private website that others can't visit. Only I can visit it by sending a token in the Cookie to the server. If the token isn't included in the Cookie, every request will cause a 500 server error response. This is secure because everything is on HTTPS.
But unfortunately, I find this isn't very safe on my own machine, because after I visit my site and then visit a malicious site, this malicious site can use the following method to run my script:
<script src="https://my-website.com/main.js"></script>
That's because the Cookies of my website on my machine will be sent to my server as 3rd-party Cookies.
How to prevent that? Can access-control-allow-origin do so?
P.S. I don't want to disable all 3rd-party cookies in browser settings. Cookie's SameSite also doesn't make sense because only Chrome support it now.
There are a number of imaginable ways to prevent other sites from using the script element to run copies of scripts from your site in their sites, but CORS isn’t one of them.
Browsers are where the same-origin policy (SOP) is enforced and browsers are what block JavaScript running in Web apps from being able to use responses from cross-origin requests.
But browsers don’t use SOP/CORS when a Web app uses the script element to embed some JavaScript. Specifically, browsers don’t check that the script is served from the other site with an Access-Control-Allow-Origin header, which is the foundation of the whole CORS protocol.
So CORS is definitely not a solution to the problem you seem to want to solve.
But unfortunately, I find this isn't very safe on my own machine, because after I visit my site and then visit a malicious site, this malicious site can use the following method to run my script:
<script src="https://my-website.com/main.js"></script>
But if that site embeds your script in theirs that way, it runs within their origin, not yours. It runs there as a trusted script with all the same privileges of any script they’ve written themselves.
In that scenario, the other site is the one taking a security risk—because you can at any time change your https://my-website.com/main.js script to do anything you want at their site.
That is, by embedding your script that way, the other site gives your script programmatic fully-trusted access to do anything it wants at their entire origin—gifting you an XSS opportunity.

How do site analytics tools know the URL that visitors were referred from?

I'm building a rudimentary tracking tool for one of my sites, and I'm realizing that Google Analytics and my Squarespace site are aware of the URL that referred my visitors to my site.
For example, Squarespace's analytics can detect the exact URL of the pinterest pin that 3 of my visitors came from, which blog post referred 15 visitors to me, etc. How can my server possibly know who referred them to my site?
I'm a full stack .Net/C#/Javascript engineer and have no ideas. Thanks!
There is an HTTP referrer header that is usually populated by default by your browser upon clicking links. It's possible to disable this as the browser is what chooses to include the header. You can make requests in a variety of other ways and leave that header blank, but clicking a simple link in a standard browser is pretty much always going to include the header.
(click for larger view)
basically, when you click a link on a site, that site will send location(the URL) information to the destination page, which your server logs.

Using a Chrome extension content script to embed additional content

I am working on a Chrome extension that will add content to a particular set of pages. From my research, it sounds like what I want is a content script that will execute for the appropriate pages. I can specify the "appropriate pages" using the content_script.matches manifest.json field.
However, the problem I'm running into is that content scripts run in an isolated world, separate from the rest of your extension.
How I had envisioned my extension was a set of UI pages that would be embedded on the appropriate pages by the content script. The background page would contain the code for build the content of the UI pages. The background page, and by extension, the UI pages, would need access to the various Chrome APIs (e.g., local storage), as well as being able to make cross-domain requests to retrieve their data. However, it seems this is not possible, since the content scripts run in an isolated world, and don't have access to the Chrome APIs that I need.
Message passing allows a content script to send and receive data from the background page, but doesn't allow you to take a UI page and embed it on the current webpage.
I initially thought I was making some headway on this when I was able to make a jQuery AJAX request from my content script for an UI page, but that only gets me the HTML file itself. My UI pages depend on code to programmatically build the content--it's not just a static HTML page. And that "build the page" JavaScript code depends on Chrome APIs that are not available to the content script. So, if I just tried to make all my UI pages and JavaScript resources web_accessible_resources, I could inject them into the page but they wouldn't be able to run.
Which brings me to my question: how can a content script pull down, or embed, UI pages that can invoke code in the background page?
Tldr: you need to read about sending messages between content/background. Its in the docs and many samples.
From what I've been able to find, the architecture I was hoping for (as outlined in my question) is not possible in a Chrome Extension. Chrome's security model requires a different approach. Here's what worked for me.
Make your templates, JavaScript files, and anything that's part of your UI, web_accessible_resources.
Use your content script to load these resources and display them to the user at the appropriate times/locations.
(Almost) any calls to chrome.* API need to be done through your background page or event page. In my case, the "background page" is strictly JavaScript, there's no HTML.
Your content script, and UI, can send messages to your background/event page(s).
This model is not unlike the traditional client/server architecture of a web app. The "background page" is like your server, and your content script can send "messages" (think HTTP request) to the "background page" just like it might send a request to your server.
The background page, just like the server, has access to resources that the content script does not, e.g., the background page can use more of the chrome APIs.
This mental analogy helped me to "redesign" my app in a way that (so far) is working within the Chrome Extension security model. I had originally been thinking more along the lines of a traditional desktop app, where the entire app can do things like make cross domain requests or write to the file system. Chrome Extensions and Apps don't work this way, however.

stop ie showing security warning when loading non secure images on secure page

I am using the following JQuery plugin to load an image slider http://www.orionseven.com/imageloader/index.php
However this is on a secure page (https) although the images are from external urls so therefore are not on secure pages. Is there anyway I can stop IE 7 displaying the security warning? Maybe changing my code or something?
You cannot disable those warnings.
The reason you're seing them is because the user should be notified that non-secure requests are being made (and potentially compromising the security in the process). Turning them off would be bad for the user.
You should probably be hosting the images on your local server rather than expecting a third party to host them for you. That way they can all be served as HTTPS from the same site, and problem solved.
If you must fetch them from the third party server, you'll only be able to solve this issue if that third party also provides HTTPS on their server. In that case, you'd need to modify the URL used to request the images to change the protocol depending on what protocol the main page is being served with.
If you want to load them remotely and that remote server doesn't provide HTTPS, then you cannot get rid of the message -- it's there intentionally in IE to provide a legitimate security warning. You can't override it.
I have the exact same issue. Since M$ considers every single one of their users to be brain-dead and decided to lock-down the ability to bypass that warning, I've decided on a much simpler solution- Use literally any other browser. Check out this solution-
https://stackoverflow.com/a/23047482/3692082
You could proxy images through localy hosted php script.
https://server/image.php?url=foobar.com/foo.gif
<?php
echo file_get_contents("http://".$_GET['url']);
?>
some comments about cross-site-scripting vulnerability should follow:)

Categories

Resources