OWASP - User contributions [en]

Project Information:Sqlibench - Final Review - Second Reviewer - F

2008-11-03T04:43:10Z

2a373:

[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The Project appears to have reached 95+% of project goals. The how to document does a good job of replacing the beanshell scripts. While the other documentation is complete and well written.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project has approached 100% of completion of deliverables and goals. The interactive benchmarking criteria application in particular is a very interesting and useful component of the project.
|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Assessment Criteria'''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The videos still should be accomplished as soon as is convenient. They will add value to a already successful project.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|}

Project Information:Sqlibench - Final Review - Second Reviewer - F

2008-11-03T04:41:22Z

2a373:

[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The Project appears to have reached 95+% of project goals. The how to document foes a good job of replacing the beanshell scripts. While the other documentation is complete and well written.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
Th project has approached 100% of completion of deliverables and goals. The interactive benchmarking criteria application in particular id a very interesting and useful component of the project.
|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Assessment Criteria'''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The videos still should be accomplished as soon as is convenient. They will add value to a already successful project.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|}

Project Information:Sqlibench - Final Review - Second Reviewer - F

2008-11-03T04:35:04Z

2a373:

[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The Project appears to have reached 95+% of project goals. The how to document foes a good job of replacing the beanshell scripts. While the other documentation is complete and well written.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Assessment Criteria'''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The videos still should be accomplished as soon as is convenient. They will add value to a already successful project.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:28:50Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project team accomlished all of it's tasks in a timely manner.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
100%
|-

| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
My concern was with the flow of the language as you move from section to section. This, of course, is a direct byproduct of having different authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style and delivery. should this be addressed in a future project or ongoing update?

Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at standardizing this by maybe adding a detailed sample test that could address each vulnerability.

Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many, including those new to web application pen testing.
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None that I know of.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
I concur with Nam. A pdf document and a presentation are still needed.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:26:54Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project team accomlished all of it's tasks in a timely manner.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
100%
|-

| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
My concern was with the flow of the language as you move from section to section. This, of course, is a direct byproduct of having different authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style and delivery.

Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at standardizing this by maybe adding a detailed sample test that could address each vulnerability.

Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many, including those new to web application pen testing.
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None that I know of.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
I concur with Nam. A pdf document and a presentation are still needed.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:26:20Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project team accomlished all of it's tasks in a timely manner.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
100%
|-

| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
My concern was with the flow of the language as you move from section to section. This, of course, is a direct byproduct of having different authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style.

Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at standardizing this by maybe adding a detailed sample test that could address each vulnerability.

Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many, including those new to web application pen testing.
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None that I know of.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
I concur with Nam. A pdf document and a presentation are still needed.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:19:58Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project team accomlished all of it's tasks in a timely manner.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
100%
|-

| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
My concern was with the flow of the language as you move from section to section. This, of course, is a direct by product of havingdifferent authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style.

Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at standardizing this by maybe adding a detailed sample test that could address each vulnerability.

Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many, including those new to web application pen testing.
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None that I know of.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
I concur with Nam. A pdf document and a presentation are still needed.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:18:22Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project team accomlished all of it's tasks in a timely manner.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
100%
|-

| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
My concern was with the flow of the language as you move from section to section. This, of course, is a direct by product of havingdifferent authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style.

Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at standardizing this by maybe adding a detailed sample test that could address each vulnerability.

Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many including those new to web application pentesting.
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None that I know of.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
I concur with Nam. A pdf document and a presentation are still needed.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:16:15Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The project team accomlished all of it's tasks in a timely manner.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
100%
|-

| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
My concern was with the flow of the language as you move from section to section. This, of course, is a direct by product of different authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style. Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at adding a detailed sample test that could address each vulnerability.
Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many including those new to web application pentesting.
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None that I know of.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
I concur with Nam. A pdf document and a presentation are still needed.
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Testing Guide 3.0 - Final Review - Second Reviewer - F

2008-10-21T18:11:14Z

2a373:

[[Project Information:template Testing Guide 3.0|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
The project team accomlished all of it's tasks in a timely manner.
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
100%
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
My concern was with the flow of the language as you move from section to section. This, of course, is a direct by product of different authors for different sections and thier different writing styles. In a couple of spots it made the guide a little "disjointed" in it's style. Likewise, Some authors offered detailed samples of using tools and syntax to test for the vulnerability while others offered general discriptions of how to test. As we move forward perhaps we could look at adding a detailed sample test that could address each vulnerability.
Or, another code project moving forward would be to create a test checklist based on the testing guide. I think it would be of benefit to many including those new to web application pentesting.
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
None that I know of.
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
None
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
I concur with Nam. A pdf document and a presentation are still needed.
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

OWASP Testing Project v3 Review Roadmap

2008-09-19T23:08:58Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 
10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interesting and relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing 
4.5.5 Testing for bypassing authentication schema 
4.5.6 Testing for vulnerable remember password and pwd reset 
4.5.7 Testing for Logout and Browser Cache Management Testing 
4.5.8 Testing for CAPTCHA 
4.5.9 Testing Multiple Factors Authentication 
* Changed some grammar (commas, capitalization) 
 
Date 16 Sept, 2008 
4.6 Authorization testing 
4.6.1 Testing for path traversal 
4.6.2 Testing for bypassing authorization schema 
4.6.3 Testing for Privilege Escalation 
 
4.7 Session Management Testing 
4.7.1 Testing for Session Management Schema 
* I made several corrections to capitalization so as to maintain consistency accross the document. 
4.7.1 Testing for Session Management Schema 
4.7.2 Testing for Cookies attributes 
4.7.3 Testing for Session Fixation 
4.7.4 Testing for Exposed Session Variables 
* Changed A first person reference to third person reference ( "My... I would expect" to "When the authenticaion... The user..") 
 
Date: 17 September 2008 
 
4.7.4 Testing for Exposed Session Variables 
4.7.5 Testing for CSRF 
4.7.6 Testing for HTTP Exploit 
 
4.8 Data Validation Testing 
4.8.1 Testing for Reflected Cross Site Scripting 
4.8.2 Testing for Stored Cross Site Scripting 
4.8.3 Testing for DOM based Cross Site Scripting 
* Section feels incomplete. The content appears to end abruptly. The author mentions source code review for Black and Greybox testing. While this is the likely test process It would be nice to include a tool-based test if one exists for those of us who are not coders and have only rudimentary experience with code. 
4.8.4 Testing for Cross Site Flashing 
* Grammar changes (singular to plural and vica versa, capitalization. 
4.8.5 Testing for SQL Injection 
4.8.5.1 Oracle Testing 
4.8.5.2 MySQL Testing
 
DATE: 19 September, 2008

4.8.5.4 MS Access Testing
4.8.5.5 Testing PostgreSQL
4.8.6 Testing for LDAP Injection
* Changed "LDAP three" to "LDAP tree"
4.8.7 Testing for ORM Injection

4.8.8 Testing for XML Injection

4.8.9 Testing for SSI Injection

4.8.10 Testing for XPath Injection

4.8.11 IMAP/SMTP Injection

4.8.12 Testing for Code Injection

4.8.13 Testing for Command Injection

4.8.14 Testing for Buffer overflow

4.8.14.1 Testing for Heap overflow

4.8.14.2 Testing for Stack overflow

4.8.14.3 Testing for Format string

4.8.15 Testing for incubated vulnerabilities

4.9 Testing for Denial of Service

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

4.9.2 Testing for DoS Locking Customer Accounts

4.9.3 Testing for DoS Buffer Overflows

4.9.4 Testing for DoS User Specified Object Allocation

4.9.5 Testing for User Input as a Loop Counter

4.9.6 Testing for Writing User Provided Data to Disk

4.9.7 Testing for DoS Failure to Release Resources

4.9.8 Testing for Storing too Much Data in Session

4.10 Web Services Testing
* Changed "HTTP" to "the HTTP"
Questions: (Mat will answer it) 
4.10.1 WS Information Gathering

4.10.2 Testing WSDL
* I made several grammar and spelling changes to the paragraph on WSDigger and it's use. The last sentence on use appeared to be incomplete. I attempted to complete it. Please review.

Testing WSDL (OWASP-WS-002)

2008-09-19T23:06:24Z

2a373:

{{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 our web services interacting with them trough a simple interface
and allows to search query and invoke web services dynamically without writing code. 

When we interact with the web service malicious data has been entered into WSDigger the web service method must be invoked by clicking on the invoke button.
 
<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 WSDL (OWASP-WS-002)

2008-09-19T23:05:06Z

2a373:

{{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 our web services interacting with them trough a simple interface
and allows to search query and invoke web services dynamically without writing code. 

When we intercat with the web service 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

OWASP Testing Project v3 Review Roadmap

2008-09-19T22:54:12Z

2a373:

Testing for Web Services

2008-09-19T22:51:57Z

2a373:

{{Template:OWASP Testing Guide v3}}

''' 4.10 Web Services Testing '''
----

SOA (Service Orientated Architecture)/Web services applications are up-and-coming systems which are enabling businesses to interoperate and are growing at an unprecedented rate.
Webservice "clients" are generally not user web front-ends but other backend servers.
Webservices are exposed to the net like any other service but can be used on HTTP, FTP, SMTP, MQ among other transport protocols.
The Web Services Framework utilizes the HTTP protocol (as standard Web Application) in conjunction with XML, SOAP, WSDL and UDDI technologies:
* The "Web Services Description Language" (WSDL) is used to describe the interfaces of a service.
* The "Simple Object Access Protocol" (SOAP) provides the means for communication between Web Services and Client Applications with XML and HTTP.
* "Universal Description, Discovery and Integration" (UDDI) is used to register and publish Web Services and their characteristics so that they can be found from potential clients.

The vulnerabilities in web services are similar to other vulnerabilities, such as SQL injection, information disclosure and leakage, but web services also have unique XML/parser related vulnerabilities, which are discussed here as well.

The following articles describes the web services testing:

[[Testing: WS Information Gathering|4.10.1 WS Information Gathering]] 
[[Testing WSDL|4.10.2 Testing WSDL]] 
[[Testing for XML Structural|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 ]]

OWASP Testing Project v3 Review Roadmap

2008-09-19T22:31:38Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-19T21:15:30Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interesting and relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing 
4.5.5 Testing for bypassing authentication schema 
4.5.6 Testing for vulnerable remember password and pwd reset 
4.5.7 Testing for Logout and Browser Cache Management Testing 
4.5.8 Testing for CAPTCHA 
4.5.9 Testing Multiple Factors Authentication 
* Changed some grammar (commas, capitalization) 
 
Date 16 Sept, 2008 
4.6 Authorization testing 
4.6.1 Testing for path traversal 
4.6.2 Testing for bypassing authorization schema 
4.6.3 Testing for Privilege Escalation 
 
4.7 Session Management Testing 
4.7.1 Testing for Session Management Schema 
* I made several corrections to capitalization so as to maintain consistency accross the document. 
4.7.1 Testing for Session Management Schema 
4.7.2 Testing for Cookies attributes 
4.7.3 Testing for Session Fixation 
4.7.4 Testing for Exposed Session Variables 
* Changed A first person reference to third person reference ( "My... I would expect" to "When the authenticaion... The user..") 
 
Date: 17 September 2008 
 
4.7.4 Testing for Exposed Session Variables 
4.7.5 Testing for CSRF 
4.7.6 Testing for HTTP Exploit 
 
4.8 Data Validation Testing 
4.8.1 Testing for Reflected Cross Site Scripting 
4.8.2 Testing for Stored Cross Site Scripting 
4.8.3 Testing for DOM based Cross Site Scripting 
* Section feels incomplete. The content appears to end abruptly. The author mentions source code review for Black and Greybox testing. While this is the likely test process It would be nice to include a tool-based test if one exists for those of us who are not coders and have only rudimentary experience with code. 
4.8.4 Testing for Cross Site Flashing 
* Grammar changes (singular to plural and vica versa, capitalization. 
4.8.5 Testing for SQL Injection 
4.8.5.1 Oracle Testing 
4.8.5.2 MySQL Testing
 
DATE: 19 September, 2008

4.8.5.4 MS Access Testing
4.8.5.5 Testing PostgreSQL
4.8.6 Testing for LDAP Injection
* Changed "LDAP three" to "LDAP tree"

Questions: (Mat will answer it)

Testing for LDAP Injection (OTG-INPVAL-006)

2008-09-19T21:12:41Z

2a373:

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

== Brief Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.
[[LDAP injection]] is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. 
This is done by manipulating input parameters afterwards passed to internal search, add and modify functions.

== Description of the Issue ==

A web application could use LDAP in order to let users authenticate or search other users information
inside a corporate structure.

The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.

[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
defines a grammar on how to build a search filter on LDAPv3 and
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

An LDAP search filter is constructed in Polish notation,
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will be represented as:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an
LDAP search filter could be applied by using
the following metacharacters:
{| border=1
|| '''Metachar''' || '''Meaning'''
|-
|| & || Boolean AND
|-
|| | || Boolean OR
|-
|| ! || Boolean NOT
|-
|| = || Equals
|-
|| ~= || Approx
|-
|| >= || Greater than
|-
|| <= || Less than
|-
|| * || Any character
|-
|| () || Grouping parenthesis
|-
|}
More complete examples on how to build a search filter can be
found in the related RFC.

A successful exploitation of an LDAP injection vulnerability could allow the tester to:

* Access unauthorized content
* Evade application restrictions
* Gather unauthorized informations
* Add or modify Objects inside LDAP tree structure.

== Black Box testing and example ==

=== Example 1. Search Filters ===

Let's suppose we have a web application using a search
filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

If the value 'John' is replaced with a '*',
by sending the request:

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

the filter will look like:

searchfilter="(cn=*)"

which matches every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection, it will display some or all of the users attributes, depending on the application's execution flow and the permissions of the LDAP connected user,

A tester could use a trial-and-error approach, by inserting in the parameter
'(', '|', '&', '*' and the other characters, in order to check
the application for errors.

=== Example 2. Login ===

If a web application uses LDAP to check user credentials during the login process and it is vulnerable to LDAP injection, it is possible to bypass the authentication check by injecting an always true LDAP query (in a similar way to SQL
and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

the search filter will results in:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true.
This way, the tester will gain logged-in status as the first user in LDAP tree.

== References ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf 
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 
 
'''Tools''' 
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php 

{{Category:OWASP Testing Project AoC}}

Testing for MS Access

2008-09-19T20:51:55Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Short Description of the Issue ==
This article describes how to exploit SQL Injection vulnerabilties when the
backend database is MS Access, in particular, the article focuses on how to exploit Blind SQL Injection.
After an initial introduction on the typical functions that are useful to exploit an SQL Injection vulnerability,
a method to exploit Blind SQL Injection will be discussed.

== Black Box testing and example ==

=== Standard Test ===
First of all, let's show a typical example of SQL error that can encounter when
a test is executed:

Fatal error: Uncaught exception 'com_exception' with message 'Source: Microsoft JET Database Engine Description:

That means that maybe we are testing an application with an MS Access Database backend.

Unfortunately, MS Access doesn't support any comment character in the SQL query,
so it is not possible to use the trick of inserting the characters /* or -- or # to truncate the query. On the other hand, we can fortunately bypass this limit with the NULL character. If we insert the char %00 at some place in
the query, all the remaining characters after the NULL are ignored. That happens
because, internally, strings are NULL terminated.
However, the NULL character can sometimes cause troubles. We can notice that there is another value that can be used in order to truncate the query.
The character is 0x16 (%16 in url encoded format) or 22 in decimal. So if we have the following query:

SELECT [username],[password] FROM users WHERE [username]='$myUsername' AND [password]='$myPassword'

we can truncate the query with the following two urls:

http://www.example.com/index.php?user=admin'%00&pass=foo
http://www.example.com/index.php?user=admin'%16&pass=foo

==== Attributes enumeration ====
In order to enumerate the attributes of a query, it is possible to use the same method used for the database
MS SQL Server. In short, we can obtain the name of the attributes by error messages. For example,
if we know the existence of a parameter because we got it by an error message due to the
' character, we can also know the name of the remaining attributes with the following query:

' GROUP BY Id%00

in the error message received we can notice that the name of the next attribute is shown. We iterate the
method until we obtain the name of all the attributes. If we don't know the name of at least
one attribute, we can insert a fictitious column name, and, just like by magic, we obtain the name of
the first attribute.

==== Obtaining Database Schema ====
Various tables exist in MS Access that can be used to obtain the name of a table in a
particular database. In the default configuration these tables are not accessible, however it's
possible to try it. The names of these table are:

* MSysObjects
* MSysACEs
* MSysAccessXML

For example, if a union SQL injection vulnerability exists, you can use the following query:

' UNION SELECT Name FROM MSysObjects WHERE Type = 1%00

These are the main steps that you can use to exploit a SQL injection vulnerability on
MS Access. There are also some functions that can be useful to exploit custom
queries. Some of these functions are:

* ASC: Obtain the ASCII value of a character passed as input
* CHR: Obtain the character of the ASCII value passed as input
* LEN: Return the length of the string passed as parameter
* IIF: Is the IF construct, for example the following statement IIF(1=1, 'a', 'b') return 'a'
* MID: This function allows you to extract substring, for example the following statement mid('abc',1,1) return 'a'
* TOP: This function allows you to specify the maximum number of results that the query should return from the top. For example TOP 1 will return only 1 row.
* LAST: This function is used to select only the last row of a set of rows. For example the following query SELECT last(*) FROM users will return only the last row of the result.

Some of these functions will be used to exploit a blind SQL injection as we see in the next
paragraph. For other functions please refer to References.

=== Blind SQL Injection testing ===
[[Blind SQL Injection]] vulnerabilities are by no means the most frequent type of vulnerability
that you will find. Generally, you find an SQL injection in a parameter where no union
query is possible. Also, usually, there is no chance to execute shell commands or to read/write
a file. All you can do is infer the result of your query. For our test we take the
following example:

http://www.example.com/index.php?myId=[sql]

where the id parameter is used in the following query:

SELECT * FROM orders WHERE [id]=$myId

For our test, we will consider the myId parameter vulnerable to blind SQL injection.
We want to extract the content of the table users, in particular, of the column
username (we have already seen how to obtain the name of the attributes thanks
to the error messages and other techniques). It is supposed that the reader already knows the theory behind
the blind SQL injection attack, so we go straight to show some examples. A typical query that
can be used to infer the first character of the username of the 10th rows is:

http://www.example.com/index.php?id=IIF((select%20mid(last(username),1,1)%20from%20(select%20top%2010%20username%20from%20users))='a',0,'ko')

If the first character is 'a', this query will return a 0 (a "true response"), otherwise a
'ko' string. Now we will explain why we have used this particular query.
The first thing to point out is that with the functions IFF, MID and LAST, we extract the first
character of the username of the selected row. Unfortunately, the original query returns a set of records and not only one record, so we can't use this methodology directly. We must first select only one row. We can use the TOP function, but it only works with the first row. To select the other
queries we must use a trick. We want to infer the username of the row number 10.
First we use the TOP function to select the first ten rows with the query:

SELECT TOP 10 username FROM users

Then, we extract from this set the last row with the function LAST. Once we have only one row and
exactly the row that we want, we can use the IFF, MID and LAST functions to infer the value
of the username.
It may be interesting to notice the use of the IFF. In our example we use IFF to return a number or a string. With this trick we can distinguish when we have a true response or not. This is because id is of a numeric type, so if we compare it with a string we obtain an sql error, otherwise with the 0 value we have no errors. Of course if the parameter was of type string we can use different values. For example, we can have the following query:

http://www.example.com/index.php?id='%20AND%201=0%20OR%20'a'=IIF((select%20mid(last(username),1,1)%20from%20(select%20top%2010%20username%20from%20users))='a','a','b')%00

that returns a query that is always true if the first character is 'a' or a query that is always false in the other case.

This method allows us to infer the value of the username. To understand when we have
obtained the complete value we have two choices:

# We try all the printable values, when no one is valid then we have the complete value.
# We can infer the length of the value (if it's a string value we can use the LEN function) and stop when we have found all the characters.

== Tricks ==
Sometimes we are blocked by some filtering function, here we see some tricks to bypass these filters.

=== Alternative Delimiter ===
Some filter strips away the space from the input string. We can bypass this filter using
the following values as delimiter instead of the white space:

'''
9
a
c
d
20
2b
2d
3d
'''

For example we can execute the following query:

http://www.example.com/index.php?username=foo%27%09or%09%271%27%09=%09%271

to bypass a hypothetical login form.

== References ==
'''Whitepapers''' 
* http://www.techonthenet.com/access/functions/index_alpha.php
* http://www.webapptest.org/ms-access-sql-injection-cheat-sheet-IT.html

OWASP Testing Project v3 Review Roadmap

2008-09-17T23:12:01Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interesting and relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing 
4.5.5 Testing for bypassing authentication schema 
4.5.6 Testing for vulnerable remember password and pwd reset 
4.5.7 Testing for Logout and Browser Cache Management Testing 
4.5.8 Testing for CAPTCHA 
4.5.9 Testing Multiple Factors Authentication 
* Changed some grammar (commas, capitalization) 
 
Date 16 Sept, 2008 
4.6 Authorization testing 
4.6.1 Testing for path traversal 
4.6.2 Testing for bypassing authorization schema 
4.6.3 Testing for Privilege Escalation 
 
4.7 Session Management Testing 
4.7.1 Testing for Session Management Schema 
* I made several corrections to capitalization so as to maintain consistency accross the document. 
4.7.1 Testing for Session Management Schema 
4.7.2 Testing for Cookies attributes 
4.7.3 Testing for Session Fixation 
4.7.4 Testing for Exposed Session Variables 
* Changed A first person reference to third person reference ( "My... I would expect" to "When the authenticaion... The user..") 
 
Date: 17 September 2008 
 
4.7.4 Testing for Exposed Session Variables 
4.7.5 Testing for CSRF 
4.7.6 Testing for HTTP Exploit 
 
4.8 Data Validation Testing 
4.8.1 Testing for Reflected Cross Site Scripting 
4.8.2 Testing for Stored Cross Site Scripting 
4.8.3 Testing for DOM based Cross Site Scripting 
* Section feels incomplete. The content appears to end abruptly. The author mentions source code review for Black and Greybox testing. While this is the likely test process It would be nice to include a tool-based test if one exists for those of us who are not coders and have only rudimentary experience with code. 
4.8.4 Testing for Cross Site Flashing 
* Grammar changes (singular to plural and vica versa, capitalization. 
4.8.5 Testing for SQL Injection 
4.8.5.1 Oracle Testing 
4.8.5.2 MySQL Testing
 

Questions: (Mat will answer it)

OWASP Testing Project v3 Review Roadmap

2008-09-17T20:36:59Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interesting and relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing 
4.5.5 Testing for bypassing authentication schema 
4.5.6 Testing for vulnerable remember password and pwd reset 
4.5.7 Testing for Logout and Browser Cache Management Testing 
4.5.8 Testing for CAPTCHA 
4.5.9 Testing Multiple Factors Authentication 
* Changed some grammar (commas, capitalization) 
 
Date 16 Sept, 2008 
4.6 Authorization testing 
4.6.1 Testing for path traversal 
4.6.2 Testing for bypassing authorization schema 
4.6.3 Testing for Privilege Escalation 
 
4.7 Session Management Testing 
4.7.1 Testing for Session Management Schema 
* I made several corrections to capitalization so as to maintain consistency accross the document. 
4.7.1 Testing for Session Management Schema 
4.7.2 Testing for Cookies attributes 
4.7.3 Testing for Session Fixation 
4.7.4 Testing for Exposed Session Variables 
* Changed A first person reference to third person reference ( "My... I would expect" to "When the authenticaion... The user..") 
 
Date: 17 September 2008 
 
4.7.4 Testing for Exposed Session Variables 
4.7.5 Testing for CSRF 
4.7.6 Testing for HTTP Exploit 
 
4.8 Data Validation Testing 
4.8.1 Testing for Reflected Cross Site Scripting
4.8.2 Testing for Stored Cross Site Scripting
4.8.3 Testing for DOM based Cross Site Scripting
* Section feels incomplete. The content appears to end abruptly. The author mentions source code review for Black and Greybox testing. While this is the likely test process It would be nice to include a tool-based test if one exists for those of us who are not coders and have only rudimentary experience with code.
4.8.4 Testing for Cross Site Flashing
* Grammar changes (singular to plural and vica versa, capitalization.
4.8.5 Testing for SQL Injection

Questions: (Mat will answer it)

OWASP Testing Project v3 Review Roadmap

2008-09-17T20:24:14Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interesting and relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing 
4.5.5 Testing for bypassing authentication schema 
4.5.6 Testing for vulnerable remember password and pwd reset 
4.5.7 Testing for Logout and Browser Cache Management Testing 
4.5.8 Testing for CAPTCHA 
4.5.9 Testing Multiple Factors Authentication 
* Changed some grammar (commas, capitalization) 
 
Date 16 Sept, 2008 
4.6 Authorization testing 
4.6.1 Testing for path traversal 
4.6.2 Testing for bypassing authorization schema 
4.6.3 Testing for Privilege Escalation 
 
4.7 Session Management Testing 
4.7.1 Testing for Session Management Schema 
* I made several corrections to capitalization so as to maintain consistency accross the document. 
4.7.1 Testing for Session Management Schema 
4.7.2 Testing for Cookies attributes 
4.7.3 Testing for Session Fixation 
4.7.4 Testing for Exposed Session Variables 
* Changed A first person reference to third person reference ( "My... I would expect" to "When the authenticaion... The user..") 
 
Date: 17 September 2008 
 
4.7.4 Testing for Exposed Session Variables 
4.7.5 Testing for CSRF 
4.7.6 Testing for HTTP Exploit 
 
4.8 Data Validation Testing 
4.8.1 Testing for Reflected Cross Site Scripting
4.8.2 Testing for Stored Cross Site Scripting
4.8.3 Testing for DOM based Cross Site Scripting
* Section feels incomplete. The content appears to end abruptly. The author mentions source code review for Black and Greybox testing. While this is the likely test process It would be nice to include a tool-based test if one exists for those of us who are not coders and have only rudimentary experience with code.

Questions: (Mat will answer it)

Testing for CSRF (OTG-SESS-005)

2008-09-17T19:43:12Z

2a373:

{{Template:OWASP Testing Guide v3}}

==Overview==

[[CSRF]] is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.

==Related Security Activities==

===Description of CSRF Vulnerabilities===

See the OWASP article on [[CSRF]] Vulnerabilities.

===How to Avoid CSRF Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to CSRF |Avoid CSRF]] Vulnerabilities.

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Review Code for CSRF]] Vulnerabilities.

[[Category:Security Focus Area]]
__NOTOC__

==Description of the Issue==
[[Category:FIXME|This section obviously needs to move, since it's describing CSRF. However, I didn't want to just delete it because it seems that there is content here that isn't in the ASDR. I need an SME to take a look]]
The way CSRF is accomplished relies on the following facts: 
1) Web browser behavior regarding the handling of session-related information such as cookies and http authentication information; 
2) Knowledge of valid web application URLs on the side of the attacker; 
3) Application session management relying only on information which is known by the browser; 
4) Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''. 

Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required.

Point 1) Browsers automatically send information which is used to identify a user session. Suppose ''site'' is a site hosting a web application, and the user ''victim'' has just authenticated himself to ''site''. In response, ''site'' sends ''victim'' a cookie which identifies requests sent by ''victim'' as belonging to ''victim’s'' authenticated session. Basically, once the browser receives the cookie set by ''site'', it will automatically send it along with any further requests directed to ''site''.

Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).

Point 3) By “known by the browser”, we mean information such as cookies or http-based authentication information (such as Basic Authentication; NOT form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.

Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If ''victim'' has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).

<center>[[Image:session_riding.GIF]]</center>

The GET request could be originated in several different ways:

* by the user, who is using the actual web application;
* by the user, who types the URL directly in the browser;
* by the user, who follows a link (external to the application) pointing to the URL.

These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There is a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on ''site'', the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application – probably not what the user expects to happen! Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications...

By using a tag such as ''img'', as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:

<pre>
<html><body>

...

<img src=”https://www.company.example/action” width=”0” height=”0”>

...

</body></html>
</pre>

What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results into a request being automatically sent to the web application hosted on ''site''. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the ''src'' field anyway; this happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.

The problem here is a consequence of the following facts:

* there are HTML tags whose appearance in a page result in automatic http request execution (''img'' being one of those);
* the browser has no way to tell that the resource referenced by ''img ''is not actually an image and is in fact not legitimate;
* image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.

It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.

The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.

Things may be obfuscated further, by referencing seemingly valid image URLs such as

<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>

where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on http://[attacker]/picture.gif to http://[thirdparty]/action.

Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).

'''Sample scenario.'''

Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself; subsequently, session information is stored in a cookie.

Let's suppose our firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form

https://[target]/fwmgt/delete?rule=1

(to delete rule number one)

https://[target]/fwmgt/delete?rule=*

(to delete all rules).

The example is purposely quite naive, but shows in a simple way the dangers of CSRF.

<center>[[image:Session Riding Firewall Management.gif]]</center>

Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.

https://www.company.example/fwmgt/delete?rule=*

with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation...).

<center>[[image:Session Riding Firewall Management 2.gif]]</center>

Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL https://[target]/fwmgt/delete?rule=*

or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded ''img'' tag pointing to the same URL.

In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall.

One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.

An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant... Sounds far fetched? Probably, but it is a possibility.

Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.

'''Countermeasures.'''

The following countermeasures are divided among recommendations to users and to developers.

Users

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

Developers

Add session-related information to the URL. What makes the attack possible is the fact that the session is uniquely identified by the cookie, which is automatically sent by the browser. Having other session-specific information being generated at the URL level makes it difficult to the attacker to know the structure of URLs to attack.

Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit.

Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack. The same is true with intermediate confirmation pages (such as: “Are you sure you really want to do this?” type of pages). They can be bypassed by an attacker, although they will make their work a bit more complex. Therefore, do not rely solely on these measures to protect your application. Automatic logout mechanisms somewhat mitigate the exposure to these vulnerabilities, though it ultimately depends on the context (a user who works all day long on a vulnerable web banking application is obviously more at risk than a user who uses the same application occasionally).

==Black Box testing and example==

To test black box, you need to know URLs in the restricted (authenticated) area. If you possess valid credentials, you can assume both roles – the attacker and the victim. In this case, you know the URLs to be tested just by browsing around the application.

Otherwise, if you don’t have valid credentials available, you have to organize a real attack, and so induce a legitimate, logged in user into following an appropriate link. This may involve a substantial level of social engineering.

Either way, a test case can be constructed as follows:

* let ''u'' the URL being tested; for example, u = http://www.example.com/action
* build an html page containing the http request referencing url u (specifying all relevant parameters; in case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);
* make sure that the valid user is logged on the application;
* induce him into following the link pointing to the to-be-tested URL (social engineering involved if you cannot impersonate the user yourself);
* observe the result, i.e. check if the web server executed the request.

==Gray Box testing and example==

Audit the application to ascertain if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the application is vulnerable. By “client side values” we mean cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; NOT form-based authentication, which is an application-level authentication). For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user ([3] uses the term ''secret'' to refer to this piece of information).

Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automatized via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.

==References==
'''Whitepapers''' 
* This issue seems to get rediscovered from time to time, under different names. A history of these vulnerabilities has been reconstructed in: http://www.webappsec.org/lists/websecurity/archive/2005-05/msg00003.html
* Peter W:"Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt
* Thomas Schreiber:"Session Riding" - http://www.securenet.de/papers/Session_Riding.pdf
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
* Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml

'''Tools''' 
* Currently there are no automated tools that can be used to test for the presence of CSRF vulnerabilities. However, you may use your favorite spider/crawler tools to acquire knowledge about the application structure and to identify the URLs to test.

OWASP Testing Project v3 Review Roadmap

2008-09-16T22:00:28Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interesting and relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing 
4.5.5 Testing for bypassing authentication schema 
4.5.6 Testing for vulnerable remember password and pwd reset 
4.5.7 Testing for Logout and Browser Cache Management Testing 
4.5.8 Testing for CAPTCHA 
4.5.9 Testing Multiple Factors Authentication 
* Changed some grammar (commas, capitalization) 
 
Date 16 Sept, 2008 
4.6 Authorization testing 
4.6.1 Testing for path traversal 
4.6.2 Testing for bypassing authorization schema 
4.6.3 Testing for Privilege Escalation 
 
4.7 Session Management Testing 
4.7.1 Testing for Session Management Schema 
* I made several corrections to capitalization so as to maintain consistency accross the document. 
4.7.1 Testing for Session Management Schema 
4.7.2 Testing for Cookies attributes 
4.7.3 Testing for Session Fixation 
4.7.4 Testing for Exposed Session Variables 
* Changed A first person reference to third person reference ( "My... I would expect" to "When the authenticaion... The user..") 
Questions: (Mat will answer it)

OWASP Testing Project v3 Review Roadmap

2008-09-16T21:55:14Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interestinga nd relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing
4.5.5 Testing for bypassing authentication schema
4.5.6 Testing for vulnerable remember password and pwd reset
4.5.7 Testing for Logout and Browser Cache Management Testing
4.5.8 Testing for CAPTCHA
4.5.9 Testing Multiple Factors Authentication
* Changed some grammar (commas, capitalization)

Date 16 Sept, 2008
4.6 Authorization testing
4.6.1 Testing for path traversal
4.6.2 Testing for bypassing authorization schema
4.6.3 Testing for Privilege Escalation

4.7 Session Management Testing
4.7.1 Testing for Session Management Schema
* I made several corrections to capitalization so as to maintain consistency accross the document.
4.7.1 Testing for Session Management Schema
4.7.2 Testing for Cookies attributes
4.7.3 Testing for Session Fixation
4.7.4 Testing for Exposed Session Variables
* Changed some grammar (commas, capitalization)
Questions: (Mat will answer it)

Testing for Exposed Session Variables (OTG-SESS-004)

2008-09-16T21:50:51Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. As such, it is important that it is protected from eavesdropping at all times – particularly whilst in transit between the Client browser and the application servers.
 

== Short Description of the Issue==

The information here relates to how transport security applies to the transfer of sensitive Session ID data rather than data in general, and may be stricter than the caching and transport policies applied to the data served by the site.
Using a personal proxy, it is possible to ascertain the following about each request and response:
* Protocol used (e.g., HTTP vs. HTTPS)
* HTTP Headers
* Message Body (e.g., POST or page content)
Each time Session ID data is passed between the client and the server, the protocol, cache and privacy directives and body should be examined.
Transport security here refers to Session IDs passed in GET or POST requests, message bodies or other means over valid HTTP requests.

== Black Box testing and example ==

'''Testing for Encryption & Reuse of Session Tokens vulnerabilities:''' 
Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunnelling or encryption.
It should be noted that encryption or cryptographic hashing of the Session ID should be considered separately from transport encryption, as it is the Session ID itself being protected, not the data that may be represented by it.
If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk.
It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used (e.g., a hidden form field).
Simple checks such as replacing https:// with http:// during interaction with application should be performed, together with modification of form posts to determine if adequate segregation between the secure and non-secure sites is implemented. 
Note: if there is also an element to the site where the user is tracked with Session IDs but security is not present (e.g., noting which public documents a registered user downloads) it is essential that a different Session ID is used. The Session ID should therefore be monitored as the client switches from the secure to non-secure elements to ensure a different one is used. 
'''Result Expected:''' 
Every time the authentication is successful The user should expect to recieve:
* A different session token
* A token sent via encrypted channel every time I make an HTTP Request
 
'''Testing for Proxies & Caching vulnerabilities:''' 
Proxies must also be considered when reviewing application security. In many cases, clients will access the application through corporate, ISP or other proxies or protocol aware gateways (e.g., Firewalls).
The HTTP protocol provides directives to control the behaviour of downstream proxies, and the correct implementation of these directives should also be assessed.
In general, the Session ID should never be sent over unencrypted transport and should never be cached. The application should therefore be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs. Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches. 
The application should also be configured to secure data in Caches over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate controls with reference to HTTP.
HTTP/1.1 provides a number of cache control mechanisms. Cache-Control: no-cache indicates that a proxy must not re-use any data. Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data. In the case of web-cafes or other shared systems, this presents a clear risk. Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used. HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive.

'''Result Expected:''' 
The “Expires: 0” and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data.
Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use.
 
'''Testing for GET & POST vulnerabilities:''' 
In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs. They are also far more easily manipulated than other types of transport, although it should be noted that almost any mechanism can be manipulated by the client with the right tools.
Furthermore, [[Cross-site scripting]] attacks are most easily exploited by sending a specially constructed link to the victim. This is far less likely if data is sent from the client as POSTs.
 
'''Result Expected:''' 
All server side code receiving data from POST requests should be tested to ensure it doesn’t accept the data if sent as a GET.
For example, consider the following POST request generated by a login page.
<pre>
POST http://owaspapp.com/login.asp HTTP/1.1
Host: owaspapp.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b
Accept: */*
Accept-Language: en-us, en
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

Login=Username&password=Password&SessionID=12345678
</pre>
If login.asp is badly implemented, it may be possible to log in using the following URL:
http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678

Potentially insecure server-side scripts may be identified by checking each POST in this way.
 
'''Testing for Transport vulnerabilities:''' 
All interaction between the Client and Application should be tested at least against the following criteria.
* How are Session IDs transferred? E.g., GET, POST, Form Field (including hidden fields)
* Are Session IDs always sent over encrypted transport by default?
* Is it possible to manipulate the application to send Session IDs unencrypted? E.g., by changing HTTP to HTTPS?
* What cache-control directives are applied to requests/responses passing Session IDs?
* Are these directives always present? If not, where are the exceptions?
* Are GET requests incorporating the Session ID used?
* If POST is used, can it be interchanged with GET?

== References ==
'''Whitepapers''' 
* RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L. Montulli] - www.ietf.org/rfc/rfc2965.txt, www.ietf.org/rfc/rfc2109.txt
* RFC 2616 – Hypertext Transfer Protocol -- HTTP/1.1 - www.ietf.org/rfc/rfc2616.txt

OWASP Testing Project v3 Review Roadmap

2008-09-16T21:36:40Z

2a373:

'''This page track all the update to the Testing Guide v3 during the Reviewing phase.''' 

In particular the focus is: 
- Review the content of each article 
- Review the english sintax 
- no "attacker", better "tester" 
- no "we describe", but "it is described" 

Official Testing Guide Reviewers are:
* Nam Nguyen
* Kevin R.Fuller
* if you want to review it add your name please and keep track of updating

'''Nam Review:'''
----
Aug 31, 2008
* Appendix D
* Appendix C
* Appendix B
* Appendix A
* Chapter 5
** [[How to write the report of the testing]]
*** ``TO UPDATE WITH V3 controls`` is still in the article. Has it been updated to v3? '''(Mat: I'm updating it, thanks)'''
* Chapter 4
** Section 4.11 [[Testing for AJAX Vulnerabilities]]
*** There are mentioning of "attackers" but I think they are fine.
*** The subsection on Memory leaks is not complete.
** Section 4.11 [[Testing for AJAX]]
*** The subsection "Intercepting and Debugging JS code with Browsers" is very difficult to understand. I tried to fix it, but I'm afraid what I have might not reflect what the original author wanted to express.

Sep 02, 2008
* Chapter 4
** Section 4.10
*** Subsection [[Testing for WS Replay]] Gray box testing and examples gives incomplete sample code. I believe the call to GetSessionIDMac() missed four parameters. In this same part, using SSL helps in preventing replay attack but it doesnt prevent replay attack by itself. In this same subection, the images show identifiable real Internet address in Hungary, should them be masked off?

Sep 04, 2008
* Chapter 4
** Section 4.9
** Section 4.8
*** I'm not sure if format string could be classified under subsection 4.8.14 "Buffer overflow testing".
*** Subsecion 4.8.3: Incomplete
*** Subsection 4.8.4: Incomplete
*** Subsection 4.8.5: What is "data-plane input"?

Sep 06, 2008
* Chapter 4
** Section 4.8

Sep 07, 2008
* Chapter 4
** Section 4.7
** Section 4.6
*** Subsection 4.6.1: "Review code for path traversal" does not exist in the Code Review Guide, or the link the broken.
** Section 4.5

Sep 10, 2008
* Chapter 4
** Section 4.4
** Section 4.3
** Section 4.2
** Section 4.1
* Chapter 3
* Chapter 2
* Chapter 1
** [[Testing Guide Frontispiece]] still shows v2 editors and reviewers
** [[About The Open Web Application Security Project]] The link to the printed edition of the book is invalid. This page is a generally shared wiki page among all projects.

'''Kevin Review:'''
----
August 27/28th
articles reviewed 
1. Frontispiece 
1.1 About the OWASP Testing Guide Project 
 
1.2 About The Open Web Application Security Project 
 
2. Introduction 
2.1 The OWASP Testing Project 
2.2 Principles of Testing 
2.3 Testing Techniques Explained 
2.4 Security requirements test derivation,functional and non functional test requirements, 
and test cases through use and misuse cases 
2.4.1 Security tests integrated in developers and testers workflows 
2.4.2 Developers' security tests: unit tests and component level tests 
2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment 
2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting 
 
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 
 
4.Web Application Penetration Testing 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
4.2.6 Analysis of Error Codes 
4.3 Configuration Management Testing 
4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) 
4.3.2 DB Listener Testing 
4.3.3 Infrastructure Configuration Management Testing 
4.3.4 Application Configuration Management Testing 
 
* I was concerned about the structure and flow of this section. It did not read cleanly for me and appeared more "wordy" then the other sections. The format also did not appear to be consistent with the other sections resulting in a disjointed feeling when reading it. 
4.3.5 Testing for File Extensions Handling 
4.3.6 Old, Backup and Unreferenced Files 
 
03 September, 2008 
4.1 Introduction and Objectives 
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.2 Search Engine Discovery/Reconnaissance 
* Changed "GoogleBot" to the "GoogleBot" 
4.2.3 Identify application entry points 
4.2.4 Testing for Web Application Fingerprint 
4.2.5 Application Discovery 
 

10 September, 2008 
4.3.7 Infrastructure and Application Admin Interfaces 
4.3.8 Testing for HTTP Methods and XST 
* Grammer change in the section "Arbitrary HTTP Methods". Changed "and / or" to "and/or"
* Grammer change in section "Test XST Potential" andded a space between bullet number 1 and 2 and the text.

4.4 Business Logic Testing 
 
* The section read out a little longer then the other sections. All the content was interestinga nd relevant. I would suggest taking Example 2 and breaking it out into another example (Example 2.1 or 3?)in order to break up the flow. I found my self losing my train of thought the further I read into it 
 
 
4.5 Authentication Testing 
*What is "provenance"? It might be better to use adifferent, more common word with the same meaning. An average user might get confused if they do not know what it means. 
4.5.1 Credentials transport over an encrypted channel 
* I made several grammar related changes (commas and is vs are)and one content change. Please crosscheck to insure the context is the same and check for additional grammar issues. 
4.5.2 Testing for user enumeration 
4.5.3 Testing for Guessable (Dictionary) User Account
* made several grammar related changes with regard to commas
4.5.4 Brute Force Testing
4.5.5 Testing for bypassing authentication schema
4.5.6 Testing for vulnerable remember password and pwd reset
4.5.7 Testing for Logout and Browser Cache Management Testing
4.5.8 Testing for CAPTCHA
4.5.9 Testing Multiple Factors Authentication

Date 16 Sept, 2008
4.6 Authorization testing
4.6.1 Testing for path traversal
4.6.2 Testing for bypassing authorization schema
4.6.3 Testing for Privilege Escalation

4.7 Session Management Testing
4.7.1 Testing for Session Management Schema
* I made several corrections to capitalization so as to maintain consistency accross the document.

* Changed some grammar (commas, capitolization)
Questions: (Mat will answer it)

Testing for Session Management Schema (OTG-SESS-001)

2008-09-16T21:31:16Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. 
These mechanisms are known as Session Management and, while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials. In this test, we want to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker that is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.

 

==Related Security Activities==

===Description of Session Management Vulnerabilities===

See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].

