OWASP - User contributions [en]

Buffalo

2011-07-15T18:53:39Z

Jekist: /* Call For Presentations */

File:Buffalo OWASP CFP July 2011.pdf

2011-07-15T18:50:53Z

Jekist: Buffalo OWASP Call For Presentations July 2011

Buffalo OWASP Call For Presentations July 2011

Buffalo

2011-07-15T18:47:23Z

Jekist: /* Call For Presentations */

2007-11-05T18:31:12Z

Jekist: /* Local News */

== Welcome the OWASP Buffalo NY chapter ==

The Buffalo NY chapter was formed in August 2004. We meet 4 times a year for 1 to 2 hours per meeting and discuss topics related to web application security.

== Goals & Objectives ==

It is our goal to freely distribute information related specifically to web application security. We want to ensure our members receive "free, professional-quality, open-source documentation, tools, and standards", as quoted directly from the main OWASP site. Participation is free and open to all. All are encouraged to participate.

== Chapter Officers ==

President [mailto:james.kist@gmail.com James Kist]



For information on how to join the chapter or if you would like to attend a meeting or even speak at a meeting, please send one of the officers an email. If you have any suggestions for meeting topics, please send an email with your ideas.

== Location ==

The meetings for OWASP Buffalo will be held at:
KnowledgeAir, LLC
726 Exchange St
Suite 628 (6th floor)
Buffalo, NY 14210

== Local Mailing List ==

You can sign up for the local mailing list. This list hosts discussions about chapter activity, planning for meetings and discussions about past and future presentations. To subscribe, go to http://lists.owasp.org/mailman/listinfo/owasp-buffalo and supply your email address.

== Participation ==

You can participate by either signing up for the mailing list or just show up for the next meeting!

== Local News ==

'''Next Chapter Meeting'''

The next Buffalo chapter meeting is going to be held at KnowledgeAir, LLC on Fri. Nov 16th from 8 to 10am. Details:

Date: Nov. 16th
Time: 8 to 10am
Location:
KnowledgeAir, LLC
726 Exchange St
Suite 628 (6th floor)
Buffalo, NY 14210

Agenda:
What is OWASP?
Web application security resources available at OWASP website
Quick overview of OWASP guide
Quick overview of OWASP testing guide
OWASP Top 10 web application security problems (updated in 2007)
Introduction to web application security tools
Links to websites dealing with web application security
Ideas for future meetings (group discussion)

Please note that each of the topics will be covered on an overview
level (due to time constraints). For future meetings, we can cover any
of those topics in detail. The floor will also be open to suggestions
for future meetings.

== Other Local IT Organizations ==

