OWASP - User contributions [en]

How to modify proxied conversations

2006-08-09T13:06:19Z

Rdawes: Show how to use Proxy scripts

== Objective ==

To make repetitive modifications to either requests or responses (or both) as they pass through the proxy

== Approach ==

Write a script to make the modifications as desired. Scripts can be written in the Proxy->BeanShell plugin, or attached to Hooks in the ScriptManager interface. Depending on which you choose, the script itself changes a little.

== What methods exist to manipulate the request and response? ==

The request and response are instances of the Request and Response classes, respectively. These classes both extend the Message class which provides functionality common to both.

The Message class provides the following methods, which are common to both the Request and Response classes:
String[] getHeaderNames()
String getHeader(String name)
void setHeader(String name, String value)
void addHeader(String name, String value)
void deleteHeader(String name)
NamedValue[] getHeaders()
void setheaders(NamedValue[] headers)
byte[] getContent()
void setContent(byte[] content)

The Request class adds the following methods:
String getMethod()
void setMethod(String method)
HttpUrl getURL()
void setURL(HttpUrl url)
void setURL(String url) throws MalformedURLException
String getVersion()
void setVersion(String version)

The Response class adds the following methods:
String getVersion();
void setVersion(String version);
String getStatus();
void getStatus(String status);
String getMessage();
void setMessage(String message);
String getStatusLine();

== Using the Proxy->BeanShell plugin ==

The Proxy->BeanShell plugin comes supplied with a very simple script to show you how to get access to the request and response objects. Unfortunately, it doesn't provide much assistance on how to go forward from there. Here is an example, showing you how to reject all requests for Flash content:

import org.owasp.webscarab.model.HttpUrl;
import org.owasp.webscarab.model.Request;
import org.owasp.webscarab.model.Response;
import org.owasp.webscarab.httpclient.HTTPClient;
import java.io.IOException;

public Response fetchResponse(HTTPClient nextPlugin, Request request) throws IOException {
HttpUrl url = request.getURL();
if (url.toString().endsWith(".swf"))
throw new IOException("No flash content allowed");
response = nextPlugin.fetchResponse(request);
return response;
}

Here's an example showing how to replace a particular string in a JavaScript response:

import org.owasp.webscarab.model.Request;
import org.owasp.webscarab.model.Response;
import org.owasp.webscarab.httpclient.HTTPClient;
import java.io.IOException;

public Response fetchResponse(HTTPClient nextPlugin, Request request) throws IOException {
response = nextPlugin.fetchResponse(request);
String cType = response.getHeader("Content-Type");
if (cType != null && cType.endsWith("javascript")) {
byte[] bytes = response.getContent();
if (bytes != null) {
String content = new String(bytes);
content = content.replace("my search string", "my replacement");
response.setContent(content.getBytes());
}
}
return response;
}

== So, what's with the ScriptManager? ==

The ScriptManager is intended to provide a more generic interface to scripting throughout WebScarab. Each plugin can provide Hooks that can have scripts attached to them. Each Hook provides a brief explanation of how to use it. The Proxy provides 3 hooks:

* Allow Connection

Called when a new connection is received from a browser
Use connection.getAddress() and connection.closeConnection() to decide and react

This hook is intended to provide a measure of security in installations where WebScarab is allowing connections from non-localhost interfaces. Here is an example of how it may be used:

import java.net.InetAddress;

InetAddress from = connection.getAddress();
if (! from.getHostAddress().startsWith("192.168.1."))
connection.closeConnection();

This script rejects all connections from hosts outside the 192.168.1 subnet.

* Intercept Request

Called when a new request has been submitted by the browser
Use connection.getRequest() and connection.setRequest(request) to perform changes

Here is an example, corresponding to the one shown above:

import org.owasp.webscarab.model.Request;
import org.owasp.webscarab.model.HttpUrl;

Request request = connection.getRequest();
HttpUrl url = request.getURL();
if (url.toString().endsWith(".swf"))
throw new IOException("No flash content allowed");

* Intercept Response

Called when the request has been submitted to the server, and the response has been received.
Use connection.getResponse() and connection.setResponse(response) to perform changes

Here is an example, again corresponding to the one shown above:

import org.owasp.webscarab.model.Response;

Response response = connection.getResponse();
String cType = response.getHeader("Content-Type");
if (cType != null && cType.endsWith("javascript")) {
byte[] bytes = response.getContent();
if (bytes != null) {
String content = new String(bytes);
content = content.replace("my search string", "my replacement");
response.setContent(content.getBytes());
connection.setResponse(response);
}
}

Note that to actually make your changes take effect, you have to call setResponse(response), since the object you have been modifying is only a copy, not the actual response object.

[[Category:How To]]
[[Category:OWASP WebScarab Project]]
[[Category:Session Management]]
[[Category:OWASP Testing Project]]

