<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mmacdonell</id>
		<title>OWASP - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mmacdonell"/>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php/Special:Contributions/Mmacdonell"/>
		<updated>2026-05-31T17:25:53Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.27.2</generator>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing:_Information_Gathering&amp;diff=15183</id>
		<title>Testing: Information Gathering</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing:_Information_Gathering&amp;diff=15183"/>
				<updated>2007-01-10T21:27:48Z</updated>
		
		<summary type="html">&lt;p&gt;Mmacdonell: Minor changes (spelling and grammar)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents#Web_Application_Penetration_Testing Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
=== Information Gathering ===&lt;br /&gt;
----&lt;br /&gt;
The  first phase in security assessment is focused on collecting all the information about a target application.&lt;br /&gt;
Information Gathering is a necessary step of a penetration test.&lt;br /&gt;
&lt;br /&gt;
This task can be carried out by using many different ways.&lt;br /&gt;
&lt;br /&gt;
Using public tools (search engines), scanners, sending simple HTTP requests, or specially crafted requests, it is possible to force the application to leak information by sending back error messages, revealing the versions and technologies used by the application.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Often it is possible to gather information by receiving a response from the application which, as a consequence of bad default configuration of the application server or web server, could reveal vulnerabilities in the configuration or bad server management.&lt;br /&gt;
&lt;br /&gt;
[[Application Discovery AoC|4.2.1 Application Fingerprint]]&lt;br /&gt;
&lt;br /&gt;
Application fingerprint is the first step of the Information Gathering process; knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing. &lt;br /&gt;
&lt;br /&gt;
[[Application Discovery AoC|4.2.2 Application Discovery]]&lt;br /&gt;
&lt;br /&gt;
Application discovery is an activity oriented to the identification of the web applications hosted on a web server/application server.&amp;lt;br&amp;gt;&lt;br /&gt;
This analysis is important because many times there is not a direct link connecting the main application backend so a discovery analysis would be useful to reveal details such as web-apps used for administrative purposes, old versions of files or artifacts (such as scripts not properly deleted after their usage while crafted during the test/development phase or as the result of maintenance).&lt;br /&gt;
&lt;br /&gt;
[[Spidering and googling AoC|4.2.3 Spidering and googling]]&lt;br /&gt;
&lt;br /&gt;
This phase of the Information Gathering process consists of browsing and capturing resources related to the application being tested. Search engines, such as Google, can be used to discover issues related to the web application structure or error pages produced by the application that are usually found after being exposed to the public domain.&lt;br /&gt;
&lt;br /&gt;
[[Testing for Error Code|4.2.4 Analysis of error code]]&lt;br /&gt;
&lt;br /&gt;
Web applications may divulge information during a penetration test which is not intended to be seen by an end user. Information (such as error codes) can inform the tester about technologies and products being used by the application.&amp;lt;br&amp;gt;&lt;br /&gt;
Such error codes can be easy to exploit without using any particular skill due to bad error handling strategy.&lt;br /&gt;
&lt;br /&gt;
[[Infrastructure configuration management testing AoC|4.2.5 Infrastructure configuration management testing]]&lt;br /&gt;
&lt;br /&gt;
Often analysis of the infrastructure and topology architecture can reveal a lot of information about a web application such as source code, HTTP methods permitted, administrative functionalities, authentication methods and infrastructural configurations.&amp;lt;br&amp;gt;&lt;br /&gt;
For those reasons, focusing only on the web application will not be an exhaustive test, considering the fact that the information collected during the security assessment could not be as exhaustive as the information possibly gathered by performing a wider test comprehensible to an infrastructure analysis.  &lt;br /&gt;
&lt;br /&gt;
[[SSL/TLS Testing AoC|4.2.5.1 SSL/TLS Testing]]&lt;br /&gt;
&lt;br /&gt;
SSL and TLS are two protocols which provide, with the support of the cryptography, a secure channel for the communications to protect the confidentiality &amp;amp; authentication of the information and a secure channel.&amp;lt;br&amp;gt;&lt;br /&gt;
Considering the importance of those security implementations it is important to verify the usage of a strong cipher algorithm and its proper implementation has been performed.&lt;br /&gt;
&lt;br /&gt;
[[DB Listener Testing AoC|4.2.5.2 DB Listener Testing]]&lt;br /&gt;
&lt;br /&gt;
During the configuration of a database server, many DB administrators do not consider the importance around the lack of security of the DB Listener component. It could reveal sensible data as well as the configuration settings or database instances running.&amp;lt;br&amp;gt;&lt;br /&gt;
The collection of this information could provide some useful hints needed to compromise the reservedness, integrity and availability of the data stored.&amp;lt;br&amp;gt;&lt;br /&gt;
An accurate security analysis of the DB listener configuration can allow for the acquisition this information.&lt;br /&gt;
&lt;br /&gt;
[[Application configuration management testing AoC|4.2.6 Application configuration management testing]]&lt;br /&gt;
&lt;br /&gt;
The web applications hide some information which is usually are not considered during the development or configuration of the application itself.&amp;lt;br&amp;gt;&lt;br /&gt;
This data can be discovered in the source code, in the log files or in the default error codes of the web servers so a correct approach to this topic is fundamental during a security assessment.&lt;br /&gt;
&lt;br /&gt;
[[File extensions handling AoC|4.2.6.1 File extensions handling]]&lt;br /&gt;
&lt;br /&gt;
By observing the file extensions present in a web server or a web-app, it is possible to identify the technologies which compose the target application (for example jsp and asp extensions in a server-side architecture) and sometimes additional systems connected to the application.&lt;br /&gt;
&lt;br /&gt;
[[Old file testing AoC|4.2.6.2 Old, backup and unreferenced files]]&lt;br /&gt;
&lt;br /&gt;
Redundant files which could be present on a web server (such as old, backup and renamed files), which remain freely readable and downloadable, are a big source of information leakage. It is necessary to verify the presence of these files because they may contain parts of source code, installation paths as well as passwords for applications and/or databases.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>Mmacdonell</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing:_Introduction_and_objectives&amp;diff=15181</id>
		<title>Testing: Introduction and objectives</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing:_Introduction_and_objectives&amp;diff=15181"/>
				<updated>2007-01-10T20:57:22Z</updated>
		
		<summary type="html">&lt;p&gt;Mmacdonell: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents#Web_Application_Penetration_Testing Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
