Keep on Fuzzing!

April 14, 2008 – 5:15 AM

As you will have noticed we’ve posted quite a number of Fuzzing Tools built around different frameworks and in different languages..most for difference targets/purposes too.

Fuzzing has definitely exploded in the last year or so as more people try and understand it and code tools to automate the process. There are tools for Web Services Fuzzing, Web Application Fuzzing and XML Fuzzing.

“Fuzzing has been a round a while – but we are seeing it becoming much higher profile now. Everyone wants it although they don’t necessarily understand it,” principal security consultant for Leviathan Security Michael Eddington told Reg Dev ahead of his RSA presentation.

Eddington hopes to give RSA attendees a better grasp of fuzzing. The top line is fuzzing needs to be factored into the development lifecycle along with other security tests. “The advantage of fuzzing is that it gets round the problem of making assumptions in testing – it stops us being too smart and missing the obvious,” Eddington said.

People are getting more interested in fuzzing and as with penetration testing I’m sure there will be more and more service requests for fuzzing even though people aren’t really sure what it means. The same went for SQL Injection and XSS attacks over the past couple of years.

“Fuzzing is useful for finding bugs in bad code. The number-one mistake application developers make in testing is that they expect data to arrive in a certain order and fuzzing can get round this. But the trick is to know when to stop fuzzing and how to move on to other techniques such as static analysis,” he said.

Chess advocates established code-coverage metrics – such as statement coverage – to work out when fuzzing has done its job. “Once the code-coverage metric has flattened out you know that its time to move on to other test methods. It’s important to find the balance between dynamic-testing techniques like fuzzing and static analysis,” Chess said.

I agree that fuzzing is certainly a faster way of analyzing code and looking for problems and bugs, code auditing takes a very very long time and is extremely tedious.

Breaking apps from the outside is far less hands on but will still show up the same problems. As mentioned in the article though there is still a place for static analysis.

Source: Darknet