I'm trying to make a bookmarklet to use on youtube and other video sites in order to easily get information from the video and store it elsewhere.
From today, apparently I can't do that anymore since youtube force itself on a https connection and from what I've read on chrome's console window, the bookmarklet doesn't run on a https page. Is there a workaround?
Here is the edited code:
javascript:(function(){var jsCode=document.createElement('script');jsCode.setAttribute('src','http://[mysite]/b/enter.php?i=userid&r='+Math.random());document.body.appendChild(jsCode);}());
Google Chrome (and possibly other browsers?) blocks HTTP resources from being accessed from an HTTPS document. This is to prevent "mixed content" attacks, in which insecure HTTP scripts could be intercepted by an attacker in transit over the network and altered to perform any kind of malicious activity (e.g., leak cookies or sensitive page information to a third party). Such a violation would undo any protection granted by HTTPS.
Chrome used to provide a prominent warning that an insecure resource was blocked, but now it no longer does so, and all insecure loads silently fail. The only solution available to you at this time is to use HTTPS yourself when you serve the script.
In Firefox, if you want to run a bookmarklet that references http on an https page, the way to get around this is to temporarily disable security.mixed_content.block_active_content. There are two ways to do this.
go to about:config in a new tab, search for security.mixed_content.block_active_content and then toggle the value to false. Run your bookmarklet and then toggle it back to true (since you probably want it turned on most of the time).
use an add-on / extension to toggle the block. A quick search turned up Toggle Mixed Active Content, and a quick test seemed to work well. There may be others.
Have fun and be careful. Here be dragons!
the bookmarklet doesn't run on a https page
Why not?
Try changing to a HTTPS domain yourself. Usually HTTP content is blocked when you're on a HTTPS domain.
I have created a work-around "fix" for this issue using a Greasemonkey userscript. You can now have bookmarklets on all CSP and https:// sites, plus have your bookmarklets in a nice, easily-editable library file instead of being individually squished into a bookmark.
Related
I am calling a rest API from Https deployed Application
to Http Rest API.
I have written the logic in JavaScript by using Angular Js framework.
The web service call got failed with the below message.
The page at 'https://********someurl****' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint
Requesting if any one can help me get out of this error.
Workaround:
1- Click the shield icon in the far right of the address bar.
Allow mixed content in Google Chrome
2- In the pop-up window, click "Load anyway" or "Load unsafe script".
If you want to set your Chrome browser to ALWAYS(in all webpages) allow mixed content:
1- Close Chrome. Chrome must be fully closed before the next steps.
2- Right-click the Google Chrome desktop icon (or Start Menu link). Select Properties.
3- At the end of the existing information in the Target field, add: " --allow-running-insecure-content" (There is a space before the first dash.)
4- Click OK.
5- Open Chrome and try to launch the content that was blocked earlier. It should work now.
This is just workaround and you need to solve by securing both app and rest api.
Use an https endpoint for your Rest API, otherwise you will end up with mixed content
HTTPS is important to protect both your site and your users from attack.
Mixed content degrades the security and user experience of your HTTPS site.
If you are unable to switch to https, another solution is to set up a server side end point which you access via https, which then makes the call to the http url and returns the result. In other words, making your own little HTTPS proxy to the http resource
In my case chrome was causing the issue, don't know why, other browsers work fine.
**Tip: I wasted two days trying to find out the cause, hope this will help someone.
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.
I am getting below error in IE8
"Do you want to view the webpage content that was delivered securely"
To disable this error we need to set this option
"Internet options -> Security -> Internet -> Custom -> Miscellaneous -> Display Mixed contents"
to enable
I am looking for a solution that can be done in code (probably javascript). Please tell me guys if have face any of such problem. The reason I am looking for a programmatic solution is because I cannot expect every user to enable this option.
You need to change your website to not embed any http:// resources on a https:// website. There is no other solution (except maybe not using HTTPS at all).
Actually, it would be very bad if scripts on a website could disable this warning. Mixed content can easily compromise the whole security provided by HTTPs e.g. when a script is loaded via http - it could be easily replaced e.g. through a MITM attack or DNS manipulation and then do anything with the website itself that was loaded securely.
You can't disable this security policy using javascript.
As #ThiefMaster said, this error is produced because you have a combination of things being fetched by both http:// and https://.
If all resources that you are currently serving via http:// can successfully be served via https:// instead, then you should change them all to do so.
Once they are all consistent, the error should go away.
A better way of referencing your URLs might be to use "protocol relative URLs" instead. This means that instead of "http://myserver.com/dir/resource.js" you use "//myserver.com/dir/resource.js" (i.e. remove the "http:" or "https:"). If you change all your URLs to that format (which is perfectly valid), then if the page itself is served over HTTP, then all resources (javascript, CSS, images, etc) will be served via HTTP as well. Likewise, if the page is served via HTTPS, then all resources will be served likewise. Again, make sure you can serve all resources this way first.
First, should this be on anther StackExchange site?
I'm trying to scrape a site and it appears to set a cookie in Javascript: when looking at the HTTP requests all of a sudden the cookie appears as a request cookie without a preceding response command to set it. Is there any way in any major browser (ideally on OS X but I can boot into Windows or Linux) to watch a site's cookies and pause loading or execution of a page when there's a change and highlight the Javascript code or HTTP response that is responsible?
Cookies are not asked for, they are given, therefore you wont see it being requested.
They will come down in the headers and there is no way to determine, what, who or where they came from (apart from knowing they came from the site you are browsing or possibly sites it is linked to).
Open up Webkit Inspector and look at the network/resources tabs. Filter by "documents". Go through each documents' response headers and see if there is a cookie set. If not, then it must be JavaScript in which case you can do a search for "document.cookie".
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:)