week 2 assignment 2

15OWASP Level 1A Pass/Fail Verdicts

17OWASP Level 1B Pass/Fail Verdicts

18Web Server NIST Pass/Fail Verdicts

Template Instructions:

1. Remove all notes and hints in red for the final deliverable.

2. Repaginate the table of contents for the final deliverable.

3. Replace the <Application Name> in the page header with your own title header for the final deliverable.

4. Run spell and grammar checker for the final deliverable.

1 Assessment Introduction

<Include introductory paragraph on the assessment purpose for this project>

The purpose of this report is to review and assess the web application Target of Verification (TOV) security for the top ten (and beyond) application security risks – and to report assessed vulnerabilities and recommended actions. For purposes of this document, application review and assessment is also called “verification”.

This report is based upon the Application Security Verification Standard (ASVS) by OWASP, which defines four levels of verification that increase in both breadth and depth at higher levels. The breadth is defined in each level by a set of security requirements that must be addressed. The depth of the verification is defined by the approach and level of rigor required in verifying each security requirement.

Figure One – OWASP ASVS Levels

This report focuses on Level 1 (“Automated Verification”), which is typically appropriate for applications where some confidence in the correct use of security controls is required. Threats to security will typically be viruses and worms (targets are chosen indiscriminately through wide scans and impact the most vulnerable). The scope of verification includes code that was developed or modified in order to create the application.

In Level 1, the verification involves the use of automated tools augmented with manual verification. This level only provides partial application security verification coverage. The manual verification is not intended to make the application security verification performed at this level complete, only to verify that each automated finding is correct and not a false positive.

The Assessment Report contains the following additional sections:

· Section 2: The Target of Verification (TOV) Description. This section describes the TOV implementation. In this context, it is the web application itself.

· Section 3: Assumptions. This section describes the assumptions made during verification.

· Section 4: Verification Requirements. This section identifies the OWASP ASVS verification requirements that the verification was performed against- as well as other web server requirements that are best practices that are not specifically enumerated in the ASVS

· Section 5: Verification Approach. This section identifies the verification methodology that was used to determine if ASVS verification requirements were met or not.

· Appendices A, B, C, and D – Verification Findings. These appendices summarize the results of verification activities that were performed. The complete set of architecture-related findings is provided in Appendix A, while summaries of results using tools are provided in Appendices B, C, and D.

· Appendix E – OWASP ASVS Pass/Fail verdicts. This appendix documents pass/fail verdicts for OWASP ASVS verification requirements.

1.1 References

<Include references. For the remediation project include references from the earlier findings project as well. For readability, separate references using a numbered list>

2 Web Application Description

2.1 Application Overview

The Target of Verification (TOV) is the <Web Site Name> web site. It components are deployed as depicted in Figure 2 below.

<Insert Network Diagram here or describe in a paragraph the infrastructure based upon the project instructions>

2.2 Application Architecture

The web sites can be described in terms of the following components:

· Network firewall component

· Web server software component

· Application server component

· Relational database component

· File system component

· Remote devices

Component details are below.

2.2.1 Network Firewall Application Component

<Brief Description>

2.2.2 Web Server Component

<Brief Description>

2.2.3 Application Server Application Component

<Brief Description of Web server software (e.g., Apache)>

2.2.4 File System Application Component

