Microsoft Advertising Now Generating and Automatically Running Incoherent Ads for Customers

The quality of Microsoft’s search advertising system has gone down over time, as has Google’s, as they have taken more and more control away from advertisers. At best, they greatly overestimate the ability of their system to produce good results. At worst, they are intentionally doing things to increase their revenue, knowing that they are increasing costs for their customers while producing worse results for them.

About a month ago Microsoft announced they would start automatically running ads for customers generated by Microsoft, without the approval of customers. That seems rather ill-conceived idea, as they are putting words into the mouths of their customers. But much worse, looking at ads that have been generated for us, the implementation is even more ill-conceived, as the ads are often not even coherent.

When customers go to the Microsoft Ads web interface, they might now notice a somewhat vague message about this:

We’ve created recommended ad(s) which could improve your performance. Please review these recommendations as they may be eligible to automatically apply at a later date.

From there you can see up to 50 ad suggestions. While a few of the ones currently suggested to us are decent, most are not close to that. Here is one where the ad text looks like it mixed up the words install and upgrade:

Let Us Help You Install Your PrestaShop Installation to the Latest Version.As written, it doesn’t make sense.

In another example of this, this text seems like it should refer to second best instead of second chance:

Don't Settle for Second Chance. Call Us Today to Learn More!Somehow they are messing up phrases like that.

This ad text combines an incoherent message with this odd capitalization of a word with an apostrophe in it:

If You Can't Find a Better Price, We’Ll Give You the Best Price.It would appear their system isn’t advanced enough to understand not to add capitalization there.

Sometimes the headlines and ad text don’t go together, this headline makes no sense in the context of the service being advertised or the ad text:

Don't Trust Your Mediawiki | Until You Read Our Reviews - If You’Re Looking to Upgrade Your Mediawiki Installation, We Do the Rest.The ad text of this one claims we provide an alternative to something that isn’t a thing as far as we are aware:

Our Moodle Upgrade Service Is the Most Affordable Alternative to Existing Plugins.Others advertise services we don’t offer, like this one offering to install PrestaShop:

Let Us Take the Guesswork Out of Installing Your Prestashop. Call Today!Here is the ad text for another one, which, among other issues, emphatically claims we do something, which we don’t do:

If You Can't Find a Better Price on Concrete5 Installation, We Do It!Probably the worst ad though suggests we get websites hacked:
Don't Go Scammed | We Get Them HackedIt doesn’t look like Microsoft did basic testing before rolling out these generated ads.

Despite them creating this content, they have a notice in the documenation for that says that it is the customer’s content:

Any ads or content created by Microsoft Advertising as part of this program are subject to editorial review, and will remain your “Content” as defined by your Microsoft Advertising Agreement.

The Likely Reason Malware Keeps Returning to Your WordPress Website

One question that comes up from time to time when dealing with malware infected WordPress websites is why does malware keep returning to the website. While there are multiple reasons that can occur, what we find most often with websites that keep getting infected, WordPress or otherwise, is that they haven’t actually been infected more than once. Instead, the original issue was never fully resolved.

While some malware can be difficult to fully remove, in most cases what we find is that corners were cut during the cleanup process. That isn’t just an issue with hiring someone who doesn’t have much experience with malware infected websites, as we have often been brought in to re-remove malware form websites when that is the case with supposedly reputable providers. That includes companies who are frequently promoted by journalists, despite what they are covering being itself a pretty big warning that something is a miss with the company.

To properly clean up malware on a website, there are three key components:

  • Removing the malware.
  • Getting the website secured as possible (which usually involves getting any software on the website up to date).
  • Trying to determine how the website was infected and fix that.

If a company’s marketing material doesn’t focus on those, then there is a good chance they are cutting corners. You might get lucky and not experience the downside of that, but if you are like lots of people hire us after having hired someone else, you end paying more and dealing with more problems than if just hired us to remove it in the first place.

It Is Hard to Believe How Poor SiteGround’s Support Documentation Is

