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
Difference between revisions of "Tiger User Manual"
Line 46: | Line 46: | ||
* Select the target to add a test to and, from the '''Project''' menu, select '''Add Test'''. | * Select the target to add a test to and, from the '''Project''' menu, select '''Add Test'''. | ||
* Right-click on the target in the Project Explorer and select '''Add Test''' from the shortcut menu. | * Right-click on the target in the Project Explorer and select '''Add Test''' from the shortcut menu. | ||
+ | ===Configuring a Test=== | ||
+ | ====Relative Path==== | ||
+ | The scheme, host, port and virtual path parts of the virtual directory are defined by the target containing that particular test. The other parts of the test URL (namely, the file name, query and fragment) can be, if needed, supplied by the test itself, using its '''Relative Path''' property. Supplying a value for that property, however, is not mandatory (this allows you test the default document of the target’s virtual directory). | ||
+ | |||
+ | This division of the URL parts between the target and test objects may seem awkward at first, but it allows you to redirect execution of a bunch of tests to a different server (or virtual directory) just by changing one property value (specifically, the '''Path''' property of the Target object). | ||
+ | ====Method==== | ||
+ | Tests can be invoked using the standard GET or POST HTTP methods. You can define which one to use via the '''Method''' property. The default is GET. | ||
+ | ====Parameters==== | ||
+ | Tiger supports passing parameters to tests. Basically, a parameter is a pair of strings where the first value in the pair represents the name of the parameter, and the other represents the actual value to be passed. | ||
+ | |||
+ | How the parameters are ultimately passed to the test is determined by the value of the '''Method''' property. | ||
+ | ====Alerts==== | ||
+ | After a test has finished executing, its response is matched against a set of conditions. If one of these condition is met, an alert is generated. Alerts notify the user that something is wrong (although nothing prevents you from defining alerts to be generated when something is right) with the web site or application being tested. | ||
+ | |||
+ | Each alert is defined by its alert condition, message and type. More info on alerts is provided in the [[#Managing Alerts section]]. |
Revision as of 00:16, 5 February 2007
Managing Projects
What is a Tiger Project?
Tiger project is a logical grouping of test targets and tests to be performed as a whole. Each Tiger project consists of zero or more targets, each containing zero or more tests (although projects without any targets and tests are not very meaningful).
Starting a New Project
A blank project is created automatically when you start Tiger. If you need to create a project based on a project template, or simply another blank project, do this:
- To create a project based on a project template, from the File menu, select New.
- To create a blank project, click the New button on the toolbar, or press Ctrl+N. Alternatively, from the File menu, select New and choose the "Blank Project" template.
Opening an Existing Project
To open an existing project, either
- Click the Open toolbar button, or
- From the File menu, select Open
Tiger projects have the .tgp file extension.
Saving Your Project
To save your project, either
- Click the Save toolbar button, or
- From the File menu, select Save (to save the project using its current file name and location) or Save As (to save the project under a new name and/or at a new location)
Saving Your Project as a Project Template
You can also save your project as a template. That way, you and other users can quickly create new projects based on your project. After your template is imported (currently, there is no GUI for this, just place your .tgpt file in the Project Templates subfolder), it will appear in the New Project dialog (displayed when you select New from the File menu, or press Ctrl+N) and new projects can easily be created based on it.
Note: Typically, users will want to run the same tests, but not on the same servers as you did in your project, so it’s a good idea to clear the Path properties of your project targets before saving the project as a template.
Tiger currently ships with the Tiger ASP.NET Module template, which contains tests for some well known ASP.NET 2.0 vulnerabilites.
Managing Targets
What is a Tiger Target?
Tiger target is a web site or virtual directory upon which tests are to be performed. Each target contains zero or more tests to be performed. Essentially, target is defined by its path (a http or https prefixed URL, without the document name, query and fragment. If needed, all of those can be provided at the test level).
Each project can contain multiple targets, and each target can contain multiple tests.
Adding a Target
You can add targets to your project by
- Selecting Add Target from the Project menu
- Right-clicking the project node in the Project Explorer, and selecting Add Target from the shortcut menu that appears.
Configuring a Target
Path
The Path property of the target object must be set to a valid http or https scheme URL of the web site or virtual directory containing tests to be executed. Otherwise, you won’t be able to run the project.
Additionally, the Tests collection should contain one or more Test objects. Although technically possible, creating a target with no associated tests does not make much sense (unless, of course, you plan to add tests later).
Deleting a Target
To delete a target from your project, right-click on it in the Project Explorer window. Then select Delete from the shortcut menu. After you confirm the deletion, the target (along with all the tests it contained) is gone.
Managing Tests
What is a Tiger Test?
Tiger test is a web page or service that is to be called during the execution of a project, using the supplied parameters and specified HTTP method. The outcome of that call is later evaluated by a set of various conditions. If those conditions are met, they generate alerts (essentially signals that something is wrong). Generation of such alerts is the ultimate goal of running any Tiger project.
Each test is associated with a target, which defines the scheme, host, port and virtual path parts of the virtual directory that contains that particular test. (Please note that Tiger supports only the http and https schemes.)
Adding a Test
To add a new test to your project (or, more precisely, target), do one of the following:
- Select the target to add a test to and, from the Project menu, select Add Test.
- Right-click on the target in the Project Explorer and select Add Test from the shortcut menu.
Configuring a Test
Relative Path
The scheme, host, port and virtual path parts of the virtual directory are defined by the target containing that particular test. The other parts of the test URL (namely, the file name, query and fragment) can be, if needed, supplied by the test itself, using its Relative Path property. Supplying a value for that property, however, is not mandatory (this allows you test the default document of the target’s virtual directory).
This division of the URL parts between the target and test objects may seem awkward at first, but it allows you to redirect execution of a bunch of tests to a different server (or virtual directory) just by changing one property value (specifically, the Path property of the Target object).
Method
Tests can be invoked using the standard GET or POST HTTP methods. You can define which one to use via the Method property. The default is GET.
Parameters
Tiger supports passing parameters to tests. Basically, a parameter is a pair of strings where the first value in the pair represents the name of the parameter, and the other represents the actual value to be passed.
How the parameters are ultimately passed to the test is determined by the value of the Method property.
Alerts
After a test has finished executing, its response is matched against a set of conditions. If one of these condition is met, an alert is generated. Alerts notify the user that something is wrong (although nothing prevents you from defining alerts to be generated when something is right) with the web site or application being tested.
Each alert is defined by its alert condition, message and type. More info on alerts is provided in the #Managing Alerts section.