===Description of Session Management Countermeasures===

See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].

===How to Avoid Session Management Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.

===How to Review Code for Session Management| Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.

==Description of the Issue==

Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or more than one) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP.

A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).

Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. In this test we have to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). Usually the main steps of the attack pattern are the following:
* '''cookie collection''': collection of a sufficient number of cookie samples;
* '''cookie reverse engineering''': analysis of the cookie generation algorithm;
* '''cookie manipulation''': forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).

Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here we are not trying to recreate a perfectly valid cookie. Instead, our goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.

==Black Box Testing and Examples==

All interaction between the client and application should be tested at least against the following criteria:
* Are all Set-Cookie directives tagged as Secure?
* Do any Cookie operations take place over unencrypted transport?
* Can the Cookie be forced over unencrypted transport?
* If so, how does the application maintain security?
* Are any Cookies persistent?
* What Expires= times are used on persistent cookies, and are they reasonable?
* Are cookies that are expected to be transient configured as such?
* What HTTP/1.1 Cache-Control settings are used to protect Cookies?
* What HTTP/1.0 Cache-Control settings are used to protect Cookies?

===Cookie collection===

The first step required in order to manipulate the cookie is obviously to understand how the application creates and manages cookies. For this task, we have to try to answer the following questions:

* How many cookies are used by the application ?
Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.
* Which parts of the the application generate and/or modify the cookie ?
Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie ?
* Which parts of the application require this cookie in order to be accessed and utilized?
Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.

