Contents

Downloading Watcher

From the
download page you can get the ZIP file for manual installation or the EXE installer. A
Team Foundation Server (TFS) component is also included as a separate download with instructions for installing and exporting results to TFS.

Note also, if you're looking for a tool to perform cross-site scripting (XSS) testing, check out our
x5s XSS testing tool. Watcher does include a check to find user-controlled HTML, but x5s is more active and geared toward finding encoding issues that lead to XSS.

Works seamlessly with complex Web 2.0 applications while you drive the Web browser

Non-intrusive, will not raise alarms or damage production sites

Real-time analysis and reporting - findings are reported as they’re found, exportable to XML, HTML, and Team Foundation Server (TFS)

Configurable domains with wildcard support

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.

Prior work

There has been a lot of great work over the years creating Web-app security tools. Passive assessment proxies do exist, such as
RatProxy,
Burp proxy, ProxMon,
Paros, and OWASP's
Pantera and
WebScarab. Some of these even combine active testing methods.
Charles proxy has also been a very useful proxy during assessments. We use whatever tools suit our needs in a given situation, based on the functions and reporting they provide.

I still find reason to use some of the other proxies, but found a compelling interest to develop Watcher. For one thing, Fiddler is free and widely used. We work with a large group of developers and testers who either use Windows or Fiddler on a daily basis.
Switching between different proxies for functional testing and security testing wasn't optimal, so we decided to build a plugin for Fiddler that incorporates the security testing we want to passively automate. You can perform your functional testing as
normal, and have Watcher find security issues for you.

Fiddler provides a proxy framework with builtin tools for HTTP, HTML/XML, and Javascript debugging. Rather than recreate the proxy, we can focus on the security checking. Fiddler will handle SSL MITM, NTLM authentication, request interception, and other functions
you'd expect from a functional proxy. It can also be easily extended and contains other useful features such as an AutoResponder, performance stats, and more.

If you wanted you could still use other proxies that suit your needs and chain them together with Fiddler and Watcher to get more coverage.

Reviews

Various unsolicited reviews of Watcher have been written. Check them out to see how different people find value and use this type of tool.

User Interface and Reporting

Watcher writes findings to a ListView which includes the Severity, SessionID, Title, and URL. The full report can be exported to an XML file. Here's a screenshot of the reporting UI, the config UI is separate still.

Installation

Install the Fiddler tool http://www.fiddlertool.com.
Fiddler must be run at least once before installing Watcher. Then either run the WatcherSetup.exe installer or open the .ZIP and copy the CasabaSecurity.Web.Watcher.Checks.dll and CasabaSecurity.Web.Watcher.dll into Fiddler's 'scripts' folder:

Configuration and Use

Requires typing in the origin domain to monitor and clicking "Enable". Wildcards are supported so
.google.com will work, or simply . However, wildcards extend the scope of the "cross-domain" checks which will get missed. You can also add "trusted domains™" to exempt them from the cross-domain checks. Some examples of domain configurations:

www.casabasecurity.com
// A specific fully qualified domain name is the most precise way to configure Watcher, and will ensure all cross-domain checks. This provides the best coverage of cross-domain issues, since domains that aren't www.casabasecurity.com will be considered
untrusted.

*.casabasecurity.com
// Any subdomain of .casabasecurity.com will be observed. This provides good coverage of cross-domain issues, since domains that aren't subdomains of casabasecurity.com' will be considered untrusted.

casaba
// Any domain or subdomain containing 'casaba' will be observed. This provides decent coverage of cross-domain issues, since domains that don't contain 'casaba' will be considered untrusted.

*
// all domains will be observed, however cross-domain issues will not be found since * assumes they're all trusted origin domains. This doesn't provide any coverage of cross-domain issues.

This makes it easy to test when your application has interactions with many subdomains off your own. However, to find cross-domain issues common to mashups, advertising, and other third-party resources, it's better to specify the specific domain.

By listing ASVL1 or ASVL2, we're considering that Watcher provides coverage for whatever the requirement calls for, be it Level 1A or Level 2A.

Checks and How the Work

All of the checks bundled in the core Watcher check library are documented separately on the
Checks page.

Creating New Checks

Visit the
AddingChecks page to see details of implementing your own custom checks, or new checks you want to contribute to the project.
We're looking forward to your checks or check idea contributions! If you don't have time to build a new check then leave your idea in the
forums and we will try. Please email me at watcher at my company website, or through the
contact form on Codeplex directly if you don't have or want to create a Codeplex account.

We're working on a tutorial walkthrough for creating new checks, in the meantime please contact if you're interested right away.

Contributing

This project is open source because we want the community to make it better - we encourage your participation! While I don't have any tee shirts or stickers to give away, I'll happily include your credits in our acknowledgements. Relevant contributions
include bugs, checks, and new ideas that get implemented.

If you submit new checks that you've implemented we will review them for inclusion in the main Watcher release. Unless you wish to remain anonymous, we will include your name in the developer list for that release, and in the acknowledgements list. We believe
that people should be recognized for their hard work.