Casaba Passive security Auditor is for Security Testing and Auditing
Find security bugs in your web applications fast and effortlessly. CPA is a Fiddler plugin that passively audits a web application for a variety of security issues. CPA acts as an assistant to the web developer, tester, or security auditor, by quickly and accurately
identifying issues that commonly lead to security problems in web apps. Integrate it into your test passes to achieve consistent coverage of security testing goals.
CPA is built in C# as a small framework with a 30+ checks already included. It's completely extensible - new checks can be easily created to perform custom audits specific to your application, or to perform more general-purpose security analysis. Examples
of the types of issues CPA will currently identify:
- Cross-domain references controlled by user-input
- Cross-domain form POSTs
- Insecure cookies which don't use 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)
- Charset declarations which are controlled by user-input
- 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
- 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)
- And more….
It’s built to work with today’s complex web 2.0 applications with a sensitive regard to the holistic interdependencies that web browsers, servers, DNS, and the application all play together. CPA acts passively in the sense that it requires almost no interaction
by the user. CPA will silently run in the background while normal user-interactions generate traffic, events, data, and content.
Why use Casaba Passive Auditor?
The security field today has several good choices for HTTP proxies which assist auditors and pen-testers. CPA does not fit this category. We chose to implement this as a plugin for Fiddler which already provides the framework for HTTP debugging. Some reasons
to use CPA include:
- Safe for production. CPA does not attack web-applications in search of passwords, cross-site scripting vulnerabilities, or cross-site request forgery. Unlike crawlers and web-application scanners, CPA does not generate any traffic. It quietly watches
normal user-interaction and makes educated reports on the security of an application. For this reason CPA is completely safe to use with a production site.
- 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. CPA fits seamlessly into the picture, providing
valuable security insight with no special training requirements, dedicated machines, or other resources.
On Windows XP flavors - Copy SecurityAuditor.dll to %userprofile%\My Documents\Fiddler2\Scripts
On Windows Vista flavors - Copy SecurityAuditor.dll to %userprofile%\Documents\Fiddler2\Scripts
Configuration and Use
Getting started right away is simple - turn it on, give it a domain name to monitor, and start surfing the site in your favorite browser. CPA will be watching all the requests and responses to identify security issues based on the included checks.
Casaba Passive Auditor is a plugin for the Fiddler Proxy
. Once loaded, CPA is easily configured through its own tab in Fiddler. Simply set the origin domain you want to audit, and include any trusted domains that should be considered with the origin domain. Wildcards are allowed in
domain names. So the following origin domains work:
* // all domains will be observed, however cross-domain issues will not be found since * assumes they're all trusted origin domains
*.casabasecurity.com // any subdomain of .casabasecurity.com will be observed
*casabasecurity* // any domain or subdomain containing casabasecurity will be observed
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.
Extending and Adding Checks
New checks can be added by writing a class that inherits from WatcherCheck. From here, there's only one method required for you to implement:
public override void Check(Watcher watcher, Session session)
The WatcherCheck class defines Check() and uses it as the entry point for running whatever logic the check implements. Of course checking wouldn't be useful without reporting, so most checks will implement something like:
private void AddAlert(Watcher watcher, Session session, String cookie)
Inside AddAlert() our checks call watcher.AddAlert(int level, int ID, String URL, String typex, String description)
as a way to report when a security issue has been identified. This is demonstrated in the following sample check, which reports when weak
authentication methods such as Basic and Digest are used.
public class HeaderWeakAuthWatcherCheck : WatcherCheck
private void AddAlert(Watcher watcher, Session session, String context)
string name = "Weak authorization method";
string text =
"Risk: Medium\r\n\r\n" +
"The server issued a weak Basic or Digest authorization challenge:\r\n\r\n" +
"The context was:\r\n\r\n" +
watcher.AddAlert(Watcher.Medium, session.id, session.url, name, text);
public override void Check(Watcher watcher, Session session)
bool authBasic = session.oResponse.headers.ExistsAndContains("WWW-Authenticate", "Basic");
bool authDigest = session.oResponse.headers.ExistsAndContains("WWW-Authenticate", "Digest");
string headers = session.oResponse.headers.ToString();
if (session.responseCode == 401)
if (authBasic || authDigest)
AddAlert(watcher, session, headers);