<Brief Description (e.g., use of NAS storage>

2.2.5 Remote Device Component

<Brief Description (e.g., Smartphones, Tablets>

3 Assessment Assumptions

3.1 Components Included in the Assessment

All code on <Web Site> will be included in the assessment/verification.

3.2 Components Excluded from the Assessment

<List of components that are out of scope (e.g., physical security)>

3.3 Other Assumptions

<List of at least three assumptions made in the assessment – such as the need for access to web servers, availability of internal resources, etc.>

3.4 Biblical Principles

<Describe in one or more paragraphs biblical principles that apply to the assessment>

4 Assessment Approach

4.1 Security Architecture Review

The security architecture review consists in a review of the application architecture, which is determined by customer-supplied diagrams and/or interviews. However, a full review of the architecture is out of scope in this assessment. The high-level diagram is provided for clarification purposes.

4.2 Web Server Security Scan

A high-level assessment of the web server security is performed using automated tooling and manual inspection. This includes the web server software (e.g., Apache, IIS) and the operating system. The tools utilized in the automated scan are <Tool Names>.

4.3 Dynamic Vulnerability Scan

Dynamic scanning was performed at OWASP ASVS Level 1A using the following tool:

<For purposes of this assignment, they are the tools used in earlier labs>.

The results of the scan can be found in Reference One. A summary of the results of the scan can be found in this document in section “Appendix B – Dynamic Scan Findings”.

4.4 Source Code Scan

Static scanning was performed using a manual code review process.

4.5 Out of Scope Items

<Modify section below as appropriate. Project instructions list what is out of scope>

5 Assessment/Verification Results

5.1 Summary of Test Results

5.1.1 Cross-Site Scripting (XSS) Findings

<Include screenshots and a paragraph or more description of Lab 1 test results>

5.1.2 Cross-Site Request Forgery (CSRF) Findings

<Include screenshots and a paragraph or more description of Lab 2 test results>

5.1.3 SQL Injections Findings

<Include screenshots and a paragraph or more description of Lab 3 test results>

5.1.4 Broken Access Control Findings

<Include screenshots and a paragraph or more description of Lab 4 test results>

5.2 Source Code Findings

<Include a summation of at least one piece of code from both Lab 2 and Lab 4 reviewing why the code revealed vulnerabilities to CSRF and Broken Access Control respectively>

5.3 OWASP ASVS Level 1A Verification Requirements

The Appendix lists the Level 1A verification requirements and whether the

assessment results are pass or fail.

<This section is included for illustrative purposes and requires no action>

5.4 OWASP ASVS Level 1B Verification Requirements

The Appendix lists the Level 1B verification requirements and whether the

assessment results are pass or fail.

<This section is included for illustrative purposes and requires no action>

5.5 Web Server NIST Verification Requirements

The Appendix lists the web server NIST verification Level 1A verification

requirements and whether the assessment results are pass or fail.

<This section is included for illustrative purposes and requires no action>

6 Recommended Remediation Actions

The following are recommendations by high-level category resulting from the findings as listed above for each lab and associated vulnerability. Each recommendation has an associated priority and remediation effort (high, medium, and low). The effort is a high-level estimate which could change with more analysis. In overall terms, a low effort denotes approximately 4-16 hours, medium effort is approximately (16-40 hours), and high effort is greater than 40 hours.

<To be completed in Remediation Project>

6.1 Web Application Recommendations - XSS

<Complete table below for 3 or more design and coding recommendations (not the server itself). Include at least one for each of the Labs 1-4>

6.2 Web Application Recommendations - CSRF

<Complete table below for 3 or more design and coding recommendations (not the server itself). Include at least one for each of the Labs 1-4>

6.3 Web Application Recommendations - SQL Injections

<Complete table below for 3 or more design and coding recommendations (not the server itself). Include at least one for each of the Labs 1-4>

6.4 Web Application Recommendations – Broken Access Controls

<Complete table below for 3 or more design and coding recommendations (not the server itself). Include at least one for each of the Labs 1-4>

6.5 Other Web Recommendations

<Complete table below for 3 or more other recommendations based upon web security best practices>

6.6 Biblical Integration Results

<Describe in one or more paragraphs how your recommendations above are consistent with the biblical principles earlier in section 3.4>

Appendix – Security Requirement Pass/Fail Verdicts

The following are the OWASP and NIST requirements for public web sites – and the pass/fail determinations of those requirements based upon both automated scans and manual inspection.

<This section is included for educational purposes and requires no action>

OWASP Level 1A Pass/Fail Verdicts

L1A.1 The verifier shall dynamically scan the web application according to the Level 1A requirements specified in the [OWASP] “Detailed Verification Requirements” section [reproduced below for convenience].

V1.1 The verifier shall identify all application components (either individual or groups of source files, libraries, and/or executables) present in the application.

V2.1 Verify that all pages and resources require authentication except those specifically intended to be public.

V2.9 Verify that if a maximum number of authentication attempts is exceeded, the account is locked.

V2.11 Verify that all password fields do not echo the user’s password when it is entered.

V3.1 Verify that the framework’s default session management control implementation is used by the application.

V3.1 Verify that sessions are invalidated when the user logs out.

V3.2 Verify that sessions timeout after a specified period of inactivity.

V3.8 Verify that all authenticated pages have logout links.

V4.1 Verify that users can only access URLs for which they possess specific authorization.

V4.2 Verify that users can only access files for which they possess specific authorization.

V4.3 Verify that directory browsing is disabled unless deliberately desired.

V4.4 Verify that users can only access protected functions for which they possess specific authorization.

V4.11 Verify that direct object references are protected, such that only authorized objects are accessible to each user.

V5.3 Verify that a positive validation pattern is defined and applied to all input.

V5.7 Verify that all input validation control failures result in input rejection.

V5.9 Verify that the environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.

V8.8 Verify that that the application does not output error messages containing sensitive data that could assist an attacker, including session id and personal information.

V9.3 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.

V10.5 Verify that TLS server certificates have been issued by a trusted CA.

V11.1 Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8).

V11.2 Verify that redirects do not include unvalidated data.

V11.3 Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST.

L1A.2 The verifier shall verify all dynamic scan results using either manual penetration testing or code review. Unverified automated results are not considered to provide any assurance and are not sufficient to qualify for Level 1.

OWASP Level 1B Pass/Fail Verdicts

L1B.1 The verifier shall perform source code scanning on the web application according to the Level 1B requirements specified in the [OWASP] “Detailed Verification Requirements” section [reproduced below for convenience].

V1.1 The verifier shall identify all application components (either individual or groups of source files, libraries, and/or executables) present in the application.

V2.1 Verify that all pages and resources require authentication except those specifically intended to be public.

V2.11 Verify that all password fields do not echo the user’s password when it is entered.

V3.7 Verify that the session id is never disclosed other than in cookie headers, particularly in URLs or logs. This includes verifying that the application does not support URL rewriting of session cookies.

V4.4 Verify that users can only access protected functions for which they possess specific authorization.

V5.9 Verify that the environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.

V8.8 Verify that that the application does not output error messages containing sensitive data that could assist an attacker, including session id and personal information.

V9.3 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.

V11.1 Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8).

