vulnerability in web application

Cross-site scripting (aka XSS) is the term used to describe a class of security vulnerabilities in web applications. An attacker can inject malicious scripts to perform unauthorized actions in the context of the victim's web session. Any web application that serves documents that include data from untrusted sources could be vulnerable to XSS if the untrusted data is not appropriately sanitized. A web application that is vulnerable to XSS can be exploited in two major ways:

    Stored XSS - Commonly exploited in a web application where one user enters information that's viewed by another user. An attacker can inject malicious scripts that are executed in the context of the victim's session. The exploit is triggered when a victim visits the website at some point in the future, such as through improperly sanitized blog comments and guestbook entries, which facilitates stored XSS.

    Reflected XSS - An application that echoes improperly sanitized user input received as query parameters is vulnerable to reflected XSS. With a vulnerable application, an attacker can craft a malicious URL and send it to the victim via email or any other mode of communication. When the victim visits the tampered link, the page is loaded along with the injected script that is executed in the context of the victim's session.

The general principle behind preventing XSS is the proper sanitization (via, for instance, escaping or filtering) of all untrusted data that is output by a web application. If untrusted data is output within an HTML document, the appropriate sanitization depends on the specific context in which the data is inserted into the HTML document. The context could be in the regular HTML body, tag attributes, URL attributes, URL query string attributes, style attributes, inside JavaScript, HTTP response headers, etc.

The following are some (by no means complete) examples of XSS vulnerabilities. Let's assume there is a web application that accepts user input as the 'q' parameter. Untrusted data coming from the attacker is marked in red.

• Injection in regular HTML body - angled brackets not filtered or escaped
  
  Your query '' returned xxx results
• Injection inside tag attributes - double quote not filtered or escaped
  
  
  
    blah">">
• Injection inside URL attributes - non-http(s) URL
  
  javascript:evil_script()">...
• In JavaScript context - single quote not filtered or escaped
  
  

In the cases where XSS arises from meta characters being inserted from untrusted sources into an HTML document, the issue can be avoided either by filtering/disallowing the meta characters, or by escaping them appropriately for the given HTML context. For example, the HTML meta characters <, >, &, " and ' must be replaced with their corresponding HTML entity references <, >, &, " and &#39 respectively. In a JavaScript-literal context, inserting a backslash in front of \, ', " and converting the carriage returns, line-feeds and tabs into \r, \n and \t respectively should avoid untrusted meta characters being interpreted as code.

How about an automated tool for finding XSS problems in web applications? Our security team has been developing a black box fuzzing tool called Lemon (deriving from the commonly-recognized name for a defective product). Fuzz testing (also referred to as fault-injection testing) is an automated testing approach based on supplying inputs that are designed to trigger and expose flaws in the application. Our vulnerability testing tool enumerates a web application's URLs and corresponding input parameters. It then iteratively supplies fault strings designed to expose XSS and other vulnerabilities to each input, and analyzes the resulting responses for evidence of such vulnerabilities. Although it started out as an experimental tool, it has proved to be quite effective in finding XSS problems. Besides XSS, it finds other security problems such as response splitting attacks, cookie poisoning problems, stacktrace leaks, encoding issues and charset bugs. Since the tool is homegrown it is easy to integrate into our automated test environment and to extend based on specific needs. We are constantly in the process of adding new attack vectors to improve the tool against known security problems.

BurpSuite_v1.3 free edition

BurpSuite_v1.3


Burp Suite is an integrated platform for attacking web applications. It contains the entire Burp tools with numerous interfaces between them designed to facilitate and speed up the process of attacking an application. All tools share the same robust framework for handling HTTP requests, persistence, authentication, upstream proxies, logging, alerting and extensibility. BurpSuite is OWASP Project tool.

Burp Suite allows you to combine manual and automated techniques to enumerate, analyses, scan, attack and exploit web applications. The various Burp tools work together effectively to share information and allow findings identified within one tool to form the basis of an attack using another.

Proxy: Burp Proxy is an interactive HTTP/HTTPS proxy server for attacking and testing web applications. It operates as a man-in-the-middle between the end browser and the target web server, and allows the user to intercept, inspect and modify the raw traffic passing in both directions.

Spider: Burp Spider is a tool for mapping web applications. It uses various intelligent techniques to generate a comprehensive inventory of an application’s content and functionality.

Intruder: Burp Intruder is a tool for automating customized attacks against web applications.

Repeater: Burp Repeater is a tool for manually modifying and reissuing individual HTTP requests, and analyzing their responses. It is best used in conjunction with the other Burp Suite tools.

Sequencer: Burp Sequencer is a tool for analysing the degree of randomness in an application’s session tokens or other items on whose unpredictability the application depends for its security.


Decoder: Burp Decoder is a simple tool for transforming encoded data into its canonical form, or for transforming raw data into various encoded and hashed forms. It is capable of intelligently recognizing several encoding formats using heuristic techniques.

Comparer: Burp Comparer is a simple tool for performing a comparison (a visual “diff”) between any two items of data. In the context of attacking a web application, this requirement will typically arise when you want to quickly identify the differences between two application responses (for example, between two responses received in the course of a Burp Intruder attack, or between responses to a failed login using valid and invalid usernames), or between two application requests (for example, to identify the different request parameters that give rise to different behavior).

