Media- and file-based attacks

It’s been pretty busy at work so I’ve only been able to finish How to Break Software only last week in one of the nights when we had to do overtime work for our demo project. Anyway, there was this section on media-based and file-based attacks. In previous web projects, we had’t considered these as extensively as we had done in JV. In JV, the client’s machine is the environment so we had to be more conscious of the files and folders s/he uses.

Media-based attacks

1. See if your software can handle a full storage medium. Fill up the hard drive and then force the software to perform file operations (by opening, moving, and saving files).
2. See if the software can gracefully deal with a busy file system. Some applications don’t have the proper timeout/waiting mechanisms, so they can fail when the file system is busy serving a request from another application. Force the software to perform file operations in conjunction with background applications that are also performing file operations.
3. Try forcing the software through file operations with a damage medium. Applications with weak fault handling code will often fail in this scenario.

File-based attacks

1. Try assigning invalid file names to the application’s data files, temporary files, and read-only files. Then force the software to use those files.
2. Change the access permissions of the application’s data files. User permissions and read-write-execute-delete permissions are often ignored by the developers.
3. See if the software can handle corrupt data in a file. Since most data corruption results in a failed cyclical redundancy check, Canned HEAT is the perfect mechanism to inject such a faults. Otherwise, use a hex/text editor to change the contents of a file and then force the software to open the file or read from it.

In addition, some other stuff I consider:

• Try using a removable drive for storing some files. See what happens when the drive has been removed properly or removed in the middle of an operation.
• Try using a remote location when specifying some files to be used as the program’s input. I encountered cases wherein the behavior hadn’t turned out as expected when I specified \machine-named$filename.

Input and output attacks

I’ve recently started leafing through one of the testing books available in the 28th floor bookshelf. The book is entitled How to Break Software by James Whittaker. And it conveniently has a summary of input and output attacks.

Summary of the Input/Output Attacks — A Checklist for Battle

1. Make sure you see all error messages at least once by applying invalid input. Think of invalid inputs that the developers might have missed.
2. Force the software to assign its default values for any internal variable that can be set through the user interface. First display and accept existing values. Then assign bogus values to force the software to calculate good ones.
3. For every input field, enter values of the wrong type and values that represent strings that may be treated in a special way. Study the OS and programming language and make a list of possible problematic strings. Apply them all in every test entry field.
4. In every input field enter the maximum number of characters allowed.
5. Find input panels where a number of inputs are entered before pressing “OK”. Determine legal values for each individual field and try combinations that represent an illegal set of inputs.
6. Find places where inputs are accepted and apply the same input or series of inputs over and over. Choose inputs that cause some underlying computation or data manipulation over inputs that are simply displayed on the screen.
7. Pick an input, apply it to the software under test, and note the output. Think about other outputs that could occur when this input is applied in other situations. Apply the inputs in these other situations to ensure that each such output is observed during testing.
8. Think of outputs that the software cannot or should not generate. Find a combination or sequence of inputs that will cause one of these illegal outputs to be generated.
9. Apply an input that generates an output with some observable and changeable property, such as size. Force the property to change.
10. Determine when the software under test is refreshing the screen. Create situations where the software refreshes the screen too often or in which it fails to refresh what it should.