I've been looking at fuzzing tools lately and they really are the starting line for testing whether or not any system is secure. If your API/protocol/etc can't stand up to a good old fashioned fuzzing then you need to do some serious work. Basic input validation and error handling is the first public indicator of a secure system, so fuzzing tools are very handy at identifying systems where even these basic concerns haven't been addressed.
Because fuzzing attacks are easy and they can be automated system developers are at risk from every potentially malicious individual who has access to their systems. A well-developed system will pay proper attention to validating inputs and handling the errors associated with obviously bad inputs. Fuzzing is essentially an automated series of technical attacks on a system and the presence of errors indicates that certain situations have not been planned for. Poorly-developed systems won't have these safeguards in place, and if they are lacking it can be expected that other protections against more sophisticated logical system attacks have been forgotten as well.
The dynamic web application scanners on the market today are essentially fuzzing tools with some extra logic for classifying errors found thrown in. Sprajax acts in exactly the same manner for AJAX-enabled applications. These tools are great for getting a initial look at whether or not a web application has the validation and error handling which should be a cornerstone of any solid development effort.
True system development security begins with risk assessment and threat modelling. But effective blind security testing begins with fuzzing.
Yesterday we had an excellent presentation from Vijay Kumar about Single Sign On. I have updated the OWASP San Antonio page and uploaded the slide deck. Many thanks to Vijay for the presentation and thanks to all the OWASP San Antonio members who attended.
The Port80 folks have just posted about how AJAX applications are no less secure than normal web applications. They make some good arguments - the best of which is that if developers aren't paying attention to input validation for web applications they are unlikely to pay attention to input validation for AJAX-enabled applications. However, AJAX is just so new and exciting we have seen far too many developers who know better go an do stupid stuff when they start building AJAX apps. The cause: they get too enamored with what they CAN do rather than what they SHOULD do.
The problem isn't a breakdown in the coding idioms that help to avoid technical security vulnerabilities. Rather the problem is the breakdown in attack/threat/risk modeling that helps to prevent logical vulnerabilities. Web 2.0 is new enough that these patterns aren't well understood yet and that is why AJAX applications are more prone to insecurity than traditional web applications.
In the beginning we started doing work centered on web application security, but over time this has evolved to software security in general. Warnings being sent out about security for these two non-traditional development platforms only serve to underscore the importance of ANY developers building software for distributed applications having training in secure software development techniques.
Saw a great article on Informit.com that walks you through a real-world application penetration scenario. The author starts out by finding and exploiting a cross-site scripting (XSS) vulnerability and then walks through exploiting additional vulnerabilities to the point that he can run shell commands on the system. This is a great view into the mindset of application-level attackers.
I did have an issue with one of his recommended fixes. In order to fix the XSS vulnerability that he used in the first place he recommended stripping out a list of bad characters often used in XSS attacks. Although that might appear to fix the problem in this case, this is a bad strategy. Blacklisting bad characters is a stop-gap solution that fails to provide real security. Instead, each input should be specifically validated to make sure that it contains what it should. An email address should look like an email address (email@example.com), a positive integer should be a positive integer (12345) and so on.
This may seem like a minor point to argue about but it is not. If security vulnerabilities are going to be remediated, they need to be remediated correctly. Applying band-aid solutions to the problem is a bad idea because underlying serious vulnerabilities will remain and everyone will be left with a false sense of security. That is, of course, until someone exploits the remaining vulnerabilities - then developers will be in hot water. It won't be a fun conversation trying to explain why an application is still vulnerable even though $X and Y weeks were "securing" it.
So if you are going to set out to fix something you should actually fix it. You probably won't get a second chance.