[http://www.isacawny.org/ ISACA WNY]

[http://www.rochissa.org/ ISSA Rochester]

[http://dc585.info/ Rochester, NY Defcon Group]

[http://www.infotechniagara.org/ infoTech Niagara]

[http://dnug.infotechniagara.org/ infoTech Niagara .NET Users Group]

[http://www.issabuffaloniagara.org/ ISSA Buffalo Niagara]

[http://www.wnysip.org/ WNYSIP - Western New York Society for Information Professionals ]

[[Category:OWASP Chapter]]

Buffalo

2007-11-05T18:29:32Z

Jekist: /* Location */

Buffalo

2007-11-05T18:28:25Z

Jekist: /* Chapter Officers */

Buffalo

2007-08-22T05:30:08Z

Jekist: /* Chapter Officers */

OWASP Spring Of Code 2007 Applications

2007-03-30T15:22:24Z

OWASP Testing Guide v2 Review Panel

2006-12-01T17:49:38Z

Jekist:

[[http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents Table of Contents]]

Update: 24th November, 23.00 (GMT+1) 

<nowiki>
**********************
</nowiki> Reviewing planning 
<nowiki>
**********************
</nowiki> 

The reviewers are:
Mark Roxberry,
Alberto Revelli,
Daniel Cuthbert,
Antonio Parata,
Matteo G.P. Flora,
Matteo Meucci,
Eoin Keary,
Stefano Di Paola,
James Kist,
Vicente Aguilera,
Mauro Bregolin,
Syed Mohamed A,
Paul Davies

* II phase reviewing

<nowiki>
*********************************************************
</nowiki> Here is the complete list of articles to be reviewed: 
<nowiki>
*********************************************************
</nowiki>

----
* '''Introduction --> reviewed by Eoin Keary'''
'''[OK]'''

----
* '''The OWASP Testing Framework -->...'''
1 of 1 article to be reviewed (Daniel doing this)

----
* '''4.1 Introduction and objectives -->.EK'''
'''[OK]'''

----
* '''4.2 Information Gathering (Reviewed by EK) --> Keary'''
9 of 10 articles reviewed -> 
* '''Testing Web Application Fingerprint''' -added new article
** (Reviewed by JK) - Corrected the English in the "Brief Summary" section. Added "Description of the Issue". In the Black-Box testing section, is it necessary to show all of the different web server versions? This information is just repeated from the referenced whitepaper. If we are going to do that, should we also include output from newer versions, such as IIS 6.0, Apache 1.3.37, Apache 2.x, etc.?
* '''Application Discovery''':
** Reviewed + updated(EK) (Maybe we should include HTTP methods for application descovery, such as HTTP HEAD command?) 
** (Bregolin) If you are referring to things such as "fingerprinting", it was hinted - and I personally agree on this - to create a new section on Web application fingerprinting. There's however a bit of overlap with Infrastructure configuration management testing
* '''Analysis of error codes''':
** Reviewed + updated(EK) 
** Besides the own error, it would be necessary to speak about the voluntary provocation of errors? (Vicente). Two examples: 
*** Example 1: Type error. (original): ?id=276 (test): ?id=X 
*** Example 2: Type conversion error. (original): ?id=276 (test): ?id=276 and 1 in (select top 1 name from sysobjects) 
** (Bregolin) Agree with the above. A testing methodology should be formalized, i.e. tester should verify if it is possible to cause information disclosure in error or diagnostic messages by tampering with user-alterable input using a set of techniques (such as type mismatch, overflow/underflow, excess input length, various forms of injection, ...)
* '''Infrastructure configuration management testing AoC''':
** Reviewed by EK. '''Not in typical guide structure -> (MM: I've changed the structure)''' 
* '''SSL/TLS Testing AoC''':
** Reviewed + updated(EK). '''(Reviewed by MM: changed the structure)''' 
* '''DB Listener Testing''':
** '''Incomplete''' 
* '''Application configuration management testing''':
** Reviewed by EK. '''Not typical guide structure -> (MM: I've changed the structure)'''
** This is generally a "white box" section. There are no examples of testing the configuration from a remote perspective. If this was the aim of the document, thats fine. '''- Need feedback on this one!!'''
** ''Sample/known files and directories'': might be good to refer to http://www.owasp.org/index.php/Old_file_testing_AoC ??
** ''Logging'': Timestamp is also important
* '''File extensions handling''' 
** contains the text: "''...To review and expand...''" - '''Is this complete??'''
** '''Need a second opinion on this one...(MM yes it is complete)'''
* '''Old file testing''': Reviewed by EK
 

----
* '''4.3 Business logic testing --> Meucci'''
1 of 1 article reviewed
'''[OK]'''

----
* '''4.4 Authentication Testing --> Roxberry (articles have been edited)'''
0 of 7 articles to be reviewed
'''[OK]'''
** 4.4 Authentication Testing (95%) : Reviewed by MR, Paul Davies to push to 100%
** 4.4.1 Default or guessable (dictionary) user account (80%) : Reviewed by MR
** 4.4.2 Brute Force (95%) : Reviewed by MR
** 4.4.3 Bypassing authentication schema (95%) : Reviewed by MR
** 4.4.4 Directory traversal/file include (100%) : Reviewed by MR
** 4.4.5 Vulnerable remember password and pwd reset (90%) Reviewed by MR
** 4.4.6 Logout and Browser Cache Management Testing (100%) Reviewed by MR

----
* '''4.5 Session Management Testing --> Syed Mohamed A'''
5 of 6 articles to be reviewed
** 4.5 Session Management Testing (95%->100%) (daniel reviewing)
** 4.5.1 Analysis of the Session Management Schema (90%->100%) (daniel reviewing)
** 4.5.2 Cookie and Session token Manipulation (100%) (daniel reviewing)
** 4.5.3 Exposed session variables (90%->100%) (daniel reviewing)
** 4.5.4 Session Riding (XSRF) (80%->100%) (daniel reviewing)
** 4.5.5 HTTP Exploit (0%) (daniel reviewing)

----
* '''4.6 Data Validation Testing --> Meucci'''
18 articles reviewed (3 are at 0%)
'''[OK]'''
** 4.6 Data Validation Testing : Reviewed by EK
*** (Bregolin) begin
*** [Note: Haven't committed the following since that would imply a substantial rewrite, let's see what others think]
*** I think that this section should first categorize what constitutes input for a web application. (Which allows to identify what must be tested, and how). i.e., obviously input fields, hidden fields, HTTP headers (such as Referer, cookies), HTTP methods etc.
*** There are other kinds of injection, such as CRLF injection.
*** SQL Injection affects SQL statements, and not queries (though usually that's the case)
*** It should be stressed that the main reason to perform data validation is to prevent application faults, i.e. unexpected behavior, that is violation of (security) requirements. Regardless of the categories of vulnerabilities listed, an application should (actually must!) verify all input against: type, length, range or domain validity. "Bad" input may not cause any of the listed vulnerabilities yet cause the application to misbehave, if it is not checked (possibly causing DoS or violating data integrity or confidentiality).
*** (Bregolin) end
** 4.6.1 Cross site scripting: Reviewed by EK (Reformatted it slightly with wiki tags). '''Not completed'''
*** Reviewed by SDP. Some thought about content structure:
***:As it is a testing guide, any other information about how to sanitize input should be referenced to Owasp Data Validation Project (no redundancy). Approach in testing section could be more schematic.
***:A kind of:
**** Special characters entities etc.
**** Context Dependent characters (an intro)
**** How to search for Reflected, stored and DOM vulnerabilities.
**** Non obvious injections (Administrative pages or non obvious pages) and second order injections (at least a small intro and/or a whitepaper/reference to incubated flaws).
** 4.6.1.1 HTTP Methods and XST Reviewed by MM. Reviewed by AP.
** 4.6.2 SQL Injection (90%->100%) Reviewed by MM. Reviewed by EK.
*** Not sure about "inferential" injection definition in "Description of Issue"
*** Added some reference to Oracle. Corrected English.
** 4.6.2.1 Stored procedure injection (40%) '''TD (not enough informations)'''
**4.6.2.2 Oracle testing (0%) '''TD (not enough informations)'''
** 4.6.2.3 MySQL testing (100%) Reviewed by MM
** 4.6.2.4 SQL Server testing (95%) Reviewed by MM. Reviewed by AR.
** 4.6.3 LDAP Injection (90%) Reviewed by MM added wp and tools
** 4.6.4 ORM Injection (100%) '''TD (not enough informations)'''
** 4.6.5 XML Injection (90%) Reviwed and updated by MM. '''WP and tools?'''
** 4.6.6 SSI Injection (95%->100%) Reviewed by MM
** 4.6.7 XPath Injection (80%) Reviewed by MM. '''Gray box section is to complete?'''
** 4.6.8 IMAP/SMTP Injection (95%->100%)Reviewed by MM
** 4.6.9 Code Injection (70%) Reviewed by MM. '''Not completed'''
** 4.6.10 OS Commanding (70%) Reviewed by MM + added an example. '''Not completed'''
** 4.6.11 Buffer overflow Testing (100%) Reviewed by MM. '''Note: these tests are not usual web app tests'''
*** (Bregolin) The point is that these are not black box tests, so where they are now they are misplaced
** 4.6.11.1 Heap overflow (100%) Reviewed by MM
** 4.6.11.2 Stack overflow (100%)Reviewed by MM
** 4.6.11.3 Format string (100%)Reviewed by MM
** 4.6.12 Incubated vulnerability testing (95%) Reviewed by MM, whitepapers?

----

* '''4.7 Denial of Service Testing--> Revelli'''
8 of 8 articles Reviewed
'''[OK] - To do the References'''
** 4.7 Denial of Service Testing 100% Reviewed by Revelli
** 4.7.1 Locking Customer Accounts 100% Reviewd by Revelli
** 4.7.2 Buffer Overflows 100% Reviewd by Revelli
** 4.7.3 User Specified Object Allocation 100% Reviewd by Revelli
** 4.7.4 User Input as a Loop Counter 100% Reviewd by Revelli
** 4.7.5 Writing User Provided Data to Disk 100% Reviewd by Revelli
** 4.7.6 Failure to Release Resources 100% Reviewd by Revelli
** 4.7.7 Storing too Much Data in Session 100% Reviewd by Revelli

----
* '''4.8 Web Services Testing --> Matteo Meucci'''
6 of 6 articles reviewed
'''[OK]'''
** 4.8 Web Services Testing (100%) Reviewed by Meucci
** 4.8.1 XML Structural Testing (100%) Reviewed by Meucci
** 4.8.2 XML content-level Testing (90%->100%) Reviewed by Meucci
** 4.8.3 HTTP GET parameters/REST Testing (100%) Reviewed by Meucci
** 4.8.4 Naughty SOAP attachments (95%->100%) Reviewed by Meucci
** 4.8.5 Replay Testing (95%->100%) Reviewed by Meucci.

----
* '''4.9 AJAX Testing --> Roxberry'''
3 of 3 articles to be reviewed
** 4.9 AJAX Testing (70%)
** 4.9.1 Vulnerabilities (60%)
** 4.9.2 How to test (60%)

----
* '''5. Writing Reports: value the real risk'''
We have to write about it. I consider it not yet finished.
O of 3 articles to be reviewed.

----
* '''Appendix A: Testing Tools -->Review and updated by Meucci'''
0 article of 1: need a paragraph to describe each OWASP tool

----
* '''Appendix B: Suggested Reading -->...'''
1 article of 1: need to update it

----
* '''Appendix C: Fuzz Vectors --> Stefano Di Paola, Subere '''
ok. Some other fuzz vectors could be added. 
How about every author to add his specific fuzz vector section? 
[Meucci] Good idea. I think that we have not to write a brief description of each fuzz vectors (this is an appendix).
Example:

LDAP Injection: 

<nowiki>*)(|%26 
... </nowiki>

----

<nowiki>
*************************
</nowiki> 
Reviewers Rules 
<nowiki>
*************************
</nowiki>

1) Check the english language 
2) Check the template: the articles on chapter 4 should have the following: 

* Template (http://www.owasp.org/index.php/Template_Paragraph_Testing_AoC)

In some articles we don't need to talk about Gray Box Testing or other, so we can eliminate it.

3) Check the reference style. (I'd like to have all the referenced URLs visible because I have to produce also a pdf document of the Guide).
I agree with Stefano, we have to use a reference like that:

<nowiki>== References ==</nowiki>

<nowiki>'''Whitepapers''' </nowiki>

<nowiki>* [1] Author1, Author2: "Title" - http://www.ietf.org/rfc/rfc2254.txt </nowiki>

<nowiki>* [2]... </nowiki>

<nowiki>'''Tools''' </nowiki>

<nowiki>* Francois Larouche: "Multiple DBMS Sql Injection tool" - http://www.sqlpowerinjector.com/index.htm </nowiki>

4) Check the reference with the other articles of the guide or with the other OWASP Project.

5) Other?

OWASP Testing Guide v2 Review Panel

2006-12-01T17:45:32Z

Jekist:

[[http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents Table of Contents]]

Update: 24th November, 23.00 (GMT+1) 

<nowiki>
**********************
</nowiki> Reviewing planning 
<nowiki>
**********************
</nowiki> 

The reviewers are:
Mark Roxberry,
Alberto Revelli,
Daniel Cuthbert,
Antonio Parata,
Matteo G.P. Flora,
Matteo Meucci,
Eoin Keary,
Stefano Di Paola,
James Kist,
Vicente Aguilera,
Mauro Bregolin,
Syed Mohamed A,
Paul Davies

* II phase reviewing

<nowiki>
*********************************************************
</nowiki> Here is the complete list of articles to be reviewed: 
<nowiki>
*********************************************************
</nowiki>

----
* '''Introduction --> reviewed by Eoin Keary'''
'''[OK]'''

----
* '''The OWASP Testing Framework -->...'''
1 of 1 article to be reviewed (Daniel doing this)

----
* '''4.1 Introduction and objectives -->.EK'''
'''[OK]'''

----
* '''4.2 Information Gathering (Reviewed by EK) --> Keary'''
9 of 10 articles reviewed -> 
* '''Testing Web Application Fingerprint''' -added new article
(Reviewed by JK) - Corrected the English in the "Brief Summary" section. Added "Description of the Issue". In the Black-Box testing section, is it necessary to show all of the different web server versions? This information is just repeated from the referenced whitepaper. If we are going to do that, should we also include output from newer versions, such as IIS 6.0, Apache 1.3.37, Apache 2.x, etc.?
* '''Application Discovery''':
** Reviewed + updated(EK) (Maybe we should include HTTP methods for application descovery, such as HTTP HEAD command?) 
** (Bregolin) If you are referring to things such as "fingerprinting", it was hinted - and I personally agree on this - to create a new section on Web application fingerprinting. There's however a bit of overlap with Infrastructure configuration management testing
* '''Analysis of error codes''':
** Reviewed + updated(EK) 
** Besides the own error, it would be necessary to speak about the voluntary provocation of errors? (Vicente). Two examples: 
*** Example 1: Type error. (original): ?id=276 (test): ?id=X 
*** Example 2: Type conversion error. (original): ?id=276 (test): ?id=276 and 1 in (select top 1 name from sysobjects) 
** (Bregolin) Agree with the above. A testing methodology should be formalized, i.e. tester should verify if it is possible to cause information disclosure in error or diagnostic messages by tampering with user-alterable input using a set of techniques (such as type mismatch, overflow/underflow, excess input length, various forms of injection, ...)
* '''Infrastructure configuration management testing AoC''':
** Reviewed by EK. '''Not in typical guide structure -> (MM: I've changed the structure)''' 
* '''SSL/TLS Testing AoC''':
** Reviewed + updated(EK). '''(Reviewed by MM: changed the structure)''' 
* '''DB Listener Testing''':
** '''Incomplete''' 
* '''Application configuration management testing''':
** Reviewed by EK. '''Not typical guide structure -> (MM: I've changed the structure)'''
** This is generally a "white box" section. There are no examples of testing the configuration from a remote perspective. If this was the aim of the document, thats fine. '''- Need feedback on this one!!'''
** ''Sample/known files and directories'': might be good to refer to http://www.owasp.org/index.php/Old_file_testing_AoC ??
** ''Logging'': Timestamp is also important
* '''File extensions handling''' 
** contains the text: "''...To review and expand...''" - '''Is this complete??'''
** '''Need a second opinion on this one...(MM yes it is complete)'''
* '''Old file testing''': Reviewed by EK
 

----
* '''4.3 Business logic testing --> Meucci'''
1 of 1 article reviewed
'''[OK]'''

----
* '''4.4 Authentication Testing --> Roxberry (articles have been edited)'''
0 of 7 articles to be reviewed
'''[OK]'''
** 4.4 Authentication Testing (95%) : Reviewed by MR, Paul Davies to push to 100%
** 4.4.1 Default or guessable (dictionary) user account (80%) : Reviewed by MR
** 4.4.2 Brute Force (95%) : Reviewed by MR
** 4.4.3 Bypassing authentication schema (95%) : Reviewed by MR
** 4.4.4 Directory traversal/file include (100%) : Reviewed by MR
** 4.4.5 Vulnerable remember password and pwd reset (90%) Reviewed by MR
** 4.4.6 Logout and Browser Cache Management Testing (100%) Reviewed by MR

----
* '''4.5 Session Management Testing --> Syed Mohamed A'''
5 of 6 articles to be reviewed
** 4.5 Session Management Testing (95%->100%) (daniel reviewing)
** 4.5.1 Analysis of the Session Management Schema (90%->100%) (daniel reviewing)
** 4.5.2 Cookie and Session token Manipulation (100%) (daniel reviewing)
** 4.5.3 Exposed session variables (90%->100%) (daniel reviewing)
** 4.5.4 Session Riding (XSRF) (80%->100%) (daniel reviewing)
** 4.5.5 HTTP Exploit (0%) (daniel reviewing)

----
* '''4.6 Data Validation Testing --> Meucci'''
18 articles reviewed (3 are at 0%)
'''[OK]'''
** 4.6 Data Validation Testing : Reviewed by EK
*** (Bregolin) begin
*** [Note: Haven't committed the following since that would imply a substantial rewrite, let's see what others think]
*** I think that this section should first categorize what constitutes input for a web application. (Which allows to identify what must be tested, and how). i.e., obviously input fields, hidden fields, HTTP headers (such as Referer, cookies), HTTP methods etc.
*** There are other kinds of injection, such as CRLF injection.
*** SQL Injection affects SQL statements, and not queries (though usually that's the case)
*** It should be stressed that the main reason to perform data validation is to prevent application faults, i.e. unexpected behavior, that is violation of (security) requirements. Regardless of the categories of vulnerabilities listed, an application should (actually must!) verify all input against: type, length, range or domain validity. "Bad" input may not cause any of the listed vulnerabilities yet cause the application to misbehave, if it is not checked (possibly causing DoS or violating data integrity or confidentiality).
*** (Bregolin) end
** 4.6.1 Cross site scripting: Reviewed by EK (Reformatted it slightly with wiki tags). '''Not completed'''
*** Reviewed by SDP. Some thought about content structure:
***:As it is a testing guide, any other information about how to sanitize input should be referenced to Owasp Data Validation Project (no redundancy). Approach in testing section could be more schematic.
***:A kind of:
**** Special characters entities etc.
**** Context Dependent characters (an intro)
**** How to search for Reflected, stored and DOM vulnerabilities.
**** Non obvious injections (Administrative pages or non obvious pages) and second order injections (at least a small intro and/or a whitepaper/reference to incubated flaws).
** 4.6.1.1 HTTP Methods and XST Reviewed by MM. Reviewed by AP.
** 4.6.2 SQL Injection (90%->100%) Reviewed by MM. Reviewed by EK.
*** Not sure about "inferential" injection definition in "Description of Issue"
*** Added some reference to Oracle. Corrected English.
** 4.6.2.1 Stored procedure injection (40%) '''TD (not enough informations)'''
**4.6.2.2 Oracle testing (0%) '''TD (not enough informations)'''
** 4.6.2.3 MySQL testing (100%) Reviewed by MM
** 4.6.2.4 SQL Server testing (95%) Reviewed by MM. Reviewed by AR.
** 4.6.3 LDAP Injection (90%) Reviewed by MM added wp and tools
** 4.6.4 ORM Injection (100%) '''TD (not enough informations)'''
** 4.6.5 XML Injection (90%) Reviwed and updated by MM. '''WP and tools?'''
** 4.6.6 SSI Injection (95%->100%) Reviewed by MM
** 4.6.7 XPath Injection (80%) Reviewed by MM. '''Gray box section is to complete?'''
** 4.6.8 IMAP/SMTP Injection (95%->100%)Reviewed by MM
** 4.6.9 Code Injection (70%) Reviewed by MM. '''Not completed'''
** 4.6.10 OS Commanding (70%) Reviewed by MM + added an example. '''Not completed'''
** 4.6.11 Buffer overflow Testing (100%) Reviewed by MM. '''Note: these tests are not usual web app tests'''
*** (Bregolin) The point is that these are not black box tests, so where they are now they are misplaced
** 4.6.11.1 Heap overflow (100%) Reviewed by MM
** 4.6.11.2 Stack overflow (100%)Reviewed by MM
** 4.6.11.3 Format string (100%)Reviewed by MM
** 4.6.12 Incubated vulnerability testing (95%) Reviewed by MM, whitepapers?

----

* '''4.7 Denial of Service Testing--> Revelli'''
8 of 8 articles Reviewed
'''[OK] - To do the References'''
** 4.7 Denial of Service Testing 100% Reviewed by Revelli
** 4.7.1 Locking Customer Accounts 100% Reviewd by Revelli
** 4.7.2 Buffer Overflows 100% Reviewd by Revelli
** 4.7.3 User Specified Object Allocation 100% Reviewd by Revelli
** 4.7.4 User Input as a Loop Counter 100% Reviewd by Revelli
** 4.7.5 Writing User Provided Data to Disk 100% Reviewd by Revelli
** 4.7.6 Failure to Release Resources 100% Reviewd by Revelli
** 4.7.7 Storing too Much Data in Session 100% Reviewd by Revelli

----
* '''4.8 Web Services Testing --> Matteo Meucci'''
6 of 6 articles reviewed
'''[OK]'''
** 4.8 Web Services Testing (100%) Reviewed by Meucci
** 4.8.1 XML Structural Testing (100%) Reviewed by Meucci
** 4.8.2 XML content-level Testing (90%->100%) Reviewed by Meucci
** 4.8.3 HTTP GET parameters/REST Testing (100%) Reviewed by Meucci
** 4.8.4 Naughty SOAP attachments (95%->100%) Reviewed by Meucci
** 4.8.5 Replay Testing (95%->100%) Reviewed by Meucci.

----
* '''4.9 AJAX Testing --> Roxberry'''
3 of 3 articles to be reviewed
** 4.9 AJAX Testing (70%)
** 4.9.1 Vulnerabilities (60%)
** 4.9.2 How to test (60%)

----
* '''5. Writing Reports: value the real risk'''
We have to write about it. I consider it not yet finished.
O of 3 articles to be reviewed.

----
* '''Appendix A: Testing Tools -->Review and updated by Meucci'''
0 article of 1: need a paragraph to describe each OWASP tool

----
* '''Appendix B: Suggested Reading -->...'''
1 article of 1: need to update it

----
* '''Appendix C: Fuzz Vectors --> Stefano Di Paola, Subere '''
ok. Some other fuzz vectors could be added. 
How about every author to add his specific fuzz vector section? 
[Meucci] Good idea. I think that we have not to write a brief description of each fuzz vectors (this is an appendix).
Example:

LDAP Injection: 

<nowiki>*)(|%26 
... </nowiki>

----

<nowiki>
*************************
</nowiki> 
Reviewers Rules 
<nowiki>
*************************
</nowiki>

1) Check the english language 
2) Check the template: the articles on chapter 4 should have the following: 

* Template (http://www.owasp.org/index.php/Template_Paragraph_Testing_AoC)

In some articles we don't need to talk about Gray Box Testing or other, so we can eliminate it.

3) Check the reference style. (I'd like to have all the referenced URLs visible because I have to produce also a pdf document of the Guide).
I agree with Stefano, we have to use a reference like that:

<nowiki>== References ==</nowiki>

<nowiki>'''Whitepapers''' </nowiki>

<nowiki>* [1] Author1, Author2: "Title" - http://www.ietf.org/rfc/rfc2254.txt </nowiki>

<nowiki>* [2]... </nowiki>

<nowiki>'''Tools''' </nowiki>

<nowiki>* Francois Larouche: "Multiple DBMS Sql Injection tool" - http://www.sqlpowerinjector.com/index.htm </nowiki>

4) Check the reference with the other articles of the guide or with the other OWASP Project.

5) Other?

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

2006-12-01T17:41:24Z

Jekist:

[[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 respsonse, 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 sometimes different versions 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>
This testing methodology however is not so good. There are several techniques that allow 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 in observing the ordering of the several headers in the response. Every web server has just 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>
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 consists in sending malformed requests to the server, or requests of nonexistent pages.
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>
We notice that every server answers in a different way. The answer differs also by the version of the server. An analogous issue comes if we create requests with a not existing 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>

== Automated Testing ==
The tests to carry out can be several. A tool that automates these tests is "''httprint''" that allows, 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

{{Category:OWASP Testing Project AoC}}

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

2006-12-01T17:30:04Z

Jekist: /* Brief Summary */

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

== 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>
This testing methodology however is not so good. There are several techniques that allow 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 in observing the ordering of the several headers in the response. Every web server has just 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>
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 consists in sending malformed requests to the server, or requests of nonexistent pages.
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>
We notice that every server answers in a different way. The answer differs also by the version of the server. An analogous issue comes if we create requests with a not existing 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>

== Automated Testing ==
The tests to carry out can be several. A tool that automates these tests is "''httprint''" that allows, 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

{{Category:OWASP Testing Project AoC}}