Screen shots for webscarab tool

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

Web Application Vulnerability Scanners

Web Application Vulnerability Scanners are tools designed to automatically scan web applications for potential vulnerabilities. These tools differ from general vulnerability assessment tools in that they do not perform a broad range of checks on a myriad of software and hardware. Instead, they perform other check, such as potential field manipulation and cookie poisoning, which allows a more focused assessment of web applications by exposing vulnerabilities of which standard VA (Vulnerability Assessment) tools are unaware.
Web Applications Issues
• Scripting issues
• Sources of input: forms, text boxes, dialog windows, etc.
• Multiple Charset Encodings (UTF-8, ISO-8859-15, UTF-7, etc.)
• Regular expression checks
• Header integrity (e.g. Multiple HTTP Content Length, HTTP Response Splitting)
• Session handling/fixation
• Cookies
• Framework vulnerabities (Java Server Pages, .NET, Ruby On Rails, Django, etc.)
• Success control: front door, back door vulnerability assessment
• Penetration attempts versus failures
Technical vulnerabilities
 Invalidated input:
 Tainted parameters - Parameters users in URLs, HTTP headers, and forms are often used to control and validate access to sensitive information and Tainted data.



 Cross-Site Scripting flaws:
 XSS takes advantage of a vulnerable web site to attack clients who visit that web site. The most frequent goal is to steal the credentials of users who visit the site.
 Content Injection flaws:
 Data injection
 SQL injection - SQL injection allows commands to be executed directly against the database, allowing disclosure and modification of data in the database
 XPath injection - XPath injection allows attacker to manipulate the data in the XML database
 Command injection - OS and platform commands can often be used to give attackers access to data and escalate privileges on backend servers.
 Process injection
 Cross-site Request Forgeries

Security Vulnerabilities
 Denial of Service
 Broken access control
 Path manipulation
 Broken session management (synchronization timing problems)
 Weak cryptographic functions, Non salt hash

Architectural/Logical Vulnerabilities
 Information leakage
 Insufficient authentification
 Password change form disclosing detailed errors
 Session-idle deconstruction not consistent with policies
 Spend deposit before deposit funds are validated


Other vulnerabilities
 Debug mode
 Thread Safety
 Hidden Form Field Manipulation
 Weak Session Cookies: Cookies are often used to transit sensitive credentials, and are often easily modified to escalate access or assume another user's identify.
 Fail Open Authentication
 Dangers of HTML Comments

Open source Tools for Web Application Testing using Manual vulnerability penetration testing.

Open source Tools for Web Application Testing using Manual vulnerability penetration testing.
Methodical approach to web application penetration testing to ensure we are effective, efficient, and repeatable. Our methodology goes well beyond looking for the OWASP Top Ten issues.
Discovery – We work with you to understand the business impact of various features, so that we can qualify and quantify the business risk of the vulnerabilities we find.
Assessment – To ensure that all important areas are tested and to ensure consistency and repeat¬ability, we use a common security frame.
    ->Authentication
    ->Authorization
    ->User management    Session management     
    ->Data validation, including all common attack • such as SQL Injection, Cross Site Scripting, Command     Injection, Client Side Validation
    ->Error handling and exception management
    ->Auditing and logging
Reporting and deliverable – At the end of the engagement, we produce a detailed, written report with an executive summary prioritizing findings and the impact on your business. Our individual technical findings all contain specific details and recommendations for mitigation.

METHODOLOGY DIGRAM FOR PENETRATION TESTING

WEB TESTING

WEB TESTING:


While testing a web application you need to consider following Cases:

• Functionality Testing
• Performance Testing
• Usability Testing
• Server Side Interface
• Client Side Compatibility
• Security

Ø      Functionality:
In testing the functionality of the web sites the following should be tested:
• Links
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links

Ø       Forms
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields

Ø      Database
* Testing will be done on the database integrity.

Ø      Cookies
* Testing will be done on the client system side, on the temporary Internet files.

Ø      Performance:
Performance testing can be applied to understand the web site’s scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase.

Ø      Connection Speed:
Tested over various networks like Dial Up, ISDN etc
• Load:
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
• Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..

Ø      Usability:
Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.
• Ease of learning
• Navigation
• Subjective user satisfaction
• General appearance

Ø      Server Side Interface:
In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.

Ø      Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.

Ø      Security:
The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection

The Top 25 Mapped to Application Security Methods

The possible ways such as Education,Manual Process,Using Tools and Threat Model of finding the vulnerability using the web application security testing process as mentioned below picture.

Use Enumerations for web application security testing.

Enumerations help identify specific software-related items that can be counted, aggregated, evaluated over time

CVE->Common Vulnerabilities and Exposures.
CWE->Common Weakness Enumeration.
CAPEC->Common Attack Pattern Enumeration and Classification.

The Class were  mentioned CVE,CWE,CAPEC below.

SQL Injection XSS Attack Buffer Overflow Directory Traversal PHP Include Symbolic Link Authorization Bypass Dos Malformed Input Information Leak

Integer Overflow CSRF Bad Permissions Hard coded Password Weak Crypto Insufficient Randomness Search Path Sensitive data root Dos Flood Eval Injection

Automated Software Testing for the User Interface

Eggplant is automated QA test software that is...

 non-invasive

 technology agnostic

 easy to script and use

EggPlant is image-based – which means it can “see” the user interface, just as the human eye does. The difference is, EggPlant can test your software using a fraction of the time and resources.

We can test any operating system – Mac, Linux, Windows , Solaris, Symbian, Blackberry, Windows Mobile, KVM Switches

We can test any interface – screens, POS, command and control systems, air traffic control screens, smartphones, mobile devices.

Software may have perfectly written code and still result in inaccuracies at the user interface. Do you want to find the flaws or wait until your customers point them out?

If you need functional, regression, integration, load, user experience, GUI,Multi-media, Mobile, QoS, or SLA testing – we can assist you!

Security testing.

Security is a very critical aspect of Web Applications, keeping in mind the alarming rise in cyber crimes and intrusion attempts by malicious users. The financial losses and legal consequences that organizations can face due to security incidents are immense.

This paper addresses some of the common maladies faced by QA Personnel and Customers from a SecurityPerspective. It describes the common Security vulnerabilities in applications with examples and techniques for testing the application for those vulnerabilities. Modelling techniques are discussed that help in identifying vulnerabilities and evaluate the Security Risks for an application. The paper suggests Processes, Framework, and Tools to help in providing highly effective and low cost Security Testing Solutions (specifically Penetration
Testing) for Web Applications. Embedded in the paper are Traceability Templates, a Test Plan Template, a Checklist and a Process flow for Security Testing.