OWASP - User contributions [en]

OWASP Working Session Top 10 2009

2008-12-18T14:45:12Z

Mmella: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|'''OWASP Top 10 2009'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|Aims to provide a key awareness document for web application security.
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|[[:Category:OWASP Top Ten Project|OWASP Top Ten Project]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair''' [mailto:dave.wichers(at)owasp.org '''Dave Wichers''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary''' [mailto:jeff.williams(at)owasp.org '''Jeff Williams''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list''' [https://lists.owasp.org/mailman/listinfo/owasp-topten '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
* Discuss current Top10 structure and objectives,
* Identify which information sources will be considered for analysis, Eg:
** MITRE
** Compromise DB's (Attrition, WASC etc) and bias due to reporting
** Anonomised penetration test results and the difficulty in obtaining
* Define methodology to collect attacks statistics,
* Define prioritisation approach
** Agree weighting between current or emerging threats
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue''' [[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time''' November 5 & 7, 2008 Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model''' "Participants + Attendees"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.

Potential Resources:

* [http://cve.mitre.org/cve/ MITRE's Common Vulnerability Enumeration (CVE) Database]

* The [http://www.webappsec.org/projects/whid/whid.shtml WASC Web Hacking Incidents Database]

* The [http://www.webappsec.org/projects/statistics/ 2007 WASC Web Application Security Statistics Report]
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|The sources of input for the 2009 Top 10 will be identified.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|The ordering scheme for the Top 10 will be determined.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Discussion of whether the existing document structure should be maintained or adjusted.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|[http://uk.youtube.com/watch?v=GsRbpshqqII Video]
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add your name by editing this table. On the right, just above this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Paolo Perego
| style="width:15%; background:#cccccc" align="center"|Spike Reply
| style="width:63%; background:#cccccc" align="center"|As penetration tester it woud be great to me to participating in writing the new Top 10. As code reviewer and Orizon project leader it would be very interesting in scouting dynamic threats in order to add some dynamic feature to my tool.
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|David Campbell
| style="width:15%; background:#cccccc" align="center"|OWASP Denver
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Robert Mann
| style="width:15%; background:#cccccc" align="center"|RBS / ABN AMRO
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"|Troy Leach
| style="width:15%; background:#cccccc" align="center"|[https://www.pcisecuritystandards.org/ PCI Security Standards Council]
| style="width:63%; background:#cccccc" align="center"|Technical Director
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|Eoin Keary
| style="width:15%; background:#cccccc" align="center"|Ernst & Young. Long time OWASP member (Code and Testing guides)
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"| Matteo Meucci
| style="width:15%; background:#cccccc" align="center"| Minded Security
| style="width:63%; background:#cccccc" align="center"| I'd like to discuss about a new way to create the Top10 from the OWASP Community
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|Giorgio Fedon
| style="width:15%; background:#cccccc" align="center"|Minded Security
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|Andrea Cogliati
| style="width:15%; background:#cccccc" align="center"|OWASP Rochester, NY
| style="width:63%; background:#cccccc" align="center"|I volunteered as a technical writer
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|Christian Martorella
| style="width:15%; background:#cccccc" align="center"|S21sec
| style="width:63%; background:#cccccc" align="center"|Interested in participating on the creating the Top 10, share some ideas.
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|Nishi Kumar
| style="width:15%; background:#cccccc" align="center"|Systems Architect (FIS) Global Web Development Group
| style="width:63%; background:#cccccc" align="center"|Interested in participating and sharing ideas

|-
| style="width:7%; background:#7B8ABD" align="center"|11
| style="width:15%; background:#cccccc" align="center"| Tom Brennan
| style="width:15%; background:#cccccc" align="center"| OWASP/WhiteHat Security
| style="width:63%; background:#cccccc" align="center"| Want to discuss some of the stats we can share with OWASP

|-
| style="width:7%; background:#7B8ABD" align="center"|12
| style="width:15%; background:#cccccc" align="center"| Georg Hess
| style="width:15%; background:#cccccc" align="center"| OWASP Germany
| style="width:63%; background:#cccccc" align="center"| mainly to get some insight into the process
|

|-
| style="width:7%; background:#7B8ABD" align="center"|12
| style="width:15%; background:#cccccc" align="center"| Arturo 'Buanzo' Busleiman
| style="width:15%; background:#cccccc" align="center"| Independent
| style="width:63%; background:#cccccc" align="center"| Expert Contributor for SANS TOP20 since 2005. want to contribute here.
|

|-
| style="width:7%; background:#7B8ABD" align="center"|12
| style="width:15%; background:#cccccc" align="center"| Fabio Cerullo
| style="width:15%; background:#cccccc" align="center"| AIB
| style="width:63%; background:#cccccc" align="center"| Interested in participating on the creation of the Top 10, share some ideas.
|-
| style="width:7%; background:#7B8ABD" align="center"|12
| style="width:15%; background:#cccccc" align="center"| Sébastien Gioria
| style="width:15%; background:#cccccc" align="center"| OWASP France
| style="width:63%; background:#cccccc" align="center"| Interested in reviewing and give some Point of View frome France ans some pentesting made here. Also interessted to translate it as soon as possible for our France Market.
|-
| style="width:7%; background:#7B8ABD" align="center"|13
| style="width:15%; background:#cccccc" align="center"| Marco Mella
| style="width:15%; background:#cccccc" align="center"| Independent
| style="width:63%; background:#cccccc" align="center"|

|}

[[Category:OWASP_Working_Session]]

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-21T09:07:22Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from http://www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The service offer, for example, to search all UDDI with a specific string in business names, service name or service types. 

'''Advanced UDDI browsing''' 

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
To invoke a web services from command line, we can create a SOAP request file
similar to the following one an then use CURL to submit it to server. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 
-SQL Injection 

==References==
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html
* WebServices Testing: http://www.aboutsecurity.net
 
'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
* Soaplite: http://www.soaplite.com
* Perl: http://www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/
* CURL: http://curl.haxx.se
 
'''On-line tools''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org

OWASP Testing Guide v3 Table of Contents

2008-09-16T08:06:57Z

Mmella: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

Testing Guide v3 (draft)
Updated: 15th September 2008

'''T A B L E o f C O N T E N T S'''
----

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 100%) 2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 100%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

[[Testing: Information Gathering|'''4.2 Information Gathering''']]

[[Testing: Spiders Robots and Crawlers|(C.Heinrich)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(C.Heinrich)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity)]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(imp: A. Goodman - 100%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 100%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(K.Horvath - 100% - adam updated) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon - 100%) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: A. Goodman - 100%) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (M.Meucci - 100% (updated by adam)) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new:S.Di Paola - 100%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]

