Watcher: Web security testing tool and passive vulnerability scanner

Updated Wiki: Home

chrisweber — Fri, 31 May 2013 06:44:17 GMT

Why use the Watcher passive Web-security scanner?

by Chris Weber, co-founder at Casaba Security, contact me through CodePlex, email me at casaba .com, or drop me a message on Twitter

Ever find yourself looking for that showstopper exploit in a Web-app, and forgetting to check out all the low-hanging fruit? That's intitially why we created Watcher. For one thing, we don't want to manually inspect a Web-app for many of these issues (cookie settings, SSL configuration, information leaks, etc), but we still want to find and fix them. Watcher provides this level of security analysis, plus provides hot-spot detection to help pen-testers focus in on the spots that will lead to that showstopper exploit.

Watcher is a Fiddler addon which aims to assist penetration testers in passively finding Web-application vulnerabilities. The security field today has several good choices for HTTP proxies which assist auditors and pen-testers. We chose to implement this as a plugin for Fiddler which already provides the proxy framework for HTTP debugging. Some reasons to use Watcher include:

Safe for the Cloud and hosting environments. Being passive gives Watcher several advantages - when applications live in the Cloud there's often a risk that running security testing could damage the shared infrastructure. However, using a passive tool like Watcher ensures that there's no chance of damaging Cloud-like infrastructure.
Safe for production environments. Watcher does not attack web-applications with loads of intrusive requests, it doesn't modify inputs to your application. Unlike crawlers and web-application scanners, Watcher does not generate dangerous traffic. It quietly analyzes normal user-interaction and makes educated reports on the security of an application.
Low overhead, no training. If you’re building web-applications you already have a development and test staff. Fiddler has been valuable to dev and test for years as a general-purpose HTTP debugging proxy. Watcher fits seamlessly into the picture, providing valuable security insight with no special training requirements, dedicated machines, or other resources.

If you're looking for a tool to perform cross-site scripting (XSS) testing, check out our x5s XSS testing tool.

Quick Links

Latest version download
Detailed Documentation
Descriptions of the Checks
Sample screenshot
x5s tool for active XSS testing

Acknowledgements

We would like to thank the following people for their hard work, contributions, and ideas:

Eric Lawrence (for building the Fiddler HTTP proxy)

(Contributors)
Samuel Bucholtz
Robert Mooney
Jason D. Montgomery
Hidetake Jo
Bryan Sullivan

(Suggestions and Ideas)
Bryan Sullivan
Dave Wichers
Russ McRee
David Byrne
Adrien de Beaupre

Updated Wiki: Documentation

chrisweber — Thu, 28 Mar 2013 19:01:49 GMT

by Chris Weber, co-founder at Casaba Security, contact me through CodePlex, or email me at casaba .com.

Frequently Asked Questions:
Answers to common questions are on the FAQ page.

Download
Background
Prior Work
Reviews
User Interface and Reporting
Installation
Configuration and Usage
Compliance with OWASP
Checks and how they work
Creating and Contributing Checks

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.

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:

Passive detection of security, privacy, and PCI compliance issues in HTTP, HTML, Javascript, CSS, and development frameworks (e.g. ASP.NET, JavaServer)
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.

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.

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:

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:

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.

Compliance with OWASP Application Security Verification Standard

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:

Requirement	Level Coverage	Watcher check description
V8.9	ASVL1,ASVL2	Identify Web server error messages.
V8.9	ASVL1,ASVL2	Identify database error messages.
V9.2	ASVL2	Identify proper use of the Cache-Control headers.
V9.5	ASVL2	Identify sensitive information disclosure in URL.
V9.5	ASVL2	Identify sensitive information disclosure in HTTP headers.
V10.5	ASVL1,ASVL2	Identify SSL certificate validation errors.
V11.2	ASVL2	Identify cookies without the 'secure' flag set.
V11.1	ASVL2	Identify cookies without the 'httponly' flag set.
V11.5	ASVL1,ASVL2	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 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.

Updated Wiki: Home

chrisweber — Thu, 28 Mar 2013 19:01:09 GMT

Why use the Watcher passive Web-security scanner?

by Chris Weber, co-founder at Casaba Security, contact me through CodePlex, or email me at casaba .com.

Ever find yourself looking for that showstopper exploit in a Web-app, and forgetting to check out all the low-hanging fruit? That's intitially why we created Watcher. For one thing, we don't want to manually inspect a Web-app for many of these issues (cookie settings, SSL configuration, information leaks, etc), but we still want to find and fix them. Watcher provides this level of security analysis, plus provides hot-spot detection to help pen-testers focus in on the spots that will lead to that showstopper exploit.

Watcher is a Fiddler addon which aims to assist penetration testers in passively finding Web-application vulnerabilities. The security field today has several good choices for HTTP proxies which assist auditors and pen-testers. We chose to implement this as a plugin for Fiddler which already provides the proxy framework for HTTP debugging. Some reasons to use Watcher include:

Safe for the Cloud and hosting environments. Being passive gives Watcher several advantages - when applications live in the Cloud there's often a risk that running security testing could damage the shared infrastructure. However, using a passive tool like Watcher ensures that there's no chance of damaging Cloud-like infrastructure.
Safe for production environments. Watcher does not attack web-applications with loads of intrusive requests, it doesn't modify inputs to your application. Unlike crawlers and web-application scanners, Watcher does not generate dangerous traffic. It quietly analyzes normal user-interaction and makes educated reports on the security of an application.
Low overhead, no training. If you’re building web-applications you already have a development and test staff. Fiddler has been valuable to dev and test for years as a general-purpose HTTP debugging proxy. Watcher fits seamlessly into the picture, providing valuable security insight with no special training requirements, dedicated machines, or other resources.

If you're looking for a tool to perform cross-site scripting (XSS) testing, check out our x5s XSS testing tool.

Quick Links

Latest version download
Detailed Documentation
Descriptions of the Checks
Sample screenshot
x5s tool for active XSS testing

Acknowledgements

Updated Wiki: Home

chrisweber — Thu, 28 Mar 2013 19:00:56 GMT

Why use the Watcher passive Web-security scanner?

by Chris Weber, co-founder at Casaba Security, contact methrough CodePlex, or email me at casaba .com.

Ever find yourself looking for that showstopper exploit in a Web-app, and forgetting to check out all the low-hanging fruit? That's intitially why we created Watcher. For one thing, we don't want to manually inspect a Web-app for many of these issues (cookie settings, SSL configuration, information leaks, etc), but we still want to find and fix them. Watcher provides this level of security analysis, plus provides hot-spot detection to help pen-testers focus in on the spots that will lead to that showstopper exploit.

Watcher is a Fiddler addon which aims to assist penetration testers in passively finding Web-application vulnerabilities. The security field today has several good choices for HTTP proxies which assist auditors and pen-testers. We chose to implement this as a plugin for Fiddler which already provides the proxy framework for HTTP debugging. Some reasons to use Watcher include:

Safe for the Cloud and hosting environments. Being passive gives Watcher several advantages - when applications live in the Cloud there's often a risk that running security testing could damage the shared infrastructure. However, using a passive tool like Watcher ensures that there's no chance of damaging Cloud-like infrastructure.
Safe for production environments. Watcher does not attack web-applications with loads of intrusive requests, it doesn't modify inputs to your application. Unlike crawlers and web-application scanners, Watcher does not generate dangerous traffic. It quietly analyzes normal user-interaction and makes educated reports on the security of an application.
Low overhead, no training. If you’re building web-applications you already have a development and test staff. Fiddler has been valuable to dev and test for years as a general-purpose HTTP debugging proxy. Watcher fits seamlessly into the picture, providing valuable security insight with no special training requirements, dedicated machines, or other resources.

