Over the last year I’ve led a multitude of security workshops aimed to educate entry-level WordPress users about website security. Some of the questions I regularly field in these workshops are related to the mechanics of SSL certificates, and their role in protecting website data from prying eyes. As you may know, the installation of an SSL certificate on a web server allows the server to accept traffic on the hypertext transfer protocol (secure), or simply ‘HTTPS,’ the primary form of encrypted data transfer between websites and visitors. I’d like to share the answers to some of the most frequently asked questions I’ve had on the subject.
The first thing I’d like to clarify on the subject of HTTPS and SSL certificates specifically is that the use of SSL certificates and HTTPS do not in any way, shape, or form protect the data on your website itself. HTTPS encrypts data in transit only. Neither does it protect data resting on visitors’ computers. You should consider HTTPS the armored truck of websites, not the bank vault. It acts as the protection against adversaries while data travels from point ‘A’ to point ‘B’.
Last year we published an #AskSecPro series where we explained how signature-based malware analysis works, as well as how traditional signatures are created. An area we don’t often talk about in public channels, but has played a pivotal role in SiteLock becoming a global leader in website security solutions, is our research and development efforts in new security technologies. In addition to our more traditional approaches to malware detection, SiteLock continues to explore new frontiers in technological improvement to push the field of security research forward. For some time SiteLock has been developing machine learning mechanisms as part of its process for discovering new malware iterations on an automatic basis. Our research in the field has shown that machine learning promises to be an important part of early malware detection and preliminary identification. One of the most significant breakthroughs we’ve had in machine learning as it pertains to malware detection and signatures, has been in feature-based signature analysis.
In Part One of our #AskSecPro series on WordPress Database Security, we learned about the anatomy of WordPress. Now that we have a firm understanding of the role the WordPress MySQL database plays in a WordPress installation, we can take a look at the various ways an adversary can exploit the mechanisms involved. We’ll also explore some of the ways to defend your database against compromise.
Over the last few days you may have heard the term #Cloudbleed thrown around the water cooler. Some of the questions our customers are asking us include, “What is Cloudbleed?” and “Am I protected from Cloudbleed?” As your resident Security Professional, I’ll be glad to help you to understand what the Cloudbleed buzz is all about and how it may impact you.
— First, I want to be very clear that the Cloudbleed bug does NOT impact SiteLock TrueShield™ WAF/CDN. More below.
For most people the year is still just getting started, but for some website owners the year has already packed quite a punch in the form of website attacks. This month hackers exploiting a vulnerability in the WordPress REST API successfully defaced over a million websites in what has become one of the largest website defacement campaigns to date. The attacks injected content that overwrote existing posts on WordPress websites running versions 4.7 and 4.7.1, leaving website owners with an immeasurable number of “Hacked by” posts across the droves of impacted websites.
Many website owners who have unfortunately found themselves in the proverbial trenches of a digital battlefront, some of which had at least some security measures, are facing a difficult data recovery situation. It is from these recent events that the next Ask a Security Professional question was crafted; How can I better protect my data?
I feel that it’s important to fully understand what the problem is in order to best understand what forms a solution can take. In Part One of #AskSecPro we’ll cover an introduction to some of the infrastructure behind WordPress. Let’s start at the beginning.
So far in this #AskSecPro DDoS series we’ve covered both Application Layer DDoS Attacks and Protocol-Based DDoS Attacks. We’ve also identified the differences between a DoS and a DDoS attack. In this final segment of the DDoS series, we’ll discuss the third category of DDoS attacks, Volumetric Attacks, also known as Volume-Based Attacks
Continuing our #AskSecPro DDoS series where we last discussed Application Layer Attacks, today we’ll focus on some of the most popular protocol-based DDoS attacks we’ve seen hit our customers’ web application firewall, SiteLock TrueShield™, over the years. TrueShield™ is SiteLock’s distributed cloud-based web application firewall (WAF) with the capability of defending against attacks across layers 3, 4, and 7.
In our last #AskSecPro article we discussed the differences between a DoS and a DDoS attack. Now that we understand what a DDoS attack is in concept, let’s learn a little more about the mechanisms involved in these attacks. In Part Two of the DDoS Attacks series we’ll focus on some of the attack vectors utilized by adversaries when launching a denial of service attack.
There’s a lot of buzz going around in many online communities concerning the recent distributed denial of service (DDoS) attacks the world has witnessed. In many of my own circles I’m often the only security guy in the room so I end up fielding a lot of questions, the most common of which is, “how do they do this stuff?!” In this District #AskSecPro series, I’ll be explaining the anatomy of D/DoS attacks and the practical weaponization of regular computers.
There are times when a website may want to send a visitor to another page either immediately or after a specified amount of time (usually seconds). As an example, consider an outdated page that you believe your visitors have bookmarked – You don’t want to lose the traffic, so you just automatically redirect them to another page. While less common today, these redirects and forwards do still exist, but if not setup properly, they could pose an outside risk to your online presence.
While there are many ways to create a redirect or forward, the exploit in this case boils down to the destination URL being included in the address bar for the source page. When the redirect or forward is activated, the application will read the destination URL from the address bar and forward a user to that address. Consider this example source URL:
We can see here that the “About Us” page is being redirected back to the home page. The problem with this is that there is potential for anyone to take that full URL and insert their own redirect destination address and then send it to a site’s users. From there, depending on that source page, users’ could be tricked into thinking they are still on the source site. These unvalidated redirects/forwards could ultimately lead to a phishing scam in which users are fooled into giving up sensitive information about themselves.
© Copyright 2017, SiteLock LLC.