[[Testing for MS Access|(new:A.Parata - 100%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[Testing for Heap Overflow|4.8.14.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.14.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.14.3 Testing for Format string]]

[[Testing for Incubated Vulnerability|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci, M.Mella -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci, M.Mella -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci, M.Mella -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish Sureddy)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-15T07:38:51Z

Mmella: /* References */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from http://www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The service offer, for example, to search all UDDI with a specific string in business names, service name or service types. 

'''Advanced UDDI browsing''' 

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
To invoke a web services from command line, we can create a SOAP request file
similar to the following one an then use CURL to submit it to server. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html
* WebServices Testing: http://www.aboutsecurity.net
 
'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
* Soaplite: http://www.soaplite.com
* Perl: http://www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/
* CURL: http://curl.haxx.se
 
'''On-line tools''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-14T14:10:33Z

Mmella: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server, when we provide a valid username is different than when we use an invalid one.

In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

against any message that reveals the existence of user, for instance, message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 responses. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
'''Other ways to enumerate users''' 
We can enumerate users in several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provide a userID and password to the web application, we see a message indication that an error has occurred in the URL.
In the first case we has provided a bad userID and bad password. In the second, a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometimes a web server responds differently if it receives a request for an existing directories or not. For instance in some portals every user is associated with a directory, if we try to access an existing directory we could receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exists, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance, if we cannot authenticate to an application and receive a web page whose title is similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could return a message that reveala if a username exists or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''- Friendly 404 Error Message''' 
When we request for a user within the directory that does not exist, we don't always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some cases the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL.

Again, we can guess a username from the information received from an LDAP query or from a google information gathering for example from a specific domain.
Google for example can help to find domain users through a specific queries or through a simple shell script or tool.

For other information on guessing for userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing have the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
Marco Mella, ''Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net ''
''Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities ''

'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org
* Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T19:24:51Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from http://www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The service offer, for example, to search all UDDI with a specific string in business names, service name or service types. 

'''Advanced UDDI browsing''' 

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
To invoke a web services from command line, we can create a SOAP request file
similar to the following one an then use CURL to submit it to server. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T06:57:29Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from http://www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The service offer, for example, to search all UDDI with a specific string in business names, service name or service types. 

'''Advanced UDDI browsing''' 

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 
Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing WSDL (OWASP-WS-002)

2008-09-13T06:54:50Z

Mmella: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Once that the WSDL is identified, we can test that entry point.

== Description of the Issue ==
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.

== Black Box testing and example ==

Given the Standard SOAP message that the Web services supplier waits from Web services consumer, you can craft a particular message that invoke some hidden operations.
'''Example:''' 
A good example is WebGoat 5.0 WSDL Scanning lesson. The following is a screenshot from that lesson: 
<center>
[[Image:WSDLWebGoat.png]]
</center>
 Here we have an interface that invokes a Web Service using only FirstName, LastName, and Login Count as parameters. 
If you look at the relative WSDL you will find:

...
<wsdl:portType name="WSDLScanning">
<wsdl:operation name="'''getFirstName'''" parameterOrder="id">
<wsdl:input message="impl:getFirstNameRequest" name="getFirstNameRequest"/>
<wsdl:output message="impl:getFirstNameResponse" name="getFirstNameResponse"/>

</wsdl:operation>
<wsdl:operation name="'''getLastName'''" parameterOrder="id">
<wsdl:input message="impl:getLastNameRequest" name="getLastNameRequest"/>
<wsdl:output message="impl:getLastNameResponse" name="getLastNameResponse"/>
</wsdl:operation>

<wsdl:operation name="'''getCreditCard'''" parameterOrder="id">
<wsdl:input message="impl:getCreditCardRequest" name="getCreditCardRequest"/>
<wsdl:output message="impl:getCreditCardResponse" name="getCreditCardResponse"/>
</wsdl:operation>

<wsdl:operation name="'''getLoginCount'''" parameterOrder="id">
<wsdl:input message="impl:getLoginCountRequest" name="getLoginCountRequest"/>
<wsdl:output message="impl:getLoginCountResponse" name="getLoginCountResponse"/>
</wsdl:operation>
</wsdl:portType>
...

We find 4 operations and not only 3. Using WebScarab Web Service plugin, we can craft a SOAP Request to get the Credit Card given a specific ID.
<center>
[[Image:WSDLWebScarab.png]]
</center>

The SOAP Request resulting from this request is:
POST http://localhost:80/WebGoat/services/SoapRequest HTTP/1.0
Accept: application/soap+xml, application/dime, multipart/related, text/*
Host: localhost:80
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-length: 576
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=

<?xml version='1.0' encoding='UTF-8'?>
<wsns0:Envelope
xmlns:wsns1='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'>
<wsns0:Body
wsns0:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>
<wsns2:'''getCreditCard'''
xmlns:wsns2='http://lessons.webgoat.owasp.org'>
<id xsi:type='xsd:int'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
>'''101'''</id>
</wsns2:getCreditCard>
</wsns0:Body>
</wsns0:Envelope>

And the SOAP Response with the credit card number (987654321) is:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Wed, 28 Mar 2007 10:18:12 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:getCreditCardResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://lessons.webgoat.owasp.org">
<getCreditCardReturn xsi:type="xsd:string">'''987654321'''</getCreditCardReturn></ns1:getCreditCardResponse>
</soapenv:Body>
</soapenv:Envelope>

 
'''WSDigger'''
 
WSDigger is a free open source tool to automate web services security testing. 
With this tool we can test ours webservices interacting with them trough a simple interface
and allows to search query and invoke web services dynamically without writing code. 

When we intercat with Webservice malicious data has been entered into WSDigger the web service method must be invoked by
 
<center>
[[Image:wsdigger_part.jpg]]
 
</center>
 

'''Result expected:''' 

The tester should include full details of where the web service application permits access to an operation that is not used during normal SOAP messages and that provides access to confidential data.

'''Whitepapers''' 
* W3Schools schema introduction - http://www.w3schools.com/schema/schema_intro.asp 

'''Tools''' 
*[[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Foundstone WSDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm

Testing for XML Structural (OWASP-WS-003)

2008-09-13T06:53:29Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
XML needs to be well-formed to function properly. XML which is not well-formed shall fail when parsed by the XML parser on the server side. A parser needs to run thorough the entire XML message in a serial manner in order to assess the XML well-formedness.

An XML parser is also very CPU labour intensive. Some attack vectors exploit this weakness by sending very large or malformed XML messages.

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.

==Description of the Issue==
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.

For example, elements which contain large numbers of attributes can cause problems with parsers. This category of attack also includes XML documents which are not well-formed XML
(e.g., with overlapping elements,or with open tags that have no matching close tags).
DOM based parsing can be vulnerable to DoS due to the fact that the complete message is loaded into memory (as opposed to SAX parsing). For example, oversized attachments can cause an issue with DOM architectures.

'''Web Services weakness:''' You have to parse XML via SAX or DOM before one validates the structure and content of the message.

==Black Box Testing and example==
'''Examples:'''

Malformed structure:
The XML message must be well formed in order to be successfully parsed. Malformed SOAP messages may cause unhandled exceptions to occur;

<?xml version="1.0" encoding="ISO-8859-1"?>
<note id="666">
'''<to>'''OWASP
<from>EOIN</from>
<heading>I am Malformed '''</to>'''
</heading>
<body>Don’t forget me this weekend!</body>
</note>

'''Example 2:'''

Back to the following WS example:

http://www.example.com/ws/FindIP.asmx?WSDL

we have obtained the following ws Profile: 
[Method] GetURLIP
[Input] string EnterURL
[Output] string

A standard SOAP Request is like the following:

POST /ws/email/FindIP.asmx HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.2032)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/webservices/GetURLIP"
Content-Length: 329
Expect: 100-continue
Connection: Keep-Alive
Host: www.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetURLIP xmlns="http://example.com/webservices/">
<EnterURL>'''www.owasp.org'''</EnterURL>
</GetURLIP>
</soap:Body>
</soap:Envelope>

The SOAP Response is:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 26 Mar 2007 11:29:25 GMT
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 396

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetURLIPResponse xmlns="http://example.com/webservices/">
<GetURLIPResult>'''www.owasp.com IP Address is: 216.48.3.18'''
</GetURLIPResult>
</GetURLIPResponse>
</soap:Body>
</soap:Envelope>

An example of XML Structural testing is the following:

POST /ws/email/FindIP.asmx HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.2032)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/webservices/GetURLIP"
Content-Length: 329
Expect: 100-continue
Connection: Keep-Alive
Host: www.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetURLIP xmlns="http://example.com/webservices/">
<EnterURL>www.example.com
</GetURLIP>
</EnterURL>
</soap:Body>
</soap:Envelope>

A web service utilizing DOM based parsing can be "upset" by including a very large payload in the XML message which the parser would be obliged to parse:

'''VERY LARGE & UNEXPECTED PAYLOAD:'''

<Envelope>
<Header>
<wsse:Security>
<Hehehe>I am a Large String (1MB)</Hehehe>
<Hehehe>I am a Large String (1MB)</Hehehe>
<Hehehe>I am a Large String (1MB)</Hehehe>
<Hehehe>I am a Large String (1MB)</Hehehe>
<Hehehe>I am a Large String (1MB)</Hehehe>
<Hehehe>I am a Large String (1MB)</Hehehe>
<Hehehe>I am a Large String (1MB)</Hehehe>…
<Signature>…</Signature>
</wsse:Security>
</Header>
<Body>
<BuyCopy><ISBN>0098666891726</ISBN></BuyCopy>
</Body></Envelope>

'''Binary attachments:'''

Web Services can also have a binary attachment such as a Blob or exe.
Web service attachments are encoded in base64 format since the trend is that DIME (Direct Internet Message Encapsulation) seems to be a dead-end solution.

By attaching a very large base64 string to the message, a tester may consume parser resources to the point of affecting availability. Additional attacks may include the injection of an infected binary file into the base64 binary stream.
Inadequate parsing of such an attachment may exhaust resources:

'''UNEXPECTED LARGE BLOB:'''
<Envelope>
<Header>
<wsse:Security>
<file>jgiGldkooJSSKFM%()LFM$MFKF)$KRFWF$FRFkflfkfkkorepoLPKOMkjiujhy:llki-123-01ke123-
04QWS03994k£R$Trfe£elfdk4r-45kgk3lg"£!04040lf;lfFCVr$V$BB^^N&*<M&NNB%...........10MB</file>
<Signature>…</Signature>
</wsse:Security>
</Header>
<Body>
<BuyCopy><ISBN>0098666891726</ISBN></BuyCopy>
</Body>
</Envelope>

 
'''WSDigger''' 
Using this tool we can insert a malicious data into web service method and see the results in the output of WSDigger interface.
 

WSDigger contains also sample attack plug-ins for:
* SQL injection
* cross site scripting
* XPATH injection attacks

 
<center>
[[Image:wsdigger_attack.jpg]]
 
</center>

 

==Grey Box Testing and example==

If one has access to the schema of the web service, it should be examined. One should assess that all the parameters are being data validated.
Restrictions on appropriate values should be implemeneted in accordance to data validation best practice.

'''enumeration''': Defines a list of acceptable values

'''fractionDigits''': Specifies the maximum number of decimal places allowed.
Must be equal to or greater than zero

'''length''': Specifies the exact number of characters or list items allowed.
Must be equal to or greater than zero

'''maxExclusive''': Specifies the upper bounds for numeric values
(the value must be less than this value)

'''maxInclusive''': Specifies the upper bounds for numeric values
(the value must be less than or equal to this value)

'''maxLength''': Specifies the maximum number of characters or list items allowed.
Must be equal to or greater than zero

'''minExclusive''': Specifies the lower bounds for numeric values
(the value must be greater than this value)

'''minInclusive''': Specifies the lower bounds for numeric values
(the value must be greater than or equal to this value)

'''minLength''': Specifies the minimum number of characters or list items allowed.
Must be equal to or greater than zero

'''pattern''': Defines the exact sequence of characters that are acceptable

'''totalDigits''': Specifies the exact number of digits allowed. Must be greater than zero.

'''whiteSpace''': Specifies how white space
(line feeds, tabs, spaces, and carriage returns) is handled

==References==

'''Whitepapers''' 
* W3Schools schema introduction - http://www.w3schools.com/schema/schema_intro.asp 

'''Tools''' 
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T06:47:48Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from http://www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The service offer, for example, to search all UDDI with a specific string in business names, service name or service types. 

'''Advanced UDDI browsing''' 

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T06:42:20Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from http://www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The service offer, for example, to search all UDDI with a specific string in business names, service name or service types. 

'''Advanced UDDI browsing''' 

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T06:37:27Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 instead of .aspx extension we can also use .ascx, .asmx, .ashx extensions
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A live web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The services offer, for example, to search all UDDI offer from a specific key in business names, service name or service types.

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T06:33:04Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd). 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 or extenstions .ascx, .asmx, .ashx
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A live web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The services offer, for example, to search all UDDI offer from a specific key in business names, service name or service types.

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-13T06:13:48Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can is use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd) and/or DISCO descriptors available on Web server. 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
how we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 or extenstions .ascx, .asmx, .ashx
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A live web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from www.soapclient.com. 
How we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The services offer, for example, to search all UDDI offer from a specific key in business names, service name or service types.

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing WSDL (OWASP-WS-002)

2008-09-12T15:41:48Z

Mmella: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Once that the WSDL is identified, we can test that entry point.

== Description of the Issue ==
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.

== Black Box testing and example ==

Given the Standard SOAP message that the Web services supplier waits from Web services consumer, you can craft a particular message that invoke some hidden operations.
'''Example:''' 
A good example is WebGoat 5.0 WSDL Scanning lesson. The following is a screenshot from that lesson: 
<center>
[[Image:WSDLWebGoat.png]]
</center>
 Here we have an interface that invokes a Web Service using only FirstName, LastName, and Login Count as parameters. 
If you look at the relative WSDL you will find:

...
<wsdl:portType name="WSDLScanning">
<wsdl:operation name="'''getFirstName'''" parameterOrder="id">
<wsdl:input message="impl:getFirstNameRequest" name="getFirstNameRequest"/>
<wsdl:output message="impl:getFirstNameResponse" name="getFirstNameResponse"/>

</wsdl:operation>
<wsdl:operation name="'''getLastName'''" parameterOrder="id">
<wsdl:input message="impl:getLastNameRequest" name="getLastNameRequest"/>
<wsdl:output message="impl:getLastNameResponse" name="getLastNameResponse"/>
</wsdl:operation>

<wsdl:operation name="'''getCreditCard'''" parameterOrder="id">
<wsdl:input message="impl:getCreditCardRequest" name="getCreditCardRequest"/>
<wsdl:output message="impl:getCreditCardResponse" name="getCreditCardResponse"/>
</wsdl:operation>

<wsdl:operation name="'''getLoginCount'''" parameterOrder="id">
<wsdl:input message="impl:getLoginCountRequest" name="getLoginCountRequest"/>
<wsdl:output message="impl:getLoginCountResponse" name="getLoginCountResponse"/>
</wsdl:operation>
</wsdl:portType>
...

We find 4 operations and not only 3. Using WebScarab Web Service plugin, we can craft a SOAP Request to get the Credit Card given a specific ID.
<center>
[[Image:WSDLWebScarab.png]]
</center>

The SOAP Request resulting from this request is:
POST http://localhost:80/WebGoat/services/SoapRequest HTTP/1.0
Accept: application/soap+xml, application/dime, multipart/related, text/*
Host: localhost:80
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-length: 576
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=

<?xml version='1.0' encoding='UTF-8'?>
<wsns0:Envelope
xmlns:wsns1='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'>
<wsns0:Body
wsns0:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>
<wsns2:'''getCreditCard'''
xmlns:wsns2='http://lessons.webgoat.owasp.org'>
<id xsi:type='xsd:int'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
>'''101'''</id>
</wsns2:getCreditCard>
</wsns0:Body>
</wsns0:Envelope>

And the SOAP Response with the credit card number (987654321) is:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Wed, 28 Mar 2007 10:18:12 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:getCreditCardResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://lessons.webgoat.owasp.org">
<getCreditCardReturn xsi:type="xsd:string">'''987654321'''</getCreditCardReturn></ns1:getCreditCardResponse>
</soapenv:Body>
</soapenv:Envelope>

 
'''WSDigger'''
 
WSDigger is a free open source tool to automate web services security testing. 
With this tool we can test ours webservices interacting with them trough a simple interface
and allows to search query and invoke web services dynamically without writing code. 

When we intercat with Webservice malicious data has been entered into WSDigger the web service method must be invoked by
 
<center>
[[Image:wsdigger_part.jpg]]
 
</center>
 

Using this tool we can insert a malicious data into web service method and see the results in the output of WSDigger interface.
 

WSDigger contains also sample attack plug-ins for:
* SQL injection
* cross site scripting
* XPATH injection attacks

 
<center>
[[Image:wsdigger_attack.jpg]]
 
</center>

 

'''Result expected:''' 

The tester should include full details of where the web service application permits access to an operation that is not used during normal SOAP messages and that provides access to confidential data.

'''Whitepapers''' 
* W3Schools schema introduction - http://www.w3schools.com/schema/schema_intro.asp 

'''Tools''' 
*[[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Foundstone WSDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm

File:Wsdigger attack.jpg

2008-09-12T15:22:55Z

Mmella:

File:Wsdigger part.jpg

2008-09-12T15:22:20Z

Mmella:

Testing WSDL (OWASP-WS-002)

2008-09-12T15:21:59Z

Mmella: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Once that the WSDL is identified, we can test that entry point.

== Description of the Issue ==
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.

== Black Box testing and example ==

Given the Standard SOAP message that the Web services supplier waits from Web services consumer, you can craft a particular message that invoke some hidden operations.
'''Example:''' 
A good example is WebGoat 5.0 WSDL Scanning lesson. The following is a screenshot from that lesson: 
<center>
[[Image:WSDLWebGoat.png]]
</center>
 Here we have an interface that invokes a Web Service using only FirstName, LastName, and Login Count as parameters. 
If you look at the relative WSDL you will find:

...
<wsdl:portType name="WSDLScanning">
<wsdl:operation name="'''getFirstName'''" parameterOrder="id">
<wsdl:input message="impl:getFirstNameRequest" name="getFirstNameRequest"/>
<wsdl:output message="impl:getFirstNameResponse" name="getFirstNameResponse"/>

</wsdl:operation>
<wsdl:operation name="'''getLastName'''" parameterOrder="id">
<wsdl:input message="impl:getLastNameRequest" name="getLastNameRequest"/>
<wsdl:output message="impl:getLastNameResponse" name="getLastNameResponse"/>
</wsdl:operation>

<wsdl:operation name="'''getCreditCard'''" parameterOrder="id">
<wsdl:input message="impl:getCreditCardRequest" name="getCreditCardRequest"/>
<wsdl:output message="impl:getCreditCardResponse" name="getCreditCardResponse"/>
</wsdl:operation>

<wsdl:operation name="'''getLoginCount'''" parameterOrder="id">
<wsdl:input message="impl:getLoginCountRequest" name="getLoginCountRequest"/>
<wsdl:output message="impl:getLoginCountResponse" name="getLoginCountResponse"/>
</wsdl:operation>
</wsdl:portType>
...

We find 4 operations and not only 3. Using WebScarab Web Service plugin, we can craft a SOAP Request to get the Credit Card given a specific ID.
<center>
[[Image:WSDLWebScarab.png]]
</center>

The SOAP Request resulting from this request is:
POST http://localhost:80/WebGoat/services/SoapRequest HTTP/1.0
Accept: application/soap+xml, application/dime, multipart/related, text/*
Host: localhost:80
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-length: 576
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=

<?xml version='1.0' encoding='UTF-8'?>
<wsns0:Envelope
xmlns:wsns1='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'>
<wsns0:Body
wsns0:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>
<wsns2:'''getCreditCard'''
xmlns:wsns2='http://lessons.webgoat.owasp.org'>
<id xsi:type='xsd:int'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
>'''101'''</id>
</wsns2:getCreditCard>
</wsns0:Body>
</wsns0:Envelope>

And the SOAP Response with the credit card number (987654321) is:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Wed, 28 Mar 2007 10:18:12 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:getCreditCardResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://lessons.webgoat.owasp.org">
<getCreditCardReturn xsi:type="xsd:string">'''987654321'''</getCreditCardReturn></ns1:getCreditCardResponse>
</soapenv:Body>
</soapenv:Envelope>

 
'''WSDigger'''
 
WSDigger is a free open source tool to automate web services security testing. 
With this tool we can test ours webservices interacting with them trough a simple interface. 

 
<center>
[[Image:wsdigger_part.jpg]]
 
</center>

WSDigger contains sample attack plug-ins for:
* SQL injection
* cross site scripting
* XPATH injection attacks

 
<center>
[[Image:wsdigger_attack.jpg]]
 
</center>

'''Result expected:''' 

The tester should include full details of where the web service application permits access to an operation that is not used during normal SOAP messages and that provides access to confidential data.

'''Whitepapers''' 
* W3Schools schema introduction - http://www.w3schools.com/schema/schema_intro.asp 

'''Tools''' 
*[[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Foundstone WSDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm

File:WSdigger part.jpg

2008-09-12T15:15:45Z

Mmella:

File:Wsdigger.jpg

2008-09-12T15:07:48Z

Mmella:

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-12T14:34:45Z

Mmella: /* References */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can is use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd) and/or DISCO descriptors available on Web server. 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
as we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 or extenstions .ascx, .asmx, .ashx
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A live web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from www.soapclient.com. 
As we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The services offer, for example, to search all UDDI offer from a specific key in business names, service name or service types.

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==
 
* DISCO: http://msdn.microsoft.com/en-us/magazine/cc302073.aspx
* UDDI OASIS Standard: http://www.oasis-open.org/specs/index.php#uddiv3.0.2
* Undestanding UDDI: http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/index.html

 

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin
* Mac OSX Soap Client: http://www.ditchnet.org/soapclient
* Foundstone WsDigger: http://www.foundstone.com/us/resources/proddesc/wsdigger.htm
 
'''Web Resource''' 
* Web Services Directory: http://www.wsindex.org
* Seekda: http://seekda.com/
* UDDI Browser: http://www.soapcliet.com/
* Xmethods: http://www.xmethods.net
* WSIndex: http://www.wsindex.org
 
* Soaplite: www.soaplite.com
* Perl: www.perl.com
* SOAPClient4XG: http://www-128.ibm.com/developerworks/xml/library/x-soapcl/

Testing: WS Information Gathering (OWASP-WS-001)

2008-09-12T14:26:47Z

Mmella: /* Black Box Testing and example */

{{Template:OWASP Testing Guide v3}}

==Brief Summary==
The first step to perform a Web Service Testing is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS.

==Black Box Testing and example==
'''Zero Knowledge''' 
Normally you will have a WSDL path to access the Web Service, but if you have zero knowledge about it, you will have to use UDDI to find a specific service.
Web Services have three critical building blocks – UDDI, WSDL and SOAP. There is a third intermediate player facilitating communication between the consumer and supplier, referred to as Universal Business Registry (UBR).
There are several ways to find our WSDL: the easiest one is to make a search Query in public search engine. For example if you have to assess an example.com public WS, on google.com you can type:

inurl:wsdl site:example.com

and you will find all the public Example WSDL.
Net Square wsPawn is a useful tool that acts as Web Services Consumer and makes a query to the UBR and looks for services as per requirements. Then UBR supplies the list of available services. The Web Services Consumer chooses one or more available services. Next, Web Services Consumer requests for an access point or end point for these services. UBR supplies this information. From this moment Web Services Consumer approaches the Web Services Supplier’s Host/IP address (WDSL) and starts accessing service. 

'''WSDL endpoints''' 
When a tester accesses to the WSDL, he can determine an access point and available interfaces for web services. These interfaces or methods take inputs using SOAP over HTTP/HTTPS. If these inputs are not defined well at the source code level, they can be compromised and exploited.
For example given this WDSL Endpoint:

http://www.example.com/ws/FindIP.asmx?WSDL

you can obtain the following description of the Web Services:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://example.com/webservices/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/webservices/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://example.com/webservices/">
<s:element name="GetURLIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="EnterURL" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetURLIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetURLIPResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetURLIPSoapIn">
<wsdl:part name="parameters" element="tns:GetURLIP" />
</wsdl:message>
<wsdl:message name="GetURLIPSoapOut">
<wsdl:part name="parameters" element="tns:GetURLIPResponse" />
</wsdl:message>
<wsdl:message name="GetURLIPHttpGetIn">
<wsdl:part name="EnterURL" type="s:string" />
……
</wsdl:service>
</wsdl:definitions>
</pre>
This WS simply receives in input a logical name (EnterURL) and gives in output the realtive IP Address. So we have GetURLIP as method for the WS and EnterURL (string) as input.
In that manner we have identified the WS entry point and we are ready to test it.
 
 
'''Web Services Discovery''' 
Web Services consumer need a simple and standardized ways to find a Web Services available from from remote servers.
There are two ways for the discovery a Web Services, DISCO and UDDI. 
The Web Service Discovery (DISCO) is one way that we can is use to discover the URLs WSDL descriptor and other XML documents, like Schema Definition Document (.xsd) and/or DISCO descriptors available on Web server. 

For istance with a http query to a Web server:
http://myexample.com/myexampleService.asmx?DISCO

we obtain a following one DISCO descriptor:
 
<pre>
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://myexample.com/MyexampleService.asmx?wsdl" docRef="http://myexample.com/myexample.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap address="http://myexample.com/MyexampleService.asmx" xmlns:q1="http://myexample.com/terraserver/" binding="q1:myexampleServiceSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>
</pre>
 
as we can see in the above XML document we have a reference for WSDL document where obtain a descriptions of Web Services available from remote Web Server.

DISCO is a Microsoft tecnology, UDDI (Universal Description, Discovery and Integration) instead is a OASIS standard .
 
'''WS Well Known Naming''' 
Common Web Services platforms have a naming convention for offering a WSDL documents: This naming convention can be used to retrieve WSDL via URIs probing or through queries to web search server.

Some URLs that we can use are for example:

http://<webservice-host>:<port>/<servicename>
http://<webservice-host>:<port>/<servicename>.wsdl
http://<webservice-host>:<port>/<servicename>?wsdl
http://<webservice-host>:<port>/<servicename>.aspx?wsdl
 or extenstions .ascx, .asmx, .ashx
 Same thing with ?disco instead of ?wsdl

http://<webservice-host>:<port>/<servicename.dll>?wsdl
http://<webservice-host>:<port>/<servicename.exe>?wsdl
http://<webservice-host>:<port>/<servicename.php>?wsdl
http://<webservice-host>:<port>/<servicename.pl>?wsdl

For Apache Axis we can try:
http://<webservice-host>:<port>/axis/services/<servicename>?wsdl
http://<webservice-host>:<port>/axis/services/<service-name>
 
 

'''Search for public Web Services''' 
The seekda Web Services Search Engine can help to find a public Web Services with related descriptions.
To find Web Services just type the keyword into seekda Web Services Search Engine. We can also browse by several other criteria such as Tag Cloud, Services by Countries, Most Used Services.
http://seekda.com
 

[[Image:seekda.jpg]]

 
Another Web Server with good links and Resources is WSindex (http://www.wsindex.org).

[[Image:wsindex.png]]
 
 
''' UDDI Browser''' 
A live web server that provide a very useful UDDI on-line tool for to browse and search public UDDI resource in offered from www.soapclient.com. 
As we can see we can use two operator Microsoft and Xmethods

[[Image:uddi_browser_part.jpg]]
 

The services offer, for example, to search all UDDI offer from a specific key in business names, service name or service types.

We can search private UDDI registries using Avanced feature of UDDI browser.
 
[[Image:uddi_browser.jpg]]
 
 
This services allow interaction with Web services dynamically. 
Soapclient offer others methods for to allow to discover web services and usefull links to other resources.

 
 

'''Command line interaction'''
 
Sometimes are usefull interact with webservives from a command line.
 
 
Simple SOAP Client - SOAPClient4XG 
SOAP Client for XML allow to make a SOAP request from command line, for example:

java -jar SOAPClient4XG http://api.google.com/search/beta2 my_sample_search.xml 
 

CURL 
We can also consume a Webservices using CURL. 
For example: 

curl --request POST --header “Content-type: text/xml 
--data @my_request.xml http://api.google.com/search/beta2 

Perl - SOAPlite 
With Perl and SOAP::lite modules we can create a scripts to automatize a SOAP request. 

'''SOAP XML File'''
 
For create a basic SOAP XML file for Webservices request, we can simple use a RAW request and create an SOAP XML request. 
For example we can create a SOAP XML similar to to the following one to invoke the webservices. 

<pre>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetZip xmlns:m="http://namespaces.example.com">
<country>Italy</country>
<city>Roma</city>
</m:GetZip>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>
</pre>

 
 

Creating a malformed XML file we can test a Webservices for a typical attack as the following: 
-oversized XML Tag 
-nested or recursive declarations 
-parameter attack 
-authentication testing 
-XSS 

==References==

'''Tools''' 
* Net Square wsPawn
* [[OWASP_WebScarab_Project|OWASP WebScarab]]: Web Services plugin

File:Seekda.jpg

2008-09-12T11:27:32Z

Mmella:

File:Uddi browser part.jpg

2008-09-12T11:21:07Z

Mmella:

File:Uddi browser.jpg

2008-09-12T11:15:34Z

Mmella:

File:Wsindex.png

2008-09-12T11:07:18Z

Mmella:

File:Wsindex.jpg

2008-09-12T11:03:20Z

Mmella:

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-05T08:54:01Z

Mmella: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from web application or web server, when we provide a valid username is different than we use an invalid usename.

In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
Google for example can helps to find domain users through a specific queries or through a simple shell scripts or tools.

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-05T08:52:03Z

Mmella: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from web application or web server, when we provide a valid username is different than we use an invalid usename.

In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
Google for example can helps to find domain users through a specific queries or through a simple tools like finger google.

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-05T08:26:26Z

Mmella: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from web application or web server, when we provide a valid username is different than we use an invalid usename.

In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
Google for example can helps to find domain users through a specific queries or through a simple tools like finger google.

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org
* Finger Google (module of Twister): http://sourceforge.net/projects/wf-twister/

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-05T08:23:17Z

Mmella: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from web application or web server, when we provide a valid username is different than we use an invalid usename.

In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
Google for example can helps to find domain users through a specific queries or through a simple tools like finger google.

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-03T12:03:00Z

Mmella: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from web application or web server, when we provide a valid username is different than we use an invalid usename.

In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
From google we can found for example a email address that can be used for users enumeration. (finger google…)

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-03T11:47:11Z

Mmella: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from applications responds to a valid username differently than a username is invalid.
In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
From google we can found for example a email address that can be used for users enumeration. (finger google…)

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-03T11:44:08Z

Mmella: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from applications responds to a valid username differently than a username is invalid.
In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
From google we can found for example a email address that can be used for users enumeration. (finger google…)

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-03T11:43:02Z

Mmella: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from applications responds to a valid username differently than a username is invalid.
In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities.
If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
 
 
'''HTTP Response message'''
 
'''Testing for Valid user/right password'''
 
Record the server answer when you submit a valid userID and valid password.
 

'''Result Expected:''' 
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
 

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

again any message that reveal the existence of user, for istance message similar to: 
Login for User foo: invalid password
 

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 
 
'''Testing for a nonexistent username''' 
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:''' 
If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account
 

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer. 
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 
 
'''Other way to enumerate users''' 
We can enumerate users in other several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze. 

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2
 
As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL.
In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.
 
 

'''- URI Probing''' 
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
 
In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.
 

'''- Analyzing Web page Title''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:
Invalid user
Invalid authentication

 
 
'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''-Friendly 404 Error Message''' 
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some case the userIDs are created with specific policies of administrator or company.
For example we can view a users with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the username are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain.
From google we can found for example a email address that can be used for users enumeration. (finger google…)

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
'Credentials submitted are not valid'
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]

File:NoConfFound.jpg

2008-09-03T10:21:30Z

Mmella: uploaded a new version of "Image:NoConfFound.jpg"

File:NoConfFound.jpg

2008-09-03T10:13:33Z

Mmella:

File:No conf found.png

2008-09-03T10:11:25Z

Mmella:

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2008-09-03T09:53:33Z

Mmella: /* Description of the Issue */

Testing for Web Application Fingerprint (OWASP-IG-004)

2007-02-07T15:59:28Z

Mmella:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

== Description of the Issue ==
There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, do different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Black Box testing and example ==
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html

$
</pre>

from the ''Server'' field we understand that the server is Apache, version 1.3.3, running on Linux operating system.
Three examples of the HTTP response headers are shown below:

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>
From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is not so good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1
Forbidden Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML;
charset=iso-8859-1
</pre>

In this case the server field of that response is obfuscated: we cannot know what type of web server is running.

=== Protocol behaviour ===
Refined techniques of testing take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

'''HTTP header field ordering'''
The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise and IIS.

'''Malformed requests test'''
Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
We consider the following HTTP response:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. An analogous issue comes if we create requests with a non-existant protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

=== Automated Testing ===
The tests to carry out testing can be several. A tool that automates these tests is "''httprint''" that allows one, through a signature dictionary, to recognize the type and the version of the web server in use. 
An example of such tool is shown below: 

[[Image:httprint.jpg]]

=== OnLine Testing ===
On Line tool that often delivers a lot of informations on target Web Server, very useful for Penetration Testing, is Netcraft.
With this tool we can retrive informations about Operating System, Web Server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S. 
An example is shown below: 

[[Image:netcraft.jpg]]

== References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://net-square.com/httprint/httprint_paper.html
'''Tools''' 
* httprint - http://net-square.com/httprint/index.shtml
* Netcraft - http://www.netcraft.com

{{Category:OWASP Testing Project AoC}}

Testing for Web Application Fingerprint (OWASP-IG-004)

2007-02-07T14:38:12Z

Mmella: /* OnLine Testing */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

== Description of the Issue ==
There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, do different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Black Box testing and example ==
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html

$
</pre>

from the ''Server'' field we understand that the server is Apache, version 1.3.3, running on Linux operating system.
Three examples of the HTTP response headers are shown below:

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>
From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is not so good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1
Forbidden Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML;
charset=iso-8859-1
</pre>

In this case the server field of that response is obfuscated: we cannot know what type of web server is running.

== Protocol behaviour ==
Refined techniques of testing take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

=== HTTP header field ordering ===
The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise and IIS.

=== Malformed requests test ===
Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
We consider the following HTTP response:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. An analogous issue comes if we create requests with a non-existant protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>
== OnLine Testing ==
On Line tool that often delivers a lot of information on target Web Server very useful for Penetration Testing is Netcraft.
With this tool we can retrive informations about Operating System, Web Server used, Server Uptime, Netblock Owner, history of change related to Web server, O.S. 
An example is show below: 

[[Image:netcraft.jpg]]

== References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://net-square.com/httprint/httprint_paper.html
'''Tools''' 
* httprint - http://net-square.com/httprint/index.shtml

== OnLine Testing ==
On Line tool that often delivers a lot of information on target Web Server very useful for Penetration Testing is Netcraft.
With this tool we can retrive information about Operating System, Web Server used, Server Uptime, Netblock Owner, history of change related to Web server, O.S. 

[[Image:netcraft.jpg]]

== References ==
'''Tools''' 
* Netcraft - http://www.netcraft.com

{{Category:OWASP Testing Project AoC}}

File:Netcraft.jpg

2007-02-07T14:31:41Z

Mmella:

Testing for Web Application Fingerprint (OWASP-IG-004)

2007-02-07T14:12:05Z

Mmella:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

== Description of the Issue ==
There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, do different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Black Box testing and example ==
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html

$
</pre>

from the ''Server'' field we understand that the server is Apache, version 1.3.3, running on Linux operating system.
Three examples of the HTTP response headers are shown below:

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>
From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is not so good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1
Forbidden Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML;
charset=iso-8859-1
</pre>

In this case the server field of that response is obfuscated: we cannot know what type of web server is running.

== Protocol behaviour ==
Refined techniques of testing take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

=== HTTP header field ordering ===
The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise and IIS.

=== Malformed requests test ===
Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
We consider the following HTTP response:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. An analogous issue comes if we create requests with a non-existant protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>
== Automated Testing ==
The tests to carry out testing can be several. A tool that automates these tests is "''httprint''" that allows one, through a signature dictionary, to recognize the type and the version of the web server in use. 
An example of such tool is shown below: 

[[Image:httprint.jpg]]

== References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://net-square.com/httprint/httprint_paper.html
'''Tools''' 
* httprint - http://net-square.com/httprint/index.shtml

== OnLine Testing ==
On Line tool that often delivers a lot of information on target Web Server very useful for Penetration Testing is Netcraft.
With this tool we can retrive information about Operating System, Web Server used, Server Uptime, Netblock Owner, history of change related to Web server, O.S. 

[[Image:netcraft.jpg]]

== References ==
'''Tools''' 
* Netcraft - http://www.netcraft.com

{{Category:OWASP Testing Project AoC}}