General Info

CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. CAL9000 gives you the flexibility and functionality you need for more effective manual testing efforts.

Since CAL9000 is written in a combination of html, javascript and xml files, you do not need to install anything in order to use it. Instead, just open up the CAL9000.html file in your browser. Note that browsers all have their quirks, so refer to the table below for guidance.

CAL9000 Browser Issues:

Firefox For the best functionality and performance, run CAL9000 in Firefox. The variety of useful testing-related add-ons (Tamper Data, Web Developer, etc.) makes it a great platform for security work.
     The only potential gotchas that I have been able to find relate to the setting of Request Headers. You are not allowed to modify or delete the "Host" Request Header while crafting and sending a CAL9000 Http Request in Firefox. Also, for certain Methods, Firefox will add particular headers even if they are not specified. I've found that the values for these headers can be overwritten with other values, but not nulls. I would recommend running the requests through an application proxy if you need to have complete control over the Request Headers that are being sent.
     You may disregard any "some function is not defined" errors at startup. Firefox has some issues with the onLoad event - it does actually find the functions, despite the error messages.
     While using CAL9000, Firefox may pop up windows asking you to grant exceptions to its security policy. These are normal and may be safely accepted. If you are reluctant to approve granting these requests, you can review the source code. I can say with reasonable certainty that CAL9000 will not go crazy and try to kill you.
Internet Explorer After much hardship and cursing, I have been able to get CAL9000 working in IE. If you are using IE7, you will need to go to the browser's Advanced Options and turn OFF the native support for xmlHttpRequests. It appears that the "native" XHR support in IE fouls up most everything in CAL9000, so we avoid that mess by using the old ActiveX XHR implementation.
     Also, while crafting and sending an Http Request in IE, you are not allowed to modify or delete ANY of the Request Headers that are automatically set by the browser. You can see what these are by going to the HTTP Requests page and selecting the IE option from "Add Browser Headers". As I stated above with Firefox, I would recommend running the requests through an application proxy if you need to have complete control over what Request Headers are being sent. Other IE issues with sending Requests are that it does not handle some redirects and URL Authentication does not seem to work.
Other Browsers While many of CAL9000's features will work in other browsers, from what I have found only Firefox and IE allow you to easily save to disk. Since this such an integral feature of CAL9000 (customization options, request/response history, etc.), I would only recommend using some other browser as a last resort.

CAL9000 is written in Javascript, so you have full access to the source code. Feel free to modify it to best suit your particular needs. CAL9000 has some powerful features (like executing cross-domain xmlHttpRequests and writing to disk). It is purposefully designed to do some horribly insecure things. Therefore, I would strongly encourage that you only run it locally and NOT off of a server.

Though I am not actively supporting CAL9000, feel free to contact me if you have any questions about the application's usage or suggestions for improving it. Check out my website for program updates. Have fun - Chris Loomis.

XSS Attack Library Help

The XSS Attack Library is a collection of attacks that illustrates the myriad of ways that attackers may attempt to inject XSS code into web applications. Right-click Here to download the latest xssAttacks.xml file from RSnake. Replace the file of the same name in the CAL9000/files/xml/ folder.

To view the details of a particular XSS attack, just click on a topic in the left-column list. The Code, Description and Browser Support information will then be displayed. The textareas are editable, so you can try modifying the attack in the Code textarea or even trying something completely different.

Browser support reference table for XSS Attacks:

Browser Description
IE7.0 Vector works in Internet Explorer 7.0. Most recently tested with Internet Explorer 7.0.5700.6 RC1, Windows XP Professional SP2.
IE6.0 Vector works in Internet Explorer 6.0. Most recently tested with Internet Explorer 6.0.28.1.1106CO, SP2 on Windows 2000.
NS8.1-IE Vector works in Netscape 8.1+ in IE rendering engine mode. Most recently tested with Netscape 8.1 on Windows XP Professional. This used to be called trusted mode, but Netscape has changed it's security model away from the trusted/untrusted model and has opted towards Gecko as a default and IE as an option.
NS8.1-G Vector works in Netscape 8.1+ in the Gecko rendering engine mode. Most recently tested with Netscape 8.1 on Windows XP Professional.
FF2.0 Vector works in Mozilla's Gecko rendering engine, used by Firefox. Most recently tested with Firefox 2.0 on Windows XP Professional.
O9.02 Vector works in Opera. Most recently tested with Opera 9.02, Build 8586 on Windows XP Professional.
NS4 NS4 attacks will be displayed if selected, but the NS4 filter category has been removed from CAL9000.

