IT Security Standard: Web Application Security Vulnerabilities

russianmiserableSecurity

Jun 13, 2012 (5 years and 3 months ago)

491 views

IT Security Standard: Web Application Security Vulnerabilities 
Effective Date:  
9/30/2010 
Compliance Date:  
9/30/2010 
Revision History: 
Date
By
Action
Pages
09/30/10 Dara Manker
Linda Sandy
Release of New Document All
Review Frequency: 
Annually. 
Responsible Office: 
ITS 
Responsible Officer: 
Timothy Kearns 
CIO, Vice Provost Information Technology 
Brief Description: 
The purpose of this standard is to provide guidelines and documentation for reviewing web applications 
for security vulnerabilities prior to deployment. 
Related Policy: 
CSU Information Security Policy 8070.0: Information Systems Acquisition, Development and 
Maintenance:  
http://www.calstate.edu/icsuam/sections/8000/8070.0.shtml
 
Introduction:  
Web applications are susceptible to attacks that may result in exposure or modification of sensitive 
data, or impact on availability of services to authorized users.  Application testing is conducted to 
identify security flaws introduced in the design, implementation or deployment of an application.  
Developers and application administrators must identify functions that are critical to security, and test 
those functions to verify correct operation. 
Scope: 
This standard applies to any departments that implement and maintain web applications that are locally 
developed and configured. 
  1
