Testing Tips

The following tips can assist you in testing a server application when sending malicious requests .

  • Find all network traffic that can be sent to the server component you want to test. This can be accomplished by reading documentation, talking with the server architects and programmers, reading client and server source code, and/or by using a sniffer to capture network traffic between the client and server.

  • Understand how that traffic is formatted. Sniffers often include built-in decoders that detail each part of the network packet. RFCs, other documentation, and talking with other testers and developers often is helpful. The better understanding you have of how each part of a request is interpreted and used, the better your test cases will be.

  • Start with one modification per request. Often, several fields within a network request should be tested . It is tempting to test multiple fields in the same request, but this usually isnt a good idea. Often, the server validates certain fields, and if one of the fields you modified is checked by the server and invalidated, you might be misled into believing that the other modification in the request didnt result in a security bug. If you test the fields separately, you can more easily uncover bugs in specific fields. After you test using one modification, it can be interesting to make multiple modifications the same request to hit additional code paths.

  • Send requests out of order. Many server components expect network requests to arrive in a certain order. When you send requests out of order, you might be able to bypass authentication and validation, or cause the server to crash, or put the server into a bad state, and so forth.

  • Send requests with lower privileges than should be allowed. For applications that require a certain level of permission to invoke certain functionality, send requests to invoke that functionality as a lower-privileged user . Sometimes the only thing blocking the request is client-side validation.

  • Remove fields. Just as modifying the value of fields is important, it is also worthwhile to remove fields of a request entirely.

  • Determine what client-side validation of data is done, and send data that violates the validation. For example, if the client prevents sending data containing a space, it is important to try that case without using the legitimate client.

  • Use a fuzzer. Fuzzing is sometimes dismissed because its goal is to send random junk to the component being tested. People often think that this wont yield great results and that targeted testing will cover these cases. Surprisingly, fuzzing can find bugs that arent discovered through code review and targeted testing. Fuzzing is a worthwhile activity that shouldnt be overlooked.

  • Send malicious requests. Malicious requests allow more thorough coverage of input validation security bugs (including cross-site scripting, SQL injection, denial of service, etc.). When you send malicious requests, it is important to include tests in these areas.



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