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=92s 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=92re
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=92s 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=85.

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=92re 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