Data Validation Testing, Denial of Service Testing, Web Services Testing, and AJAX Testing (from OWASP)

1. Data Validation Testing
The most common web application security weakness is the failure to properly validate input coming from the client or environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.

1.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)

We gonna tried <script>alert("hello world")</script>: http://www.akakom.ac.id/index.php?user=<script>alert("hello world")</script>, so the link directed to http://www.akakom.ac.id/index.php?user=%20script%3EALERT%20%20hello%20world%20%20%20%2Fscript%3E#31610346594256744308. The page seems not changed anything.

1.2 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.

1.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)
An attacker may append <script>alert('xss')</script> to the affected page URL which would, when executed display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but yet as a fragment. In this example the code is immediately executed and an alert of "xss" is displayed in the page. Unlike the more common types of cross site scripting persistent and non-persistent), in which the code is sent to the server and redisplayed to the user, this is immediately executed in the user’s browser.

1.4 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.

1.5 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.

Example, we tried to fill in username = 1′ or ’1′ = ’1 and password = 1′ or ’1′ = ’1, so the resultt failed, http://www.akakom.ac.id/phpmyadmin/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1

Technology specific Testing Guide pages have been created for the following DBMSs:
1.5.1 Oracle Testing
1.5.2 MySQL Testing
1.5.3 SQL Server Testing
1.5.4 MS Access Testing
1.5.5 Testing PostgreSQL

1.6 LDAP Injection (OWASP-DV-006)
LDAP is an acronym for Lightweight Directory Access Protocol. 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. A successful exploitation of LDAP Injection could allow the tester to:
• Access unauthorized content
• Evade Application restrictions
• Gather unauthorized information
• Add or modify Objects inside LDAP tree structure.

1.7 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.

1.8 XML Injection (OWASP-DV-008)
Inject an XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive.

1.10 XPath Injection (OWASP-DV-010)
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.

1.11 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.

1.12 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. With "http://www.akakom.ac.id/cgi-bin/", we got report form the target "don't have permission to access /cgi-bin/ on this server".

1.13 OS Commanding (OWASP-DV-013)
We tested an application for OS commanding testing: this means tried to inject an on command through an HTTP request to the application.

1.14 Buffer overflow Testing (OWASP-DV-014)
Different types of buffer overflow vulnerabilities have different testing methods. Here are the testing methods for the common types of buffer overflow vulnerabilities.
• Testing for heap overflow vulnerability
• Testing for stack overflow vulnerability
• Testing for format string vulnerability

1.15 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.

1.16 Testing for HTTP Splitting/Smuggling (OWASP-DV-016)
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

2. Denial of Service Testing
The most common type of denial of service (DoS) attack is the kind used on a network to make a server unreachable by other valid users.

The DoS tests talk about:

2.1 Testing for SQL Wildcard Attacks (OWASP-DS-001)
SQL Wildcard attacks might affect all database back-ends but mainly affect SQL Server because the MS SQL Server LIKE operator supports extra wildcards such as "[]","[^]","_" and "%".

2.2 Locking Customer Accounts (OWASP-DS-002)
In this test we check whether an attacker can lock valid user accounts by repeatedly attempting to log in with a wrong password.

2.3 Buffer Overflows (OWASP-DS-003)
In this test we check whether it is possible to cause a denial of service condition by overflowing one or more data structures of the target application.

2.4 User Specified Object Allocation (OWASP-DS-004)
In this test we check whether it is possible to exhaust server resources by making it allocate a very high number of objects.

2.5 User Input as a Loop Counter (OWASP-DS-005)
In this test we check whether it is possible to force the application to loop through a code segment that needs high computing resources, in order to decrease its overall performance.

2.6 Writing User Provided Data to Disk (OWASP-DS-006)
With this test, we check that it is not possible to cause a DoS condition by filling the target disks with log data.

2.7 Failure to Release Resources (OWASP-DS-007)
With this test, we check that the application properly releases resources (files and/or memory) after they have been used.

2.8 Storing too Much Data in Session (OWASP-DS-008)
In this test, we check whether it is possible to allocate big amounts of data into a user session object in order to make the server exhaust its memory resources.

3. Web Services Testing
The Web Services Framework utilizes the HTTP protocol (as standard Web Application) in conjunction with XML, SOAP, WSDL and UDDI technologies:
• The "Web Services Description Language" (WSDL) is used to describe the interfaces of a service.
• The "Simple Object Access Protocol" (SOAP) provides the means for communication between Web Services and Client Applications with XML and HTTP.
• "Universal Description, Discovery and Integration" (UDDI) is used to

