TESTING FOR REFLECTED CROSS SITE SCRIPTING (OWASP-DV-001)
Reflected Cross-site Scripting (XSS) is another name for non-persistent XSS, where the attack doesn’t load with the vulnerable web application but is originated by the victim loading the offending URI. In this article we will see some ways to
test a web application for this kind of vulnerability.
test a web application for this kind of vulnerability.
TESTING FOR STORED CROSS SITE SCRIPTING (OWASP-DV-002)
Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application.
This vulnerability can be used to conduct a number of browser-based attacks including:
This vulnerability can be used to conduct a number of browser-based attacks including:
- Hijacking another user’s browser
- Capturing sensitive information viewed by application users
- Pseudo defacement of the application
- Port scanning of internal hosts (“internal” in relation to the users of the web application)
- Directed delivery of browser-based exploits
- Other malicious activities
TESTING FOR DOM BASED CROSS SITE SCRIPTING (OWASP-DV-003)
The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security – for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.
TESTING FOR CROSS SITE FLASHING (OWASP-DV-004)
ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. ActionScript, like every other language, has some implementation patterns which could lead to security issues.
In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.
In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.
SQL INJECTION (OWASP-DV-005)
A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.
LDAP INJECTION (OWASP-DV-006)
LDAP is an acronym for Lightweight Directory Access Protocol. It is a paradigm to store information about users, hosts and many other objects. LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified or inserted.
This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.
This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.
ORM INJECTION (OWASP-DV-007)
ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.
XML INJECTION (OWASP-DV-008)
In this section, we describe a practical example of XML Injection: first we define an XML style communication, and we show how it works. Then we describe the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).
SSI INJECTION (OWASP-DV-009)
Web servers usually give to the developer the possibility of adding small pieces of dynamic code inside static HTML pages, without having to play with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI), a very simple extension that can enable an attacker to inject code into HTML pages, or even perform remote code execution.
XPATH INJECTION (OWASP-DV-010)
XPath is a language that has been designed and developed to operate on data that is described with XML. The XPath injection allows an attacker to inject XPath elements in a query that uses this language. Some of the possible goals are to bypass authentication or access information in an unauthorized manner.
IMAP/SMTP INJECTION (OWASP-DV-011)
This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
CODE INJECTION (OWASP-DV-012)
This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by
the web server.
the web server.
OS COMMANDING (OWASP-DV-013)
In this paragraph we describe how to test an application for OS commanding testing: this means try to inject an on command through an HTTP request to the application.
BUFFER OVERFLOW TESTING (OWASP-DV-014)
INCUBATED VULNERABILITY TESTING (OWASP-DV-015)
Also often referred to as persistent attacks, incubated testing is a complex testing that needs more than one data validation vulnerability to work. In this section we describe a set of examples to test an Incubated Vulnerability.
- The attack vector needs to be persisted in the first place, it needs to be stored in the persistence layer, and this would only occur if weak data validation was present or the data arrived into the system via another channel such as an admin console or directly via a backend batch process.
- Secondly once the attack vector was “recalled” the vector would need to be executed successfully. For example, an incubated XSS attack would require weak output validation so the script would be delivered to the client in its executable form.
TESTING FOR HTTP SPLITTING/SMUGGLING (OWASP-DV-016)
We will analyze two different attacks that target specific HTTP headers: HTTP splitting and HTTP smuggling. The first attack exploits a lack of input sanitization which allows an intruder to insert CR and LF characters into the headers of the
application response and to ‘split’ that answer into two different HTTP messages. The goal of the attack can vary from a cache poisoning to cross site scripting. In the second attack, the attacker exploits the fact that some specially crafted HTTP
messages can be parsed and interpreted in different ways depending on the agent that receives them. HTTP smuggling requires some level of knowledge about the different agents that are handling the HTTP messages (web server, proxy, firewall) and therefore will be included only in the Gray Box testing section
application response and to ‘split’ that answer into two different HTTP messages. The goal of the attack can vary from a cache poisoning to cross site scripting. In the second attack, the attacker exploits the fact that some specially crafted HTTP
messages can be parsed and interpreted in different ways depending on the agent that receives them. HTTP smuggling requires some level of knowledge about the different agents that are handling the HTTP messages (web server, proxy, firewall) and therefore will be included only in the Gray Box testing section
Post a Comment