A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.

===Session Analysis===

The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage. 
* Token Structure & Information Leakage
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:
<pre>
192.168.100.1:owaspuser:password:15:58
</pre>

If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:
<pre>
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5 01c2fc4f0a817afd8366689bd29dd40a
</pre>

Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:
<pre>
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
</pre>

Having analyzed a single session token, the representative sample should be examined.
A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.
The following areas should be addressed during the single and multiple Session ID structure testing:
* What parts of the Session ID are static?
* What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses
* What easily decoded confidential information is stored?
* What information can be deduced from the structure of the Session ID?
* What portions of the Session ID are static for the same login conditions?
* What obvious patterns are present in the Session ID as a whole, or individual portions?

===Session ID Predictability and Randomness===

Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in the Session ID content.
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements.
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
In analyszing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
* Are the Session IDs provably random in nature? I.e., can the resulting values be reproduced?
* Do the same input conditions produce the same ID on a subsequent run?
* Are the Session IDs provably resistant to statistical or cryptanalysis?
* What elements of the Session IDs are time-linked?
* What portions of the Session IDs are predictable?
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs?

===Cookie reverse engineering===

Now that we have enumerated the cookies and have a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies are we interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks. These characteristics are summarized below:
#Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, he/she will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.
#Tamper resistance: a cookie must resist malicious attempts of modification. If we receive a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from disk/memory afterwards, in order to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel)
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.

