How Testers Should Use a Completed Threat Model

Software testers commonly create a test plan , which specifies exactly which features and functionalities will be tested and how they will be tested, as well as which features and functionalities will not be tested. The threat model provides the foundation for the test plan. The threats define specific scenarios of interest that should be tested . It is a tester s responsibility to make sure threats contain enough information to make each threat a set of test cases; if the threats aren t actionable enough to test, you are missing critical information in your threat model. Application developers and designers often must provide this information. As a tester, it is important that you encourage programmers and designers to include enough detail in the threats so that the threats are actionable enough to test. You might need to interview these people to understand the specific features better and to obtain the data you need. Each threat brainstormed and included in the threat model must be tested to assess whether it is an actual flaw in the product.

If the threats aren t carefully verified , the value of threat modeling is quickly diminished. The Microsoft Office group , for example, is serious about verifying threats. The threat modeling tool the team uses automatically enters a bug in the bug tracking system for each threat. Next, the feature designer investigates whether there is a potential design flaw. If there is, the feature designer can modify the product s specification to eliminate the threat or mitigate it. If the designer doesn t think the threat is an issue, he or she assigns the threat to a developer, who verifies this by looking at the code. Assuming the threat doesn t affect the product or has been deemed not serious enough to warrant removing or mitigating, the threat is assigned to the tester that works on the functionality in question. Testers should treat threats in the same way and can use the same process testers have for closing fixed or won t fix functionality bugs . Testers need to think carefully about the assumptions the designer and developer might have made during their assessment of the issue.

Threats May Be Erroneously Dismissed

Sometimes threats turn out to be more serious than originally understood . Testers are often able to use their wide knowledge of the product and aptitude for breaking applications to identify additional test cases and attacks based on the threat. This information on the seriousness of a threat can be used to encourage a fix be made in the product. Testers are advocates for the product s users. Security is very important to customers, and testers must help ensure the product is secure.

The following subsections discuss some of the threats in the e-mail Web page example and how testers can make these actionable test cases.

Test Cases for the Spam Threat

Spammers want to send mass e-mail that contains their custom advertisement. Because the e-mail Web page feature enables the user to specify a custom message, a spammer might be able to take advantage of this. As a tester, you need to find clever ways the feature could be used for this purpose. How much of this feature can a user control? In addition to actual security test cases, your tests must include an intentionally varied mix of cases designed to find out more about how the functionality is really implemented because you cannot totally trust that the spec or threat model reflects the feature s true implementation. Following are examples of test cases that come out of this threat:

  • Can the attacker specify the subject line? (The spammer might be able to insert advertisements in the subject line itself.)

  • Does the body of the message contain any text informing the recipient that the sender was not verified? (If so, this information can help mitigate the threat when an attacker can use a bogus From e-mail address.)

  • Is the text of the message limited to only a few text characters ? (It isn t a good idea for the feature to allow a long message or special formatting such as HTML to be included.)

  • Does the message contain a way for the recipient to report abuse, if necessary?

Test Cases for the Mail Bombing Threat

An attacker might be able to flood a user s mailbox through this feature by invoking the e-mail Web page feature many times using the same destination e-mail address. You must find out from the developer whether the feature includes any built-in limitations on sending mail, and then test those limits. If there are no limits, it is worth pushing to have limits put in place. Testers should ask the following questions and perform tests around this threat:

  • Is there a limit on how many e- mails can be sent to a single address?

  • Is there a limit on how many times the feature can be invoked by a specific IP address in a certain amount of time? (Implementing a limit on how many times the feature can be invoked by a specific IP address might not work as a solution because many legitimate users might use the same IP address [such as a proxy server, Network Address Translation device], and malicious users often can change their IP addresses periodically.)

  • Is it easy for someone to automate invoking the feature? Many Web applications now require the user to enter the randomly generated alphanumeric characters displayed as an image, known as a Human Interactive Proof, to thwart automation attempts.

  • Is there an easy way to determine whether someone is using the feature to mail bomb? If so, is there a way to restrict this user s address?

Test Cases for the Repudiation Threat

E-mail is mostly sent over the Internet using SMTP, which enables the sender to specify any address as the From address. As you might imagine, many people have used this functionality to cause trouble. For example, many e-mail scams set the From address to an address the recipient might be likely to trust. Forging the From address is known as spoofing an e-mail message, and scams such as phishing use this technique to entice users to click links or perform other actions. Phishing attacks are discussed in more detail in Chapter 6. Knowledge of this SMTP issue is useful for testing the e-mail Web page feature. One way SMTP servers attempt to mitigate this threat is to stamp the sender s IP address in the e-mail message headers. Someone can look at the message headers to find more information on who really sent the message.

If the e-mail Web page feature is implemented without consideration for the spoofing threat, it can be very difficult for an e-mail recipient to determine who is the true sender of the message. The e-mail message is sent using SMTP, so the machine connecting to the mail server is included in the message headers. In this case, the IP address of the e-mail Web page server would be included, not the IP address of the user viewing the Web page. This fact potentially enables a malicious sender to hide more easily. Example test cases for this threat include the following:

  • Is information on who originated the request present in the e-mail headers and message body? Can the information in the e-mail message body be spoofed?

  • Can the attacker specify the From address? (Spammers might like to be able to spoof a From address.)

Test Cases for Denial of Service and Code Execution Threats

These types of threats are different from the others in the threat list. These threats are related to implementation flaws, whereas the others are related to design issues. The denial of service and code execution threats do not contain enough information for you to test easily. To test these threats you must understand which entry points allow data to enter the application and how the data is formatted. If possible, you should to talk to the programmer and/or look at the code to find out how the application handles and parses this data. If you don t have access to the programmer or source code, you can experiment with black box testing (testing without having access to the source code) and can reverse-engineer how the application is implemented. Code execution threats are the most serious threats in the threat model. More information about these implementation flaws is covered in Chapter 8, Buffer Overflows and Stack and Heap Manipulation, Chapter 9, Format String Attacks, and Chapter 16, SQL Injection. Reverse-engineering is covered in more detail in Chapter 17, Reverse Engineering.

Note  

Black box testing is an approach to testing used when the tester has no knowledge of how the code was implemented. Conversely, white box testing includes methods in which the tester finds bugs by examining the source code.



Hunting Security Bugs
Hunting Security Bugs
ISBN: 073562187X
EAN: 2147483647
Year: 2004
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net