This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
OWASP Fiddler Addons for Security Testing Project
| |
|
|---|---|
|
Main
Welcome to the OWASP page presenting Fiddler addons for security testing. This is home of the Watcher and x5s security testing tools built as extensions for the Fiddler HTTP proxy. A quick overview:
- Watcher is a passive vulnerability scanner for Web applications
- x5s is an active cross-site scripting testing tool for Web applications
- Fiddler is an HTTP debugging proxy with support (and scripting support) for traffic interception, traffic modification, replay, comparison, data parsing, offline usage, NTLM/basic/digest auth, and much more
Fiddler HTTP Proxy
The Fiddler HTTP debugging proxy has a long history with a wide user base and was chosen as the platform for building security testing tools found on this page. By leveraging Fiddler we can focus our efforts on the security testing logic and let the proxy do its job.
Watcher
Visit the Watcher project page on CodePlex
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.
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.
User Interface
The main configuration screen for Watcher makes it as simple as clicking the 'enable' button. Once you do that, all HTTP traffic starts getting observed and analyzed for security issues. You can also narrow Watcher's scope by specifying an ***origin*** domain that will be the focus of analysis, all others being ignored. Custom Watcher configurations can also be saved so you don't need to re-enter the same information each time you launch the tool.
To get more granular, the checks configuration screen allows you enable and disable individual checks. Some checks even come with their own configurations such as noise reduction or string analysis.
The most interesting screen will probably be the results screen, where each finding is displayed. From here you can remove findings, filter by severity, and export to XML, HTML, or TFS.
Source Code
Watcher has been written in C# for .NET. The source code is hosted by CodePlex in a Mercurial repository which can be cloned at:
Mercurial repo: https://hg01.codeplex.com/websecuritytool
Or simply browse the source code at: http://websecuritytool.codeplex.com/SourceControl/BrowseLatest
Watcher itself can be easily extended to include new checks.
Extensibility
Watcher was built to be easily extended with new checks. You should be able to easily add custom checks and have them included in all of Watcher's functionality. A good way to get started is to browse the code looking at the Watcher Check Library, and picking one of the simpler checks to use as a template. That will show you the basic structure of what's required. I should really write a tutorial about this... added to the roadmap.
List of Security Checks
The following is a list of security checks for Watcher 1.5 as of December 6, 2010. Details are available over at Watcher's Codeplex page.
- ASP.NET checks
- Insecure VIEWSTATE tampering possibility
- Charset checks
- Charset declaration was not UTF-8
- A Charset mismatch was identified
- Cookie checks
- Loosely scoped cookie was identified
- Cookie's secure flag was not set
- Cookie's HttpOnly flag was not set
- Cross-Domain checks
- Cross-domain CSS resource
- Cross-domain JavaScript src reference
- Cross-domain JavaScript DOM reference
- Cross-domain Form action
- Flash checks
- Flash allows JavaScript access
- Flash Crossdomain.xml file contains insecure domain references
- HTTP Header checks
- Cache-Control not set to 'no-store'
- Content-Type declaration missing
- X-XSS-PROTECTION disables Internet Explorer protection
- X-XFRAMES-OPTIONS not set to prevent click-jacking
- X-CONTENT-TYPE-OPTIONS not set to prevent MIME-type sniffing
- Weak authentication
- Information Disclosure checks
- Information disclosure in error messages
- Information disclosure in database error messages
- Information disclosure in comments
- Information disclosure in HTTP referrer
- Information disclosure in URL parameters
- Java checks
- Java Server MyFaces vulnerable to VIEWSTATE tampering
- Javascript checks
- Use of javascript eval methods
- Use of javascript domain lowering techniques
- Sharepoint checks
- Sharepoint insecure document library
- Silverlight checks
- Silverlight clientaccesspolicy.xml/crossdomain.xml contains insecure domain references
- Silverlight settings allow javascript access
- SSL checks
- Insecure transition from HTTP to HTTPS
- Insecure transition from HTTPS to HTTP
- SSL certificates failed validation
- Legacy SSL v2 protocol was accepted by server
- Unicode checks
- Ill-formed UTF-8 byte sequence was identified
- User-Controlled Input checks
- A user-controlled charset declaration was identified
- A potential cookie-poisoning vulnerability was found
- A potential XSS vulnerability was found
- A likely XSS vulnerability was found in a user-controlled page event
- A potential XSS vulnerability was found through a user-controlled javascript reference
- A user-controlled open redirect was identified
x5s
Visit the x5s project page on CodePlex
X5s can help you find encoding issues that lead to XSS (cross-site scripting) attacks. It auto-injects test probes into every parameter of an HTTP request and analyzes responses to find where probes were not safely encoded.
x5s is a Fiddler addon which aims to assist penetration testers in finding cross-site scripting vulnerabilities. This is not a point and shoot tool, it requires some understanding of how encoding issues lead to XSS, and it requires manual driving. See the Quickstart Tutorial to jump right in but be ready to do a little work. It's main goal is to help you identify the hotspots where XSS might occur by:
- Detecting where safe encodings were not applied to emitted user-inputs
- Detecting where Unicode character transformations might bypass security filters
- Detecting where non-shortest UTF-8 encodings might bypass security filters
It injects ASCII to find traditional encoding issues, and it injects special Unicode characters and encodings to help an analyst identify where XSS filters might be bypassed. The approach to finding these hotspots involves injecting single-character probes separately into each input field of each request, and detecting how they were later emitted. The focus is on reflected XSS issues however persisted issues can also be detected. The idea of injecting special Unicode characters and non-shortest form encodings was to identify where transformations occur which could be used to bypass security filters. This also has the interesting side effect of illuminating how all of the fields in a Web-app handle Unicode. For example, in a single page with many inputs, you may end up seeing the same test case get returned in a variety of ways – URL encoded, NCR encoded, ill-encoded, raw, replaced, dropped, etc. In some cases where we’ve had Watcher running in conjunction, we’ve been able to detect ill-formed UTF-8 byte sequences which is indicative of ‘other’ problems.
x5s acts as an assistant to the security tester by speeding up the process of parameter manipulation and aggregating the results for quick viewing. It automates some of the preliminary XSS testing work by enumerating and injecting canaries into all input fields/parameters sent to an application and analyzing how those canaries were later emitted. E.g. Was the emitted output encoded safely or not? Did an injected character transform to something else?
Semi-Automated XSS Test Cases
x5s does not inject XSS payloads - it does not attempt to exploit or confirm an XSS vulnerability. It's designed to draw your attention to the fields and parameters which seem likely candidates for vulnerability. A security-tester would review the results to find issues where special characters were dangerously transformed or emitted without a safe encoding. This can be done by quickly scanning the results, which have been designed with the intention of providing quick visual inspection. Results filters are also included so the tester could simply click show hotspots to see only the potential problem areas. After identifying a hotspot it's the tester's job to perform further validation and XSS testing.
The types of test cases that x5s includes:
- Traditional test cases - characters typically used to test for XSS injection such as <, >, ",and ' which are used to control HTML, CSS, or javascript;
- Transformable test cases - characters that might uppercase, lowercase, Normalize, best-fit map, or other wise transform to completely different characters, E.g. the Turkish 'İ' which will lower-case to 'i' in culture-aware software.
- Overlong UTF-8 test cases - non-shortest UTF-8 encodings of the 'traditional' test cases noted above. E.g. the ASCII < is 0x3C normally and 0xC0 0xBC in non-shortest form UTF-8.
It does not inject any XSS payloads in testing. It simply injects canaries - test strings which include a single-character probe. x5s will replay a new request for each user-controlled input parameter an application accepts. In this way each parameter gets tainted and tested independently of the others.
We wanted to automate the tedious testing process of injecting probes into every input parameter of a Web-app, followed by trying to figure out how that probe was later emitted by the Web-app. However, we did not want to rely on a fully automated scan. Instead we wanted some control and insight into each test case. Was it encoded safely or not? Was it transformed into something else? Was it replaced or dropped? In some cases, testing for XSS involves what can be over-simplified as a 3-step process:
- Test user-controlled input using special characters like <, >, ', and ".
- Review how the output encodes the special characters.
- Inject a full XSS payload to validate that a vulnerability exists.
x5s will automate the first two steps of this process. This has been useful in saving time and effort, and in reducing the potential problem areas to a small, manageable set of 'hot-spots'. Once a hot-spot has been identified, the pen-tester can perform the final step of validation.
Why should you use this tool?
x5s was first and foremost designed to find encoding and character transformation issues that can lead to XSS vulnerability, and present them in a visual way where they could be reviewed with a quickness. Many tools exist for testing Web-applications to find cross-site scripting bugs. There are browser plugins, Web-scanners, and static code analyzers. We use whatever suits us in a given situation and produces the output we're interested in receiving. We developed x5s for penetration testers and other security-minded persons who already know how to find and exploit an XSS vulnerability. The tool has a slightly different bent than other tools we've used. It's main goals include:
- Automate finding the encoding issues that can lead to XSS.
- Identify where character transformations occur by injecting multibyte characters such as higher Unicode code points and non-shortest form character encodings.
Injecting probes to find encoding issues makes sense for finding XSS hotspots, but why should you be concerned with character transformations? Bypassing an XSS filter would be a big problem for any application. By detecting where characters transform, x5s can help you identify where your filters might be bypassed when special characters or encodings are used.
Extensibility was intended as well, so that new request parsers could be included in x5s. So in addition to JSON, and traditional form data, new or custom protocols can be considered and used in testing. The character mappings used in the test case configuration are also extensible, by modifying the XML file that ships with x5s.
FAST - Project About
- The OWASP Fiddler Addons for Security Testing Project (aka OWASP FAST) is the umbrella for two complementary projects:
- Watcher Project - a passive vulnerability scanner,
- X5s Project - an active XSS testing and input/output encoding detection.
Watcher - Project About
| PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| |||||||||||||||||||||||||||||||||||||||||||||
X5s - Project About
| PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| |||||||||||||||||||||||||||||||||||||||||||||