This Chapter describes the OWASP Web Application Penetration testing methodology and explains how to test each vulnerabilities.&lt;br /&gt;
&lt;br /&gt;
'''What is a Web Application Penetration Testing?'''&amp;lt;br&amp;gt;&lt;br /&gt;
A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application.&amp;lt;br&amp;gt;&lt;br /&gt;
The process involves an active analysis of the application for any weaknesses, technical flaws or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.&lt;br /&gt;
&lt;br /&gt;
'''What is a vulnerability?'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Given an application owns a set of assets (resources of value such as the data in a database or on the file system), a vulnerability is a weakness on an asset that makes a threat possible.&lt;br /&gt;
So a threat is a potential occurrence that may harm an asset by exploiting a Vulnerability.&lt;br /&gt;
A test is an action that tends to show a vulnerability in the application.&lt;br /&gt;
&lt;br /&gt;
'''Our approach in writing this guide'''&lt;br /&gt;
&lt;br /&gt;
The OWASP approach is Open and Collaborative:&lt;br /&gt;
* Open: every security expert can participate with his experience in the project. Everything is free.&lt;br /&gt;
* Collaborative: we usually perform brainstorming before the articles are written. So we can share our ideas and develop a collective vision of the project. That means rough consensus, wider audience and participation.&amp;lt;br&amp;gt;&lt;br /&gt;
This approach tends to create a defined Testing Methodology that will be:&lt;br /&gt;
* Consistent&lt;br /&gt;
* Reproducible&lt;br /&gt;
* Under quality control&amp;lt;br&amp;gt;&lt;br /&gt;
The problems that we want to be addressed are:&lt;br /&gt;
* Document all&lt;br /&gt;
* Test all&lt;br /&gt;
We think that is important to use a method to test all the know vulnerabilities and document all the the pen test activities.&amp;lt;br&amp;gt;&lt;br /&gt;
'''What is the OWASP testing methodology?'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Penetration testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, penetration testing is only an appropriate technique for testing the security of web applications under certain circumstances. &lt;br /&gt;
The goal is to collect all the possible testing techniques, explain them and keep the guide updated.&amp;lt;br&amp;gt;&lt;br /&gt;
The OWASP Web Application Penetration Testing is based on black box approach. The tester know nothing or a few informations about the application to test.&lt;br /&gt;
The testing model is like this:&lt;br /&gt;
* Tester: Who performs the testing activities &lt;br /&gt;
* Tools and methodology: The core of this Testing Guide project&lt;br /&gt;
* Application: The black box to test&lt;br /&gt;
The test is divided in 2 phases:&lt;br /&gt;
* Passive mode: in the passive mode the tester tries to understand the application's logic, plays with the application; a tool can be used for information gathering and HTTP proxy to observe all the HTTP requests and responses. At the end of this phase the tester should understand all the access points (gates) of the application (e.g. Header HTTP, parameters, cookies). For example the tester could find the following:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
https://www.example.com/login/Autentic_Form.html&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
This indicates an authentication form in which the application requests a username and a password. &amp;lt;br&amp;gt;&lt;br /&gt;
The following parameters represent two access points (gates) to the application:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://www.example.com/Appx.jsp?a=1&amp;amp;b=1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
In this case, the application shows two gates (parameters a and b).&lt;br /&gt;
All the gates found in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all the access points would be useful for the second phase.&amp;lt;br&amp;gt; &amp;lt;br&amp;gt;&lt;br /&gt;
* Active mode: in this phase the tester begins to test using the methodology described in the follow paragraphs.&lt;br /&gt;
&lt;br /&gt;
We have split the set of tests in 8 sub-categories:&lt;br /&gt;
*Information Gathering &lt;br /&gt;
*Business Logic Testing&lt;br /&gt;
*Authentication Testing &lt;br /&gt;
*Session Management Testing&lt;br /&gt;
*Data Validation Testing &lt;br /&gt;
*Denial of Service Testing &lt;br /&gt;
*Web Services Testing &lt;br /&gt;
*AJAX Testing &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is the list of test that we will explain in the next paragraphs:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;[[Image:Table1.PNG]]&amp;lt;/center&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;[[Image:Table2.PNG]]&amp;lt;/center&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;[[Image:Table3.PNG]]&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>Mmacdonell</name></author>	</entry>

	</feed>