The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if we need to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).

It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies: a cookie collected before being authenticated can be very different from a cookie obtained after the authentication.

Another aspect to keep into consideration is time: always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a timestamp as part of the cookie value). The time recorded could be the local time or the server's timestamp included in the HTTP response (or both).

Analyzing the collected values, try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.

Examples of checks to be performed at this stage include:
* What character set is used in the cookie ? Has the cookie a numeric value ? alphanumeric ? hexadecimal ? What happens if we insert in a cookie characters that do not belong to the expected charset ?
* Is the cookie composed of different sub-parts carrying different pieces of information ? How are the different parts separated ? With which delimiters ? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step. An example of an easy-to-spot structured cookie is the following:

<pre>
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q
</pre>

In this example we see 5 different fields, carrying different types of data:

<pre>
ID – hexadecimal
CR – small integer
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
S – alphanumeric
</pre>

Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:

<pre>
0123456789abcdef
</pre>

===Brute Force Attacks===
Brute force attacks inevitably lead on from questions relating to predictability and randomness.
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
* How long would a brute-force attack on all possible Session IDs take?
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?

== Gray Box testing and example ==
If you have access to the session management schema implementation, you can check for the following:
* Random Session Token
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).
* Token length
Session ID will be at least 50 characters length.
* Session Time-out
Session token should have a defined time-out (it depends on the criticality of the application managed data)
* Cookie configuration:
** non-persistent: only RAM memory
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]
More information here: [[Testing_for_cookies_attributes]]

