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