Hello,

As a software tester I might offer some information.

I am primarily a "black box" tester, which means I do not go into the code.  I use the 
product as a user would.  We do some automated testing with tools like Winrunner.

However, many testers do exploratory or ad hoc testing for these items.  This involves 
using the program thinking of ways to break it, theny trying them and documenting the 
results.  In many cases there are requirements to test against, but these rarely find 
the type of problems you are addressing.  However, requirements and written test cases 
can ensure that the bug does not reappear due to code reuse or old code getting into a 
build.

Testing can be a basic as holding down a key in a field for two minutes to see if a 
buffer overflow happened (it did). I include things like the entry of bad data and 
other items in my test cases. 

>From a customer standpoint, many people do not allow new code to be placed on 
>production systems.  They have separate test systems where the program is exercised 
>before it can go on  to production system.  Such a system can lend itself to 
>automating test cases for new version of existing software.

It really comes down to having people who like to break software.  These do not have 
to be programmers or IT admins.  My background is in newspaper journalism. In some 
cases specific technical knowledge may be needed.  But often the technical person 
needs to be teamed with someone who thinks more like a user.

If a programmer says "someone would never do that" in reference to an action with a 
program, you can bet everything you own that at some time somebody will.  Take the 
classic case of a video card that if it had more than one monitor connected to it, the 
monitors would catch fire!

  

-----Original Message-----
From: kaipower [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 04, 2002 7:05 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Techniques for Vulneability discovery


Hi,

After reading the mailing list for quite a while, there is a burning
question which I kept asking myself:

How do experts discover vulnerabilities in a system/software?

Some categories of vulnerabilities that I am aware of:
1) Buffer overflow (Stack or Heap)
2) Mal access control and Trust management
3) Cross site scripting
4) Unexpected input - e.g. SQL injection?
5) Race conditions
6) password authentication

Do people just run scripts to brute force to find vulnerabilities? (as in
the case of Buffer overflows)
Or do they do a reverse engineer of the software?

How relevant is reverse engineering in this context?

Anybody out there care to give a methodology/strategy in finding
vulnerabilities?

Mike



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



__________________________________________________
D O T E A S Y - "Join the web hosting revolution!"
             http://www.doteasy.com

Reply via email to