There are two main ways to conduct penetration testing: black box and white box.  Both provide different approaches to the methodology and require different levels of interaction from the client. White box can often return more findings while improving the tester’s efficiency.

We’ve already covered black box testing in the first part of this two-part series. If you missed the first post of black box testing, you can find it here.

If you recall from the first part of this series, a pen-test is a simulation of how an attacker would attack your product or infrastructure, with the end goal of reducing the risk of cyber threats by following the recommendations you get with the pen-test’s report.

You’ll also recall that there are two main methods of pen-testing. Black box has no source code, configurations, documentation, nor access to the development team. On the other hand, white box testing provides some or all of these aids to speed up the testing and give the tester’s a one-up on how actual attackers would see your system.

Each piece of additional information we as testers get gives us a one up on attackers; this saves us time and provides better value for money.

Source code is invaluable when conducting a pen-test. It will often lead the investigation to areas of interest quicker, can show dangerous test cases without having to test them blindly, and reveal dangerous and insecure functionality that would otherwise be hidden from us.

Many things from SQL injection to insecure deserialization can stand out as vulnerabilities from reviewing the source code but can seem secure from a black box perspective. Hidden functionality or high attack complexity can make these vulnerabilities very hard to find black box, and almost impossible to exploit blindly – especially on the limited time frame of a pen-test.

Similarly, documentation can help us understand complex backend logic that might be used insecurely without us having to analyse it from scratch, which again, saves us time and you money.

With the emergence of cloud-native applications, configurations are more important than ever. Not only of how your applications and infrastructure are configured, but also the account used to manage your cloud infrastructure.

Since access to an organisations cloud account can mean a complete cyber compromise of the organisation – and serious legal, financial, and reputational consequences – it’s important to also verify that the cloud infrastructure is locked down appropriately.

Because of the head-start white box testing provides the testers, it provides a higher level of security assurance to the product or infrastructure being tested. This can be required for mission-critical applications, or where security is a high priority – for example, an application handling sensitive medical data or a bank’s backend server applications.

All this additional information has to come from somewhere though, so the lead up to a white box penetration test is more involved from the client. The manager organising a white box pen-test has to gather the source code and any extra information to send us, in addition to getting us any credentials we may need for an app and whitelisting us in any network or web application firewalls that may be in place. This increases the lead-in time to the pen-test, and the effort required to complete the engagement.

White box penetration testing is pen-testing with source code, allowing the testers to “see behind the curtain.” It enables testing to be performed faster, can find otherwise hidden vulnerabilities, and provide an overall higher level of security assurance. While it requires more work from the organisation receiving the pen-test, the better value for money and more thorough testing often outweighs the additional inconvenience. Red Cursor offers both white box and black box pen-testing; you can view our pen-testing services on our penetration testing services page.