If you’re a developer, you may already be familiar with the concepts of “Black Box” and “White Box” testing as it pertains to the development life cycle of your software. It’s a simple concept, really. In software development, Black Box Testing is the testing of the design and/or structure of a piece of software by a party that is not familiar with the inner-workings of said software. Conversely, White Box Testing in software development means having a party that is typically familiar with the inner-workings of the software and the intended behavior of the software run the same sorts of tests. In the specific context of security testing, the definitions are still conceptually the same, but security professionals are looking at the software for entirely different reasons and we bring our own tools to the table.
In the world of cyber security there are a variety of methods that security professionals use to evaluate the strength of a target’s security (i.e. penetration testing). Generally, these methods can still be classified as either Black Box or White Box, but in practice are sometimes labeled external or internal security audits respectively. That is, running a test from the outside-in versus from the inside-out. In this two-part series, we’ll discuss both methods, starting with Black Box Testing.
When a security professional uses the term ‘Black Box Testing,’ they’re most often referring to external penetration testing methods. With respect to a WordPress website, external penetration testing will typically consist of one or more of the following methods:
A network scan solicits responses from the target server across a vast multitude of ports to see which ports respond as open, and are potentially usable in an attack. However, it should be noted that there will always be open ports on a web server, as certain port(s) must be open to deliver the website to the public. Since network scans often return large lists of open ports that can seem daunting, some providers, like SiteLock, have implemented a definition and scoring system to help WordPress users decipher what an open port can mean. Remember that some ports need to be open in order for the web server to operate normally. Additionally, false positives are to be expected from time to time from a network scan, especially when scanning environments using virtualization.
Application scans are a type of dynamic application security testing (DAST). An application scan is any form of automated scan that sends requests to a server which is, in simple terms, asking what services are running on the server. Based on the answers provided by the target server, we’re able to establish what services could potentially be targeted. For example, using an application scan, we are typically able to determine what web services a site is running (e.g. Apache, MySQL) and even what versions. The applications and versions can be used to establish where potential vectors of attack could exist. For example, when SiteLock gathers this information, it’s checked against our massive database of known vulnerabilities to establish which vulnerabilities apply to the specific WordPress website.
The most common form of vulnerabilities found in WordPress websites today are injection vulnerabilities. Whether it be cross-site scripting (XSS) or SQL injection vulnerabilities, each is directly related to how input is sanitized before being output by the web server. Let’s say you have a form on your website that allows visitors to subscribe to your newsletter. Behind your front-facing subscription script or plugin you may be saving the email addresses provided in your SQL database. Unbeknownst to you, that script or plugin may not be properly sanitizing the input received by visitors. Instead of the script saving a visitor’s email address to your database, a bad actor may alter the behavior by typing in a SQL query that outputs a list of all other subscribers or even more sensitive information. At SiteLock, we black box test injection vectors by attempting to inject harmless arbitrary code into fields like these in order to establish if proper sanitization is in place. If we’re able to execute arbitrary code during our automated external injection scans, the customer is immediately notified of this critical vulnerability and which arguments are susceptible.
Your average network security professional may not consider a malware scan to be a part of black box testing. However, as a security professional specializing in application-based attacks, I will tell you that malware scans should always be part of your black box testing. Malware present on a web server is, by definition, a backdoor. A backdoor is not only a vulnerability, it is a real and present threat being demonstrated in real-time. WordPress website owners have become all too familiar with malware incursions, influencing many to adopt better security mechanisms including malware scans. SiteLock provides both black box and white box approaches to malware discovery. In terms of black box testing, SiteLock uses an external crawler-based malware scanner that simulates the behavior of a regular visitor to play the victim in any attacks that may be triggered by external visits.
Many of the methods described above have counterparts used in White Box Testing, which we’ll discuss in Part Two of this series, White Box Testing. To see how SiteLock provides Black Box Testing to WordPress websites, take a look at SiteLock® Website Scanning.
Have a question for our security professionals that you would like us to write about? Message @SiteLock and use the #AskSecPro tag!
Interested to know what others think about us? Read the WP Buffs SiteLock review here.