Well, I tried to make it as simple as possible and therefore I grouped the types of bugs only into 3 major types. There are much more and especially more precise classifications of bugs out there but we want to keep it simple.

The Quick-n-Dirties:

User Inputs:

“Advanced Bugs”:

When doing white box testing you have internal knowledge, so you have the view point of an insider. You can read the source code and you can view the configuration of the systems involved. Some people call white box testing also source code auditing. So you take the source code, you read it and you search for possible security holes.

It sounds like an easy job? But it is not! Ok sometimes it can be really easy, but in general it is a real hard job to find bugs in foreign code!

There are tools that help you to scan the source code. One of the tools is called R.A.T.S (Rough Auditing Tool for Security) or you could also use grep.

function getNews($p_id, $p_ctrl) {
  $query  = "SELECT id, value, title ";
  $query .=   "FROM News ";
  $query .=   "WHERE id = '" . $p_id . "' ";
     
  if($sth = mysql_query($query, $p_ctrl->getDB())) {
  …
  } else print("Error: ".$query."br\n");
}

To show you white box testing, read the above PHP source code snippet. Do you see any bugs? Anything you would have programmed different? Yea, the handling of the variable $p_id could cause some SQL injection possibilities. But the problem is, that it only could! It is not certain that it is a problem, because we do not know where the method getNews is call and if the arguments passed to this method are already filtered.

White box testing therefore often must be combined with the analysis of the data flow within the application. Otherwise you can not make sure that tainted data is handled correctly in all situations.

Black box testing is the opposite to white box tests, you are in the position of an outsider. You only can send requests to the System Unter Test (SUT) and you receive some kind of response. The hard job hear is to tell from the response you received that the SUT has bugs or security holes.

I call my favorite method gray box testing. First of all it is similar to black box tests, because we do not have the source code of the application we want to test. But we have full access to the SUT. We can run debuggers we can configure the application by our willing.

The picture shows an typical test lab approach, you have the SUT and several possibilities to interact with this system (the green boxes). You can use regular clients or even some self made client emulators. The blue boxes show ways in which you could extract useful information from the SUT for further analysis.