In this appendix: | |
---|---|
When providing security training, we have often been asked for a “cheat sheet” for the security test cases that should be performed. The main problem with such a list is that testers then generally tend to use only the security test cases on the list to determine whether a feature is secure. This is a huge mistake because no list can include all the test cases needed to guarantee your application is secure. On the other hand, having a cheat sheet is a great starting point to help you generate ideas when security testing. At a minimum, use the following test cases for the different security vulnerabilities that are covered throughout this book. You can then refer back to the chapter in which the test cases are discussed for more in-depth information.
Network requests and responses are an entry point into the application. Bugs in other categories should be tested in the request and response. In addition, the following test cases attempt to send data the client or server might not expect. Refer to Chapter 4 and Chapter 5.
Test Case | Description |
---|---|
Send requests/responses out of order | The client/server might not maintain proper state, might allow certain validation to be bypassed, or might crash the client/server. |
Modify a packet’s contents to slightly different values. Example: Change the price value from 100 to 1 | Abuse the logic of the client/server with valid datatypes. |
Remove fields from the network request/response | Crash the parser or bypass any checks performed on the field. |
Modify the query string values, POST data, and cookie values | Obtain or modify data not normally accessible. |
Send invalid, illegal, or malformed for the values of the fields in the request/response | Crash the parser. |
Save HTML forms to another site and submit the form as a different user from the one who requested it | Cross-site request forgery (CSRF) attack. |
The goal when testing for spoofing issues is to make something appear to the target application or end user as something else. As a result, spoofing can cause a decision made by the application or user to be based on incorrect information. Refer to Chapter 6 and Chapter 12.
Test Case | Description |
---|---|
Check for features that trust a connection based on the domain from which the connection originates | Trust should not be elevated based on a domain name gained through a DNS reverse lookup (it can be spoofed). |
Hand-craft SMTP messages | To, From, Subject, headers, body, and so forth can all be spoofed. |
Modify HTTP Referer | Some features erroneously use this to ensure links originate from specific places. |
Modify MAC address | Some features mistakenly believe that MAC addresses are unique and cannot be spoofed. |
Spoofing IP address | Like the MAC address, a machine’s IP can also be spoofed, which is commonly used in DDoS attacks. |
Some text<CR/LF>Text on new line | Use a carriage return and linefeed (<CR/LF>) to inject a new line, which can alter the dialog box layout. |
Some text<TAB><TAB><TAB><TAB>More text | Use tab characters (<TAB>) to inject whitespace to cause the text to wrap to the next line in a dialog box. |
Some text More text | Use a lot of spaces to cause the text to wrap to a new line in a dialog box. |
Some text<NULL>Text is truncated | Use a NULL to truncate the line displayed. |
C:goodfile.txt<TAB><TAB><TAB><TAB>.exe | Use tab characters in the filename to cause part of the filename to wrap out of the viewable text area. |
C:goodfile.txt .exe | Use spaces in the filename to cause part of the filename to wrap out of the viewable text area. |
http://www.goodsite.com@ | Some applications allow the user name and password to be specified as part of the URL. Use the user name to attempt to spoof the name of the server. |
http://www.goodsite.com/good.txt%00bad.exe | Use an encoded null character (%00) to truncate the name of a file. |
http://www.goodsite.com/good.txt%0D%0Abad.exe | Use an encoded CR/LF (%0D%0A) to inject a new line. |
To find information disclosure bugs, observe the information that your application discloses and that an attacker can obtain. Sometimes the information disclosed might not seem like a security flaw unless it is a password or something else that is obvious; however, attackers generally use information to assist them in additional attacks. Refer to Chapter 7.
Test Case | Description |
---|---|
Monitor data sent across the network | An attacker can potentially monitor and even tamper with data that is sent over a network. Use tools, such as Ethereal, to monitor the network traffic. Sensitive data should be encrypted, such as by using SSL. |
Monitor data stored in files | Every file the application uses can potentially disclose information, including the application’s program files, any temporary files the application might create, and the output files that are generated by the application. |
Monitor the information stored in memory | Information stored in memory can potentially be accessible to other users in ways you wouldn’t expect. For instance, the system could potentially dump the memory to a page file or a file used when the system hibernates. |
Look for “secrets” | Any binary files that contain secrets, such as keys, passwords, and so forth, that the application uses to encrypt or protect data should never be stored in the file because an attacker can reverse engineer the file and extract them. |
Look for credentials stored in clear text | Credentials, passwords, database connection strings, and so forth should never be stored in clear text, especially if they aren’t protected with access control. |
Look at the contents of binary files for sensitive data | Files can contain more information than might be obvious. Use tools, such as Strings or a binary editor, to look at the data stored in a binary file. |
Look for internal server names | Sometimes internal server names are considered sensitive information because an attacker can use those names to aid them in attacking your internal network. |
Look for file path disclosures returned by a Web application | A Web application should disclose information about the Web server itself. Look for places, especially error conditions, where file paths of the server are disclosed. |
Exercise error conditions | Often, error conditions can reveal useful information to an attacker. Exercise all the error conditions that are possible and observe the results. |
Look for more information returned than is needed | Even simple information, such as whether a logon was unsuccessful, can be a security vulnerability that an attacker can use against your system. Question whether the information returned to a user is too much and too revealing. |
Look for places where data is obfuscated | Obfuscated data, including encoded data, does not protect sensitive information. For instance, using certain encodings, such as base64 or hexadecimal, might not make a password understandable at first glance; however, after an attacker figures out which encoding was used, the attacker can easily determine the unencoded password. |
Look for sensitive data that is part of the URL | Even if the connection uses SSL, the URL is still readable in clear text. Also, the HTTP Referer can disclose sensitive information. |
Make sure sensitive data the application uses cannot be guessed easily | If the data can be guessed easily, it can’t be protected from an attacker. For example, if a Web application uses consecutive numbers for the session ID, an attacker will easily be able to guess someone else’s valid session ID. |
The goal when testing for buffer and integer overflows is to cause the computer to write outside allocated memory, often by using values that are longer than the application might expect. In the sample test cases, <BO> is used to indicate places where a buffer overflow is attempted by supplying long input as part of the data. Refer to Chapter 8.
Test Case | Description |
---|---|
<BO>:folderfile.txt | Attempt to overflow the drive letter of a file path. |
C:<BO>file.txt | Attempt to overflow the name of a folder. |
C:folder<BO>.txt | Attempt to overflow the filename. |
C:folderfile.<BO> | Attempt to overflow the extension. |
<BO>://www.server.com/file.txt | Attempt to overflow the protocol portion of a URL. |
http://<BO>/file.txt | Attempt to overflow the server name. |
http://www.<BO>.com/file.txt | Attempt to overflow portions of the server name. |
http://server/<BO>.txt | Attempt to overflow the filename. |
http://server /file.<BO> | Attempt to overflow the extension. |
http://server/file.asp?<BO> | Attempt to overflow the query string. |
http://server/file.asp?<BO>=value | Attempt to overflow part of the query string parameter names. |
http://server /file.asp?name=<BO> | Attempt to overflow the query string parameter values. |