From our experience people trust their web host to provide good advice on dealing with problems with their websites, but also from our experience, unfortunately, the advice is often useless and sometimes even harmful. Since most of that is coming from one-off exchanges with support personnel, it is hard to attribute that to a general issue with the web host. But with a recent instance involving SiteGround, the public advice they provide in their support documentation is so bad it is hard to understand how it exists in that form.

With a website we have been brought in to do some work, a problem needing to be dealt with was at least part caused by an ill-conceived action taken by the SiteGround, but in trying to resolve that our customer had tried to resolve another issue, a mixed content error. Mixed content refers to having content on a page being served over HTTP when the page itself is served over HTTPS. SiteGround provides instructions on dealing with that, on a page titled What Is Mixed Website Content Error and How to Fix It?. Under the heading “How to fix the mixed content error” they write this:

The fastest way to solve this issue is by using the functionality ‘Force HTTPS’ in the SG Optimizer plugin. It will redirect all the traffic for your website to HTTPS which should help avoid mixed content, except in some cases of remote resources still being pulled over HTTP.

Then the first step to do that is:

  1. Install the plugin by logging into the WordPress Admin > Plugins > Add New.

You can only log in to the WordPress Admin if your website is using the WordPress software, so these instructions are only relevant for WordPress websites, but that isn’t clearly noted. The first mention of WordPress is in step 1. After getting through all the instructions, they write this:

If you are not using WordPress or even after using SG Optimizer there is still mixed content on the website pages, then you can use this online tool to find which content is being served via HTTP. You would have to attempt to correct all of them to load over HTTPS manually, based on the specific elements.

Wouldn’t you want to note that the instructions are not relevant to websites not using WordPress before providing them, and not after?

It isn’t like that is something that you can only come across from their website with notice that it applies to WordPress. At the bottom of that page a related article, How to enable padlock on my site?, is listed. The totality of the information provided on that is, with a link to this page at the end:

  • Your SSL certificate is installed and valid.
  • The website is working over HTTPS.
  • There are no elements loaded over an HTTP connection (mixed content).

 

SiteGround Doesn’t Even Warn Their SuperCacher Caching System Can Break Website Functionality

Less than a month ago we wrote a post that mentioned a recent situation where a Zen Cart based ecommerce website was not allowing products to be added to the shopping cart in some instances, which is a big problem. The source of the problem was caching done by a web host we didn’t mention in the post. The same exact issue has come up with another website and this time we had access to the web host’s control panel, so we could better see what is going on with the web host, SiteGround, and things don’t look good.

When you go the settings page for their SuperCacher caching system, you are provided with this information about it:

SuperCacher services are developed by our server optimization experts to increase the number of hits a site can handle seamlessly and dramatically boost your website’s loading speed. There are 3 different caching options for maximum optimization of your websites. Our tests show that a website using simultaneously NGINX Direct Delivery & Dynamic caching along with Memcached can handle 100 times more hits than a regular website without any caching.

There is no warning that the feature can cause problems, like the one we have now run across twice in less than a month. Perhaps they don’t understand the implications of what they are doing, which is quite problematic considering the caching causing the problem with those websites is enabled by default.

Disabling Dynamic Caching

If that were not bad enough, while two of three types of caching provided, NGINX Direct Delivery and Memcached, can easily be disabled on the feature’s settings page, the one that is at issue here, Dynamic Caching, can’t. The tutorial for the feature, which is linked from that page, also doesn’t currently provide any information on disabling that. If you use the search function accessible on that tutorial, you also won’t find the information. There is a page on a separate part of their website, for some reason they have two different support sections, explains how to disable that using code added to the website’s .htaccess file.

Update – 4/16/2021 – SiteGround doesn’t provide a way to contact them through their website unless you are a customer (which is odd), but we tried notifying them through Twitter about the problem they are causing here. They responded, but the response wasn’t good, starting with them stating that performance is apparently more important to them than not breaking websites:

One of our primary goals is to ensure the best possible performance of all sites hosted on our servers and our caching setup plays a major role in the process.