Note: if a vector is not marked it either does not work or it is untested. Some listings are informational and will not show as being supported in any particular browser.

Browser Filtering

You can limit which attacks are displayed in the "Attack Info" drop-down box by making a selection from the "Filter" drop-down box. Here are the options:

Create Your Own Attacks

Now you can create/edit/save/delete your own attacks. At the bottom the Attack List is a new category - User Defined. This is where your attacks will be listed. When you select one of the attacks, you may notice that the name of the attack is displayed in the "Editor" text field and some of the browser checkboxes may be checked. These are all editable values.
The "Edit Actions" drop-down box has several options:
Since the User-Defined attack information is saved to the xssUserAttacks.xml file, it will not be over-written if you import an updated xssAttacks.xml file from RSnake.

You can test attacks using the Selected Text Action: Test In New Window. See the Selected Text help section for more information. This will open another browser window and attempt to execute the selected code. If successful, most of the attacks will cause an additional pop-up alert to be generated. Note that XSS results are browser-dependent, so you may want to conduct your reviews with more than one to make sure that you are testing the application, not just that particular browser.

Regular Expressions

The XSS Attack page also provides a means for testing regular expressions. Type in the regex that you want to test in the "Regex Filter" text field (the leading and trailing slashes are provided for you). Add any Flags (e.g. gim) in the Flags text field. If you want to replace the matches with some other text, add that in the "Replace With" text field.
The "Regex Actions" drop-down box has four options for regex processing:
  1. Show Matches - Any regex matches to the data in the "Code" textarea will be displayed in the "Regex Result" textarea (it is the same as the "Description" textarea).
  2. Replace Matches - Any regex matches to the data in the "Code" textarea will be replaced by the "Replace With" text and displayed in the "Regex Result" textarea.
  3. Split on Matches - The data in the "Code" textarea will be split on any regex matches and displayed in the "Regex Result" textarea.
  4. Test in New Window - Any regex matches to the data in the "Code" textarea will be replaced by the "Replace With" text and CAL9000 will try to execute the filtered code in a new window.

Choose a field name from the "Clear Fields" drop-down box to clear out one or more XSS Attack page fields.

The textareas and text fields of the XSS Attacks function are eligible for Selected Text processing. See the Selected Text help section for more information.

The textareas are eligible for the Store/Restore feature. See the Store/Restore help section for more information.

Encoder/Decoder Help

The Character Encoder/Decoder offers the ability to convert strings to/from alternate encoding types. The following types are supported:

Type Format Info
URL %XX Letters, numbers and these characters: $_.+!*~(),&/:;=?@#'- are not encoded. All other characters (ASCII only) converted to/from 2-digit hexadecimal (e.g. %20). This is not a pure URL Encoding scheme because the reserved and syntax characters are not encoded regardless of context.
Hex %XX All characters (iso-8859-1 only) converted to/from 2-digit hexadecimal (e.g. %52).
Unicode %uUUUU All characters (no restrictions) converted to/from 4-digit unicode (e.g. %u0031).
HTML-Entity: Named &AAA (varies) All characters (iso-8859-1 only) are converted to/from their respective HTML Named Entities (&lt).
HTML-Entity: Decimal &#DDD (varies) All characters (no restrictions) converted to/from 2 to 5-digit decimal (e.g. &#39321).
HTML-Entity: Hex &#xXX All characters (iso-8859-1 only) converted to/from 2-digit hexadecimal (e.g. &#x26).
HTML-Entity: Hex (long) &#x00XX All characters (iso-8859-1 only) converted to/from 4-digit hexadecimal (e.g. &#x0026).
Javascript Escaped varies The characters ('" [newline] [tab] \\) converted to/from their Javascript escaped equivalents (\' \" \n \t \\\\).
XML Escaped varies The characters (<>'"&) converted to/from their XML escaped equivalents (&lt;&gt;&apos;&quot;&amp;).
Straight Decimal DD All characters (no restrictions) converted to/from 2 to 5-digit decimal (e.g. 39321). Note that you must have delimiters or trailing characters present in order to decode straight decimal encodings.
Straight Hex XX All characters (iso-8859-1 only) converted to/from 2-digit hexadecimal (e.g. 52).
IE Hex \xXX to \x00000XX All characters (iso-8859-1 only) converted to/from 2 to 7-digit hexadecimal (e.g. \x52).
IE Unicode \uUUUU All characters (no restrictions) converted to/from 4-digit unicode (e.g. \u0031).
Base-64 hash All characters (iso-8859-1 only) converted to/from base-64 (e.g. Q0FMOTAwMA==).
Md4 hash Encode Only. String converted to 32 character MD4 (e.g. 8a9d093f14f8701df17732b2bb182c74).
Md5 hash String converted to/from 32 character MD5 (e.g. 5f4dcc3b5aa765d61d8327deb882cf99).
Sha1 hash Encode Only. String converted to 40 character Sha1 (e.g. 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8).


Parameters

Before you can encode or decode text, you need to know about some optional parameters:
Uppercase Checkbox
Checking this box will cause any Hex-based, Unicode and HTML Entity-Name encodings to have uppercase letters (%3C, %U003C and &LT instead of %3c, %u003c and &lt). Uppercase Hex-based and Unicode values will decode properly, even if you do not have the Uppercase Checkbox checked, but HTML Entity-Name values will not. Note: There are several HTML Entity Names that have the same spellings, differentiated only by case (&Ntilde != &ntilde). This becomes an issue when you want to encode in uppercase, as both of these examples would encode to (&NTILDE). When decoding back from this, it is not possible to determine which "ntilde" it should be - "&Ntilde" or "&ntilde". Therefore, names that would have ambiguous meanings if in all-caps are left as is.
Trailing Character
Any items in this text field will be added to the end of every character as it is encoded or removed from the end of every character sequence as it is decoded. It is most commonly a semi-colon(;), but you can set it to whatever you want. Note, however, that certain characters may interfere with CAL9000's decoding process, causing strange results.
Delimiter
Any items in this text field will be added between the characters as they are encoded or removed from between every character sequence as it is decoded. It is most commonly a comma(,), but you can set it to whatever you want. Note, however, that certain characters may interfere with CAL9000's decoding process, causing strange results.
Include Unselected Text Checkbox
If this is checked, it allows you to encode/decode only part of the text and include the unselected text as part of the result in its original format. The most important thing to remember when using this feature is that you must have some of the text to be encoded/decoded selected. If not, you will get some strange results.
Base64 Filler Characters
Base64 Encoding/Decoding uses a 64-character array - made up of the characters A to Z, a to z, 0 to 9 plus two special characters. These last two characters are usually + and /, but you may run into instances when you want to use different special characters instead. Just overwrite the existing values in the text fields to change them. The padding character is usually the = sign, but you can change this value as well.

Encoding

Encoding with CAL9000 is easy. Just follow these steps:
Fill "Plain Text" textarea
Make sure that there is some text in the "Plain Text" textarea.
Make Selection
If you want to encode the entire contents of the textarea, it is a good idea to either click anywhere in the textarea or use the button to make sure that all of the text is included. If you only want to encode some of the text, select the portion you want (See the Selected Text help section for more information).
Choose Encoding Type
Click on the encoding type that you would like to use in the Select Encoding Type select box.
View Result
The encoded text should appear in the "Encoded Text" textarea.

Decoding

For decoding, it is pretty much the same drill:
Fill "Encoded Text" textarea
Make sure that there is some text in the "Encoded Text" textarea.
Make Selection
If you want to decode the entire contents of the textarea, it is a good idea to either click anywhere in the textarea or use the button to make sure that all of the text is included. If you only want to decode some of the text, select the portion you want (See the Selected Text help section for more information).
Choose Decoding Type
Click on the decoding type that you would like to use in the Select Decoding Type select box.
View Result
The decoded text should appear in the "Plain Text" textarea.

Wrappers

Another interesting Encode/Decode feature is the Wrapper. Wrappers are string combinations that are commonly used in XSS attacks (for example, Script Tags - <script>YourCodeGoesHere</script>).

To use a wrapper, there are three steps:
- First, select which wrapper that you would like to use from the Wrapper drop-down box.
- Then, select where you would like to apply the wrapper by choosing an option from the Apply drop-down box. You can apply or remove plain text wrappers to or from either the "Plain Text" or "Encoded Text" textareas.

Wrappers are applied to the entire textarea. The Wrappers that are provided are simple building blocks. You can nest multiple Wrappers for more sophisticated combinations. Also, you can add/edit/remove wrappers in the drop-downs.js file.


The "Plain Text" and "Encoded Text" textareas of the Encode/Decode function are eligible for Selected Text processing. See the Selected Text help section for more information.

The "Plain Text" and "Encoded Text" textareas of the Encode/Decode function are eligible for the Store/Restore feature. See the Store/Restore help section for more information.

Http Requests Help

CAL9000 includes the ability to manually craft and send HTTP requests to servers and receive the responses. See the RFC 2616 Cheatsheet for more information about server requests and responses.

schema://user:password@fqdn:port/Absolute/path/to/file;parameter?QStringName=QStringValue

HTTP Request User-editable Fields

The Requests that you send are comprised of the values in the following fields:
  1. Method - Drop-down box with the following HTTP Methods: GET, POST, HEAD, TRACE, TRACK, OPTIONS, CONNECT, PUT, DELETE, COPY, LOCK, MKCOL, MOVE, PROPFIND, PROPPATCH, SEARCH and UNLOCK.
  2. Authentication Type - Drop-down box with Authentication choices Basic and URL. CAL9000 will automatically insert the User and Password into the xmlHttpRequest or the URL, depending on the selection.
  3. Authentication User - Text field for the User information.
  4. Authentication Password - Text field for the Password information.
  5. Schema - Drop-down box with schema choices http://, https://, file:///, ftp://, ldap:// and ldaps://.
  6. FQDN (Hostname) - The first (sometimes only) part of the URL path. Includes everything up to the first single / in the path (e.g. www.cnn.com). With more complicated URLs, the slash and any remaining path info goes in the "Absolute Path of URL" field.
  7. Port - Port number to send the request to. Only need to specify in cases when it is not 80.
  8. Absolute Path of URL - See FQDN description above.
  9. Parameter Separator - URL indicator (usually ; / or |) that a Parameter follows. This is NOT the Query String Separator.
  10. URL Parameter - Mainly used for URL rewriting (e.g. sessionID). This is NOT the field for Query String parameters.
  11. URL Query String Separator - URL indicator (usually a ?) that a Query String follows.
  12. URL Query String - Name=Value pairs in the URL.
  13. HTTP Request Headers - The Headers for the request.
  14. HTTP Request Body - Name=Value pairs (POST) or file contents (PUT).
  15. Upload File - Enter the Absolute Path to the file you wish to upload. The file may reside on your local machine or a remote machine.
There are three things, at a minimum, that you need to define before you can send a Request.
  1. Method
  2. Schema
  3. FQDN (Hostname)

Request Header Features

CAL9000 makes it easy to add Request Headers. First, make a selection from the "Header Name" drop-down box. The "Header Value" drop-down box will then automatically populate itself with a list of common values for that Header. Select one of those values and the Header:Value pair will be added to the "HTTP Request Headers" textarea. Also, the textarea is editable, so you can put whatever Header information you want to in it directly.

Add Browser Headers - Adds all of the browser headers that are customarily included by the chosen browser (Firefox or IE).
Add Method Headers - Adds all of the browser headers that are customarily included when using the chosen method.

Important Note: CAL9000 clears out the Headers that are automatically supplied by the browser. Whatever Headers are present in the "HTTP Request Header" textarea are the ones that get sent with the Request. However, with the Firefox browser, it is not possible to remove or overwrite the value for the Host header.

Request Body Features

CAL9000 also makes it easy to add Name:Value parameter pairs to the Request. One way is to use the "Add Request Parameter" feature. Enter the Name and Value info into the respective text fields, then choose where to insert the pair with the "Add Parameter" drop-down box.

The "Request Body Actions" drop-down has several options:
  1. Split Name/Value Pairs - Often, when you are working with a Request Body that contains a bunch of Name/Value pairs, it can be confusing trying to keep everything straight. This option splits each pair onto it's own line.
  2. Concat Name/Value Pairs - This option concatenates the Name/Value pairs that you have split using the above option back into a single line for sending.
  3. Show Character Count - This option is useful in cases where you need to know the number of characters in the "HTTP Request Body". The result is displayed as a pop-up message in the CAL9000 banner.
As with "HTTP Request Header", the "HTTP Request Body" textarea is fully editable, so you can make changes directly if you wish.

Uploading Files

Uploading files with CAL9000 requires two steps. Before you can send the request (usually a PUT or POST), you'll have to Preload the file that you want to upload. Type in the path to the file-to-be-uploaded in the "Upload File" text field and hit the button. If successful, the contents of the file will be displayed in the "HTTP Request Body" textarea. Note that the upload file does not have to reside on your local machine.

Quick Encode

The Http Requests Page also includes the Quick Encode feature. Choose a field from the drop-down box and then choose which encoding to use. This will apply an encoding type (Url, Hex, Unicode, Base64 or MD5) to the selected text in the chosen field, or to all of the text in that field if nothing has been selected. The encodings are basic (no trailing chars, delimiters, etc).

Load AutoAttack Features

CAL9000 gives you the ability to send multiple Requests at one time. Say you have a Query String parameter that you want to try to exploit with some Injection attacks. Here is an example (ignore the URL encoding issues):

Manual Requests:
http://www.somesite.com/login.asp?password=0 or 1=1--
http://www.somesite.com/login.asp?password=' or 'x'='x
http://www.somesite.com/login.asp?password=' or 'x'='x'--

Instead of manually sending a Request for each attack, you can go to the AutoAttack List Editor page and create an Attack List (for this example, named InjectionAttacks) containing all of the attacks. Attack List items: 0 or 1=1--, ' or 'x'='x, ' or 'x'='x'--.

Back on the HTTP Requests page, choose the Attack List you wish to use from the "List" drop-down. The "Placeholder" text field will then automatically display the Placeholder value. Insert that value into the Request fields at all of the places where you want the Attack List value to be inserted.

Now, you only need to send one AutoAttack Request.

AutoAttack Request:
http://www.somesite.com/login.asp?password=[InjectionAttacks]

CAL9000 will iterate through the List and send a Request for each item, substituting the [Placeholder] value with each value in the List.

The total number of Requests sent for each AutoAttack will equal the number of items in the chosen Attack List. You can use AutoAttack substitutions for any user-editable fields in the Request. For now, only one Attack List may be used at a time.

Sending the Request(s)

To send a single Request, click on the button.
To send a multiple Request, click on the button.

If everything works correctly, a case will be saved in the History and a CaseID will be added for every Request to the "History" drop-down box. Clicking on a CaseID will display the Request info for that case on the HTTP Requests Page and the Response info on the HTTP Responses Page.

History Functions

When you send a Request via the HTTP Requests Page, the Request and Response information is saved to an XML file. Click on a CaseID in the "History" drop-down box to view the ReqResp information for that case. If you navigate over to the HTTP Responses Page, you will see the Response information for that case. If there is more than one Case listed in the drop-down, you can iterate through them by using the and buttons.
There are two History Action options: The History information is saved in the reqRespHistory.xml file.

Important Note: For obvious reasons, javascript was not originally intended to be able to save to disk. The process that CAL9000 uses to save/delete items in the XML files is rather cumbersome. In a nutshell, the program has to manually rebuild the entire XML file for every save/delete. For the smaller files, this is not a problem, but for the reqRespHistory.xml file, in particular, once the size of the file gets substantial (imagine 50 GET requests) it will peg the CPU and sit there for what seems like an eternity when you try to delete a case. Just keep this in mind when setting up your tests. You may want to break them down into manageable chunks or just delete cases yourself manually directly from the reqRespHistory.xml file.
--------------------------------------------------------------------

Examples

Here are some examples to give you an idea of what types of information goes in the various fields. Of course, there are many different ways to accomplish the same thing. Say we want to send this GET request that has some URL parameters:

http://www.somesite.com/pages/login.php?user=someuser&password=somepass

The Method would be: GET
The Schema would be: http://
The FQDN would be: www.somesite.com
The Absolute Path of URL would be: /pages/login.php
The URL Query Separator would be: ?
The URL Query String would be: user=someuser&password=somepass
The HTTP Request Headers could be:
    Host: www.somesite.com
    Connection: close
--------------------------------------------------------------------

Here is a similar example with POST:

http://www.somesite.com/pages/login.php

The Method would be: POST
The Schema would be: http://
The FQDN would be: www.somesite.com
The Absolute Path of URL would be: /pages/login.php
The HTTP Request Headers could be:
    Host: www.somesite.com
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Content-Length: 31
The HTTP Request Body could be:
    user=someuser&password=somepass
--------------------------------------------------------------------

The HEAD, TRACE and OPTIONS requests are pretty straightforward:

http://www.somesite.com/

The Method would be: HEAD, TRACE or OPTIONS
The Schema would be: http://
The FQDN would be: www.somesite.com
The Absolute Path of URL would be: /
The HTTP Request Headers would vary

Note regarding TRACE - Firefox does not currently support the TRACE function (via xmlHttpRequest). CAL9000 gets the TRACE info from a server-side script. Also, a reminder that any request directed at a resource (http://www.blah.com/index.html) is not necessarily going to generate the same response as one directed at a directory (http://www.blah.com/js/), even though they are on the same site.
--------------------------------------------------------------------

The PUT method requires two steps. Say you want to create an index.html file at 'somesite.com' with the contents of your file myindex.html. Before you can send the request, you'll have to Preload the file that you want to upload. Type in the path to the file-to-be-uploaded in the "Upload File" text field and hit the button. You should see a completion message to confirm the preload and the contents of the upload file will appear in the "HTTP Request Body" textarea. Note that the upload file does not have to reside on your local machine.

http://www.somesite.com/index.html

The Method would be: PUT
The Schema would be: http://
The FQDN would be: www.somesite.com
The Absolute Path of URL would be: /index.html
The HTTP Request Headers could be:
    Host: www.somesite.com
    Content-Type: multipart/form-data; charset=UTF-8
    Content-Length: 1984 (length of upload file contents)
The HTTP Request Body would be:
    (Contents of the upload file)

Once the preload is complete, you are ready to . The resource name that you use in the "Absolute Path of URL" field will be the name of the uploaded file on the target server. If there is no current resource on the server with that name, it will be created. If a resource with the same name exists on the server, it will be replaced by your file. Note - you may have issues uploading non-text-based files, as CAL9000 does not encode them as binary streams.
--------------------------------------------------------------------

Be careful with the DELETE method:

http://www.somesite.com/index.html

The Method would be: DELETE
The Schema would be: http://
The FQDN would be: www.somesite.com
The Absolute Path of URL would be: /index.html

In this example, the index.html file will be deleted. There is no "undo" so pay attention when you are using this. If you send a DELETE pointing to a directory and not a specific resource in a directory, that directory may be history!
--------------------------------------------------------------------


The textareas and text fields are eligible for Selected Text processing. See the Selected Text help section for more information.
Choose a field name from the "Clear" drop-down box to clear out one or more HTTP Requests Page fields.

Http Responses Help

The HTTP Responses Page displays the server responses to the requests that have been created and executed on the HTTP Requests Page.

The "Target URL" text field shows the request that generated this response. Clicking on the button will send a simple GET request with the "Target URL" value and populate the result fields, without having to go back to the HTTP Requests Page. Note that these results are not saved to the History file.
-------------------------------------------------------------------------

History Functions

The History functions operate the same way as on the HTTP Requests Page. Click on a CaseID in the "History" drop-down box to view the Response information for that case. If you navigate over to the HTTP Requests Page, you will see the Request information for that case. If there is more than one Case listed in the drop-down, you can iterate through them by using the and buttons.
There are two History Action options: The History information is saved in the reqRespHistory.xml file.

Important Note: For obvious reasons, javascript was not originally intended to be able to save to disk. The process that CAL9000 uses to save/delete items in the XML files is rather cumbersome. In a nutshell, the program has to manually rebuild the entire XML file for every save/delete. For the smaller files, this is not a problem, but for the reqRespHistory.xml file, in particular, once the size of the file gets up there (imagine 50 GET requests) it will peg the CPU and sit there for what seems like an eternity when you try to delete a case. Just keep this in mind when setting up your tests. You may want to break them down into manageable chunks or just delete cases yourself manually directly from the reqRespHistory.xml file.

Elements Processing


The Elements drop-down allows you to view the Scripts (within the Response Body source or remotely called), Forms and Cookies for the "Target URL". If there is more than one Script or Form listed in the elements textarea, you can iterate through the list by using the and buttons. The button will select all of the text currently in the Elements textarea. The button will remove the currently-displayed Script or Form from the list and also from the Response Body. This is useful when you are trying to use the feature, but the display gets hung up on an advertisement or something. These are NOT permanent changes. To display the original Response Body, click on that Case-ID from the "History" drop-down box.

The button will execute the contents of the Response Body textarea in a new window. Note that sometimes links in the page that rely on relative pathnames may not work correctly.
--------------------------------------------------------------------

The textareas and text fields are eligible for Selected Text processing. See the Selected Text help section for more information. Note, however, that Script source code that is displayed in a new window is not eligible. Use the standard cut and paste techniques instead.

Choose a field name from the "Clear" drop-down box to clear out one or more HTTP Responses Page fields.

Scratch Pad Help

The Scratchpad provides a convenient way for you to store notes, attack info, code snippets, test results, etc.

The button erases the text in the "Scratchpad" textarea.

The Scratchpad textarea is eligible for Selected Text processing. See the Selected Text help section for more information.

Cheat Sheets Help

The Cheat Sheets are a collection of primers on various languages and platforms that you may encounter while conducting web application security reviews. While not all-inclusive, they provide a handy way to check things like the syntax of a certain HTML tag or the usage of a particular advanced operator in Google™.

To view a cheat sheet, simply click on its respective button and the content will be displayed in the window. If the text is too small to read, try right-clicking and then opening the cheat sheet in its own window.

Misc Tools Help

The Miscellaneous Tools page has three different mini-tools on it. Scroogle Search is a privacy-friendly relay of Google™ search results. The IP Encoder/Decoder allows you to convert an IP address to/from its Dword, Hex or Octal equivalents. The String Generator allows you to create very long strings to expose an application's error handling or to do buffer overflow testing.

Scroogle Search

This graphic shows how Scroogle Search works:

Scroogle


To do a search on a particular search term, type it into the "Term" text field and click on the button. The Domain field defaults to *, which means All Domains. To limit the search, type the domain in the text field. Use the Advanced Operator options to further refine your search. For more information about Advanced Operators, check out the "Google" Cheat Sheet.

The button will clear out the Term and Advanced Operator text fields.

--------------------------------------------------------------------

IP Encoder/Decoder

The IP Encoder/Decoder allows you to evade IP address filtering or to help track down spammers or attackers that use alternate encodings to obfuscate their origin. Start by typing in an IP, Dword, Hex or Octal address in the appropriate text field. Then, press the corresponding button. This will display the address in each of the other encoding schemes. The Dword level is usually zero, but you can experiment with setting it to one.

The button will clear out all of the address text fields.

All IP Encoder/Decoder text fields are eligible for Selected Text processing. See the Selected Text help section for more information.

--------------------------------------------------------------------

String Generator

The String Generator allows you to easily create input strings of a specific length. First, type in the length of the string you want to create in the "String Length" text field.

Now, type in the character that you want to use in the "Character" text field. Once this is done, click on the button to create the string.

The button will clear out the text fields and the Result textarea.

The Result textarea is eligible for Selected Text processing. See the Selected Text help section for more information.

Testing Checklist Help

The Checklist page has two components - a Testing Tips list and a Web Application Security Testing Checklist.

Testing Tips

The Testing Tips list is a collection of security testing tips and techniques. Of course, this list is not complete. Use it as a baseline for the types of things that you might consider exploring while conducting a web application security review.

To view a Testing Tip, just click on a topic in the left-side list. The Tip Description and Examples/Actions information will then be displayed. The Testing Tip content is loaded in from the 'testTips.xml' file.

Testing Checklist

The Testing Checklist function gives you the ability to track the progress of your testing efforts and record your findings. The Checklist categories roughly correlate with the Manual Testing Techniques from the OWASP Testing Guide - click here for more details.

Click on a checklist item to display the Results/Notes for that item. The Checklist information is stored in the checklist.xml file. There are two sets of Editor functions. The first are Category-level:
The second set of Editor functions are Item-level:
The checklistOrig.xml file contains the original Checklist values, if you ever need to revert to them. This file can be found in the files/xml folder.


The textareas and text fields are eligible for Selected Text processing. See the Selected Text help section for more information.

Choose a field name from the "Clear" drop-down box to clear out one or more Testing Checklist Page fields.

AutoAttack Help

Use this function to build and maintain the AutoAttack Lists that are used to drive the automated multiple-request capabilities on the HTTP Requests Page.

Click on one of the AutoAttack List names in the "Attack Lists" drop-down to view the Items for that list. The details of each Item are displayed in the "Individual Item Display" textarea. Use the and buttons to iterate through the list Items.

The "Attack List Workarea" textarea holds the code snippets sent to this page via the Selected Text Action: Send To AutoAttack function.

There are two sets of Editor functions. The first are List-level:
The second set of Editor functions are Item-level:

Quick Encode

The AutoAttack List Editor also includes the Quick Encode feature. This will apply an encoding type (Url, Hex, Unicode, Base64 or MD5) to the selected text in the "Individual Item Display" textarea, or all of the text if nothing is selected. The encodings are basic (no trailing chars, delimiters, etc). The changes are not permanently applied to the Item until you click on the Item Editor option Save Item Changes.


The automatorOrig.xml file contains the original AutoAttack values, if you ever need to revert to them. This file can be found in the files/xml folder.

The textareas and text fields are eligible for Selected Text processing. See the Selected Text help section for more information.

Choose a field name from the "Clear" drop-down box to clear out one or more AutoAttack List Editor Page fields.

Save/Load State Help

The contents of textareas and text fields of CAL9000 can be saved permanently to disk via the button found in the banner at the top of the page. Note that the dynamically-created Script, Form or Cookies listings from the HTTP Responses function will not be saved. So now you don't have to worry if your testing session gets interrupted by something important, like lunch. There are no limits to the number of characters that can be saved - the data is stored in a file, not a cookie.

When you are ready to resume testing, just click on the button to repopulate the fields.

Note that every time you Save State, you overwrite the previous save. If you want to retain a particular session, go into the "saves" folder and rename the 'CAL9000.txt' file to something else.

Store/Restore Help

The and buttons are a handy way to temporarily hold the contents of some of the textareas, without having to resort to a full Save State. Say, for instance, if you want to try out some variations of an attack, but don't want to lose the initial attack text.

To Store the entire contents of an eligible textarea, click on the button to select all of the text (or just click somewhere in the textarea), then click on the button to Store the value. If you only want to Store part of the value, select (highlight) that portion and then click on the button.

To Restore the value, click on the button. The stored value will replace whatever is currently in the textarea.

To see what value is currently stored, just position the cursor over the or buttons. The value will appear in a window above the textarea. Note that the entire value may not be displayed in the window if it is beyond a certain length. Also, the displayed value is Decimal encoded (to prevent XSS issues), so you may see some strange characters at the end of a truncated value. When you Restore, however, the "true" value is restored.

Stored values are not retained as part of the "Save State" function.

Selected Text Processing Help

The Selected Text Processing features of CAL9000 give you a lot of control and flexibility. They tie all of the functions together and make it easy to pass information between them.

To use these features, you first need to select (highlight) some text. There are several ways to do this. Here are some examples:
Each browser seems to have it's own individual quirks when you try to select text. You may need to do some experimentation in order to find the techniques that work best for you.

OK, so now you have selected some text. So what can you do with it? CAL9000 gives you several options via the Selected Text Actions drop-down box:
Show Current Selection
Displays the currently selected text in an alert window.
Test In New Window
Attempts to execute the selected text in a new window. This works for small code snippets all the way up to entire web pages.
Send For RegEx Test
Copies the selected text to the "Code" textarea of the XSS Attacks function.
Send For Encoding
Copies the selected text to the "Plain Text" textarea of the Encode/Decode function.
Send For Decoding
Copies the selected text to the "Encoded Text" textarea of the Encode/Decode function.
Send To Request FQDN
Copies the selected text to the "FQDN (hostname)" text field of the HTTP Requests function.
Send To Request QString
Copies the selected text to the "URL Query String" text field of the HTTP Requests function.
Send To Request Header
Copies the selected text to the "HTTP Request Headers" textarea of the HTTP Requests function.
Send To Request Body
Copies the selected text to the "HTTP Request Body" textarea of the HTTP Requests function.
Send To ScratchPad
Copies the selected text to the "Scratchpad" textarea of the Scratch Pad function.
Send To IP Encoder
Copies the selected text to the "IP Address" text field of the Misc Tools function.
Send To AutoAttack
Copies the selected text to the "Attack List Workarea" textarea of the AutoAttack function.
Clear Current Selection
Clears out the current Selected Text value.
Delete Current Selection
Deletes the current Selected Text from the field where you selected it.

You may have noticed an additional drop-down box next to the Selected Text Actions drop-down. These are the options that you have when you select an action that copies selected text to another textarea or text field.
Append
Adds the Selected Text to the end of the existing text in the target field.
Prepend
Adds the Selected Text to the beginning of the existing text in the target field.
Replace
Replaces the contents of the target field with the Selected Text.
Word of warning: Make sure to set this BEFORE you select one of the copying actions. Actions are executed as soon as an action is selected from the Selected Text Actions drop-down.

OWASP

The Open Web Application Security Project (OWASP) is a not-for-profit charitable organization dedicated to finding and fighting the causes of insecure software. All of the OWASP tools, documents, forums and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process and technology problem because the most effective approaches to application security include improvements in all of these areas.

Everyone is welcome to participate in our forums, projects, chapters and conferences. OWASP is a fantastic place to learn about application security, to network and even to build your reputation as an expert.

If you find the OWASP materials valuable, please consider supporting our cause by becoming an OWASP member. All monies received by the OWASP Foundation go directly into supporting OWASP projects.

CAL9000 is an OWASP tool and has been selected for sponsorship in the 2006 Autumn of Code.