==References==
'''Whitepapers''' 
* RFC 2965 “HTTP State Management Mechanism”
* RFC 1750 “Randomness Recommendations for Security”
* “Strange Attractors and TCP/IP Sequence Number Analysis”: http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm
* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html
* ENT: http://fourmilab.ch/random/
* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
* Darrin Barrall: "Automated Cookie Analisys" – http://www.spidynamics.com/assets/documents/SPIcookies.pdf
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net
* Matteo Meucci:"MMS Spoofing" - www.owasp.org/images/7/72/MMS_Spoofing.ppt
 
'''Tools''' 
* [[:Category:OWASP WebScarab Project|OWASP's WebScarab]] features a session token analysis mechanism. You can read [[How to test session identifier strength with WebScarab]].
* Foundstone CookieDigger - http://www.foundstone.com/resources/proddesc/cookiedigger.htm

Testing for Privilege escalation (OTG-AUTHZ-003)

2008-09-16T21:04:25Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
This section describes the issue of escalating privileges from one stage to another. During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow privilege escalation attacks.
 

== Description of the Issue ==
 
Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed and such elevation/changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.

The degree of escalation depends on which privileges the attacker is authorized to possess and which privileges can be obtained in a successful exploit. For example, a programming error that allows a user to gain extra privilege after successful authentication limits the degree of escalation because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation.

Usually, we refer to ''vertical escalation'' when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to ''horizontal escalation'' when it is possible to access resources granted to a similarly configured account (e.g., in an online banking application, accessing information related to a different user).

 

== Black Box testing and example ==
'''Testing for role/privilege manipulation''' 
In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), to receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such function as another user in order to verify, for example, if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

For example: 
The following HTTP POST allows the user that belongs to grp001 to access order #0001:
<pre>
POST /user/viewOrder.jsp HTTP/1.1
Host: www.example.com
...

gruppoID=grp001&ordineID=0001
</pre>
Verify if a user that does not belong to grp001 can modify the value of the parameters ‘gruppoID’ and ‘ordineID’ to gain access to that privileged data.

For example: 
The following server's answer shows a hidden field in the HTML returned to the user after a successful authentication.

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close

<form name=“autoriz" method="POST" action = “visual.jsp">
<input type="hidden" name="profilo" value="SistemiInf1">
<body onload="document.forms.autoriz.submit()">
</td>
</tr>

What if the tester modifies the value of the variable "profilo" to “SistemiInf9”? Is it possible to become administrator?

For example: 
In an environment in which the server sends an error message contained as value in a specific parameter in a set of answer's codes, as the following:

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValido`-1`0`0` Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar`0`0`0`
StateExecToolBar`0`0`0`FlagsToolBar`0

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.
In this condition, verify that it is not possible to escalate privileges by modifying the parameter values.
In this particular example, by modifying the `PVValido` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.

 
'''Result Expected:''' 
The tester should verify the execution of successful privilege escalation attempts. 
 

== References ==
'''Whitepapers''' 
* Wikipedia: http://en.wikipedia.org/wiki/Privilege_escalation 
'''Tools''' 
* OWASP WebScarab: [[OWASP_WebScarab_Project]]

OWASP Testing Project v3 Review Roadmap

2008-09-10T23:17:33Z

2a373:

Testing Multiple Factors Authentication (OWASP-AT-009)

2008-09-10T22:53:01Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Evaluating the strength of a “Multiple Factors Authentication system” (MFAS) is a critical task for the Penetration tester. Banks and other Financial institutions are going to spend considerable amounts of money on expensive MFAS; therefore performing accurate tests before the adoption of a particular solution is absolutely suggested. In addition a further responsibility of the Penetration Testers is to acknowledge if the currently adopted MFAS is effectively able to defend the organization assets from the threats that generally drive the adoption of a MFAS.
 

== Description of the Issue ==
 
Generally the aim of a two factor authentication system is to enhance the strength of the authentication process [1]. This goal is achieved by checking an additional factor, or “something you have” as well as “something you know”, making sure that the user holds a hardware device of some kind in addition to the password. The hardware device provided to the user may be able to communicate directly and independently with the authentication infrastructure using an additional communication channel; this particular feature is something known as “separation of channels”.
 
Bruce Schneier in 2005 observed that some years ago “the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses” [2]. Actually the common threats that a MFAS in a Web environment should correctly address include:
 
# Credential Theft (Phishing, Eavesdropping, MITM e.g. Banking from compromised network)
# Weak Credentials (Credentials Password guessing and Password Bruteforcing attacks)
# Session based attacks (Session Riding, Session Fixation)
# Trojan and Malware attacks (Banking from compromised clients)
# Password Reuse (Using the same password for different purposes or operations, e.g. different transactions)
 
The optimal solution should be able to address all the possible attacks related to the 5 categories above.
Since the strength of an authentication solution is generally classified depending on how many “authentication factors” are checked when the user gets in touch with the computing system, the typical IT professional’s advise is: “If you are not happy with your current authentication solution, just add another authentication factor and it will be all right”. [3] Unfortunately, as we will see in the next paragraphs, the risk associated to attacks performed by motivated attackers cannot be totally eliminated; in addition some MFAS solutions are more flexible and secure compared to the others.
 
Considering the ''5-Threats (5T)'' above we could analyze the strength of a particular MFAS solution, since the solution may be able to ''Address'', ''Mitigate'' or ''Not Remediate'' that particular Web Attack. 

== Gray Box testing and example ==
A minimum amount of information about the authentication schema in use is necessary for testing the security of the MFAS solution in place. This is the main reason why the “Black Box Testing” section has been omitted. In particular, a general knowledge about the whole authentication infrastructure is important because:
* MFAS solutions are principally implemented to authenticate disposal operations. Disposal actions are supposed to be performed in the inner parts of the secure website.
* Attacks carried out successfully against MFAS are performed with a high degree of control over what is happening. This statement is usually true because attackers can “grab” detailed information on a particular authentication infrastructure by harvesting any data they can intercept through Malware attacks. Assuming that an attacker must be a customer to know how the authentication of a banking website works is not always correct; the attackers just need to get control of a single customer to study the entire security infrastructure of a particular website (Authors of SilentBanker Trojan [4] are known for continuously collecting information of visited websites while infected users browse the internet. Another example is the attack performed against the Swedish Nordea bank in 2005 [5]).
 
The following examples are about a security evaluation of different MFAS, based upon the ''5T'' model presented above.
 
The most common authentication solutions for Web applications is User ID and password authentication. In this case, an additional password for authorizing wire transfers is often required.
MFAS solution add “something you have” to the authentication process. This component is usually a:
 
* One-time password (OTP) generator token.
* Grid Card, Scratch Card and any information that only the legitimate user is supposed to have in his wallet
* Crypto devices like USB tokens or smart cards, equipped with X.509 certificates.
* Randomly generated OTPs transmitted through a GSM SMS messages [SMSOTP] [6]
 
The following examples are about the testing and evaluation of different implementations of MFAS similar to the ones above. Penetration Testers should consider all possible weaknesses of the current solution to propose the correct mitigating factors, in case the infrastructure is already in place. A correct evaluation may also permit to choose the right MFAS for the infrastructure during a preliminary solution selection.
 
A mitigating factor is any additional component or countermeasure that might result in reduced likelihood of exploitation of a particular vulnerability. Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card's existence isn't even verified . The credit card companies spend their security dollar “controlling” the transaction, not the cardholder [7]. The transactions could be effectively controlled by behavioral algorithms that automatically fill up a risk score chart while the user uses his own credit card. Anything that is marked as suspected could be temporarily blocked by the circuit. 
Another mitigating factor is also informing the customer about what is happening through a separate and secure channel. Credit Card industry uses this method for informing the user about credit card transactions via SMS messages. If a fraudulent action is taken, the user knows immediately that something gone wrong with his credit card. Real time information through separate channels can also have an higher accuracy by informing the user about transactions, before those transactions are successfully.
 
Common '''"User ID, password and Disposal password"''' usually protect from (3), partially from (2). Usually do not protect from (1), (4) and (5). From a Penetration tester's point of view, for correctly testing this kind of authentication system, we should concentrate on what the solution should protect from.
 
In other words the adopters of a “User ID, Password and Disposal password” authentication solution should be protected from (2) and from (3). A penetration tester should check if the current implementation effectively enforce the adoption of strong passwords and if is resilient to Session Based attacks (e.g. Cross Site Request Forgeries attacks in order to force the user to submitting unwanted disposal operations).
 
*Vulnerability Chart for “UserID + Password + Disposal Password” based authentication: 
**''Known Weaknesses:'' 1, 4 ,5 
**''Known Weaknesses (Details):'' This technology doesn’t protect from (1) because the password is static and can be stolen through blended threat attacks [8] (e.g. MITM attack against a SSLv2 connection). It doesn’t protect from (4) and (5) because it’s possible to submit multiple transactions with the same disposal password. 
**''Strengths (if well implemented):'' 2, 3
**''Strengths (Details):'' This technology protects from (2) only if password enforcement rules are in place. It protects from (3) because the need for a disposal password does not permit an attacker to abuse the current user session to submit disposal operations [9].
 
Now let’s analyze some different implementations of MFASs:
 
'''"One Time Password Tokens"''' protects from (1), (2) and (3) if well implemented. Do not always protect from (5). Almost never protect from (4).
 
*Vulnerability Chart for "One Time Password Tokens" based authentication: 
**''Known Weaknesses:'' 4, sometimes 5 
**''Known Weaknesses (Details):'' OTP tokens do not protect from (4), because Banking Malware is able to modify the Web Traffic in real-time upon pre-configured rules; examples of this kind include malicious codes SilentBanker, Mebroot, and Trojan Anserin . Banking Malware works like a web proxy interacting with HTTPS pages. Since Malware takes total control over a compromised client, any action that a user performs is registered and controlled: Malware may stop a legitimate transaction and redirecting the wire transfer to a different location. Password Reuse (5) is a vulnerability that may affect OTP tokens. Tokens are valid for a certain amount of time e.g. 30 seconds; if the authentication does not discard tokens that have been already used, it could be possible that a single token may authenticate multiple transactions during its 30 seconds lifetime. 
**''Strengths (if well implemented):'' 1,2,3 
**''Strengths (Details):'' OTP tokens mitigate effectively (1), because token lifetime is usually very short. In 30 seconds the attacker should be able to steal the token, entering the banking website and performing a transaction. It could be feasible, but it’s not usually going to happen in large scale attacks. Usually protect from (2) because OTP HMAC are at least 6 digits long. Penetration Testers should check that the algorithm implemented by the OTP tokens under the test is safe enough and not predictable. Finally usually protect from (3) because the disposal token is always required. Penetration testers should verify that the procedure of requesting the validation token would not be bypassed.
 
'''"Grid Cards, Scratch Cards and any information that only the legitimate user is supposed to have in his Wallet"'''
should protect from (1), (2), (3). Like OTP tokens cannot protect from (4). During testing activities grid cards in particular have been found vulnerable to (5). Scratch card are not vulnerable to password reuse, because any code can be used just one time. 
The penetration tester during the assessment of technologies of this kind should pay particular attention to Password Reuse attacks (5) for grid cards. A grid card based system commonly would request the same code multiple times. An attacker would just need to know a single valid disposal code (e.g one of those inside the grid card), and to wait until the system requests the code that he knows. Tested grid cards that contain a limited number of combinations are usually prone to this vulnerability. (e.g., if a grid card contains 50 combinations the attacker just needs to ask for a disposal, filling up the fields, checking the challenge, and so on. This attack is not about bruteforcing the disposal code, it’s about bruteforcing the challenge). Other common mistakes include a weak password policy. Any disposal password contained inside the gridcard should have a length of at least 6 numbers . Attacks could be very effective in combination with blended threats or Cross Site Request forgeries.
 
'''"Crypto Devices with certificates (Token USB, Smart Cards)"''' offer a good layer of defense from (1), (2). It’s a common mistake to believe that they would always protect from (3), (4) and (5).
Unfortunately technologies offer the best security promises and at the same time some of the worst implementations around. USB tokens vary from vendor to vendor. Some of them authorize a user when they are plugged in, and do not authorize operations when they are unplugged. It seems to be a good behavior, but what it looks like is that some of them add further layers of implicit authentication. Those devices, do not protect users from (3) (e.g. Session Riding and Cross Site Scripting code for automating transfers).
 
'''Custom “Randomly generated OTPs transmitted through a GSM SMS messages [SMSOTP]”''' could protect effectively from (1), (2), (3) and (5). Could also mitigate effectively (4) if well implemented. This solution, compared to the previous one is the only one that uses an independent channel to communicate with the banking infrastructure.
This solution is usually very effective if well implemented. By separating the communication channels, it’s possible to inform the user about what is going on. 
Ex. of a disposal token sent via SMS: 
"This token: 32982747 authorizes a wire transfer of $ 1250.4 to bank account 2345623 Bank of NY".
The previous token authorizes a unique transaction, that is reported inside the text of the SMS message. In this way the user can control that the intended transfer is effectively going to be directed to the right bank account. 
The approach described in this section is intended to provide a simple methodology to evaluate Multiple factor authentication systems. The examples shows are taken from real-case scenarios and can be used as a starting point for analyzing the efficacy of a custom MFAS.

== References ==
'''Whitepapers''' 
[1] [Definition] Wikipedia, Definition of Two Factor Authentication 
http://en.wikipedia.org/wiki/Two-factor_authentication 
[2] [SCHNEIER] Bruce Schneier, Blog Posts about two factor authentication 2005, 
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html 
http://www.schneier.com/blog/archives/2005/04/more_on_twofact.html 
[3] [Finetti] Guido Mario Finetti, "Web application security in un-trusted client scenarios" 
http://www.scmagazineuk.com/Web-application-security-in-un-trusted-client-scenarios/article/110448 
[4] [SilentBanker Trojan] Symantec, Banking in Silence 
http://www.symantec.com/enterprise/security_response/weblog/2008/01/banking_in_silence.html 
[5] [Nordea] Finextra, Phishing attacks against two factor authentication, 2005 
http://www.finextra.com/fullstory.asp?id=14384 
[6] [SMSOTP] Bruce Schneier, “Two-Factor Authentication with Cell Phones”, November 2004, 
http://www.schneier.com/blog/archives/2004/11/twofactor_authe.html 
[7] [Transaction Authentication Mindset] Bruce Schneier, "Fighting Fraudolent Transaction" 
http://www.schneier.com/blog/archives/2006/11/fighting_fraudu.html 
[8] [Blended Threat] http://en.wikipedia.org/wiki/Blended_threat 
[9] [GUNTEROLLMANN] Gunter Ollmann, “Web Based Session Management. Best practices in managing HTTP-based client sessions”, 
http://www.technicalinfo.net/papers/WebBasedSessionManagement.htm

OWASP Testing Project v3 Review Roadmap

2008-09-10T22:17:08Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-10T21:45:32Z

2a373:

Testing for Default or Guessable User Account (OWASP-AT-003)

2008-09-10T21:28:29Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Today's web applications typically run on popular open source or commercial software that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces. 
Often these applications are not properly configured and the default credentials provided for initial authentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure. 
These default username and password combinations are widely known by penetration testers and malicious attackers, who can use them to gain access to various types of custom, open source, or commercial applications. 
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken.
 

== Description of the Issue ==
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
* Programmers who leave backdoors to easily access and test their application and later forget to remove them.
* Application administrators and users that choose an easy username and password for themselves
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications which leak information as to the validity of usernames during either authentication attempts, password resets, or account signup.
 
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.

== Black Box testing and example ==
In Blackbox testing the tester knows nothing about the application, its underlying infrastructure, and any username or password policies. In reality this is often this is not the case and some information about the application is known. If this is the case, simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. Common credentials for many systems can be found using a search engine or by using one of the sites listed in the Further Reading section.
 
When facing applications to which we do not have a list of default and common user accounts, or when common accounts do not work, we can perform manual testing:

 Note that the application being tested may have an account lockout, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it 

 Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. More information on this can be seen in the section [[Testing for user enumeration]].
 
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", "guest" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully manage to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories, etc for source code that may contain comments of interest.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

== Gray Box testing and example ==
The following steps rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the password policy for the application, checking whether username and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
* Examine the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/passwords
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

'''Tools''' 
* Burp Intruder: http://portswigger.net/intruder/
* THC Hydra: http://www.thc.org/thc-hydra/
* Brutus http://www.hoobie.net/brutus/

OWASP Testing Project v3 Review Roadmap

2008-09-10T21:15:33Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-10T20:34:18Z

2a373:

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2008-09-10T20:30:28Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Testing for credentials transport means to verify that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is beinging sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels you can refer to the chapter [[Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into web forms, for example, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not. To do this we will consider various examples.
 

== Description of the Issue ==
 
Nowadays, the most common example of this issue is the login page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log into a web site, usually, the user has to fill a simple form that transmits the inserted data with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the net with a sniffer tool.
 

== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' 

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the header of our request with WebScarab, we get something like this: 
<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password by simply sniffing the net with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through en encrypted channel and that they are not readable by other people.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data is transmitted in a secure way through encryption. This situation occurs, for example, when we are on a portal of a big company that offers various information and services publicly available, without identification, but which has also a private section accessible from the home page through a login. So when we try to login, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the referer field in the header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So, in this case, we have no lock inside our browser window that tells us that we are using a secure connection, but, in reality, we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead. This is because when the GET method is used, the url that it requests is easily available from, for example, the server logs exposing your sensitive data to information leakage.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than HTTP, then the whole HTTP package is still encrypted and the URL is unreadable to an attacker. It is not a good practice to use the GET method in these cases, because the information contained in the URL can be stored in many servers such as proxy and web servers, leaking the privacy of the user's credentials.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the HTTPS for sensitive information transmissions. 
Then, check with them if HTTPS is used in every sensitive transmission, like those in login pages, to prevent unauthorized users to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* [[OWASP WebScarab Project|WebScarab]]

OWASP Testing Project v3 Review Roadmap

2008-09-10T20:19:18Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-10T20:17:20Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-10T16:10:22Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-10T16:09:12Z

2a373:

OWASP Testing Project v3 Review Roadmap

2008-09-10T16:03:13Z

2a373:

Test HTTP Methods (OTG-CONFIG-006)

2008-09-10T14:56:42Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
HTTP offers a number of methods that can be used to performs actions on the web server. Many of theses methods are designed to aid developers deploy and test HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the servers HTTP TRACE method, is examined. 

== Short Description of the Issue (Topic and Explanation) ==
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim server as a file repository
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
* CONNECT: This method could allow a client to use the web server as a proxy
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and it is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

== Arbitrary HTTP Methods ==

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen and/or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and again were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== Black Box testing and example ==
'''Discover the Supported Methods''' 
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

icesurfer@nightblade ~ $
</pre>
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[Cross_site_scripting_AoC | Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:

* 1. Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet, that contains the TRACE request, in the vulnerable application, as in a normal Cross Site Scripting attack
* 2. Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

== Black Box Testing of HTTP method tampering ==

Testing for HTTP method tampering is essentially the same as testing for XST.

=== Testing for arbitrary HTTP methods ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If your framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin.

=== Testing for HEAD access control bypass ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If you get a "405 Method not allowed" or "501 Method Unimplemented", the application/framework/language/system/firewall is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin, all using blind request submission.

== Gray Box testing and example ==
The testing in a Gray Box scenario follows the same steps of a Black Box scenario
 
== References ==
'''Whitepapers''' 
* RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
* RFC 2109 and RFC 2965: “HTTP State Management Mechanism”
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

'''Tools'''
* NetCat - http://www.vulnwatch.org/netcat

Test HTTP Methods (OTG-CONFIG-006)

2008-09-10T14:55:00Z

2a373:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
HTTP offers a number of methods that can be used to performs actions on the web server. Many of theses methods are designed to aid developers deploy and test HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the servers HTTP TRACE method, is examined. 

== Short Description of the Issue (Topic and Explanation) ==
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim server as a file repository
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
* CONNECT: This method could allow a client to use the web server as a proxy
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and it is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

== Arbitrary HTTP Methods ==

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen and / or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and again were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== Black Box testing and example ==
'''Discover the Supported Methods''' 
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

icesurfer@nightblade ~ $
</pre>
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[Cross_site_scripting_AoC | Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:

* 1. Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet, that contains the TRACE request, in the vulnerable application, as in a normal Cross Site Scripting attack
* 2. Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

== Black Box Testing of HTTP method tampering ==

Testing for HTTP method tampering is essentially the same as testing for XST.

=== Testing for arbitrary HTTP methods ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If your framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin.

=== Testing for HEAD access control bypass ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If you get a "405 Method not allowed" or "501 Method Unimplemented", the application/framework/language/system/firewall is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin, all using blind request submission.

== Gray Box testing and example ==
The testing in a Gray Box scenario follows the same steps of a Black Box scenario
 
== References ==
'''Whitepapers''' 
* RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
* RFC 2109 and RFC 2965: “HTTP State Management Mechanism”
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

'''Tools'''
* NetCat - http://www.vulnwatch.org/netcat

Conduct search engine discovery/reconnaissance for information leakage (OTG-INFO-001)

2008-09-03T14:34:51Z

2a373:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
This section describes how to search the Google Index and remove the associated web content from the Google Cache.
 

== Description of the Issue ==
 
Once the GoogleBot has completed crawling, it commences indexing the web page based on tags and associated attributes, such as <TITLE>, in order to return the relevant search results. [1]

If the robots.txt file is not updated during the lifetime of the web site, then it is possible for web content not intended to be included in Google's Search Results to be returned.

Therefore, it must be removed from the Google Cache.
 

== Black Box Testing==
Using the advanced "site:" search operator, it is possible to restrict Search Results to a specific domain [2].

Google provides the Advanced "cache:" search operator [2], but this is the equivalent to clicking the "Cached" next to each Google Search Result. Hence, the use of the Advanced "site:" Search Operator and then clicking "Cached" is preferred.

The Google SOAP Search API supports the doGetCachedPage and the associated doGetCachedPageResponse SOAP Messages [3] to assist with retrieving cached pages. An implementation of this is under development by the [http://www.owasp.org/index.php/Category:OWASP_Google_Hacking_Project OWASP "Google Hacking" Project].

== Example ==
To find the web content of owasp.org indexed by Google Cache the following Google Search Query is issued:
<pre>
site:owasp.org
</pre>
[[Image:Google_site_Operator_Search_Results_Example.JPG]]

To display the index.html of owasp.org as cached by Google the following Google Search Query is issued:
<pre>
cache:owasp.org
</pre>
[[Image:Google_Cached_Example.JPG]]

== Gray Box testing and example ==
Grey Box testing is the same as Black Box testing above.

== References ==
[1] "Google 101: How Google crawls, indexes, and serves the web" - http://www.google.com/support/webmasters/bin/answer.py?answer=70897 
[2] "Advanced Google Search Operators" - http://www.google.com/help/operators.html 
[3] "Google SOAP Search API" - http://code.google.com/apis/soapsearch/reference.html#1_2 
[4] "Preventing content from appearing in Google search results" - http://www.google.com/support/webmasters/bin/topic.py?topic=8459

Project Information:template Testing Guide 3.0 50 Review Second Review E

2008-07-29T21:13:45Z

2a373:

[[Project Information:template Testing Guide 3.0|Click here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Testing Project v3 Roadmap|OWASP Testing Project V3.0 Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The Project is well on it's way to completion. I read the various edits side by side with thier version 2 versions. I see how the content changes will make the end product easier to read and understand. The new additions, including the new attack vectors and testing methodologies, will help keep the guide current. The various new additions in the attack vectors and testing methodologies mentioned by reviewer one remain the primary uncompleted tasks.
|-
| style="width:25%; background:#7B8ABD" align="center"|

2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Testing Project v3 Roadmap|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
Considering the progress on the reorganization (90%) I would mark the project at 60% done.
|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
It would be usful, though maybe not practical, to somehow highlight the changes made when re-editing exisiting content? Reading side by side with the version 2 in order to identify the content added or changed was very time consuming and tiring. Also there were a couple of spelling and grammar errors I noted in passing. Nothing big but cause for note.
|}

Project Information:Sqlibench 50 Review Second Review E

2008-07-22T22:07:25Z

2a373:

Project Information:Sqlibench 50 Review Second Review E

2008-07-22T21:59:35Z

2a373:

OWASP EU Summit 2008

2008-07-22T21:47:51Z

2a373: /* Summer of Code 08 Participants & Reviewers */

(WORK IN PROGRESS /UNDER DISCUSSION)
== UPDATES ==
*[[OWASP EU Summit 2008 - updates|'''OWASP EU Summit 2008 - updates''']]

== What: OWASP Summit, a conference about OWASP and for OWASP's community ==
=== When: 4 to 7 Nov 2008 (4 & 5: Meetings and Training, 6 & 7: Conference) ===
=== Where: Portugal ===
Faro or Lisbon
=== Organization===
Paulo Coimbra and Dinis Cruz
== Agenda ==
Theme: Present OWASP's projects, community and activities ..... '....Connecting the dots.... "

'''Day 1 & 2'''
*Training sessions (similar to what happens at the moment at the other OWASP conferences)
*OWASP Working Group sessions (1/2 day each) on:
** OWASP Governance, "What is OWASP's position on ...." & Action Plan for 2009
** ESAPI
** Browser Security
** OWASP Top 10 2009

'''Day 3 & 4 Agenda:'''
* Presentations from AoC, SpoC and SoC Participants
* Presentations from 'Release' Quality OWASP projects (not included in the list above) or Key OWASP projects (like ESAPI)
* Presentations about OWASP : How it works, Financial reports, OotM (OWASP on the Move), new project management guidelines, local chapter finances, OWASP governance
* Presentation from Chapter leaders on the activities developed on their project
* Discussion on next steps for OWASP and focus of next OWASP financial investment plans

Other ideas:

* vote on 6th OWASP board member (Candidates to Apply)

== other details==

'''Projected Attendees:450 '''
* 200 with some (or all) expenses covered by OWASP
** 33 SoC participants
** 70 SoC reviewers
** 10 SoC Collaborators
** 15 AoC & SpoC participants
** 15 Chapter Leaders
** 8 OWASP Board & Employees
** 49 OWASP non-individual members (2x per 9k Corporate? 1x for the others?)

=== Financial details ===
'''Expenses'''
* Accommodation & meals: 80,000 USD = 400 USD per person (200x) for 3 nights accommodation and 5 meals (3 dinners and 2 lunches)
* Flights & Trains : 70,000 USD

'''Revenue sources'''
* Tickets (for the 250 non 'OWASP invited' attendees)
* Training Sessions
* Conference sponsors

== Participants ==
=== OWASP Board members & employees ===
* Jeff Williams
* Dave Wichers
* Dinis Cruz
* Tom Brennan
* Sebastien Deleersnyder
* Paulo Coimbra
* Kate Hartmann (to be confirmed)
* Alison McNamee (to be confirmed)
* Larry Casey (to be confirmed)

=== Summer of Code 08 Participants & Reviewers ===
* (please add your name in the following format)
* OWASP Classic ASP Security Project
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Internationalization Guidelines
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Spanish Project Reviewer Esteban Ribicic
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Ruby on Rails Security Project Leader Heiko Webers from Germany
* OWASP Code Review Guide Lead - Eoin Keary - Ireland
* OWASP Enigform and mod_Openpgp - Arturo Alberto Busleiman (a.k.a Buanzo) - Argentina
* OWASP AppSensor - Michael Coates - United States
* OWASP ASDR - Leonardo Cavallari Militelli - Brazil
**Reviewer - Frederick Donovan - United States
*OWASP Corporate Application security guide- Parvathy Iyer- USA
* OWASP Positive Security - Eduardo Vianna de Camargo Neves - Brazil
* OWASP Backend Security Project - Carlo Pelliccioni - Italy
* OWASP Source Code Review OWASP Projects
**First Reviewer - Alexander Fry - USA
**Second Reviewer - Marco M. Morana - United States
* OWASP Access Control Rules Tester Project
**Project leader - Andrew Petukhov - Russia, Moscow
* OWASP Live CD 2008
** Project Leader - Matt Tesauro - Austin, USA
* OWASP OpenSign Server Project
** Reviewer Pierre Parrend - France
** SoC's Reviewer Kevin Fuller - Sacramento Ca, USA
* OWASP Securing WebGoat using ModSecurity
**Project Lead - Stephen Craig Evans - Singapore
* OWASP Teachable Static Analysis Workbench
**First Reviewer - Alexander Fry - USA
* OWASP WeBekci Project
**First Reviewer - Alexander Fry - USA

=== Spring of Code 07 Participants (Completed Projects) ===
* Refresh Attacks list - Przemyslaw Skowron - Poland

* (please add your name)
* {Project} {Name} {Origin Country}

=== Autumn of Code 06 Participants ===
* (please add your name)
* {Project} {Name} {Origin Country}

* WebScarab-NG, Rogan Dawes, South Africa
* OWASP Pantera, Simon Roses Femerling, Spain

=== Active Chapter Leaders ===
* (please add your name in the following format)
* {Chapter} {Role} {Name} {Origin Country}
* Helsinki chapter leader - Antti Laulajainen, Finland
* NY/NJ Metro Board Member - Steve Antoniewicz, USA
* Twin-Cities chapter leader - Kuai Hinojosa, MN, USA
* Hawaii chapter leader/founder - Jim Manico, Anahola, Island of Kauai, Hawaii, USA

=== Active Project Leaders (not currently participating on SoC 08)===
* (please add your name in the following format)
* {Project} {Role} {Name} {Origin Country}
.NET ESAPI - Project Leader - Alex Smolen - USA

=== Significant Past OWASP contributor (that is not already covered by one of the above categories) ===
* (please add your name in the following format)
* {Project/Chapter} {Role} {Name} {Origin Country}

=== Logistic and Support team ===
* Summit Graphic Design + Summit organization + on-site logistics support, Sarah Cruz, UK (London)