The rest of it involved them ignoring the reality of the situation, so it doesn’t seem like they are a great option for a web host.

Dealing With Zen Cart Creating Many Log Files After Increasing PHP Version in Use

Changes in newer versions of PHP have led to more warnings being issued about code that isn’t correctly written for more recent versions of PHP. This is a more prominent issue for Zen Cart websites, since it can lead to the “logs” directory quickly filling with many files. That is something we have been dealing with quite a bit recently while working on upgrades of Zen Cart, which often coincides with switching to a newer version of PHP.

Making the situation more complicated is that the directory can also contain messages about errors, in which an issue with the website caused it to not function, alongside all those warnings of things that don’t currently cause the website to not function.

While changing back to the older version of PHP would stop those files from being created, if you are changing back to PHP version that isn’t supported anymore, you are reintroducing security risk. Though we should note, it has been quite a long time since a security issue in PHP was a major source of hacking.

More permanently dealing with the warning log files involves addressing what is being warned about. That starts with making sure you are using a version of Zen Cart that is compatible with the PHP version in use. From there, updating other software on the website may resolve issues, if the newer version has had changes made related to those. Once that has been done, that leaves you with other third-party code that needs to be updated. Those with some familiarity with PHP code or coding in general can probably handle making those changes. Others will probably want to find someone to handle that for them. With much of what needs to be dealt with, a prior familiarity with Zen Cart isn’t necessary.

While some of the issues we have run across are more complicated, most of the issue that need to be addressed are easy to fix. Take one common issue in our experience, usage of PHP 4 style constructors. The log files will provide a warning like this for that:

PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; rialto_export has a deprecated constructor in /home/[redacted]/public_html/includes/classes/observers/class.rialto_export.php on line 9.

Opening the file listed shows that class rialto_export has a constructor of the same name:

9
10
11
12
class rialto_export extends base {
	var $client, $web_username, $web_password, $success_message = false, $error_message = false;
 
