Black Box VS White Box Series – Part 2: White Box Testing

Part Two: White Box Testing

In case you missed it, we spoke about Black Box testing in the last part of this series. Today, I’m going to go over Black Box testing’s counterpart, White Box testing. In terms of WordPress website security, White Box testing is the practice of testing the code running behind the scenes from the inside-out. Internal testing can be accomplished through use of various tools to seek out any vulnerabilities that may exist. White Box testing is typically executed in the form of Static Application Security Testing (SAST). Static testing SAST is not a new concept, but true static analysis has, until recently, only been widely available to enterprise and large business applications. Static analysis builds a model of the given application and evaluates the model to generate vulnerability data in a human-readable format. Some SAST products, like SiteLock's malware scanning solution, even provide remediation advice to get you on your way to resolving vulnerabilities that it finds.

By building a model of an entire application in lieu of having to discover every single individual execution path inside the running application in order to test it, SAST is a natural fit for testing in your WordPress software development lifecycle (SDLC) in that you can basically load the entire web application into the SAST module for testing, saving dozens of hours in testing. Static analysis is able to test for hundreds of potential vulnerabilities in ways that no external test can, because of that model-based approach of internal testing. Ideally utilized prior to pushing new code to production, static analysis helps to identify those difficult-to-locate vulnerabilities not only in your code itself, but also shortcomings in encryption-at-rest of sensitive data. The downside to SAST is that it is only able to look from the inside-out, which is why it is important to combine White Box static application combine testing (SAST) with Black Box dynamic application security testing (DAST) in the audit processes of your code.

Just as we talked about in our last episode on Black Box testing; malware, and the potential for malware, should be treated as a vulnerability. In keeping with this standard, it is critical to extend your malware audit processes to include internal scans, not just external scans. While external scans are adept at identifying the behavior of malware, which is critical in discovering new zero-day malware, internal scans remain the most statistically-effective method for identifying the physical presence of malware. Malware testing may not be traditionally considered a part of White Box testing, but when it comes to your WordPress website, you can’t afford to exclude malware testing from your White Box process.

White Box malware testing should consist of file-based code auditing through both signature-based analysis and behavioral analysis, as demonstrated in our SiteLock malware scanning, malware removal, and SiteLock 911 products. That is, evaluating not only what the code looks like, but also what it acts like. The reason file-based auditing is so important in addition to your black box public source code auditing is because, as we all know, malware really likes to hide. By directly analyzing the full model of your WordPress website, you’re able to see the whole picture all at once, as opposed to a single page’s public snapshot of source code. SiteLock recommends running your malware scans on at least a daily basis to ensure the most recent data is being secured. If you would like to learn about how signature-based analysis compares to behaviors analysis, we’ll be talking more on this subject in a later episode of “Ask a Security Professional.” Stay tuned!

Have a question for our security professionals or a topic that you would like us to write about? Message @SiteLock and use the #AskSecPro tag!