How to remove Cloudflare’s javascripts slowing my site? - optimization

I have a WordPress site at http://biblicomentarios.com, and I use Cloudflare. No matter what I do, I can’t remove two javascript that comes from Cloudflare. I use GTMetrix, and I see them in the waterfall tab blocking my site. Those are email-decode.min.js and rocket-loader.min.js. Of course, I’ve already disabled email obfuscation in the Scrape Shield tab, and I have Rocket Loader disabled. I purged ALL my caches (Cloudflare cache, Autoptimize cache, SuperCache, even the Cpanel cache). But the js’s are pretty persistent, and they insist on appearing in GTMetrix waterfall, as blocking js’s and so slowing my site. Also, I can’t add expires headers to them, so I have more than a reason to want them out of my site. Is there any way to remove them as they are already disabled in the Cloudflare panel?
Please, note
- Rocket Loader is disabled; the Scrape Shields email obfuscation is disabled.
- I have not a “cdn-cgi” directory within my site or server. Typically, this directory is injected by Cloudflare, so both scripts come from Cloudflare.
- I have no “apps” installed through CloudFlare.
- The blocking scripts paths are https://ajax.cloudflare.com/cdn-cgi/scripts/2448a7bd/cloudflare-static/rocket-loader.min.js and http://biblicomentarios.com/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js.

Depending on what Cloudflare plan you're on, you can set up "Page Rules" for your site or subsections of your site.
I'd suggest adding 2 rules -
Disable Security
This should prevent email-decode.min.js from loading.
Disable Performance
This should prevent rocket-loader.min.js from loading.
I think you can have one setting per rule, and 3 page rules if you're using the Free plan.

Go to Scrape Shield
Then Disable Email Address Obfuscation
This will Disable email-decode.min.js
Go to Speed -> optimization
Then Disable Rocket Loader™
This will Disable rocket-loader.min.js
Remember to Clear Cache

Just be careful.
Disable Performance
Will turn off
Auto Minify
Rocket Loader
Mirage
Polish

Related

Reset Cloudflare's Rocket Loader

I want to reset CloudFlare's Rocket Loader, so that it acquires the latest JS from third party scripts that have been updated.
Pressing Purge Cache does not seem to affect the Rocket Loader JS.
Toggling Rocket Loader's modes does not reset the cached version used in the Automatic mode.
How do you force Rocket Loader to serve the latest versions third party scripts?
Rocket Loader just uses the scripts currently on your site. It does not maintain any kind of cache of scripts.
If you are seeing some type of issue I'd suggest opening a support ticket with CloudFlare directly so our support team can review your account settings.
p.s. I work at CloudFlare, and spoke with the developer that maintains Rocket Loader.
"I was trying to update the third party script (that I also to control) but the page continued to serve the old script, until I turned Rocket Loader off. I would like to force RL to serve the updated script"
This actually seems more like an issue with caching of that script than Rocket Loader. Are you using any other caching plugins or services on the site? Our purge cache option should work on the file (purge cache or single file purge), but you could also be seeing caching related to another service you may be running on the site.

Tools for finding Non SSL resources in web page (firebug like tool)

I'm trying to find a non-SSL resource that is being loaded on my site.
This happens occasional where one of us forgets to use the https version of a resource (like some js in a CDN).
My question is there any firebug-like tools to find these "Turds in the punch bowl"? I want my green padlock back :)
Besides Firebug, which you've mentioned, you can use the developer tools in Chrome:
Tools menu -> Developer Tools
Go through the list of loaded resources in the Network tab
Alternatively, the HttpFox extension for Firefox can also be useful. It will keep logging the traffic even when you change pages, which may be useful in some cases.
(This is very similar to Firebug.)
mitm-proxy is great for stuff like this - http://crypto.stanford.edu/ssl-mitm/
You run it on your local machine in a console window, set your browser to use it as a proxy, and you can watch /log everything that your browser requests. It's a little noisy since it shows SSL hand-shaking and file contents, but you can filter that down. When you need to debug SSL communications it's invaluable to see those details though..
mitm-proxy is based on http://grinder.sourceforge.net/g3/tcpproxy.html which has more in the way of scripting capabilities.

Apache attack on compromised server, iframe injected by string replace