If you're looking for a tool to perform cross-site scripting (XSS) testing, check out our x5s XSS testing tool.

Quick Links

Latest version download
Detailed Documentation
Descriptions of the Checks
Sample screenshot
x5s tool for active XSS testing

Acknowledgements

Updated Release: Watcher v1.5.7 (Mar 28, 2013)

chrisweber — Thu, 28 Mar 2013 18:55:42 GMT

Watcher.zip contains the two DLL's for manual installation of the plugin - drop them in your Fiddler2\Scripts user or program files folder.
WatcherSetup.exe is an installer built with NSIS that will copy the two DLL's into either your Fiddler2\Scripts user or program files folder.
WatcherTFS.zip contains the Team Foundation Server (TFS) component which Watcher uses to export results to TFS. Installation and further instructions are included in the ZIP file.

CHANGELOG
Program Watcher Passive Web Security Tool for Fiddler
Version 1.5.7
Release 28-March-2013
License Custom Open Source
Authors Chris Weber
Testers Chris Weber
Contact chris@casaba.com
Website http://websecuritytool.codeplex.com/
Company http://www.casaba.com/
Copyright (c) 2010 - 2013 Casaba Security, LLC. All Rights Reserved.

{"
+++ major new feature
+ minor new feature
* changed feature
% improved performance or quality
! fixed minor bug
!!! fixed major bug

v1.5.7 2013-03-28
!!! Bug fix in check for custom-defined regex patterns

v1.5.6 2013-01-08
+ New check allows for custom-defined regex patterns
% Minor bugfixes

v1.5.4 2011-10-01
+ New check for internal IP address disclosure
% Watcher now defaults to automatically checking for updates at start

v1.5.3 2011-07-31
! Bug fixes
% X-Frame-Options check now checks every page, unique to path, ignoring query.

v1.5.2 2011-05-21
+ New check for HTTP Strict-Transport-Security header on SSL sites
+ Added free-form text filter to Results display

v1.5.1 - 2011-02-21
% Moving checks to Majestic12 HtmlParser to overcome some bottlenecks.
% Deprecating some Utility.cs functions.
! Fixing various minor bugs.

v1.5.0 - 2010-11-17
+++ Added a button to process sessions offline. Now a user can load a .SAZ (session archive) file and process the data offline in Fiddler/Watcher.
% Fixed the ProgressDialog control to move incrementally.

v1.4.1 - 2010-11-09
* Exporting results now includes all results rather than just those selected.
* XML report now includes metadata about Watcher version and configuration.
% Check for 'Charset not UTF-8' improvements.

v1.4.0 - 2010-04-24
Attempts have been made at noise-reduction, see below.
Wiki has been updated with more check descriptions, all linked to from inside Watcher.
+++ Check descriptions all improved and updated with recommendations and external references.
+ New check for javascript document.domain lowering.
* IMPORTANT: All cookie checks now perform noise filtering by default, with no option to change.
* New installations now come with a few noisy checks disabled by default.
* New installations now come with some check configs enabled by default to reduce noise.
! Fixed bug in loosely scoped domain where it wasn't defaulting to origin when one's not specified.
! Fixed bug where check configurations weren't saving.
! Assorted bug fixes.

v1.3.0 - 2010-02-25
+++ .NET Framework 3.5 is now required.
+++ Optional plugin (separate download) to export results to Team Foundation Server (TFS).
+ New (BETA) check for ASP.NET VIEWSTATE tampering vulnerability. (thanks to Bryan Sullivan for suggestions)
+ New (BETA) check for JavaServer Faces ViewState tampering vulnerability. (thanks to David Byrne for ideas)
+ New check for Silverlight EnableHtmlAccess.
+ Export results to HTML report.
+ If no origin domain is specified, each response domain will be treated as the origin, enabling better cross-domain analysis.
+ Added compliance mappings for Microsoft SDL.
! Assorted bug fixes throughout check library.

v1.2.2 - 2009-07-24
+ User-Agent now sends version information during update check for tracking purposes.
+ Added Windows 7 support to installer.
! Fixed the configuration page so checking and unchecking immediately affect what checks are run on a request.
! Checks that maintain URL caches weren't clearing when the results list was cleared.
* Changed the 'Charset not UTF-

Released: Watcher v1.5.7 (Mar 28, 2013)

Thu, 28 Mar 2013 18:55:42 GMT

Updated Release: Watcher v1.5.7 (Mar 28, 2013)

chrisweber — Thu, 28 Mar 2013 18:52:20 GMT

Source code checked in, #68ba1270458d94c6509a982e0e2fafe5c364f5b9

Chris Weber — Thu, 28 Mar 2013 18:41:44 GMT

Bug fix in Grep check, causing it to add an empty string and consume Fiddler memory and CPU resources.

Updated Release: Watcher v1.5.6 (Jan 08, 2013)

chrisweber — Wed, 09 Jan 2013 00:48:47 GMT

Watcher.zip contains the two DLL's for manual installation of the plugin - drop them in your Fiddler2\Scripts user or program files folder.
WatcherSetup.exe is an installer built with NSIS that will copy the two DLL's into either your Fiddler2\Scripts user or program files folder.
WatcherTFS.zip contains the Team Foundation Server (TFS) component which Watcher uses to export results to TFS. Installation and further instructions are included in the ZIP file.

CHANGELOG
Program Watcher Passive Web Security Tool for Fiddler
Version 1.5.6
Release 08-January-2013
License Custom Open Source
Authors Chris Weber
Testers Chris Weber
Contact chris@casaba.com
Website http://websecuritytool.codeplex.com/
Company http://www.casaba.com/
Copyright (c) 2010 - 2013 Casaba Security, LLC. All Rights Reserved.

{"
+++ major new feature
+ minor new feature
* changed feature
% improved performance or quality
! fixed minor bug
!!! fixed major bug

v1.5.6 2013-01-08
+ New check allows for custom-defined regex patterns
% Minor bugfixes

v1.5.4 2011-10-01
+ New check for internal IP address disclosure
% Watcher now defaults to automatically checking for updates at start

v1.5.3 2011-07-31
! Bug fixes
% X-Frame-Options check now checks every page, unique to path, ignoring query.

v1.5.2 2011-05-21
+ New check for HTTP Strict-Transport-Security header on SSL sites
+ Added free-form text filter to Results display

v1.5.1 - 2011-02-21
% Moving checks to Majestic12 HtmlParser to overcome some bottlenecks.
% Deprecating some Utility.cs functions.
! Fixing various minor bugs.

v1.5.0 - 2010-11-17
+++ Added a button to process sessions offline. Now a user can load a .SAZ (session archive) file and process the data offline in Fiddler/Watcher.
% Fixed the ProgressDialog control to move incrementally.

v1.4.1 - 2010-11-09
* Exporting results now includes all results rather than just those selected.
* XML report now includes metadata about Watcher version and configuration.
% Check for 'Charset not UTF-8' improvements.

v1.4.0 - 2010-04-24
Attempts have been made at noise-reduction, see below.
Wiki has been updated with more check descriptions, all linked to from inside Watcher.
+++ Check descriptions all improved and updated with recommendations and external references.
+ New check for javascript document.domain lowering.
* IMPORTANT: All cookie checks now perform noise filtering by default, with no option to change.
* New installations now come with a few noisy checks disabled by default.
* New installations now come with some check configs enabled by default to reduce noise.
! Fixed bug in loosely scoped domain where it wasn't defaulting to origin when one's not specified.
! Fixed bug where check configurations weren't saving.
! Assorted bug fixes.

v1.3.0 - 2010-02-25
+++ .NET Framework 3.5 is now required.
+++ Optional plugin (separate download) to export results to Team Foundation Server (TFS).
+ New (BETA) check for ASP.NET VIEWSTATE tampering vulnerability. (thanks to Bryan Sullivan for suggestions)
+ New (BETA) check for JavaServer Faces ViewState tampering vulnerability. (thanks to David Byrne for ideas)
+ New check for Silverlight EnableHtmlAccess.
+ Export results to HTML report.
+ If no origin domain is specified, each response domain will be treated as the origin, enabling better cross-domain analysis.
+ Added compliance mappings for Microsoft SDL.
! Assorted bug fixes throughout check library.

v1.2.2 - 2009-07-24
+ User-Agent now sends version information during update check for tracking purposes.
+ Added Windows 7 support to installer.
! Fixed the configuration page so checking and unchecking immediately affect what checks are run on a request.
! Checks that maintain URL caches weren't clearing when the results list was cleared.
* Changed the 'Charset not UTF-

Released: Watcher v1.5.6 (Jan 08, 2013)

Wed, 09 Jan 2013 00:48:47 GMT

Watcher.zip contains the two DLL's for manual installation of the plugin - drop them in your Fiddler2\Scripts user or program files folder.
WatcherSetup.exe is an installer built with NSIS that will copy the two DLL's into either your Fiddler2\Scripts user or program files folder.
WatcherTFS.zip contains the Team Foundation Server (TFS) component which Watcher uses to export results to TFS. Installation and further instructions are included in the ZIP file.

CHANGELOG
Program Watcher Passive Web Security Tool for Fiddler
Version 1.5.6
Release 08-January-2013
License Custom Open Source
Authors Chris Weber
Testers Chris Weber
Contact chris@casaba.com
Website http://websecuritytool.codeplex.com/
Company http://www.casaba.com/
Copyright (c) 2010 - 2013 Casaba Security, LLC. All Rights Reserved.

{"
+++ major new feature
+ minor new feature
* changed feature
% improved performance or quality
! fixed minor bug
!!! fixed major bug

v1.5.6 2013-01-08
+ New check allows for custom-defined regex patterns
% Minor bugfixes

v1.5.4 2011-10-01
+ New check for internal IP address disclosure
% Watcher now defaults to automatically checking for updates at start

v1.5.3 2011-07-31
! Bug fixes
% X-Frame-Options check now checks every page, unique to path, ignoring query.

v1.5.2 2011-05-21
+ New check for HTTP Strict-Transport-Security header on SSL sites
+ Added free-form text filter to Results display

v1.5.1 - 2011-02-21
% Moving checks to Majestic12 HtmlParser to overcome some bottlenecks.
% Deprecating some Utility.cs functions.
! Fixing various minor bugs.

v1.5.0 - 2010-11-17
+++ Added a button to process sessions offline. Now a user can load a .SAZ (session archive) file and process the data offline in Fiddler/Watcher.
% Fixed the ProgressDialog control to move incrementally.

v1.4.1 - 2010-11-09
* Exporting results now includes all results rather than just those selected.
* XML report now includes metadata about Watcher version and configuration.
% Check for 'Charset not UTF-8' improvements.

v1.4.0 - 2010-04-24
Attempts have been made at noise-reduction, see below.
Wiki has been updated with more check descriptions, all linked to from inside Watcher.
+++ Check descriptions all improved and updated with recommendations and external references.
+ New check for javascript document.domain lowering.
* IMPORTANT: All cookie checks now perform noise filtering by default, with no option to change.
* New installations now come with a few noisy checks disabled by default.
* New installations now come with some check configs enabled by default to reduce noise.
! Fixed bug in loosely scoped domain where it wasn't defaulting to origin when one's not specified.
! Fixed bug where check configurations weren't saving.
! Assorted bug fixes.

v1.3.0 - 2010-02-25
+++ .NET Framework 3.5 is now required.
+++ Optional plugin (separate download) to export results to Team Foundation Server (TFS).
+ New (BETA) check for ASP.NET VIEWSTATE tampering vulnerability. (thanks to Bryan Sullivan for suggestions)
+ New (BETA) check for JavaServer Faces ViewState tampering vulnerability. (thanks to David Byrne for ideas)
+ New check for Silverlight EnableHtmlAccess.
+ Export results to HTML report.
+ If no origin domain is specified, each response domain will be treated as the origin, enabling better cross-domain analysis.
+ Added compliance mappings for Microsoft SDL.
! Assorted bug fixes throughout check library.

v1.2.2 - 2009-07-24
+ User-Agent now sends version information during update check for tracking purposes.
+ Added Windows 7 support to installer.
! Fixed the configuration page so checking and unchecking immediately affect what checks are run on a request.
! Checks that maintain URL caches weren't clearing when the results list was cleared.
* Changed the 'Charset not UTF-

Source code checked in, #ff6a74da01f3

chrisweber — Wed, 09 Jan 2013 00:46:14 GMT

Didn't like the name of the new check, changing to misc.

Updated Wiki: Checks

chrisweber — Wed, 09 Jan 2013 00:41:43 GMT

Checks make up the most useful part of Watcher - they provide analysis of the HTTP traffic and reporting of security findings. As someone running the tool you can enable, disable, and configure checks independently. As a developer you can create custom and new checks for private use or to contribute to the public project.

Watcher currently ships with 38 standard checks. A check is defined as one set of logic usually stored in a single source code file. Checks can look for multiple issues, so a single check can end up reporting several separate findings.

The contents below are dividied by the categories in which different checks operate. Within each category individual checks have been documented separately.

ASP.NET checks
1. Insecure VIEWSTATE tampering possibility
Charset checks
1. Charset declaration was not UTF-8
2. A Charset mismatch was identified
Cookie checks
Cross-Domain checks
Flash checks
1. Flash allows JavaScript access
2. Flash Crossdomain.xml file contains insecure domain references
HTTP Header checks
Information Disclosure checks
Java checks
1. Java Server MyFaces vulnerable to VIEWSTATE tampering
Javascript checks
1. Use of javascript eval methods
2. Use of javascript domain lowering techniques
Miscellaneous checks
1. Custom-defined regex patterns
Sharepoint checks
1. Sharepoint insecure document library
Silverlight checks
1. Silverlight clientaccesspolicy.xml/crossdomain.xml contains insecure domain references
2. Silverlight settings allow javascript access
SSL checks
Unicode checks
1. Ill-formed UTF-8 byte sequence was identified
User-Controlled Input checks

ASP.NET checks

Microsoft ASP.NET is a programming framework for building Web-applications.

1. ASP.NET VIEWSTATE vulnerable to tampering
Look for ASP.NET VIEWSTATE that has the MAC protection disabled. When disabled, the VIEWSTATE is vulnerable to tampering and XSS attacks - see the Trustwave advisory for details. Watcher checks the VIEWSTATE bydeserializing it with the LosFormatter class, then reserializing it and comparing the length of the two results. If the length's are equal, then a cryptographic MAC was not configured to protect the VIEWSTATE. If the length was different by 20 bytes (.NET 1.1 to .NET 3.5) or 32 bytes (.NET 4.0), then a MAC hash was protecting the VIEWSTATE.
Exploit scenario
By tampering with the VIEWSTATE an attacker could perform reflected or persistent XSS attacks.
Recommendation
Secure VIEWSTATE with a MAC by setting EnableViewStateMac to true, which is on by default.
References
Web Application Security Consoritum "Cross-site-scripting"
Vulnerability Summary for CVE-2010-2088
For code-level settings see MSDN "Page.EnableViewStateMac Property"
For web.config options see MSDN "pages Element (ASP.NET Settings Schema)"

Charset checks

HTTP responses as well as HTML, XML, and other text-based content are encoded using specific character encodings, dubbed 'charset' by W3 and other standards bodies. The concept of charsets is to allow for text to be transmitted, stored, and displayed in native languages, extending far beyond US-ASCII. Applications such as Web-browsers make decisions based on charset encodings, which are numerous and include legacy as well as modern Unicode encodings. If you can remember only one thing from here, remember to force all Web-pages to emit UTF-8.

1. Charset not explicitly set to UTF-8 in HTML/XML content
This check identifies HTTP headers, meta tags, and XML documents that don't explicitly set a charset value to UTF-8. UTF-8 is supported in all major Web browsers today, and from a security perspective it is the preferred charset for most Web-applications. When a charset is not explicitly declared, Web browsers are forced into an undesirable content-sniffing mode to determine the content's character set.
Exploit scenario
An attacker could manipulate content on the page to be interpreted in an encoding of their choice. For example, if an attacker can control content at the beginning of the page, they could inject script using UTF-7 encoded text and manipulate some browsers into interpreting that text.
Recommendation
Force UTF-8 for all text content, such as HTML and XML.
References
Browser Security Handbook

2. Detect charset mismatches between HTTP header and HTML/XML bodies
This check identifies responses where the HTTP Content-Type header declares a charset different from the charset defined by the body of the HTML or XML. When there's a charset mismatch between the HTTP header and content body Web browsers can be forced into an undesirable content-sniffing mode to determine the content's correct character set.
Exploit scenario
An attacker could manipulate content on the page to be interpreted in an encoding of their choice. For example, if an attacker can control content at the beginning of the page, they could inject script using UTF-7 encoded text and manipulate some browsers into interpreting that text.
Recommendation
Force UTF-8 for all text content in both the HTTP header and meta tags or encoding declarations in XML.
References
Browser Security Handbook

Cookie checks

Note that cookie checks are configurable with inclusive and exclusive filters. Because Watcher can't distinguish between the important and unimportant cookies, you can configure an inclusive or exclusive list of cookie names to watch.

1. Look for cookies with loosely scoped domain restrictions
Cookies can be scoped by domain or path. This check is only concerned with domain scope.The domain scope applied to a cookie determines which domains can access it. For example, a cookie can be scoped strictly to a subdomain e.g. www.nottrusted.com, or loosely scoped to a parent domain e.g. nottrusted.com. In the latter case, any subdomain of nottrusted.com can access the cookieLoosely scoped cookies are common in mega-applications like google.com and live.com.
Exploit scenario
Cookies set from a subdomain like app.foo.bar are transmitted only to that domain by the browser. However, cookies scoped to a parent-level domain may be transmitted to the parent, or any subdomain of the parent.
Recommendation
Always scope cookies to a FQDN.
References
Browser Security Handbook

2. Look for cookies without the secure flag set
This check identifes cookies set over SSL which don't set the 'secure' flag. When a cookie is set with the 'secure' flag, it instructs the browser that the cookie can only be accessed over secure SSL channels. This is an important security protection for session cookies and other sensitive cookies that should never leak or be passed over an unencrypted channel.
Because Watcher can't distinguish between the important and unimportant cookies, you can configure an inclusive or exclusive list of cookie names to watch.
Exploit scenario
Consider a session cookie that gets set over secure SSL or TLS channels (e.g. https://foo.bar), but without a 'secure' flag on the cookie. An attacker with local network access could steal those cookies by directing the user to an unencrypted channel (e.g. http://foo.bar) and sniffing the HTTP request from the network. In some cases, the cookies will be sent to unencrypted HTTP connections without any attacker intervention. This is common when fetching javascript and other resource files.
Recommendation
Always set the 'secure' flag for session cookies and other sensitive cookies that should never be sent over unencrypted channels.
References
Browser Security Handbook

3. Look for instances where the HTTPOnly flag is not set
This check looks for cookies that don't have the HTTPOnly flag set. The HttpOnly flag was invented to reduce the affect of XSS vulnerabilities, by preventing them from reading user cookies. When a cookie is set with the HTTPOnly flag, it instructs the browser that the cookie can only be accessed by the server. In other words, client-side script is forbidden from accessing the cookie. This is an important security protection for session cookies and other sensitive cookies, but less important for others.
Because Watcher can't distinguish between the important and unimportant cookies, you can configure an inclusive or exclusive list of cookie names to watch.
Exploit scenario
Consider a session cookie that gets set without the 'HttpOnly' flag. An attacker finding an XSS vulnerability in the web-application could inject javascript and read a victim's cookie, gaining access to their session or other sensitive information.
Recommendation
Always set the 'HttpOnly' flag for session cookies and other sensitive cookies that should never be read by javascript.
References
Browser Security Handbook

Cross-Domain checks

The term cross-domain refers to a domain other than the origin domain hosting the page. For example, if you're visiting a webpage at www.codeplex.com, then www.codeplex.com is the hosting domain, where www is the subdomain, and codeplex.com is the parent domain. In that case, images.codeplex.com would be considered cross-domain, since it is not the origin domain. Likewise, ads.google.com would be considered cross-domain. Cross-domain sites can be filtered out in Watcher's configuration - for example - if you wanted to ignore all references to any subdomain of codeplex.com and consider it part of the origin, then you could add *.codeplex.com as the origin domain.

1. Check for cross-domain CSS source file references, akin to client-side mashups
This check tries to identify cross-domain CSS stylesheet references in the page, e.g. import url('nottrusted.com/foo.css'). This can be an issue when untrusted CSS code gets introduced to the page, leading to XSS attacks, clickjacking attacks, and other exploits related to UI layout.
Exploit scenario
An attacker who can control a stylesheet loaded into the DOM of a site, could inject XSS through directives such as Internet Explorer's expression(). For example: * { width:expression(alert(1)); }
Recommendation
Ensure CSS files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
References
Browser Security Handbook

2. Check for cross-domain javascript source file inclusion
This check tries to identify cross-domain javascript src references in the page, e.g. <script src='nottrusted.com'>. This can be an issue when untrusted javascript code gets introduced to the page.

Unfortunately, this is a typical pattern when third-party advertising and tracking code is used (e.g. Google Analytics or DoubleClick).
Exploit scenario
An attacker who can control javascript loaded into the DOM of a site can perform any malicious actions they desire on the site's visitors.
Recommendation
Ensure javascript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
References
Web Application Security Consoritum "Cross-site-scripting"

3. Check for references to untrusted domains in javascript source
This check tries to identify javascript code that uses functions like createElement(tag) to programmatically add javascript src references to the DOM, and only reports when cross-domain javascript src references are made. This would be an issue when untrusted javascript code get introduced to the page.

Unfortunately, this is a typical pattern when third-party advertising and tracking code is used (e.g. Google Analytics or DoubleClick). Since this check doesn't implement a javascript interpreter we're limited to regular expressions to find these potential issues.
Exploit scenario
An attacker who can control references to javascript sources loaded into the DOM of a site can perform any malicious actions they desire on the site's visitors.
Recommendation
Ensure javascript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
References
Web Application Security Consoritum "Cross-site-scripting"

4. Check for cross-domain form submissions
Form-data sent to third-party sites may be considered a privacy violation. This check identifies HTML forms that post data offsite to a domain other than the origin domain. This would include subdomains if you didn't specify a wildcard or a trusted domain in your configuration, e.g. *.nottrusted.com.
Exploit scenario
Form-data sent to third-party sites may be an issue in and of itself. Worse yet would be the case where an attacker could control the location for the form-data to post to.
Recommendation
Ensure forms only post data to trusted locations, and that all data transmitted meet appropriate privacy requirements.
References

Flash checks

1. Look for instantiations of the Flash player which don't restrict javascript access
The Flash object includes a parameter named AllowScriptAccess which can be set to allow a Flash SWF file to access the browser's javascript DOM, even if the page embedding the SWF is different from the page hosting it. This means the SWF could inject javascript, open windows, or perform other dangerous actions if the SWF was vulnerable to such manipulation. Typical values are 'sameDomain', 'always', and 'never'. This check flags patterns which don't set this value to 'never', which allows script access. You may not be concerned when this value is set to 'sameDomain' as that limits the scope of access somewhat, however this gets flagged as well.
Exploit scenario
An attacker finds loads a vulnerable SWF file into their social networking blog (e.g. Spaces, Facebook, MySpace, etc.). If the social network sets the flag for AllowScriptAccess to always, then the attacker can inject into the DOM of that application, affecting all users who visit their page.
Recommendation
Set AllowScriptAccess to 'never'.
References
Adobe: Controlling access to scripts in a host web page

2. Look for issues with Flash cross-domain policy file
Flash objects can allow cross-domain access defined through a crossdomain.xml. This can introduce security vulnerability when access is allowed from untrusted domains. For example, if a wildcard '*' is set in the access list Flash will allow access from any domain. The potential security issues around this are numerous, for more info check out:
Exploit scenario
If an attacker can control code running in one of the cross-domain file's trusted domains, either via XSS or other injection, they can control the Flash object across domains. This vulnerability could be used to give the attacker access to cookies, cross-domain DOM information, and more.
Recommendation
Narrow the scope of a crossdomain.xml file to a small set of required hosts. Never use wildcards '*' to denote allowed domains.
References
Crossdomain.xml Invites Cross-site Mayhem
Adobe: Cross-domain policy file specification

HTTP Header checks

1. Check that the cache-control HTTP header is set to 'no-store'
Even in secure SSL channels sensitive data could be stored by intermediary proxies and SSL terminators. To direct such proxies from storing data, the 'no-store' Cache-Control header should be specified. This check will flag all SSL responses which don't set this value.

False positives are likey with this as the check doesn't have a good way to determine what's truly sensitive data and what's not.
Exploit scenario
When a cache-control directive is not set on sensitive content, a browser or proxy can cache it locally to disk. As an example, in a kiosk scenario, sensitive information could be stored locally when a user browses their online Web-based email, in which case the next person could easily retrieve the contents of their messages.
Recommendation
Set the cache-control directive to no-cache and no-store.
References
Cache Control Directives Demystified

2. Check that a Content-Type header is included in the HTTP response
This check flags HTTP responses which don't set a Content-Type value.The HTTP Content-Type header lets a browser know what type of content to expect e.g. HTML, javascript, images, media, etc. When a Content-Type value is not specified, the browser is forced to sniff the content to determine what it might be. Forcing browsers into this state is undesirable as it can lead to exploitable conditions.
Exploit scenario
An attacker finds a page that returns some user-controlled content (e.g. text or images) without setting the HTTP Content-Type header to the appropriate MIME value. The attacker can manipulate the content to exploit this condition, but forcing the browser into a state of content-sniffing, in which case the attacker could execute code through XSS attacks.
Recommendation
Ensure each page is setting the specific and appropriate content-type value for the content being delivered.
References
Browser Security Handbook

3. Check that IE's XSS protection filter is not being disabled by the Web-application
This check is specific to Internet Explorer 8. It flags when an HTTP response sets the 'X-XSS-Protection' header to a value of 0, which disables IE8's XSS protection filter.
Exploit scenario
An attacker finds a XSS vulnerability in a website, however it's mitigated by visitors using Internet Explorer 8 because of it's built-in XSS filter. Later the attacker finds a page that disables IE's filter, which they can now use to exploit visitors using IE.
Recommendation
If IE's XSS filter must be disabled for functional or other reasons, ensure that every page of the website is properly sanitizing user input and output, and well-protected against XSS vulnerability.
References
XSS defenses in Internet Explorer

4. Check that the X-FRAME-OPTIONS header is being set for Clickjacking defense
Including the X-FRAME-OPTIONS header in the server HTTP response instructs the browser to prevent the web page from being displayed in a subframe of the page. That is, it's a security measure similar to 'framebusting' which prevents malicious websites from hosting your website in an iframe. This check flags HTTP responses which don't set this header.
Exploit scenario
A malicious website wants to spoof your company's website and capture user login credentials. They craft a webpage that loads your website into an iframe, then they use style sheets to layover your site's login form with their own malicious form. When users land on the malicious website they could be fooled into logging in and compromising their account credentials.
Recommendation
Most modern Web browsers support the X-FRAME-OPTIONS HTTP header, ensure it's set on all web pages returned by your site.
References
Clickjacking defenses in Internet Explorer

5. Checks that the X-CONTENT-TYPE-OPTIONS defense against MIME-sniffing has been declared
This check is specific to Internet Explorer 8 and Google Chrome. It flags HTTP responses which don't set the X-CONTENT-TYPE-OPTIONS header in responses. This 'nosniff' HTTP header is used by certain browsers such as IE8 and Chrome to reduce the potential for vulnerability that can occur when an attacker can trigger and manipulate a browser's MIME-sniffing behavior.
Exploit scenario
An attacker finds a page that returns some user-controlled content (e.g. text or images) without setting the HTTP Content-Type header to the appropriate MIME value. The attacker can manipulate the content to exploit this condition, but forcing the browser into a state of content-sniffing, in which case the attacker could execute code through XSS attacks.
Recommendation
Ensure each page sets a Content-Type header and the X-CONTENT-TYPE-OPTIONS if the Content-Type header is unknown.
References
Browser Security Handbook
MSDN IE Blog

6. Look for weak authentication protocols
This check flags HTTP responses which request a weak authentication protocol such as Basic or Digest.You will need to determine whether this would be considered a vulnerability in your organization. Typically usage of these protocols are frowned upon but can be protected from snooping by using SSL channels.
Exploit scenario
An attacker could snoop on the credentials of a user logging into a site using Basic authentication without SSL enabled.
Recommendation
Ensure SSL is being forced for basic and digest
References
Browser Security Handbook

7. Look for private IP address disclosure
This check applies a regular expression to all HTTP headers to identify non-routable private IP addresses as defined in RFC 1918.
Exploit scenario
Disclosure of internal, or private, IP addresses provides network information useful to an attacker. It may be possible to abuse load balancers, proxies, or even Web servers when internal IP addresses are known.
Recommendation
Ensure private IP addresses are not revealed. Each server or load balancer may have a different configuration to control this. For example, Microsoft IIS provides some settings that will ensure the hostname is always returned instead of the internal IP address, when a request does not include a host header. See http://support.microsoft.com/kb/834141.
References
RFC 1918

Information Disclosure checks

1. Check for common debugging error messages
This check will search HTML content, including comments, for common error messages returned by platforms such as ASP.NET, and Web-servers such as IIS and Apache. You can configure the list of common debug messages.
Exploit scenario
An attacker finds path information through a stack trace returned in an error page. Using the path, the attacker is able to access sensitive files and/or functionality.
Recommendation
Disable debugging messages before pushing to production.
References
Web Application Security Consoritum "Information Leakage"
OWAS ASVS "ASVL 1 and 2"

2. Check for common error messages returned by databases (may indicate SQL injection)
This check will review HTML content, including comments, for common error messages returned by database providers such as MSSQL, MySQL, and Oracle. If found, this may indicate SQL injection potential, which will need to be tested separately. You can configure the list of common error messages.
Exploit scenario
An attacker finds SQL query information through a stack trace returned in an error page. Using this information, the attacker is able to craft a query and bypass security checks.
Recommendation
Disable debugging messages before pushing to production.
References
Web Application Security Consoritum "Information Leakage"
OWAS ASVS "ASVL 1 and 2"

3. Check for dubious comments
This check looks for common patterns in HTML and javascript comments that may be useful to inspect in a security review or audit. This performs a pattern match looking for a list of words like BUG, TODO, and profanity. You can configure the list of words to search.
Exploit scenario
An attacker finds comments in the HTML and/or javascript of an application. The comments reveal information about bugs the application hasn't been able to fix, enabling the attacker to use the bugs to their advantage.
Recommendation
Scrub all comments before pushing to production.
References
Web Application Security Consoritum "Information Leakage"

4. Look for sensitive information passed through HTTP request referrer headers
This check looks for string patterns to identify sensitive information leaked in the HTTP Referrer headers. This can violate PCI and most organizational compliance policies. You can configure the list of strings for this check to add or remove values specific to your environment. In addition this check will look for credit card numbers, SSN's, and email addresses.
Exploit scenario
An attacker is able to embed a link in your application which directs to their own website. As the referrer information is passed to the attacker's website, they can collect all information from the referring URL.
Recommendation
Do not pass sensitive information in URI's.
References
Hypertext Transfer Protocol -- HTTP/1.1 "Security Considerations"

5. Look for sensitive information passed through URL parameter
This check looks for string patterns to identify sensitive information leaked in the URL. This can violate PCI and most organizational compliance policies. You can configure the list of strings for this check to add or remove values specific to your environment. In addition this check will find credit card numbers, SSN's, and email addresses.
Exploit scenario
Sensitive information passed in the URL gets logged to an intervening proxy cache, where it gets recorded to disk and is subject to eavesdropping. The same URL's can also be recorded in the Web browser's history. In a kiosk or shared computer scenario this could be a real danger.
Recommendation
Do not pass sensitive information in URI's.
References
Hypertext Transfer Protocol -- HTTP/1.1 "Security Considerations"

Java checks

1. JavaServer Faces - identify when ViewState data is insecure.
This check looks at JavaServer Faces values implemented in Apache MyFaces and Sun's Mojarra project, to detect when cryptographic protection has been disabled. If disabled, it's possible for attackers to tamper with the ViewState and create XSS attacks.
Exploit scenario
By tampering with the VIEWSTATE an attacker could perform reflected or persistent XSS attacks.
Recommendation
Secure VIEWSTATE with a MAC specific to your environment.
References
Web Application Security Consoritum "Cross-site-scripting"
Trustwave advisory

Javascript checks

1. Examine javascript code for use of dangerous eval() methods
This check identifies the use of eval(), setTimeout(), and setInterval() in javascript code. These functions evaluate a string and execute it as javascript code. When they're passed attacker-controlled values, cross-site scripting and other attacks could be possible. These findings should be reviewed by a security analyst for exploitability. Their use may also violate your organizational policy.
Exploit scenario
An eval statement in the web-application takes user-input from a JSON response. An attacker can easily control the string passed to eval(string) to perform an XSS attack.
Recommendation
Never pass un-sanitized user-input to eval() statements. Replace eval() statements with safe
References
Web Application Security Consoritum "Cross-site-scripting"

2. Examine javascript code for domain lowering tactics
Domain lowering is a method commonly used for sharing functionality across subdomains of a site. For example, when sub.foo.bar wants to access data or functions in sub2.foo.bar, it can 'lower' the document.domain property to foo.bar in javascript. This will create a cross-domain scenario where all subdomains of foo.bar can communicate freely.
Exploit scenario
Recommendation
Avoid domain lowering.
References
MSDN CROSS-DOMAIN COMMUNICATION USING DOMAIN LOWERING

Miscellaneous checks

Checks that don't have a clear home go here.

1. Custom-defined regex patterns
This check allows you to define a regex pattern that you want to match against HTTP responses. You can search for things like URLs or any other information that may be relevant to you. For example:

\b(https?|ftp|file)://-A-Z0-9+&@#/%?=~_*[-A-Z0-9+&@#/%=~_|]

This regex pattern will match all http, https, ftp, and file URLs found in the HTTP response.

Sharepoint checks

1. Look for dangerous HTML content hosted in the Shared Document Library
This check flags SharePoint document libraries which return HTML content without setting the Content-Disposition HTTP header. Setting this header tells the Web browser to download the content rather than to parse and display it. Without setting this header, users could upload malicious HTML content that would load and execute in a visitor's browser.
Exploit scenario
An attacker hosts an HTML page in the Sharepoint doclib. When a user loads that file it will get rendered in the browser as HTML from the site.
Recommendation
You need to force the Content-Disposition HTTP header on doclibs to force downloads, otherwise a .html file will get rendered in the browser as HTML from the site.
References
How To Raise a "File Download" Dialog Box for a Known MIME Type

Silverlight checks

1. Search for insecure domain references in Silverlight client access policy
Silverlight assemblies can allow cross-domain access defined through a clientaccesspolicy.xml or crossdomain.xml. This can introduce security vulnerability when access is allowed to and from untrusted domains. For example, if a wildcard '*' is set in the access list Silverlight assemblies may introduce Cross-Site Request Forgery or other issues. The potential security issues around this are numerous depending on the functionality of the application, for more info check out the Silverlight security white paper referenced.
Exploit scenario
Recommendation
Narrow the scope of a crossdomain.xml file to a small set of required hosts. Never use wildcards '*' to denote allowed domains.
References
Security Guidance for Writing and Deploying Silverlight Applications
Silverlight 4 security overview whitepaper

2. Look for instantiations of Silverlight Player which don't restrict javascript access.
The Silverlight object includes a parameter named EnableHtmlAccess which can be used to scope how javascript can access the Silverlight code. Values can be either true or false.This check flags patterns which don't set this value to 'false', which allows script access.
Exploit scenario
Recommendation
References
Security Guidance for Writing and Deploying Silverlight Applications
Silverlight 4 security overview whitepaper
MSDN Silverlight Security

SSL checks

1. Look for insecure transition from HTTP to HTTPS during form post
This check looks for insecure HTTP pages that host HTTPS forms. The issue is that an insecure HTTP page can easily be hijacked through MITM and the secure HTTPS form can be replaced or spoofed.
Exploit scenario
Because an HTTP page is sent over unsecured channels, an attacker could modify HTML content via man-in-the-middle attack, and change the form post action to point to a malicious website.
Recommendation
Use HTTPS for landing pages that host secure forms.
References

2. Look for insecure transition from HTTPS to HTTP during form post
This check identifies secure HTTPS pages that host insecure HTTP forms. The issue is that a secure page is transitioning to an insecure page when data is uploaded through a form. The user may think they're submitting data to a secure page when in fact they are not.
Exploit scenario
When data is sent to in the clear, it's subject to snooping and tampering.
Recommendation
Ensure sensitive data is only sent over secured HTTPS channels.
References

3. Check SSL certificate validation
This check validates SSL certificates and reports a finding when validation errors such as host name mis-match and expiration are found. If configured, this check will also attempt to walk the certificate chain and perform CRL revocation checking.
Exploit scenario
SSL certificates provide a way to verify the authenticity of the server in some regards, such as the hostname and expiration date of the cert.
Recommendation
Websites should use SSL certificates that match their selected hostnames, and should be re-provisioned prior to expiration.
References

4. SSLv2 protocol check
When an SSL connection is initiated, this check attempts to connect to the server using the insecure SSL v2 protocol. If the server allows this, a finding is reported. Most servers today should support SSL v3 and disallow the legacy versions of SSL.
Exploit scenario
SSLv2 is vulnerable to a number of security issues, making it undesirable in production use.
Recommendation
Ensure that SSL version 3.0 or TLS are being forced, and SSL v2 is prohibited on the server-side application.
References
Wikipedia

Unicode checks

1. Identify ill-formed Unicode UTF-8 content, and null bytes in HTML
This check reviews the byte stream of an UTF-8 encoded HTML page, and identifies ill-formed byte sequences as well as null bytes. When a web-app emits illegal UTF-8 byte sequences, then something more detrimental could be happening deeper in the server-side code.

The types of ill-formed byte sequences detected include:

Valid lead byte, followed by one or more invalid trailing bytes
Non-shortest form (overlong) UTF-8
Invalid lead byte

Exploit scenario
By injecting illegal UTF-8 byte sequences, an attacker may be able to bypass security filters or other boundaries. Worse still they may be able to perform remote code execution attacks on the server through buffer or integer overflows.
Recommendation
If an alert is returned from this check, have a developer investigate the string handling on the server-side to identify how the string is being handled.
References
http://www.lookout.net/2009/03/25/detecting-ill-formed-utf-8-byte-sequences-in-html-content/

User-Controlled Input checks

1. Charset values
This check looks at user-supplied input in query string parameters and POST data to identify where Content-Type or meta tag charset declarations might be user-controlled. Such charset declarations should always be declared by the application. If an attacker can control the response charset, they could manipulate the HTML to perform XSS or other attacks.
Exploit scenario
An attacker controlling the <meta> element charset value is able to declare UTF-7 and is also able to include enough user-controlled payload early in the HTML document to have it interpreted as UTF-7. By encoding their payload with UTF-7 the attacker is able to bypass any server-side XSS protections and embed script in the page.
Recommendation
Force UTF-8 in all charset declarations. If user-input is required to decide a charset declaration, ensure that only an allowed list is used.
References

2. Cookie poisoning
This check looks at user-supplied input in query string parameters and POST data to identify where cookie parameters might be controlled. This is called a cookie poisoning attack, and becomes exploitable when an attacker can manipulate the cookie in nafarious ways. In some cases this will not be exploitable, however, allowing URL parameters to set cookie values is generally considered a bug.
Exploit scenario
Recommendation
Do not allow user input to control cookie names and values. If some query string parameters must be set in cookie values, be sure to filter out semicolon's that can serve as name/value pair delimiters.
References

3. HTML element attributes (potential XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where certain HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Exploit scenario
An attacker could control an html href attribute to inject script using syntax like javascript:alert(1);
Recommendation
Validate all input and sanitize output it before writing to any HTML attributes.
References
Web Application Security Consoritum "Cross-site-scripting"

4. Javascript events (likely XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where certain javascript events (e.g. onclick) might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Exploit scenario
An attacker who can control the string passed to a javascript on* event can likely execute script in the DOM of the page.
Recommendation
Validate all input and sanitize it before writing to any on* events.
References
Web Application Security Consoritum "Cross-site-scripting"

5. Javascript references (potential XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where URL's in certain javascript properties (e.g. createElement src) might becontrolled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Exploit scenario
An attacker who can control the reference location to a javascript source file can load script of their choice into an application.
Recommendation
Do not allow user-input to control javascript source location references.
References

6. Open redirect
Open redirects are one of the OWASP 2010 Top Ten vulnerabilities. This check looks at user-supplied input in query string parameters and POST data to identify where open redirects might be possible. Open redirects occur when an application allows user-supplied input (e.g. http://nottrusted.com) to control an offsite redirect. This is generally a pretty accurate way to find where 301 or 302 redirects could be exploited by spammers or phishing attacks.
Exploit scenario
An attacker finds an open redirect on a site that looks like http://www.foo.bar?redirect=http://www.nottrusted.com. They leverage this to craft a mass phishing attack and coerce users to clicking the link and downloading malware. Because the malicious link is often out of view and loaded from a trusted domain, naive end users will not suspect any foul play.
Recommendation
Implement safe redirect functionality that only redirects to relative URI's, or a list of trusted domains.
References
OWASP top ten

Updated Release: Watcher v1.5.5 (Jan 08, 2013)

chrisweber — Wed, 09 Jan 2013 00:21:32 GMT

Watcher.zip contains the two DLL's for manual installation of the plugin - drop them in your Fiddler2\Scripts user or program files folder.
WatcherSetup.exe is an installer built with NSIS that will copy the two DLL's into either your Fiddler2\Scripts user or program files folder.
WatcherTFS.zip contains the Team Foundation Server (TFS) component which Watcher uses to export results to TFS. Installation and further instructions are included in the ZIP file.

CHANGELOG
Program Watcher Passive Web Security Tool for Fiddler
Version 1.5.5
Release 08-January-2013
License Custom Open Source
Authors Chris Weber
Testers Chris Weber
Contact chris@casaba.com
Website http://websecuritytool.codeplex.com/
Company http://www.casaba.com/
Copyright (c) 2010 - 2013 Casaba Security, LLC. All Rights Reserved.

{"
+++ major new feature
+ minor new feature
* changed feature
% improved performance or quality
! fixed minor bug
!!! fixed major bug

v1.5.5 2013-01-08
+ New check allows for custom-defined regex patterns
% Minor bugfixes

v1.5.4 2011-10-01
+ New check for internal IP address disclosure
% Watcher now defaults to automatically checking for updates at start

v1.5.3 2011-07-31
! Bug fixes
% X-Frame-Options check now checks every page, unique to path, ignoring query.

v1.5.2 2011-05-21
+ New check for HTTP Strict-Transport-Security header on SSL sites
+ Added free-form text filter to Results display

v1.5.1 - 2011-02-21
% Moving checks to Majestic12 HtmlParser to overcome some bottlenecks.
% Deprecating some Utility.cs functions.
! Fixing various minor bugs.

v1.5.0 - 2010-11-17
+++ Added a button to process sessions offline. Now a user can load a .SAZ (session archive) file and process the data offline in Fiddler/Watcher.
% Fixed the ProgressDialog control to move incrementally.

v1.4.1 - 2010-11-09
* Exporting results now includes all results rather than just those selected.
* XML report now includes metadata about Watcher version and configuration.
% Check for 'Charset not UTF-8' improvements.

v1.4.0 - 2010-04-24
Attempts have been made at noise-reduction, see below.
Wiki has been updated with more check descriptions, all linked to from inside Watcher.
+++ Check descriptions all improved and updated with recommendations and external references.
+ New check for javascript document.domain lowering.
* IMPORTANT: All cookie checks now perform noise filtering by default, with no option to change.
* New installations now come with a few noisy checks disabled by default.
* New installations now come with some check configs enabled by default to reduce noise.
! Fixed bug in loosely scoped domain where it wasn't defaulting to origin when one's not specified.
! Fixed bug where check configurations weren't saving.
! Assorted bug fixes.

v1.3.0 - 2010-02-25
+++ .NET Framework 3.5 is now required.
+++ Optional plugin (separate download) to export results to Team Foundation Server (TFS).
+ New (BETA) check for ASP.NET VIEWSTATE tampering vulnerability. (thanks to Bryan Sullivan for suggestions)
+ New (BETA) check for JavaServer Faces ViewState tampering vulnerability. (thanks to David Byrne for ideas)
+ New check for Silverlight EnableHtmlAccess.
+ Export results to HTML report.
+ If no origin domain is specified, each response domain will be treated as the origin, enabling better cross-domain analysis.
+ Added compliance mappings for Microsoft SDL.
! Assorted bug fixes throughout check library.

v1.2.2 - 2009-07-24
+ User-Agent now sends version information during update check for tracking purposes.
+ Added Windows 7 support to installer.
! Fixed the configuration page so checking and unchecking immediately affect what checks are run on a request.
! Checks that maintain URL caches weren't clearing when the results list was cleared.
* Changed the 'Charset not UTF-

Source code checked in, #19c782f553d0

chrisweber — Wed, 09 Jan 2013 00:15:51 GMT

Adding a new check to allow for custom-defined regex pattern matching. Minor bugfixes.

Source code checked in, #57e5521d170c

chrisweber — Tue, 08 Jan 2013 22:45:47 GMT

Adding recognition of JSON content type.

Source code checked in, #1505ffd0c7c3

chrisweber — Tue, 08 Jan 2013 20:06:15 GMT

Fixing intro comment to reflect the check's purpose.

New Post: Watcher HTML Report

chrisweber — Wed, 07 Nov 2012 17:57:30 GMT

I agree, the HTML report looks like crap, but I don't have the time to work on it presently. As an alternative I suggest using the XML report, and applying your own XSLT stylesheet to it. That would give your report a custom look that you could control. Thanks for bringing this issue up, if anyone wants to contribute to improve the HTML reporting I'd be happy to review their submission!

New Post: Watcher HTML Report

mohammedabubakr — Wed, 07 Nov 2012 13:07:53 GMT

Hi,

I wanted to check, if there are any plans for improving the HTML report that Watcher generates?

Even though the HTML report does have all the relevant data, it is not presentable. For example, if I have to emphasize a program manager who doesn't have any knowledge in security about the bugs, having a HTML report with metrics (no. of high severity bugs, low severity bugs), along with the other details about be helpful. Sometimes, I do a print-screen of Results Tab or I prepare the report manually.

regards,

-Mohammed Abubakr

Updated Wiki: Home

chrisweber — Fri, 26 Oct 2012 04:35:01 GMT

Why use the Watcher passive Web-security scanner?

by Casaba Security, contact us through CodePlex, or email us at casabasecurity .com.

Ever find yourself looking for that showstopper exploit in a Web-app, and forgetting to check out all the low-hanging fruit? That's intitially why we created Watcher. For one thing, we don't want to manually inspect a Web-app for many of these issues (cookie settings, SSL configuration, information leaks, etc), but we still want to find and fix them. Watcher provides this level of security analysis, plus provides hot-spot detection to help pen-testers focus in on the spots that will lead to that showstopper exploit.

Watcher is a Fiddler addon which aims to assist penetration testers in passively finding Web-application vulnerabilities. The security field today has several good choices for HTTP proxies which assist auditors and pen-testers. We chose to implement this as a plugin for Fiddler which already provides the proxy framework for HTTP debugging. Some reasons to use Watcher include:

Safe for the Cloud and hosting environments. Being passive gives Watcher several advantages - when applications live in the Cloud there's often a risk that running security testing could damage the shared infrastructure. However, using a passive tool like Watcher ensures that there's no chance of damaging Cloud-like infrastructure.
Safe for production environments. Watcher does not attack web-applications with loads of intrusive requests, it doesn't modify inputs to your application. Unlike crawlers and web-application scanners, Watcher does not generate dangerous traffic. It quietly analyzes normal user-interaction and makes educated reports on the security of an application.
Low overhead, no training. If you’re building web-applications you already have a development and test staff. Fiddler has been valuable to dev and test for years as a general-purpose HTTP debugging proxy. Watcher fits seamlessly into the picture, providing valuable security insight with no special training requirements, dedicated machines, or other resources.

If you're looking for a tool to perform cross-site scripting (XSS) testing, check out our x5s XSS testing tool.

Quick Links

Latest version download
Detailed Documentation
Descriptions of the Checks
Sample screenshot
x5s tool for active XSS testing

Acknowledgements

Updated Wiki: Home

chrisweber — Sat, 01 Oct 2011 20:34:48 GMT

Why use the Watcher passive Web-security scanner?

Safe for the Cloud and hosting environments. Being passive gives Watcher several advantages - when applications live in the Cloud there's often a risk that running security testing could damage the shared infrastructure. However, using a passive tool like Watcher ensures that there's no chance of damaging Cloud-like infrastructure.
Safe for production environments. Watcher does not attack web-applications with loads of intrusive requests, it doesn't modify inputs to your application. Unlike crawlers and web-application scanners, Watcher does not generate dangerous traffic. It quietly analyzes normal user-interaction and makes educated reports on the security of an application.
Low overhead, no training. If you’re building web-applications you already have a development and test staff. Fiddler has been valuable to dev and test for years as a general-purpose HTTP debugging proxy. Watcher fits seamlessly into the picture, providing valuable security insight with no special training requirements, dedicated machines, or other resources.

If you're looking for a tool to perform cross-site scripting (XSS) testing, check out our x5s XSS testing tool.

Quick Links

Latest version download
Detailed Documentation
Descriptions of the Checks
Sample screenshot
x5s tool for active XSS testing

Acknowledgements

We would like to thank the following people for their hard work, contributions, and ideas:

Eric Lawrence (for building the Fiddler HTTP proxy)

(Contributors)
Jason D. Montgomery
Hidetake Jo
Bryan Sullivan

(Suggestions and Ideas)
Bryan Sullivan
Dave Wichers
Russ McRee
David Byrne
Adrien de Beaupre

Watcher: Web security testing tool and passive vulnerability scanner

Updated Wiki: Home

Why use the Watcher passive Web-security scanner?

Quick Links

Acknowledgements

Updated Wiki: Documentation

Contents

Downloading Watcher

A Passive tool for Web Security Testing and Auditing

Prior work

Reviews

User Interface and Reporting

Installation

Configuration and Use

Compliance with OWASP Application Security Verification Standard

Checks and How the Work

Creating New Checks

Contributing

Updated Wiki: Home

Why use the Watcher passive Web-security scanner?

Quick Links

Acknowledgements

Updated Wiki: Home

Why use the Watcher passive Web-security scanner?

Quick Links

Acknowledgements

Updated Release: Watcher v1.5.7 (Mar 28, 2013)

Released: Watcher v1.5.7 (Mar 28, 2013)

Updated Release: Watcher v1.5.7 (Mar 28, 2013)

Source code checked in, #68ba1270458d94c6509a982e0e2fafe5c364f5b9

Updated Release: Watcher v1.5.6 (Jan 08, 2013)

Released: Watcher v1.5.6 (Jan 08, 2013)

Source code checked in, #ff6a74da01f3

Updated Wiki: Checks

Contents

ASP.NET checks

Charset checks

Cookie checks

Cross-Domain checks

Flash checks

HTTP Header checks

Information Disclosure checks

Java checks

Javascript checks

Miscellaneous checks

Sharepoint checks

Silverlight checks

SSL checks

Unicode checks

User-Controlled Input checks

Updated Release: Watcher v1.5.5 (Jan 08, 2013)

Source code checked in, #19c782f553d0

Source code checked in, #57e5521d170c

Source code checked in, #1505ffd0c7c3

New Post: Watcher HTML Report

New Post: Watcher HTML Report

Updated Wiki: Home

Why use the Watcher passive Web-security scanner?

Quick Links

Acknowledgements

Updated Wiki: Home

Why use the Watcher passive Web-security scanner?

Quick Links

Acknowledgements