Thursday, April 29, 2010

WebScarab


              WebScarab.                            
 
WebScarab is a Web Application Review tool. The aim of WebScarab is to provide a free (beer as well as speech) tool for web application developers and reviewers to use to understand the functioning of web applications, and to identify possible problems that could cause those web applications to malfunction. WebScarab is an OWASP project tool.
WebScarab is basically a framework for running plugins. It provides a foundation for the plugins to generate requests and responses (aka conversations), keep an audit record of these conversations, and review what those conversations were, as well as a tree view of the URL's that have been "seen".
Other services that the framework itself provides are handling of upstream proxy servers, client side certificates, a pool of cookies that have been seen or set by various plugins, and a convenient way to perform various encodings and decoding of strings.
Current plug-ins include are
Ø       Proxy: It is possible to write proxy plugins that perform various modifications to the requests and responses in transit through the proxy
Ø       Manual Request: The Manual Request plugin allows the user to handcraft a reuest to be sent to the server. It is also possible to replay a previous request by selecting it from the drop down selection box. Previous requests which are loaded into the editor can also be edited before being sent to the server
Ø       Spider: The Spider plugin analyses responses to identify any links in the response body, or the "Location" header. If the URL represented has not been seen, the URL is added to a tree, and can be automatically downloaded when desired. WebScarab has two modes of fetching unseen links. "Fetch Tree" enumerates all currently unknown links below the selected node, and queues them for retrieval. "Fetch Selection" queues only the selected nodes for retrieval.
Ø       SessionID Analysis: Session ID Analysis is useful to determine how easy it is for an attacker to brute force a victim's sessionid, and take it over, and the possible ways of displaying in graph represent model.
Ø       Scripted: This plugin is intended to give users the ability to create test scripts, using the facilities of Webscarab.
Ø       Fragments: The fragments plugin parses HTML responses, and looks for scripts and comments. These can be interesting, first to see if there are any hidden links, or other debugging code, and also to understand how the pages are supposed to operate.
Ø       Compare: The Compare plugin allows the user to judge the degree of difference between a number of responses. This is useful when you have issued a number of requests for a particular URL, possibly via the Scripted plugin, and would like to evaluate the results. Obviously, if you can eliminate groups of identical responses at once, you can save yourself some time
Ø       Fuzzer: The fuzzer basically allows you to throw a combination of values at a server. It is still a little rough, but functionally, it works pretty well. The idea is that you configure the request method, the basic URL (without any parameters), the request version, any headers (e.g. a Host: header if you are using HTTP/1.1, etc. Don't configure cookies here!), and a list of Parameters. A Parameter is defined by its location (Path, Fragment, Query, Cookie, Body), its name (ignored for Path), type == String, Default value, Fuzz Priority, and a fuzz source.An example would be if you had a list of usernames and passwords. If both username and password parameters had the same priority, usernames and passwords would be consumed in lock-step. If they had different priorities, EVERY password would be tried for each username.
Ø       Search: The search plugin allows you to execute arbitrary beanshell scripts to identify "interesting" conversations. You are provided with the request, response, and origin (originating plugin) of the conversation, and can use the class methods to return a true or false value. A true value indicates an interesting conversation that should be displayed, and a false value indicates that the conversation should not be displayed.
Ø       XSS/CRSF: It reviews the possibility urls for the type of Vulnerability.

Procedure to run the WebScarab proxy tool using SITE
                                      www.testfire.net
For case -1 Task
Step 1:
You can use the fuzzer in WebScarab to fuzz POST or GET request parameters. In this example, we'll look at fuzzing a simple POST request. The following screenshot-1 shows the page in www.testfire.net that we'll be using for this example:
Step 2:
The top portion of the WebScarab screen shows our request. In the middle pane you can see the search parameter, called "Username",Password”,”id’s” for some reason is being submitted with a value of "lesson".

From the Summary tab in WebScarab, we can right-click on this particular POST request and select "Use as fuzz template" as you can see in the next screenshot-2:
Step 3:
Once you've selected the "Use as fuzz template" option, switch over to the Fuzzer tab in WebScarab. In the Fuzzer tab, you'll see you can fuzz more than just the POST parameters. Take a look at the next screen shot-3 to see what I'm talking about:

Step 4: Notice we can fuzz cookies, GET and POST parameters. For this example, we're going to try the Username parameter. The first thing to do is pick our fuzzing Source. We do this by clicking the "Sources" button which brings up the following window screen shot-4:
Step 5: Notice you can select a file, or enter a regular expression as fuzz sources. Using regular expressions is great for instances when you've got a numeric ID in an input and you want to try a range of other values. Say for instance you submitted a page in the app you're testing and you saw a UID=0013301 in the request. You could create a RegEx entry of [0-9][0-9][0-9][0-9][0-9][0-9][0-9], give it a description (i.e. "0000000 - 9999999"), click Add, then Close and use that regular expression to submit requests to the web server using all possible seven digit UID values. Yes, that's going to take some time. And the same possible of using password txt files and user names and id list txt files was upload as shown in  the screen shot-5:
Step 6: After selecting the fuzz source, click the Start button on at the bottom of the window and WebScarb will start POSTing using your regular expressions or lines from your file as inputs. Yes, you can fuzz more than one field at a time, you can also set the priority so that you can different fuzz inputs for different fields and you can specify multiple sources.

What you won't see in WebScarab, is the response back from the server. For that, specify a save location for your WebScarab session data, open a terminal window in the "conversations" directory where the request and response data is saved and start parsing through the requests and responses using your favorite tools and techniques (grep is your friend) to see what inputs have what effect on the responses from the server. One quick way to isolate these is to look at file sizes for the responses. If you see big variations, you may have something interesting going on.

Sometimes WebScarab gets confused about the number of items it needs to fuzz. For example, the All_attack.txt file contains 362 lines as of this writing. But sometimes the fuzz template will submit a single request and quit. When that happens, reset the fuzz source in the drop down window for that parameter, click in the parameter field and then reselect the fuzz source. I've found that usually fixes the problem
.






Screen shot-1


    Screen-shot-2

   Screen-shot-3                                                                     

Screen-shot-4



No comments:

Post a Comment