Standard: 
Required: 
1. Web applications must be reviewed and tested for security vulnerabilities.  Applications that store, 
process or provide access to Level 1 or Level 2 information must be tested to an appropriate level of 
detail based on assessed risk. For definitions of risk levels to be taken under consideration, see the 
“Related Procedures and Resources” section below. 
2. Vulnerability assessment must be coordinated with and approved by authorized individuals. 
3. All security flaws must be entered into a defect tracking system, clearly identified as a security 
defect, and categorized according to severity.  This information must be protected appropriately, 
prioritized, and fixed before the application is released.  Flaws discovered in applications that are 
already released must be assessed to determine whether there is a low/medium/high level of 
exposure due to the following factors:  
o The likelihood that the security flaw would be exposed 
o  The impact on information security, integrity and application availability 
o The level of access that would be required to exploit the security flaw 
4. Emergency procedures for addressing security flaws must be defined and documented prior to 
production deployment. 
Recommended:  
1. Web software applications should be developed per secure coding guidelines such as the Open Web 
Application Security Project (OWASP) guidelines. 
2. Peer‐review code with at least one other technically trained individual. 
3. Validate all data received via the HTTP Request. Not validating data can result in attacks such as 
Cross Site Scripting, SQL Injection, HTTP Response Splitting, Log Injection, and Directory Traversal 
(for descriptions of these vulnerabilities, see the “CWE/SANS TOP 25 Most Dangerous Software 
Errors” link in the “Related Procedures and Resources” section below.   
4. Validate the data on the server‐side (e.g. do not trust JavaScript validation).  With tools such as 
WebScarab and Paros, the user is able to modify values even after performing an HTTP POST, so 
validating on the client‐side is insufficient.  All data (even hidden fields and data from pull down 
lists) are subject to being modified by a malicious user and should be validated server‐side. 
5. Pass session IDs and cookies via SSL (HTTPS).  Hackers can intercept unprotected session IDs and 
cookies and use them to compromise the user’s session (session hijacking), and the security of your 
system.  
6. Vulnerability scans should be performed whenever there are developer changes to application code 
or configuration. 
Review the “CWE/SANS TOP 25 Most Dangerous Software Errors” web page (errors as of 9/2010
included below for convenience). Identify those potential vulnerabilities that may apply to your web
application. Review your code and test your application to ensure that your application is not
vulnerable. (See the “Related Procedures and Resources” section below for the link to more detailed
information about these software vulnerabilities.
Definitions: 
Web Application: For the purposes of these IT Security Standards, a web application is defined as any 
application that connects to a campus network and/or the Internet and that dynamically accepts user 
input. 
  2
Responsibilities:   
Anyone who develops and/or maintains web application source code is expected to have knowledge of 
and exposure to security standards and best practices.  
Non­Compliance and Exceptions: 
MARY SHAFFER TO ADD ‐ What will happen if the standard isn’t met and how to request exceptions to 
the standard. This can be added later by the OCIO and will likely be the same for all IT standards.   
Related Procedures and Resources: 
Websites 

<Definition of Risk Levels> 
<V:\its\Projects\ITS Security Team\Cal Poly Current Versions\PriorityDefs.docx> 
 

CWE/SANS TOP 25 Most Dangerous Software Errors 
http://www.sans.org/top25‐software‐errors/
 
Descriptions and examples of dangerous software vulnerabilities: 
 

The SAN Institute 
http://www.sans.org

An excellent organization for information about security concerns 
 

OWASP: The Open Web Application Security Project 
http://www.owasp.org/index.php/Main_Page
 
A 501c3 not‐for‐profit worldwide charitable organization focused on improving the security of 
application software. 
 
o
Guide to Building Secure Applications  
http://www.owasp.org/index.php/OWASP_Guide_Project
 
Much more detailed coverage, with examples in Java, ASP, PHP, etc. 
 
o
Application Security Verification standards (ASVS)  
http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_
Standard_Project#tab=Download
 
Contains specific application verification steps. It defines four levels of security 
verification, which can be attained as the [organization/developer/assessment function] 
gains experience and resources. This document is most directly applicable to verifying 
Web application security.  See pg 21 and on for the high‐level matrix of requirements at 
each level. 
 
• OSSTMM ‐ Open Source Security Testing Methodology Manual  
http://www.isecom.org/osstmm
 
  3
The Open Source Security Testing Methodology Manual (OSSTMM) is a peer‐reviewed 
methodology for performing security tests and metrics. The OSSTMM test cases are divided into 
five channels (sections) which collectively test: information and data controls, personnel security 
awareness levels, fraud and social engineering control levels, computer and telecommunications 
networks, wireless devices, mobile devices, physical security access controls, security processes, 
and physical locations such as buildings, perimeters, and military bases. 
The OSSTMM focuses on the technical details of exactly which items need to be tested, what to 
do before, during, and after a security test, and how to measure the results. New tests for 
international best practices, laws, regulations, and ethical concerns are regularly added and 
updated. 
 

Duke University’s ITSO Web Application Security Standard 
Appendix A provides code examples 
Appendix B provides their security checklist 
http://www.security.duke.edu/ITSO_Web_Application_Security_Standard_v1.pdf
 
 

CSU Chico “Application Code Development Standards”  
Appendix A: “Testing Methods and Tools” includes descriptions of static analysis and web 
application vulnerability scanners (free and commercial): 
http://www.csuchico.edu/ires/security/documents/Application%20Code%20Development%20S
tandardv7.pdf
 
 
• UC Irvine “Application Security for Developers and Quality Assurance Personnel” 
A sample security checklist for developers and QA staff: 
http://net.educause.edu/ir/library/pdf/EPS306.pdf
 
Utilities 
• SANS Internet Security Tools That Work
 
SANS WhatWorks saves user organizations months of time that would be wasted in trying to 
uncover the truth about which Internet security tools actually work in their environments. 
WhatWorks is a user‐to‐user program in which managers from organizations that have 
implemented each of the effective Internet security technologies tell a complete story of why 
they deployed it, how it works, how they know it actually improves security, what problems they 
faced, and what lessons they learned. 
 
• OWASP ESAPI Project 
ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security 
control library that makes it easier for programmers to write lower‐risk applications. The ESAPI 
libraries are designed to make it easier for programmers to retrofit security into existing 
applications.  The ESAPI Project has APIs for Java, .Net, PHP, Python, JavaScript, Ruby, and more. 
http://www.owasp.org/index.php/OWASP_ESAPI
 
 
• Static Analysis Tools 
Static code analysis is the analysis of computer software that is performed without actually 
  4
executing programs built from that software. Static Analysis Tools should: 
• Support the programming languages required 
• Scan and report vulnerabilities with a minimum of false positives and false negatives 
• Support a centralized security policy management so all scans use established policies 
• Scan for malicious code detection 
• Support the use of an underlying DBMS to collect, report, export and analyze scan 
results 
• Provide remediation for vulnerabilities found 
• Provide measurement metrics for long term trending of applications 
• Enable collaboration between security teams and development and QA 
• Provide customization capabilities to accommodate unique coding styles 
• Correlate dynamic testing to assist in the prioritization of static results 
There are many commercially available static analysis tools. A list of such tools includes: 
• Ounce Labs ‐ Ounce Labs' code review tool (formerly Prexis) analyzes the source code of 
applications and identifies confirmed vulnerabilities and other potential security issues. 
• Parasoft’s Jtest & C++test ‐ Parasoft’s Jtest is a Java testing product for development 
teams building JavaEE, SOA, Web, and other Java applications. Parasoft’s C++test 
provides coding policy enforcement, static analysis, code review, unit, and component 
testing for C and C++ code. 
• Klocwork Insight ‐ Klocwork Insight finds software bugs and security vulnerabilities in C, 
C++ and Java code. 
• Fortify Source Code Analyzer (SCA) ‐ Fortify SCA finds programming errors and 
vulnerabilities in 12 programming languages: Ajax (JavaScript), C/C++, Classic ASP, 
COBOL, ColdFusion, Java, .NET, PHP, PL/SQL, T/SQL and VB6. Fortify also finds errors in 
code that combines any of these 12 programming languages. 
• GrammaTech CodeSonar ‐ GrammaTech CodeSonar is a source code analysis tool that 
performs interprocedural analysis on C/C++ code and identifies vulnerabilities in 
programming logic. 
• Coverity Prevent ‐ Coverity Prevent identifies and resolves the critical security defects in 
C, C++ and Java source code. 
 
• Web Application Vulnerability Scanners 
Web application scanners allow testers and application developers the ability to scan web 
applications in a fully operational environment and check for many known security 
vulnerabilities. Web application scanners parse URLs from the target website to find 
vulnerabilities. These scanners check web applications for common security problems such as 
SQL injection, cross‐site scripting, command injection, buffer overflow, session management, 
and other vulnerabilities. These tools can be used to satisfy code review requirements based on 
the security checks provided by the tool. Web application scanners should be used on each web 
application release prior to deployment to a production environment. 
• Free tools: 
o WebScarab Project (OWASP.org) ‐ WebScarab is a framework for analyzing 
applications that communicate using the HTTP and HTTPS protocols. It is written 
in Java, and is thus portable to many platforms. WebScarab has several modes 
of operation, implemented by a number of plugins. In its most common usage, 
WebScarab operates as an intercepting proxy, allowing the operator to review 
and modify requests created by the browser before they are sent to the server, 
  5
  6
and to review and modify responses returned from the server before they are 
received by the browser. WebScarab is able to intercept both HTTP and HTTPS 
communication. 
o Paros Proxy (parosproxy.org) ‐ Paros Proxy is completely written in Java. 
Through Paros's proxy nature, all HTTP and HTTPS data between server and 
client, including cookies and form fields, can be intercepted and modified. 
• Commercial Tools: 
o WebInspect ‐ HP’s WebInspect is a web vulnerability scanning tool that scans 
web applications for potential security flaws such as buffer overruns, weak 
cryptography, race conditions, SQL injection, cross site scripting, and others. 
WebInspect is automatically updated with known hacking techniques with each 
assessment performed. 
o AppScan ‐ IBM’s AppScan is a web application security testing tool that scans 
and tests for all common web application vulnerabilities. Vulnerabilities scanned 
for include: SQL injection, cross‐site scripting, buffer overflow, and others. 
o Fortify Program Trace Analyzer (PTA) ‐ Fortify PTA enables QA organizations to 
find security vulnerabilities and leaks while conducting functional testing 
enabling testers to uncover security vulnerabilities in the application with no 
additional effort. Fortify PTA also pinpoints vulnerabilities to specific lines of 
code, facilitating remediation.