3.1 WS Information Gathering (OWASP-WS-001)
The first step to perform a Web Service Test is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

3.2 Testing WSDL (OWASP-WS-002)
Check the WSDL of the web service to find the entry points and try to invoke an operation that is not used in a standard SOAP Request. Ensure that the WS doesn’t give you some confidential information.

3.3 XML Structural Testing (OWASP-WS-003)
Testers can create XML documents which are structured in such a way as to create a denial of service attack on the receiving server by tying up memory and CPU resources. This occurs via overloading the XML parser ,which, as we mentioned, is very CPU-intensive. This section discusses the types of attack vectors one could send to a web service in an attempt to assess its reaction to malformed or maliciously-crafted messages.

3.4 XML Content-level Testing (OWASP-WS-004)
Content-level attacks target the server hosting a web service and any applications that are utilized by the service, including web servers, databases, application servers, operating systems, etc. Content-level attack vectors include 1) SQL Injection or XPath injection 2) Buffer Overflow and 3) Command Injection. An attacker can craft an XML document (SOAP message) that contains malicious elements in order to compromise the target system. Testing for proper content validation should be included in the web application-testing plan.

3.5 HTTP GET parameters/REST Testing (OWASP-WS-005)
Many XML applications are invoked by passing them parameters using HTTP GET queries. These are sometimes known as “REST-style" Web Services (REST = Representational State Transfer). These Web Services can be attacked by passing malicious content on the HTTP GET string (e.g. extra long parameters (2048 chars), SQL statements/injection (or OS Injection parameters).

3.6 Naughty SOAP attachments (OWASP-WS-006)
This section describes attack vectors for Web Services that accept attachments. The danger exists in the processing of the attachment on the server and redistribution of the file to clients. Binary files, including executables and document types that can contain malware, can be posted using a web service in several ways. These files can be sent as a parameter of a web service method; they can be sent as an attachment using SOAP with Attachments and they can be sent using DIME (Direct Internet Message Encapsulation) and WS-Attachments. An attacker can craft an XML document (SOAP message) to send to a web service that contains malware as an attachment. Testing to ensure the Web Service host inspects SOAP attachments should be included in the web application testing plan.

3.7 Replay Testing (OWASP-WS-007)
A replay attack is a "man-in-the-middle" type of attack where a message is intercepted and replayed by an attacker to impersonate the original sender. For web services, as with other types of HTTP traffic, a sniffer such as Ethereal or Wireshark can capture traffic posted to a web service and using a tool like WebScarab, a tester can resend a packet to the target server. An attacker can attempt to resend the original message or change the message in order to compromise the host server.

Using Wireshark on a network, sniff traffic and filter for web service traffic. Using the packets captured by ethereal, use TCPReplay to initiate the replay attack by reposting the packet.

4. AJAX Testing
AJAX, an acronym for Asynchronous JavaScript and XML. AJAX applications are vulnerable to the full range of traditional web application vulnerabilities. Insecure coding practices can lead to SQL injection vulnerabilities, misplaced trust in user-supplied input can lead to parameter tampering vulnerabilities, and a failure to require proper authentication and authorization can lead to problems with confidentiality and integrity. In addition, AJAX applications can be vulnerable to new classes of attack such as Cross Site Request Forgery
(XSRF).

4.1 AJAX Vulnerabilities (OWASP-AJ-001)
Asynchronous Javascript and XML (AJAX) is one of the latest techniques used by web application developers to provide a user experience similar to that of a local application. Since AJAX is still a new technology, there are many security issues that have not yet been fully researched. Some of the security issues in AJAX include:
• Increased attack surface with many more inputs to secure
• Exposed internal functions of the application
• Client access to third-party resources with no built-in security and encoding mechanisms
• Failure to protect authentication information and sessions
• Blurred line between client-side and server-side code, resulting in security mistakes

4.2 Testing For AJAX (OWASP-AJ-002)
Traditional web applications are fairly easy to discover in an automated fashion. An application typically has one or more pages that are connected by HREFs or other links. Interesting pages will have one or more HTML FORMs. These forms will have one or more parameters. By using simple spidering techniques such as looking for anchor (A) tags and HTML FORMs it 320 should be possible to discover all pages, forms, and parameters in a traditional web application. Requests made to this application follow a well-known and consistent format laid out in the HTTP specification. GET requests have the format: http://server.com/directory/resource.cgi?param1=value1&key=value.

We tried to the target, http://www.akakom.ac.id/directory/resource.cgi?param1=value1&key=value, the page not changed. But the link directed to http://www.akakom.ac.id/?param1=value1&key=value. Maybe this link was new 'homework' for the Nine Tails team.