	function rialto_export() {

That can be resolved by renaming the function to “__construct()” like this:

9
10
11
12
class rialto_export extends base {
	var $client, $web_username, $web_password, $success_message = false, $error_message = false;
 
	function __construct() {

For most issues, doing an internet search on the warning message will bring up documentation on how to address it.

With our Zen Cart upgrade service, we now include resolving any issues being warned about in the “logs” directory at no additional cost. If there is a interest in a service for dealing with those separate from an upgrade, please contact us.

Hiring a Freelancer Isn’t Necessarily Going to Save You Money on Web Development Tasks

We often deal with people managing their own websites who would probably be better served to hire someone to handle things for them on a continuing basis instead of handling things through a combination of doing things themselves and hiring someone like us or freelancers on a one-off basis. It’s worth noting that they are not necessarily even saving money by hiring freelancers to do work. Take something we ran across on a freelancer website recently while looking for some unrelated information. The person hiring a freelancer wanted a very simple .htaccess redirect written:

I need a website to redirect to www version and https in one hop. In other words, if user enters non-secured domain, it always needs to redirect to www. version.

For example, if they enter “[login to view URL]” it needs to go to “www.domain.com.”

If they enter non-secured domain, it needs to go to secured domain, www version. For example, If they enter “[login to view URL]”, it needs to go to “[login to view URL]”

So the end result should always be the secured domain, www version, in one hop.

I will not allow access to the server due to security reasons. The current code for the HT access is below. Please let me know if questions.

They ended up paying $60 for what should amount to a couple to a few lines of code being written. Which would take, conservatively, ten minutes to write and test. That is the sort of thing we do for no additional charge when doing other work, since it is so insubstantial.

A Web Browser Listing a Website as “Not Secure” Doesn’t Mean It has Been Hacked or Contains Malware

In dealing with hacked websites, a lot of what we do isn’t the work of the hack cleanup, but explaining things. Recently the issue of web browsers’ messages about websites being “Not Secure” came up during a cleanup. With that limited detail it is easy enough to assume, after having had your website hacked, that warning refers to a security issue relating to hacking, maybe malware, but it doesn’t.

What additional information, if any, is provided by the web browser when that warning is shown varies. Apple’s Safari web browser on Mac provides no additional information if you click on “Not Secure”. By comparison, the Mac version of Google’s Chrome web browser provides a pop-up that reads:

Your connection to this site is not secure

You should not enter any sensitive information on this site (for example, passwords or credit cards), because it could be stole by attackers.

What that is explaining is that by “Not Secure”, they mean that the connection between the website and the web browser is not encrypted, so information passing back and forth could possibly be read somewhere between the two. In a lot of cases this doesn’t really matter, since nothing sensitive is being shared between the two.

To stop the warning, the website should be accessed over HTTPS instead of HTTP. That generally involves setting up an SSL certificate and setting it so that requests to website are made over HTTPS instead of HTTP. Depending on the web host and software used on the website, that can be easily done and done for free.

It also worth noting that in most instances, from our experience dealing with lots of hacked websites, making a website secure in that way wouldn’t have an impact on whether a website is hacked, since the hacks do not involve taking advantage of that insecurity.

Zen Cart Stores Can Have One Step Checkout and be Mobile Friendly

If you have a website, you probably get contacted by email with web development offers. That is true even, if, like us, you are web developers. The lack of targeting goes farther than that, as earlier this week we got an email that looks to be intended to target those with Zen Cart stores. We don’t have a Zen Cart store or a store in general, but we do provide services for Zen Cart websites. The email seems to be worth noting due to what might be a more general misunderstanding about Zen Cart.

Here is the full email:

Hi ,

I heard you were the right person to speak with regards to your site whitefirdesign.com but if I am wrong, could you please point me in the right direction?

According to a survey by DigitalEra, e-stores having modern design with latest commerce features like one step checkout generate 27% more profits and have 52.5% less bounce rate compared to conventional e-stores.

Given Zen Cart stores have subpar aesthetics and appeal, lack modern features like 1 step checkout and are not mobile friendly, are you facing store performance issues like high bounce rate, low traffic and sales on your site?

If yes, I was curious to know if you are planning to migrate from Zen Cart?

We can help you evaluate your CMS options including WordPress, Shopify, Magento etc and migrate accordingly. Do let me know.

Regards,
Robert
WordPress Consultant

Like most web software, whether a website powered by Zen Cart is mobile friendly or not is determined by the theme/template that is being used. So a lack of mobile friendliness would be just as true or false as a WordPress or Magento website.

While Zen Cart by default has a multi step checkout process, if you want to reduce the number of steps, plugins have been available to handle for that years.

WordPress, which the person ostensibly was trying to promote switching over to, isn’t even e-commerce software. It started as blogging software and could now be considered CMS software. It can include e-commerce functionality through plugins. So suggesting switching over to WordPress to get functionality missing in Zen Cart doesn’t make a lot of sense, since it doesn’t include it by default either.

For anyone still wondering if emails like that are on the level, the survey cited there doesn’t appear to exist. The only entity we could find named DigitalEra is a cybersecurity provider. The domain of the email address to reply to, cmstowordpress.com, doesn’t currently serve up a website either.

PHP Deprecated Warnings in the error_log File Are Not The Cause of 500 Internal Server Errors

In dealing issues with websites for clients, one thing we deal with a lot is that others are giving advice on things they don’t understand. That is an acute problem with the security of websites, but it also comes in to play in other places. Recently we had a client contact us about having their Joomla website stop functioning after changing the PHP version in use on their website to PHP 7.1 or above. They had previously contacted another of their providers about the issue, Sucuri, and were giving a claimed explanation of what was going on, which was, if you are slightly familiar with the subject, clearly wrong.

Someone at Sucuri wrote this:

We have reviewed the 500 Internal Server error and see in the cPanel error_log that the joomla files caused the issue:

What followed that were several lines from the website’s error_log file that looked like this:

[02-Apr-2021 17:12:16 UTC] PHP Deprecated: Non-static method GantryGZipper::_getOutHeader() should not be called statically in /home/[redacted]/public_html/libraries/gantry/core/gantrygzipper.class.php on line 108

For the purposes of determining what was causing the website to stop functioning, the key piece of information there was this: “PHP Deprecated”. What that tells you is that message is a warning that something has been deprecated and won’t work in a future version of PHP, but it still works now. So if you start seeing that warning when the website stops working, it couldn’t be the cause of the issue, since the message is explicitly stating what is being warned about is something that hasn’t stopped working yet.

As further confirmation of this, the relevant PHP documentation states that this issue only starts causing an error in PHP 8:

Calling non-static methods statically throws an Error.

Prior to PHP 8.0.0, calling non-static methods statically were deprecated, and generated an E_DEPRECATED warning.

The actual error that was causing the website to stop wasn’t even shown in that error_log file, which isn’t an uncommon situation.

As with so much of the poor advice that comes from security providers, though usually about security, it sounded like the person knew what they were talking about, but they didn’t.

Sucuri Claims to Know The Most Common Cause of Website Hacking Despite Not Determining How They Are Hacked

We are often brought in to re-clean hacked websites after another provider, Sucuri, has been hired to clean them, but has intentionally cut corners, leading to the website still being hacked after they have claimed to have cleaned it up. In the most recent instances we were brought in, the website was still hacked, though to a more limited extent than usual. But what stood out more that not only was the website still also insecure, but it was still insecure because of Sucuri’s parent company, GoDaddy. That is something Sucuri would have noticed if they have done one of three key components of a proper cleanup, trying to determine how the website was hacked and fixing that.

What makes the lack of doing that stand out more, is that an email sent out by Sucuri after their cleanup made this claim:

Out of date software is the most common cause of website compromise. It’s highly recommended to get that updated as soon as you can.

So clearly they believe you can determine how websites are hacked, but they don’t do that. Beyond that being a problem to get things properly cleaned, it also would it make hard for something they claim to do right at the top of their home page, namely preventing future attacks:

We fix hacks and prevent future attacks.

How do you prevent future attacks if you don’t know how previous ones were actually done? In other instances we were brought in, the website was already using Sucuri’s service when they were hacked, so clearly their prevention didn’t work, but Sucuri wasn’t interested in figuring out what went wrong.

GoDaddy’s Insecure Hosting

The remaining piece of the hack that they missed were admin accounts for the website created by a hacker or hackers. Looking in to how those got there would be part of trying to determine how the website was hacked. If you actually do that work regularly, as we do, then what you immediately notice is that the accounts don’t look like they were created through the normal process in the software being used on the website, since most of the details, like when the accounts were registered, were empty. What that usually means is the hacker had direct access to the website’s database.

If the hacker had access to the database, that most likely mean they were able to get access to the credentials for the database. A type of vulnerability that could provide them with that information is one that is widely exploited when it exists in software. We rarely see websites that have been hacked due to that type of vulnerability, because in most cases the hacker doesn’t have a way to directly connect to the database to then use the credentials.

With this website, though, we confirmed that you could remotely connect to the database. The vast majority of websites don’t need to the database to be remotely accessible and they normally are not, since it introduces a security risk with no upside for almost all websites. Fixing that would be something that Sucuri should have done, if they were doing things properly instead of cutting corners. When we went to see about doing that we found it was already supposed to be the case, as the database wasn’t supposed to be able to be connected to remotely:

It wasn’t a one off issue, as another part of the work Sucuri failed to do was to update the software on the website. When went to work on that we created an additional database to test the upgrade and it was also remotely accessible despite being set to not be.

That wasn’t the only security issue we ran across with the hosting account, as we will discuss in a future post.

What really stands out is the website is hosted by GoDaddy, which owns Sucuri. Is it any wonder that security is so bad, when not only does a security company not do the basic work they should do, not only is a web host failing on basic security, but when the two are part of the same company.