Fuzzing with WebScarab

2006-07-04T10:01:47Z

Rdawes:

This document is intended to explain how to use the WebScarab Fuzzer plugin.

I assume that you are familiar with the basic functionality of WebScarab, and have managed to use it as a proxy to view and intercept some conversations already. If not, I suggest reading the [ WebScarab Getting Started | "Getting Started" ] gocument first.

==Overview==

The Fuzzer plugin is intended to simplify or automate repetitive testing of a web site. In essence, what the fuzzer does is sequentially try each one of a list of values replacing some user-specified parameters in a request that is then sent to the server. The response is then saved into the Summary, where it can be manually reviewed.

The first thing to understand is how the Fuzzer defines a parameter. A parameter is a portion of the request that is considered when creating the response:

* A parameter may be found as part of the path, as is commonly seen in a Wiki. For example it is common to see something like "http://example.com/index.php/Some_Topic". In this case, the string "Some_Topic" is a "Path parameter"

* A parameter may also be found as a "fragment", appended to the path with a semi-colon, before the query portion of the URL. For example, it is common to find session ids in a URL, like "http://example.com/index.php;PHPSESSIONID=some_hex_string"

* A parameter can commonly be found as an URL Query parameter, collected as Name/Value pairs following a "?" in the URL, separated by ampersands, as in "http://example.com/index.php?title=Some_Topic&action=edit", which illustrates 2 query parameters: "title" and "action"

* A parameter may also be found in a Cookie. Of course, cookies are most commonly used to track session state, and fuzzing a cookie is often pointless. However, if data is stored in the cookie, fuzzing it may give promising results, as it is a less commonly tested aspect of a site.

* A parameter may also be found in the body/content portion of a request, typically when the request is sent as a POST. Parameters are most commonly formatted using the same scheme as for encoding URL Query parameters. Of course, POST parameters may be formatted using any scheme supported by the server. WebScarab can currently only support POST's with a Content-Type of "application/x-www-form-urlencoded".

==Using the fuzzer==

The fuzzer interface allows a knowledgeable user to construct a new request, specifying the method, basic URL (excluding any path parameters, fragments or query parameters), the request version, any request headers, and the required parameters. Unfortunately, this is rather a tedious and error-prone way of constructing a request to fuzz.

Fortunately, there is a much easier way! Once you have used the proxy for a bit, got to the Summary View, and find a conversation that has parameters that you would like to fuzz. Then right-click on that conversation, and select "Use as fuzz template". This will identify all of the parameters in the request (other than path parameters, which are not possible to identify automatically), and copy all of the relevant information to the Fuzzer plugin interface. If you wish to, you can make any modifications you want at this point, for example, adding or deleting some headers, adding or removing parameters, etc.

Once you have defined the basic structure of the request, you need to define the fuzz sources. A "fuzz source" is a list of alternative inputs to be used a values for one or more parameters. In most cases, you will create a file containing one value per line. If you installed WebScarab using the "installer" version, you should also find two files "xss.txt" and "sql.txt" in the directory in which you installed it. These two files contain a collection of Cross Site Scripting and Sql Injection strings respectively, which may trigger errors in the application you are testing.

Define available fuzz sources by selecting the "Sources" button in the Fuzzer interface. In the dialog, type in a description of the Fuzz source. e.g. for the xss.txt file, type XSS (case is not important). Then use the "browse" button to locate the file containing the strings you wish to use, or type the filename in the "File" field. Once the file has been chosen, click "Add". WebScarab will read the file, and add each item to the list identified by the description you supplied. You can check to see if they were properly read in by clicking on the item in the list on the left hand side. You should see the fuzz strings displayed 1 per line, and the "Items" label should show how many strings were read in.

You can also define a list of strings to use, using a reduced regular expression syntax. By reduced, I mean that the syntax elements that allow for an infinitely large set to be defined is not permitted. For example, the "." character defines 65536 possible characters, and is disallowed. Similarly, the * and + operators allow an indefinite number of characters, and are also disallowed. Finally, the character count syntax that allows a variable number of characters "{3,5}" is also disallowed. This is useful if you wish to attempt to brute force something like a document identifier, that obeys a regular pattern.

Once you have defined your fuzz sources, close the dialog, and return to the main Fuzzer interface.

It would probably be a good idea to explain what each of the columns in the "Parameters" table represent at this point:

* The Location column represents where the parameter is found. The location can be one of "Path", "Fragment", "Query", "Cookie" or "Body", as explained above.

* The Name column represents the name of the parameter.

* The Value column is for the default value of that parameter, if that parameter is not being fuzzed.

