Black-box web application scanning, if we abstract from the details, is a simple process:

1. Identify all links, forms, query string parameters.
2. Send specially crafted strings to each input and analyze the output
3. Generate a report with the findings

Tools – Watcher – Fiddler Proxy Add-On

Fiddler is one of the most prevalent proxies for web application testing. In an earlier post, I discussed using an Add On called StressStrimulus for performance testing. For Web penetration testing, here are some things that Watcher (a Fiddler plugin) will provide:

• Safe for the Cloud and hosting environments. Being passive gives Watcher several advantages – when applications live in the Cloud there’s often a risk that running security testing could damage the shared infrastructure. However, using a passive tool like Watcher ensures that there’s no chance of damaging Cloud-like infrastructure.
• Safe for production environments. Watcher does not attack web-applications with loads of intrusive requests, it doesn’t modify inputs to your application. Unlike crawlers and web-application scanners, Watcher does not generate dangerous traffic. It quietly analyzes normal user-interaction and makes educated reports on the security of an application.
• Low overhead, no training. If you’re building web-applications you already have a development and test staff. Fiddler has been valuable to dev and test for years as a general-purpose HTTP debugging proxy. Watcher fits seamlessly into the picture, providing valuable security insight with no special training requirements, dedicated machines, or other resources.

Tools – W3AF – Web Application Attack and Audit Framework

Appendix – List of App Vulnerabilities

• User-controllable javascript events (e.g. onclick)
• Cross-domain form POSTs
• Insecure cookies which don’t set the HTTPOnly or secure flags
• Open redirects which can be abused by spammers and phishers
• Insecure Flash object parameters useful for cross-site scripting
• Insecure Flash crossdomain.xml
• Insecure Silverlight clientaccesspolicy.xml
• Charset declarations which could introduce vulnerability (non-UTF-8)
• User-controllable charset declarations
• Dangerous context-switching between HTTP and HTTPS
• Insufficient use of cache-control headers when private data is concerned (e.g. no-store)
• Potential HTTP referer leaks of sensitive user-information
• Potential information leaks in URL parameters
• Source code comments worth a closer look
• Insecure authentication protocols like Digest and Basic
• SSL certificate validation errors
• SSL insecure protocol issues (allowing SSL v2)
• Unicode issues with invalid byte streams
• Sharepoint insecurity checks

The post Web application intrusion testing appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.