week 2 assignment 2
week 2 assignment 2
Standardized Rubric for CSCI 631 Assessment Findings Project
Criteria
Levels of Achievement
Content Components
70%
Advanced
Proficient
Developing
Not present
Sections 1, 3, and 4
28 to 30 points
· Project report includes a customized introduction using overview information from instructions. Includes 3 or more references.
· Includes biblical integration supported by scripture.
· Project report includes assumptions for 1) included components, 2) excluded components, and 3) three (3) or more other assumptions for the project team in the assessment.
· Project report includes accurate assessment approach content for 1) tools used in section 4.2, 2) tools used in section 4.3, and 3) a paragraph in section 4.5 on out-of-scope items.
25 to 27 points
· Project report contains 1-2 inaccuracies or omissions in assessment introduction or list of references.
· Project report contains 1-2 inaccuracies or omissions in assessment assumptions when completing the three subsections
· Project report contains 1-2 inaccuracies or omissions in content for 1) tools used in section 4.2, 2) tools used in section 4.3, and 3) a paragraph in section 4.5 on out-of-scope items.
1 to 24 points
· Project report contains 3 or more inaccuracies or omissions in assessment introduction or list of references.
· Does not include biblical integration supported by scripture.
· Project report contains three (3) or more inaccuracies or omissions in assessment assumptions when completing the three subsections.
· Project report contains 3 or more inaccuracies or omissions in content for 1) tools used in section 4.2, 2) tools used in section 4.3, and 3) a paragraph in section 4.5 on out-of-scope items.
0 points
· Project report is missing any customized introduction or overview information or references.
· Project report is missing any content in the assessment assumptions 3 sub sections.
· Project report is missing any content in the assessment approach content in all sub sections.
Section 5
30 to 33 points
· Project report includes a summary of test results for each of the sub sections in 5.1-5.4 with both one or more screenshots and a descriptive paragraph for each sub section corresponding to labs 1-4.
· Project report contains a review of the source code – including specifics about one piece of code corresponding to a web vulnerability discovered in previous labs 2 and 4. Describes what makes the code an issue.
28 to 29 points
· Project report contains 1-2 inaccuracies or omissions in content (screenshots or descriptive paragraph) in sub sections 5.1-5.4 corresponding to labs 1-4.
· Project report contains 1-2 inaccuracies or omissions in comments about source code in labs 2 and 4 or what makes the code an issue.
1 to 27 points
· Project report contains 3 or more inaccuracies or omissions in content (screenshots or descriptive paragraph) for sub sections 5.1-5.4
· Project report contains 3 or more inaccuracies or omissions in comments about comments about source code in labs 2 and 4 or what makes the code an issue.
0 points
· Project report is missing any content in sub sections 5.1-5.4 (screenshots or descriptive paragraph)
· Project report is missing any content in section 5.2 about the code review of labs 2 and 4.
Structural Components 30%
Format and Mechanics
25 to 27 points
Project report adheres to current APA format and contains no significant spelling or grammatical errors. Adheres to minimum number of pages and reference requirements. Removes template instructions in red from final submission.
23 to 24 points
Project report contains 1-2 significant APA formatting or spelling issues. Number of reference requirements or minimum number of pages is one (1) less than required. Does not remove template instructions in red from final submission.
1 to 22 points
Project report contains 3-4 significant APA formatting or spelling issues. Number of reference requirements or minimum number of pages are two (2) less than required.
0 to 0 points
Project report contains more than 5 significant APA formatting or spelling issues. Number of reference requirements or minimum number of pages are three (3) or more lower than required.
CSCI631
Page 1 of 3
SECURITY ASSESSMENT FINDINGS PROJECT INSTRUCTIONS
Overview
In this project, you will perform a security assessment of a hypothetical website and report upon
the results of that assessment. You will provide both an executive summary of your findings as
well as detailed results of the assessment. You will complete the report in a subsequent paper by
providing remediation recommendations and actions you recommend to mitigate against your
findings.
Your assessment is to review the website of a hypothetical company, Insecure BankCorp. It is a
regional bank used by Liberty Beverages, Inc. – which specializes as an e-Commerce business in
the delivery of beverage products such as specialty coffee and tea products. The business
problem that they wish to address is the recent successful attack by a suspected nation state on
their bank website. The attack was able to deface the website as well as access some personal
purchasing data by customers. Given its impact on their brand and customer loyalty, this has
high visibility with senior management.
Assume that the current web infrastructure consists of a redundant group of web servers running
on a Linux platform with Apache web server software on which the web application runs. In
addition, perimeter security is provided by redundant edge routers for load balancing and
redundant firewalls (e.g., Cisco ASA 5000-series) in a demilitarized zone (DMZ) configuration
as well as an intrusion detection software (IDS) solution and SIEM (e.g., Splunk) for security
monitoring. Lastly, the web servers interface with a relational database (e.g., MySQL) and a
Storage Area Network (SAN) for persistent storage. The bank website is accessible by a variety
of devices such as conventional web browsers, tablets, and smart phones either internally or
remotely using VPN software. They communicate with the web server using the HTTPS
protocol.
For purposes of this assignment, use the lab report files you generated for previous labs 1-4 as
inputs. These involved various web vulnerabilities – Cross-Site scripting, CSRF, SQL Injections,
and Broken Access Control.
The scope of your assessment is the website itself, including the website code and configuration,
Linux platform, and Apache web server software. It is not within scope of this assignment to
assess other infrastructure components such as the routers, firewalls, IDS, and databases – nor
security on remote devices and authentication or authorization mechanisms. The only exception
to that would be if there were a vulnerability discovered in the software directly related to the
database. These may be recommended for subsequent follow-up activities.
Inputs
• Lab report files from Labs 1-4
• Course textbooks
• NIST Publication 800-44v2
• Other external resources as needed
http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2
CSCI 631
Page 2 of 3
Instructions
1. As mentioned above, collect the report files from Labs 1-4. Complete the assessment
template (or use your own organization if you include all of the appropriate content listed
below) provided for this assignment entitled “Web Application Security Report
Template”.
2. Complete the following sections in the assessment template for this project. Note: You
will complete the remaining sections in the template in the later remediation project.
a. Section 1: Assessment Introduction – Use the overview information from this
document to set the context for the report.
b. Section 1.1: References – Add at least three (3) references.
c. Section 2: Web Application Description – Leave this section and sub-sections
blank for later remediation paper.
d. Section 3: Assessment Assumptions – Use information from the assignment
overview to 1) describe components included in the assessment, 2) components
excluded from the assessment (in scope and out of scope), and 3) 3 or more other
assumptions about the hypothetical assessment. In the context of this project, as
assumption describes what an assessment team is assuming as true or in place as
part of this hypothetical assessment. These can be things like the availability of
customer resources, access to facilities, accounts and passwords, etc. An
assumption is not a description of the technical environment or facts about the
system.
e. Section 3.4: Biblical Principles – Add one or more paragraphs about biblical
principles and supporting scripture that are applicable to this project.
f. Section 4: Assessment Approach. Include paragraph in section 4.5 on out of scope
items based upon the information provided in the assignment overview (as it
mentions what is in and out of scope)- as well as the tools utilized in sections 4.2
and 4.3
g. Section 5
Sections 5.1.1-5.1.4 – Summary of test results from Labs 1-4 respectively
Include screenshots and a paragraph summation of the test results / finds from
each lab.
Section 5.2 – Summary of the source code findings from Labs 2 and 4
Review at least one piece of code from each lab describing what the issue /
finding was that makes it vulnerability to the vulnerabilities. Note that for
purposes of the assignment, this is not a full source code review of all of the web
pages but a review of at least one (1) piece of code corresponding to a web
vulnerability discovered in the labs. Be specific as possible about what the issue
was and the source code affected (e.g., lack of input validation, session
management, etc).
CSCI 631
Page 3 of 3
Sections 5.3 – 5.5 – Included for illustrative and eductional purposes and require
no action.
h. Section 6 – Recommended Remediation Actions: Leave blank for later
remediation project.
Outputs
This is a research-based paper in current APA format that focuses on the results from a web
security assessment. It leverages a standard report template – “Web Application Security Report
Template” as a starting point. You can optionally choose to use your own format, but it must
contain all of the elements mentioned above in the instructions. The paper must include at least
three (3) references in addition to the course textbooks and the Bible. Include relevant
screenshots as appropriate. Be sure to repaginate the table of contents and remove any
instructions highlighted in red from the template.
Submit this assignment by 11:59 p.m. (ET) on Sunday of Module/Week 6.
Web Security Assessment Report
Version 1.0
|
Web Application Security Assessment Report |
|
Prepared for By |
|
|
Table of Contents
1
Template Instructions:
2
1
Assessment Introduction
31.1
References
4
2
Web Application Description
42.1
Application Overview
42.2
Application Architecture
4
2.2.1
Network Firewall Application Component
4
2.2.2
Web Server Component
4
2.2.3
Application Server Application Component
5
2.2.4
File System Application Component
5
2.2.5
Remote Device Component
6
3
Assessment Assumptions
63.1
Components Included in the Assessment
63.2
Components Excluded from the Assessment
63.3
Other Assumptions
63.4
Biblical Principles
7
4
Assessment Approach
74.1
Security Architecture Review
74.2
Web Server Security Scan
74.3
Dynamic Vulnerability Scan
84.4
Source Code Scan
84.5
Out of Scope Items
9
5
Assessment/Verification Results
95.1
Summary of Test Results
9
5.1.1
Cross-Site Scripting (XSS) Findings
9
5.1.2
Cross-Site Request Forgery (CSRF) Findings
9
5.1.3
SQL Injections Findings
9
5.1.4
Broken Access Control Findings
95.2
Source Code Findings
105.3
OWASP ASVS Level 1A Verification Requirements
105.4
OWASP ASVS Level 1B Verification Requirements
105.5
Web Server NIST Verification Requirements
11
6
Recommended Remediation Actions
116.1
Web Application Recommendations – XSS
126.2
Web Application Recommendations – CSRF
126.3
Web Application Recommendations – SQL Injections
136.4
Web Application Recommendations – Broken Access Controls
136.5
Other Web Recommendations
146.6
Biblical Integration Results
15
Appendix – Security Requirement Pass/Fail Verdicts
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
4. Run spell and grammar checker for the final deliverable.
1 Assessment Introduction
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
2 Web Application Description
2.1 Application Overview
The Target of Verification (TOV) is the
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
2.2.2 Web Server Component
2.2.3 Application Server Application Component
2.2.4 File System Application Component
2.2.5 Remote Device Component
3 Assessment Assumptions
3.1 Components Included in the Assessment
All code on
3.2 Components Excluded from the Assessment
3.3 Other Assumptions
3.4 Biblical Principles
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
4.3 Dynamic Vulnerability Scan
Dynamic scanning was performed at OWASP ASVS Level 1A using the following tool:
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
5 Assessment/Verification Results
5.1 Summary of Test Results
5.1.1 Cross-Site Scripting (XSS) Findings
5.1.2 Cross-Site Request Forgery (CSRF) Findings
5.1.3 SQL Injections Findings
5.1.4 Broken Access Control Findings
5.2 Source Code Findings
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.
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.
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.
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.
6.1 Web Application Recommendations – XSS
Recommendation
Priority
Remediation Effort
6.2 Web Application Recommendations – CSRF
Recommendation
Priority
Remediation Effort
6.3 Web Application Recommendations – SQL Injections
Recommendation
Priority
Remediation Effort
6.4 Web Application Recommendations – Broken Access Controls
Recommendation
Priority
Remediation Effort
6.5 Other Web Recommendations
Recommendation
Priority
Remediation Effort
6.6 Biblical Integration Results
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.
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
20