Watcher is a runtime passive-analysis tool for HTTP-based Web applications. It complements static code analysis and manual security reviews by providing painless verification of operational and code-level issues at runtime. Watcher works seamlessly with today?s complex Web 2.0 applications by running silently in the background while you drive your browser and interact with the Web-application. It is being released for free under an Open Source license, the binaries and source are available through CodePlex at http://websecuritytool.codeplex.com/. ; A screenshot of the reporting screen is also there. This tool provides pen-testers hot-spot detection for vulnerabilities, developers quick sanity checks, and auditors PCI compliance auditing. It looks for issues related to mashups, user-controlled payloads, cookies, comments, HTTP headers, SSL, Flash, Silverlight, referrer leaks, information disclosure, Unicode, and more. Major Features: 1. Silent and passive detection of security, privacy, and PCI compliance issues in HTTP, HTML, Javascript, and CSS 2. Works seamlessly with complex Web 2.0 applications while you drive the Web browser 3. Non-intrusive, will not raise alarms or damage production sites 4. Real-time analysis and reporting - findings are reported as they?re found, exportable to XML 5. Configurable domains with wildcard support 6. Extensible framework for adding new checks Watcher is built as a plugin for the Fiddler HTTP debugging proxy available at www.fiddlertool.com. It?s built in C# as a small framework with 30+ checks already included. New checks can be easily created to perform custom audits specific to your policies, or to perform more general-purpose security assessments. Examples of the types of issues Watcher will currently identify: Cross-domain stylesheet and javascript references User-controllable cross-domain references User-controllable attribute values such as href, form action, etc. 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 access through allowScriptAccess 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 Hidden debugging messages from Web and Database servers Insecure authentication protocols like Digest and Basic SSL certificate validation errors SSL insecure protocol issues (allowing SSL v2) Unicode issues with invalid byte streams more?. Reducing false positives is a high priority, suggestions are welcome. Right now each check takes steps to reduce false positives, some better than others, and checks can be individually disabled if they?re generating too much noise. E.g. we know that only certain cookies such as session cookies need HttpOnly set, but figuring this out automatically has proven difficult without requiring the user to specify the cookie name. New checks are being planned, and new check ideas or contributions are very welcome. For example: Unicode transformation hot-spot detection (planned) User-controllable javascript events (planned) Contact me with any questions, bugs, or suggestions. -Chris Weber
