Watcher version 1.5.2 released May 4, 2011
by Casaba Security
, contact us through
, or email us through watcher at casabasecurity .com.
Frequently Asked Questions:
Answers to common questions are on the
User Interface and Reporting
Configuration and Usage
Compliance with OWASP
Checks and how they work
Creating and Contributing Checks
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.
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.
- 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
. 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
- 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 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
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.
There has been a lot of great work over the years creating Web-app security tools. Passive assessment proxies do exist, such as
, and OWASP's
. Some of these even combine active testing methods.
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.
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.
Various unsolicited reviews of Watcher have been written. Check them out to see how different people find value and use this type of tool.
Russ McRee has written a review for
ISSA Journal's _Toolsmith_
Rafal @ ishackingyou.com has written a review about how
Watcher's hotspot detection enables web-app pen-testing
Eviltester has written on
how to learn security testing with Fiddler and Watcher
John Sawyer wrote a review on Darkreading about the
passive agressive testing of Watcher
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.
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:
On Windows XP flavors - Copy the dll's to %userprofile%\My Documents\Fiddler2\Scripts
On Windows Vista flavors - Copy the dll's to %userprofile%\Documents\Fiddler2\Scripts
On Windows 7 flavors - Copy the dll's to %userprofile%\Documents\Fiddler2\Scripts
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:
// 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
// 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.
// 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.
Watcher provides checks that comply with OWASP's Application Security Verification Standard Levels 1 (ASVL1) and Level 2 (ASVL2). This is documented inside the Watcher user interface, and also here:
||Watcher check description
||Identify Web server error messages.
||Identify database error messages.
||Identify proper use of the Cache-Control headers.
||Identify sensitive information disclosure in URL.
||Identify sensitive information disclosure in HTTP headers.
||Identify SSL certificate validation errors.
||Identify cookies without the 'secure' flag set.
||Identify cookies without the 'httponly' flag set.
||Identify open redirects.
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
Creating New Checks
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
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.
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.