Passive-Analysis Tool - Watcher
Watcher is a runtime passive-analysis tool for HTTP-based Web applications. Being passive means it won’t damage production systems, it’s completely safe to use in Cloud computing, shared hosting, and dedicated hosting environments. Watcher detects Web-application security issues as well as operational configuration issues. Watcher 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 (potential XSS), cookies, comments, HTTP headers, SSL, Flash, Silverlight, referrer leaks, information disclosure, Unicode, and more.
Watcher is built as a plugin for the Fiddler HTTP debugging proxy available at www.fiddlertool.com. Fiddler provides all of the rich functionality of a good Web/HTTP proxy. With Fiddler you can capture all HTTP traffic, intercept and modify, replay requests, and much much more. Fiddler provides the HTTP proxy framework for Watcher to work in, allowing for seamless integration with today’s complex Web 2.0 or Rich Internet Applications. Watcher runs silently in the background while you drive your browser and interact with the Web-application.
A Passive tool for Web Security Testing and Auditing
Watcher is a runtime passive-analysis tool for HTTP-based Web applications. Being passive means it won’t damage production systems, it’s completely safe to use in Cloud computing, shared hosting, and dedicated hosting environments. Watcher detects Web-application security issues as well as operational configuration issues. Watcher 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 (potential XSS), cookies, comments, HTTP headers, SSL, Flash, Silverlight, referrer leaks, information disclosure, Unicode, and more.
Major Features:
1. Passive detection of security, privacy, and PCI compliance issues in HTTP, HTML, Javascript, CSS, and development frameworks (e.g. ASP.NET, JavaServer)
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, HTML, and Team Foundation Server (TFS)
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. Fiddler provides all of the rich functionality of a good Web/HTTP proxy. With Fiddler you can capture all HTTP traffic, intercept and modify, replay requests, and much much more. Fiddler provides the HTTP proxy framework for Watcher to work in, allowing for seamless integration with today’s complex Web 2.0 or Rich Internet Applications. Watcher runs silently in the background while you drive your browser and interact with the Web-application.
Watcher is built in C# as a small framework with 30+ checks already included. It’s built so that new checks can be easily created to perform custom audits specific to your organizational policies, or to perform more general-purpose security assessments. Examples of the types of issues Watcher will currently identify:
ºASP.NET VIEWSTATE insecure configurations
ºJavaServer MyFaces ViewState without cryptographic protections
ºCross-domain stylesheet and javascript references
ºUser-controllable cross-domain references
ºUser-controllable attribute values such as href, form action, etc.
º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
º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.