* The Priority column allows the user to control how the various fuzz sources increment. Fuzz sources at the same priority increment in lock step. Fuzz sources at different priorities increment sequentially. For example, if you had a list of known usernames and matching passwords, you would use a username source and a password source with the same priority. However, if you wanted to try each of the usernames with each of the passwords, you would use sources with different priorities.

* The Fuzz Source column allows the user to control which parameters will be fuzzed, and which list of fuzz strings will be used.

Now you can instruct the Fuzzer on which fuzz sources to use for each parameter. The "Fuzz Source" column is editable using a combo box, and you can selected from the defined fuzz sources, or an empty item if you do not want to fuzz that parameter.

As you change the various parameters to be fuzzed, and possibly modify the priorities of the parameters, you should notice the "Total Requests" field updating. If your fuzzed parameters are all at the same priority, the "Total Requests" field will reflect the size of the smallest Fuzz Source. If the fuzzed parameters are at different priorities, the "Total Requests" field will show the product of the sizes of the various Fuzz Sources.

==Running the fuzzer==

When you hit the Start button, you'll see the "Current Request" field incrementing, and conversations appearing in the table in the bottom half of the screen, until the "Current Request" field shows one less than the "Total Requests" field. (Yes, this is a bug that should be fixed.) If there are any errors detected while executing the fuzzer, the fuzzer plugin will pause. As long as you do not make any changes to the fuzzer setup, you can resume fuzzing where you left off. (This may or may not be a good idea, depending on the nature of the error)

Once the fuzzer is finished, you can review the resulting conversations by double-clicking on the rows in the Conversation Table in the lower half of the screen, and stepping through the list. Alternatively, you can review them from the Summary pane, at any time. Note that rerunning the fuzzer will clear the table in the Fuzzer, but will not change the conversations already in the Summary.

==Limitations==

The Fuzzer is not able to fuzz "compound requests". For example, when submitting values to a function results in a frameset description, and the real interesting result shows up in one of the child frames, WebScarab will not try to retrieve the child frame. For more complex fuzzing, I'd suggest investigating the Scripting plugin.

WebScarab Getting Started

2006-06-27T13:51:35Z

Rdawes: WebScarab Tutorial moved to WebScarab Getting Started: Not planning to do a complete tutorial in this document.

'''WebScarab''' has a large amount of functionality, and as such can be quite intimidating to the new user. But, for the simplest case, intercepting and modifying requests and responses between a browser and HTTP/S server, there is not a lot that needs to be learned.

Initially, I will assume that you have full unrestricted access to the Internet (that is, you are not behind a proxy). I will explain more complicated scenarios later in this tutorial. For the sake of simplicity, Iwill also assume that you are using Internet Explorer.

[[Image:WebScarab_startup.png]]

This is what WebScarab looks like at startup. There are a few major areas that might need explanation.

Firstly, the toolbar provides access to the various plugins, as well as the Summary window (main view), and messages (log) window.

The Summary window is split into two parts. On the top is a tree table which will show the layout of the sites that you have visited, and some attributes of the various URLs. Below that is a table showing all of the conversations that have been seen by WebScarab, normally sorted in reverse by ID, so that more recent conversations are at the top of the table. The sort order can be changed by clicking in the column headers if desired.

In order to start using WebScarab as a proxy, you need to configure your browser to use WebScarab as a proxy. This is configured in IE using the Tools menu. Select Tools -> Internet Options -> Connections -> LAN Settings to get the proxy configuration dialog.

[[Image:IE Proxy.PNG]]

WebScarab defaults to using port 8008 on localhost for its proxy. You need to configure IE to relay requests to WebScarab, rather than fetching them itself, as shown in the above image. Make sure that all checkboxes are unchecked, except for "Use a proxy server". Once you have configured IE to use the proxy, select Ok on all dialogs to get back to the browser. Browse to a non-SSL website, and then switch to WebScarab.

You should see something similar to the next image. If you don't, or you get an error while browsing, you should go back and check your proxy settings in Internet Explorer as described above. If the proxy settings are correct, one possibility is that there is already another program that is using port 8008, and preventing WebScarab from using it. If so, you should stop that other program. I will also show you how to tell WebScarab how to use a different port a bit later.

[[Image:WebScarab after browsing.png]]

Here you can see the tree of URL's, which represents the site layout, as well as the individual conversations that have passed through WebScarab. To see the details of a particular conversation, you can double-click on a row in the table, and a window showing the request and the details of the response will open. You can see the request and response in a variety of forms. The view shown here is the "Parsed" view, where the headers are broken out into a table, and the request or response content is presented according to its Content-Type header. You can also choose the "Raw" format, where the request or response is presented exactly as it would be seen on the wire.

[[Image:WebScarab conversation.png]]

You can step from one conversation (request/response) to the next in the conversation window using the "previous" and "next" buttons, as well as jumping directly to a particular conversation using the drop down combo box.