My server has been compromised recently. This morning, I have discovered that the intruder is injecting an iframe into each of my HTML pages. After testing, I have found out that the way he does that is by getting Apache (?) to replace every instance of
<body>
by
<iframe link to malware></iframe></body>
For example if I browse a file residing on the server consisting of:
</body>
</body>
Then my browser sees a file consisting of:
<iframe link to malware></iframe></body>
<iframe link to malware></iframe></body>
I have immediately stopped Apache to protect my visitors, but so far I have not been able to find what the intruder has changed on the server to perform the attack. I presume he has modified an Apache config file, but I have no idea which one. In particular, I have looked for recently modified files by time-stamp, but did not find anything noteworthy.
Thanks for any help.
Tuan.
PS: I am in the process of rebuilding a new server from scratch, but in the while, I would like to keep the old one running, since this is a business site.
I don't know the details of your compromised server. While this is a fairly standard drive-by attack against Apache that you can, ideally, resolve by rolling back to a previous version of your web content and server configuration (if you have a colo, contact the technical team responsible for your backups), let's presume you're entirely on your own and need to fix the problem yourself.
Pulling from StopBadware.org's documentation on the most common drive-by scenarios and resolution cases:
Malicious scripts
Malicious scripts are often used to redirect site visitors to a
different website and/or load badware from another source. These
scripts will often be injected by an attacker into the content of your
web pages, or sometimes into other files on your server, such as
images and PDFs. Sometimes, instead of injecting the entire script
into your web pages, the attacker will only inject a pointer to a .js
or other file that the attacker saves in a directory on your web
server.
Many malicious scripts use obfuscation to make them more difficult for
anti-virus scanners to detect:
Some malicious scripts use names that look like they’re coming from
legitimate sites (note the misspelling of “analytics”):
.htaccess redirects
The Apache web server, which is used by many hosting providers, uses a
hidden server file called .htaccess to configure certain access
settings for directories on the website. Attackers will sometimes
modify an existing .htaccess file on your web server or upload new
.htaccess files to your web server containing instructions to redirect
users to other websites, often ones that lead to badware downloads or
fraudulent product sales.
Hidden iframes
An iframe is a section of a web page that loads content from another
page or site. Attackers will often inject malicious iframes into a web
page or other file on your server. Often, these iframes will be
configured so they don’t show up on the web page when someone visits
the page, but the malicious content they are loading will still load,
hidden from the visitor’s view.
How to look for it
If your site was reported as a badware site by Google, you can use
Google’s Webmaster Tools to get more information about what was
detected. This includes a sampling of pages on which the badware was
detected and, using a Labs feature, possibly even a sample of the bad
code that was found on your site. Certain information can also be
found on the Google Diagnostics page, which can be found by replacing
example.com in the following URL with your own site’s URL:
www.google.com/safebrowsing/diagnostic?site=example.com
There exist several free and paid website scanning services on the
Internet that can help you zero in on specific badware on your site.
There are also tools that you can use on your web server and/or on a
downloaded copy of the files from your website to search for specific
text. StopBadware does not list or recommend such services, but the
volunteers in our online community will be glad to point you to their
favorites.
In short, use the stock-standard tools and scanners provided by Google first. If the threat can't otherwise be identified, you'll need to backpath through the code of your CMS, Apache configuration, SQL setup, and remaining content of your website to determine where you were compromised and what the right remediation steps should be.
Best of luck handling your issue!

Connection partially Encrypted - Part not transmitted over SSL

I'm wondering how I can find out where the culprit is, as to what is NOT being transmitted over SSL on my website. It's blowing my mind, because I use relative URLs or explicitly choose HTTPS:// for all links, images, etc...
Any ideas/tools to find out what the issue is?
Thanks.
If you mean that some resources are transferred over HTTP without encryption, you can check for this in Chrome's Developer tools in the tab Resources - that should tell you which parts come from where - look for those with address starting with http:// .
Alternately, use Fiddler: by default, it won't decrypt HTTPS connections, so you'll be seeing CONNECT requests for HTTPS, and GET/POST for HTTP - those are your culprits.
For those, like myself, who run into this issue i suggest a few tips while designing your website.
Always use relative paths when ever possible "images/someimage.png" instead of using domain paths like http://someDomainName/images/someimage.png so on. Any one of these and it will cause the browser to throw that warning at you.
When linking to external content, Google/other Ads, javascript sources(such as jquery, so on), or any other media... make sure you use a https:// link if they have one available. Myself, i had one tiny image for a link to an external site but they did not offer a https link to the image, so i simply downloaded it and put it in my images folder. Problem solved.
The Chrome resources list is a very helpful tool, not sure if Firefox has something similar in its tool box. Another method, if you have shell/command line access, is to use grep to search the files for "http:". This, most often, will show anything that is linking to non secure content.

Shut Off All Caching on Firefox, Apache, PHP Plugin, Etc

I want to shut off all caching on my Apache running under Linux, and all caching on Firefox and... is there anyplace else I might be caching? I want my PHP and .css files to be fresh from disk all the time during development.
Disclaimer: I am asking about Apache as a dev tool, not as a deployment platform. If I ask about IIS and why it's caching .DLLs, it's considered a DEV question. This is also a dev question.
Apache doesn't cache by default.
On firefox navigate to about:config and change browser.cache.disk.enabled and browser.cache.memory.enable to false.
If you are using a PHP framework that caches pages you will want to disable that, or be prepared to need to clear it manually.
The only other thing you may want to look for is if you are using a debugging proxy that it isn't caching any content as well.
Firefox caching disabling, in about:config:
set browser.cache.disk.enable to false
set browser.cache.memory.enable to false
set browser.cache.offline.enable to false
Since you're using Firefox, might I briefly recommend the rather excellent Web Developer Toolbar by Chris Pederick? It's got a slew of options for disabling caching, JavaScript, manipulating sessions and cookies, etc.
Obviously, I'm recommending it to you for the caching options, but the rest of it is frequently extremely handy stuff. It might be more convenient than manually switching options over with about:config.