可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
What's the most efficient way to find a list of all non-HTTPS URLs requested by an HTTPS page? If this kind of security violation happens, every browser alerts the user, but I can't find an easy way to find what exact URLs cause the violation.
The easiest way I've found so far is to use Firefox, but even then it's still not very convenient. First, I can right-click, select View Page Info, click the Media tab, and scroll through a list of URLs. However, this seems to only list image files, not CSS or JS includes that can also cause the error. For those, I have to use the Firebug extension, select the Net tab, and manually hover my mouse over each item to see the entire URL. Unfortunately, this can take a while if you have dozens of media files. Is there a better way?
回答1:
Note, in recent versions of Chrome, these errors will be displayed in the Javascript Console.
e.g.
The page at https://mysecuresite.com displayed insecure content from http://unsecuresite.com/some.jpg.
回答2:
Try: www.WhyNoPadlock.com It will give you a report of all insecure content on any https web page.
回答3:
You can use SslCheck
It's a free online tool that crawls a website recursively (following all internal links) and scans for unsecure content - images, scripts and CSS.
(disclaimer: I'm one of the developers)
回答4:
Recently had the same issue, using chrome developer tool it was easier to find.. In developer tool go to Security tab, you can find all non-https request
回答5:
Use Fiddler.
Secure requests won't show up at all (except as HTTPS CONNECTs, which can be hidden), so everything you'll see is bad.
回答6:
I had this problem which occurred in a javascript:
/* for Internet Explorer */
/*@cc_on @*/
/*@if (@_win32)
document.write("<script id=__ie_onload defer src=javascript:void(0)><\/script>");
(.....)
The src=javascript:void(0) should be avoided.
You can not find this problem using Fiddler or Chrome.
回答7:
You can check https://www.missingpadlock.com/
Is a online tool for crawl your site for find insecure pages.
回答8:
If you own the website, you should look into the Content-Security-Policy
header options. These can include forcing HTTPS on resources, or automatically attempting to redirect HTTP resources to HTTPS, among other things.
Notably, there is also a report-uri
directive for the closely-related Content-Security-Policy-Report-Only
header that reports any infractions of your CSP to a uri of your choosing. This means that any browser with support1 for report-uri
will send you reports of pages on your site with problematic HTTPS on an ongoing basis. Mozilla Developer Network has a PHP example of handling the reports.
1 Note that if you can reasonably expect any browser with full CSP(RO) support to hit the pages in question, it doesn't matter that some browsers do not have support for it.
回答9:
I just want to leave a note about what happened to me when this problem arose.
Suddenly my domain showed 'Mixed: Insecure Items'. I couldn't find the cause at all. The console was just showing an image was being requested: http://www.example.com/
, Which I could not find any reference to anywhere.
I searched and searched and eventually found that in the Security Tab of Chrome, Where it was displaying 'Insecure Content' it said 'Show in Network Tab'. When I clicked that, It was showing me the bad URL, again, with no information apart from the Initiatior column. It was showing the image footer_bg.jpg
.
Had someone injected code into my footer background image I wondered? Turns out no, I had inadvertently moved that image yesterday and forgot about it. So the page was requesting an image that wasn't there, returning an error. I fixed the link to the image and page loads securely again.
Just for anyone else that will possibly have this problem in the future.
回答10:
Use Burp Suite, set up the scope as your website, browse to the secure page and check which request are made to HTTP version of your website.
回答11:
If you want a one-shot, reasonably-comprehensive, recursive scan of an entire website, you can use Bramus's mixed-content-scan
from the CLI. It won't check links in supplemental JS/CSS, but it's great for finding that one post that the intern from 3 years ago put up with a dangerous non-SSL script.
For an ongoing solution, see my other answer.