V11.2 Verify that redirects do not include unvalidated data.

V11.3 Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST.

Web Server NIST Pass/Fail Verdicts

1. Verify that the host server software levels have been identified – OS and web server software.

2. Verify that all host server applications and operational services have been identified.

3. Verify that all host server operating system users and groups have been identified.

4. Verify that administrative activities have been limited to authorized users.

5. Verify that unnecessary applications and services have been disabled at the operating system and web server software levels.

6. Verify that users and administrators are able to change passwords through an established procedure.

7. Verify that users are disabled after a specified period of inactivity.

8. Verify that host server activities are logged and periodically reviewed by system administrators.

9. Verify that all vendor-recommended critical security patches have been applied and that there is an established procedure and schedule to perform this activity.

10. Verify that the password policies are in alignment with best practices.

11. Verify that additional software controls are installed and up-to-date such as such as antivirus software, antispyware software, rootkit detectors (Unix only), and host-based intrusion detection or firewalls.

12. Verify that all manufacturer documentation has been removed from the server.

13. Verify that any example or test files from the server, including scripts and executable code, have been removed.

14. Define a complete Web content access matrix. Identify which folders and files within the Web server document should be restricted and which should be accessible (and by whom).

15. Verify that the following file-level controls are applied for the web application:

a. Configure the Web server so that Web content files can be read but not written by service processes

b. Configure the Web server so that service processes cannot write to the directories where public Web content is stored

c. Configure the Web server so that only processes authorized for Web server administration can write Web content files

d. Configure the host OS so that the Web server can write log files but not read them.

e. Configure the host OS so that temporary files created by the Web server application are restricted to a specified and appropriately protected subdirectory

f. Configure the host OS so that access to any temporary files created by the Web server application is limited to the service processes that created the files

g. Install Web content on a different hard drive or logical partition than the OS and Web server application

h. If uploads are allowed to the Web server, configure it so that a limit is placed on the amount of hard drive space that is dedicated for this purpose; uploads should be placed on a separate partition

i. Ensure that log files are stored in a location that is sized appropriately; log files should be placed on a separate partition.

16. Verify that sensitive content on a public web server is restricted for the following types of information:

a. Classified records

b. Internal personnel rules and procedures

c. Sensitive or proprietary information

d. Personal information about an organization’s personnel

Telephone numbers, e-mail addresses, or general listings of staff unless necessary to fulfill organizational requirements

e. Schedules of organizational principals or their exact location (whether on or off the premises)

f. Information on the composition, preparation, or optimal use of hazardous materials or toxins

g. Sensitive information relating to homeland security

h. Investigative records

i. Financial records (beyond those already publicly available)

j. Medical records

k. Organization’s physical and information security procedures

l. Information about organization’s network and information system infrastructure

m. Information that specifies or implies physical security vulnerabilities

n. Plans, maps, diagrams, aerial photographs, and architectural plans of organizational building, properties, or installations

o. Copyrighted material without the written permission of the owner

p. Privacy or security policies that indicate the types of security measures in place to the degree that they may be useful to an attacker