How to break software security whittaker

How to Break Software Security describes the general problem of software security in a practical perspective from a software tester's point of view. It defines prescriptive techniques attacks that testers can use on their own software that are designed to ferret out security vulnerabilities in software applications. The book's style is easy to read and provides readers with the techniques and advice to hunt down security bugs and see that they're destroyed before the software is released.

There are also a number of bug-finding tools, freeware, and an easy-to-use port scanner included on the CD-ROM. Chapter Summaries. Second Attack: Manipulate the application's registry values. Third Attack: Force the application to use corrupt files. Fourth Attack: Manipulate and replace files that the application creates, reads from, writes to or executes. Fifth Attack: Force the application to operate in low memory, disk space and network availability conditions.

Second Attack: Examine all common switches and options. Third Attack: Explore escape characters, character sets and commands. First Attack: Try common default and test account names and passwords. Fifth Attack: Create loop conditions in any application that interprets script, code or other user supplied logic.

Sixth Attack: Use alternate routes to accomplish the same task. First Attack: Get between time of check and time of use. Force default values to be assigned 3.

Explore allowable character sets Attacks by input value 4. Force output size to change 5. Force screen refresh problems 7. Force invalid output Attacks by input value combination 8. Find inputs that cannot co-exist 9. Force invalid output Attacks by input order Repeat input sequences numerous times Attacks by Input Value This class of attacks require investigation of behavior using only single inputs or input values in the case of vari- able input.

We attempt to find a single value that breaks the application even though many other values work just fine. Some error messages are no-brainers, simply pause execution to display the message and then continue on the next input or when a timer expires. However, other error messages result from an excep- tion being thrown and an exception handler being executed.

Exception handlers or any centralized error routine are problematic because the instruction pointer changes abruptly without corresponding changes to the data state. Suddenly, the exception handler is executing and all kinds of data problems can ensue: files could still be open, memory could still be allocated, data could remain uninitialized. When control once again returns to the main routine, it is hard to say at what point the error handler got called and what leftover side-effects might be wait- ing to trip up unwary de- velopers: opening a file could fail because the file might already be open, or you might begin using data Figure 1: Error Message Appears without it being properly initialized.

Figure 1 shows an interesting bug my students found in Microsoft Word in which an error message appeared twice in a row for no particular reason. This bug was found when attacking the error handling routines by investi- gating single values of inputs. Make sure you force the software to establish default values.

Developers very often forget to establish proper default values when users enter data out of range or configure parameters improperly. Sometimes forcing defaults means doing nothing at all—an act that can trip up even good developers because it is so unexpected.

For example, in Word the following dialog has an options menu that when left unchanged actually makes controls disap- pear when the dialog is redisplayed. Compare the dialog on the left with the one on the right. Notice any missing controls?

Sometimes forcing defaults requires changing values from their initial settings once and then changing them a second time to an improper configuration. These back-to-back changes ensure that the default settings can be re- established once they are changed to other valid values. Explore allowable character sets for variable input. If the developer failed to consider this situation then these inputs may cause the program to fail when they are encountered. Force output size to change by replacing large inputs with small inputs and vice versa.

Focusing on the dispo- sition of output is a lucrative and little-used technique to find bugs. The idea is to think of an output or behavior that would signify a bug and then try to come up with the inputs that will force that behavior to occur. One conven- ient attack along these lines is forcing output areas to be recomputed by changing the length of inputs and input strings.

A good conceptual example is setting a clock to and watching it roll over to In the first case the display area is 4 characters long and the second it is 5. Going the other way, we establish 5 characters and then watch the text shrink to 4 characters. Too often developers write code to work with the initial case of a blank display area and are often disappointed when the display area already has data in it and new data of different size is used to replace it.

Suppose we enter a long string as shown be- low. Two things went on when the OK button was pressed. First, the routine computed the size of the output field needed and then populated the field with the text we entered.

Notice that the display area stays the same size despite the fact that only one character is inserted and the font size was not changed. If we edit the string again and type a multi-line string the output is even more interesting. I think the point is made and we can move on to the next attack. Make sure you explore the edges of display areas. This is another attack based on outputs that is very similar to the previous attack. However, instead of looking for ways to cause the area inside the dis- play to get corrupted, we are going to concentrate on out- side the display area.

Considering PowerPoint again, we can draw a textbox and fill it with a superscripted string. Changing the size of the su- perscript to a large font causes the top of the exponent to be truncated. This feature is demonstrated below in conjunction with the following related problem. Try to force screen refresh problems. This is a major problem for users of modern windows-based GUIs.

It is an even bigger problem for de- velopers: refresh too often and you slow down your application, failing to refresh causes anything from minor an- noyances i. The general idea in searching for refresh problems is to add, delete and move objects around on the screen. It is a good idea to try varying the distance you move an object from its original loca- tion.

Move it a little, then move it a lot; move it a once or twice, then move it a dozen times. Continuing with the large superscript example from above, try moving it around on the screen a little at a time. Note the nasty refresh problem shown below. Another recurring problem in Office associated with screen refresh is disappearing text. This is most annoy- ing in Word just around the page boundaries.

For example, a API that can be called with two parameters requires selection of values for one parameter based on the value chosen for the other parameter. Often it is the combination of values that was misprogrammed because of the complexity of the logic in the code. Find input value combinations that cannot co- exist. So which combinations are problematic? This is an issue still being actively researched but an approach we have found to be especially effec- tive is to determine an output you want to gener- ate and then try to find input combinations that cause the output to occur.

Try to make the target application produce an invalid output. This is a very effective attack for testers who really understand their problem do- main.

For example, if you are testing a calculator and understand that some functions have a re- stricted range for their result then trying to find input value combinations that force that result is a worthwhile effort.

However, if you do not understand mathematics, then it is likely that such an endeavor will be a waste of time—you might even interpret an incorrect results as correct. Sometimes the window itself will give you clues about which inputs are interrelated. When this is the case, then testers can experiment with ranges of values and try to violate the stated relationship.

Attacks by Input Order Software inputs form a formal language. How to Break Software Security. About Paladion. Previous Post Next Post. Recent Posts. Paladion OnDemand. Our Services.