Procedure to run the BurpSuit_v1.3 proxy tool using SITE



http://testfire.net/bank/login.aspx


CASE: 1-TASK



STEP 1:

The Burp Suite will now begin logging the requests and responses that pass through the proxy. We have browsed to the logon page of www.testfire.net/bank/login.aspx application and the Burp Suite proxy has captured the request and response: as shown in screen shot-1

STEP 2:

Select the POST or GET type of method and right click on send to Intruder then go to payloads ->add type of possible attack vector syntax for SQL injection(1’ or ‘1’=’1), XSS(<script>alert(‘XSS’)</script> and code injection(cd-) etc as shown in the screen shot-2 .And the result view shows the possibility are displayed as shown in screen shot-3 .

W3af –Web application attack and audit framework

W3af –Web application attack and audit framework

W3af is a complete environment for auditing and attacking web applications. This environment provides a solid platform for auditing and penetration-testing. It is working on python application.


Compatibility for sites use embedded objects, like Macromedia Flash and Java applets,
The framework has three types of plugins: discovery, audit and attack.
Discovery plugins have only one responsibility, finding new URLs, forms, and other “injection points”.

Audit plugins take the injection points found by discovery plugins and send specially crafted data to all of them in order to find vulnerabilities.

Attack plugins objective is to exploit vulnerabilities found by audit plugins. They usually return a shell on the remote server, or a dump of remote tables in the case of SQL injections exploits.

W3af has two user interfaces, the console user interface (consoleUI) and the graphical user interface (gtkUi). This user guide will focus on the consoleUI, which ismore fully tested and complete than the gtkUi. To fire up the consoleUI you just have to execute w3af without parameters and you will get a prompt like this one:

$ ./w3af_console
w3af>>>

Graphical user interface (gtkUi) is a framework also has a graphical user interface that you can start by executing.
The graphical user interface allows you to perform all the actions that the framework offers and features a much easier and faster way to start a scan and analyze the results. Here the screen shot-1

Three core types of plugins are discovery, audit and exploit. The complete list of plugins types is:

 Discovery: Find new points of injection

 Audit: To find vulnerabilities

 Grep: It analyze all page content and find vulnerabilities on pages that are requested by other plugins

 Exploit: Use the vulnerabilities found in the audit phase and return something useful to the user (remote shell, SQL table dump, a proxy, etc).

 Output: The way the framework and the plugins communicate with the user. Output plugins save the data to a text or html file. Debugging information is also sent to the output plugins and can be saved for analysis.

 Mangle: It allows modification of requests and responses based on regular expressions, think “sed (stream editor) for the web”.

 Bruteforce: This plugins will bruteforce logins. These plugins are part of the discovery phase.

 Evasion: Evasion plugins try to evade simple intrusion detection rules


Key features:


This following feature allows you to create a reverse tunnel that will route TCP connections through the compromised server. Unlike virtual daemon, this feature is ready to use and doesn't require any other software. Before going through an example to see how to use this feature, we will make a summary of the steps that will happen during exploitation.

 w3af finds a vulnerability that allows remote command execution

 The user exploits the vulnerability and starts the w3afAgent

 W3af performs an extrusion scan by sending a small executable to the remote server. This executable connects back to w3af and allows the framework to identify outgoing firewall rules on the remote network.

 W3afAgent Manager will send a w3afAgentClient to the remote server. The process of uploading the file to the remote server depends on the remote operating system, the privileges of the user running w3af and the local operating system; but in most cases the following happens:

o W3af reuses the information from the first extrusion scan, which was performed in step 3 in order to know which port it can use to listen for connections from the compromised server.

o If a TCP port is found to be allowed in the remote firewall, w3af will try to run a server on that port and make a reverse connection from the compromised in order to download the PE/ELF generated file. If no TCP ports are enabled, w3af will send the ELF/PE file to the remote server using several calls to the “echo” command, which is rather slow, but should always work because it's an in-band transfer method.

 W3afAgent Manager starts the w3afAgentServer that will bind on localhost: 1080 (which will be used by the w3af user) and on the interface configured in w3af (misc-settings->interface) on the port discovered during step 3.

 The w3afAgentClient connects back to the w3afAgentServer, successfully creating the tunnel

 The user configures the proxy listening on localhost:1080 on his preferred software

 When the program connects to the socks proxy, all outgoing connections are routed through the compromised server

 Authentication

 Authorization

 User management and fuzzy request for manual penetration testing.

 Session management and compare .

 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

Log: Log is normally a large quantity of text; you can enable and disable the different type of messages, using the checkboxes in the log bar. Note that these different types have different colors in the text itself. In the same bar you have a Search button, which enables the search functionality (explained in detail below).

 Graphical representation of vulnerabilities.

 Count information’s of vulnerabilities were displayed during scanning

Results:

 Showing the what are the parameters passed in URL and displaying detail information

 Request and Response information was displayed

 Showing vulnerabilities in colors representation.

 Exploitation

                                                                                                                                                                                                                        

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.