Now that you are familiar with the basic workings of WebScarab, and have made sure that your browser is correctly configured, the next step is to intercept some requests, and modify them before they are sent to the server.

You enable proxy intercepts via the Proxy plugin, accessible via the "Proxy" button on the toolbar. Then choose the "Manual Edit" tab. Once you click the "Intercept Requests" checkbox, you can choose which request methods you wish to intercept (most commonly GET or POST), and can even choose multiple methods using "Ctrl-click". Select "GET" for the moment.

[[Image:Webscarab configure intercept.png]]

Now go back to your browser, and click on a link. You should see something like the following window appear (it may only flash in the task bar initially, just select it. Future windows will pop-up properly).

[[Image:WebScarab intercept request.png]]

You can now edit any part of the request you choose. Note that the headers are shown already URL-decoded, and anything that you type in will be URL-encoded automatically. If you do not want this to happen, you should use the Raw mode. In some cases, using the Raw mode may be the easiest anyway, especially if you have something that you wish to paste in.

Once you are happy with your changes, click on the '''"Accept changes"''' button to allow the modified request to be sent to the server. If you decide that you wish to revert the changes that you have made so far, you can click on the '''"Cancel changes"''' button to allow the original request to be sent to the server. You can also click on the '''"Abort request"''' button if you don't want to send a request to the server at all. This will send an error back to the browser. Finally, if there are multiple intercept windows opened (e.g the browser is using several threads simultaneously), you can release all the requests using the '''"Cancel ALL intercepts"''' button.

WebScarab will continue to intercept all requests that match the method you specified until you uncheck the "Intercept requests" checkbox, either in the '''intercept conversation''' window, or in the '''"Manual Edit"''' tab of the '''Proxy''' plugin. But you may be wondering why WebScarab does not intercept requests for images, stylesheets, javascript, etc. If you go back to the '''"Manual Edit"''' tab, you will see a field labeled "Exclude paths matching:". This field contains a regular expression which is matched against the request URL. If there is a match, the request is never intercepted.

You can also configure WebScarab to intercept responses, in case you want to change the behaviour of some parts of the page. For example, you can disable JavaScript validation, change the list of possible items in a '''SELECT''' field, etc.

[[Category:How To]]
[[Category:OWASP WebScarab Project]]

WebScarab Tutorial

2006-06-27T13:51:35Z

Rdawes: WebScarab Tutorial moved to WebScarab Getting Started: Not planning to do a complete tutorial in this document.

#REDIRECT [[WebScarab Getting Started]]

WebScarab Getting Started

2006-06-26T08:00:06Z

Rdawes:

File:WebScarab intercept request.png

2006-06-26T07:41:17Z

Rdawes:

File:Webscarab configure intercept.png

2006-06-26T07:33:23Z

Rdawes:

WebScarab Getting Started

2006-06-23T14:20:50Z

Rdawes:

File:WebScarab conversation.png

2006-06-23T13:52:15Z

Rdawes: Showing a conversation window

Showing a conversation window

File:WebScarab after browsing.png

2006-06-23T13:41:56Z

Rdawes: Screenshot of WebScarab after some browsing

Screenshot of WebScarab after some browsing

File:IE Proxy.PNG

2006-06-23T13:34:46Z

Rdawes: Internet Explorer proxy settings

Internet Explorer proxy settings

File:WebScarab startup.png

2006-06-23T13:13:53Z

Rdawes: Screenshot showing WebScarab at startup

Screenshot showing WebScarab at startup

Category:OWASP WebScarab Project

2006-06-23T13:08:03Z

Rdawes:

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the subscription page, and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

You can download WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge].

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyses a number of cookies (and eventually URL-based parameters too) to visually determine the degree of randomness and unpredictability.

* Scripted - operators can use BeanShell to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server.

==Future development==

Features will probably include:

* Enhancing the SOAP plugin, improving support for complex schemas, and different encodings

* Combining the Search and Compare plugins, so that you can compare only specific responses

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes of Aspect Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]

Category:OWASP WebScarab Project

2006-06-23T11:45:45Z

Rdawes:

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the subscription page, and enjoy! You can read a brief tutorial [[WebScarab Tutorial | here]].

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

You can download WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge].

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyses a number of cookies (and eventually URL-based parameters too) to visually determine the degree of randomness and unpredictability.

* Scripted - operators can use BeanShell to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server.

==Future development==

Features will probably include:

* Enhancing the SOAP plugin, improving support for complex schemas, and different encodings

* Combining the Search and Compare plugins, so that you can compare only specific responses

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes of Aspect Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]

User:Rdawes

2006-06-23T11:33:48Z

Rdawes:

Rogan Dawes is a security consultant, employed by Aspect Security. He is also the author of WebScarab.