Survey of web app/server security issues

Informal, ad hoc survey of web app/server security issues: audit checklists, best practices, standards, including design, implementation, and security assessment (but not policies so much). (April, 2011)

Audit checklists:

SANS: Oracle database security checklist
SANS: Firewall checklist
SANS: Web application checklist
SANS: A Security Checklist for Web Application Design
SANS: Web application security checklist
SANS: Linux security checklist
SANS: Firewall checklist
CERT, Appendix A.3, 2005.
CSIS Critical Controls, August, 2009.
OWASP Authentication and Session Management question list, April, 2010.
OWASP Security Misconfiguration question list, April, 2010.

Vulnerabilities of web apps and web server systems, some infrastructure vulnerabilities, and some controls: not exhaustive. Some overlap between areas/names.

Injection: SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. requires checking the code; automated pentesting may not catch all cases. all input received from remote sources must be sanitized of data meaningful to backend database systems. dynamic code. owasp nsa2 nsa3 cert yahoo sans1 mitre
user-input validation attacks (overlaps with Injection). Unvalidated Sources of Input: URL parameters; form fields; cookies; HTTP headers; database queries.: sans1 cert focus
cookies (overlaps user-input validation and injection): yahoo
Cross-Site Scripting (XSS): owasp yahoo sans1 mitre
Broken Authentication and Session Management, flawed authorization: owasp nsa2 cert
Insecure Direct Object References: owasp
Cross-Site Request Forgery (CSRF): owasp yahoo mitre
Security Misconfiguration: owasp nsa2 cert
Insecure Cryptographic Storage, data storage security: owasp focus
Failure to Restrict URL Access: owasp
Insufficient Transport Layer Protection: owasp cert
Unvalidated Redirects and Forwards: owasp mitre
PHP File Include attacks (overlaps with Injection): sans1 mitre
'Zeroboard PHP' application (overlaps with Injection): sans1
'HTTP Connect Tunnel' attacks (overlaps with Injection): sans1
XML Denial of Service Issues: nsa2
Replay Attack Flaws: nsa2
Inadequate Testing: nsa2
Insufficient Logging: nsa2
Unvalidated Output Streams. (risk to client.): cert
Native Code and Buffer Overflows: cert mitre
Weak encryption: cert
Unsupported Application Interfaces: cert
Improper Administrative and Exception Handling: cert
SOAP: nsa7
third party code review: isf
'offense must inform defense.' Only people who understand how attacks are carried out can be expected to be effective defenders. maintain a security culture that makes the protection of data and end users a top priority.: sans1 focus
data execution prevention: nsa4
database hardening: nsa1
insecure system default configurations, system/OS hardening: nsa5 nsa6 focus
Test and evaluate applications for potential weaknesses whenever they have been changed or updated: focus
vendor-issued security patches and updates (OS, web server, database). Keep web server software up to date.: focus yahoo
Never store passwords in clear text.: yahoo
for those attacks that are successful, defenses must be capable of detecting, thwarting, and responding to follow-on attacks on internal enterprise networks as attackers spread inside a compromised network. defense in depth. csis nsa8
Inventory of Authorized and Unauthorized Software: automatically check the software present on systems: csis securityweek
disable/block IPv6: csis
blacklist malicious IP addresses: csis
deploy web application firewalls that inspect all traffic flowing to the web application for common web application attacks, including but not limited to Cross-Site Scripting, SQL injection, command injection, and directory traversal attacks.: csis

By organization:

SANS (SysAdmin, Audit, Network, Security) Institute
- The Top Cyber Security Risks, September, 2009. Nine page article. subset of points:
  - Two risks dwarf all others, but organizations fail to mitigate them: client-side software that remains unpatched; Internet-facing web sites that are vulnerable.
  - 'offense must inform defense.' Only people who understand how attacks are carried out can be expected to be effective defenders.
  - Web application vulnerabilities such as SQL injection and Cross-Site Scripting flaws... most web site owners fail to scan effectively for the common flaws
  - SQL Injection, Cross-site Scripting and PHP File Include attacks continue to be the three most popular techniques used for compromising web sites.
  - The SQL Injection attacks that compose this category include 'SQL Injection using SELECT SQL Statement', 'SQL Injection Evasion using String Functions', and 'SQL Injection using Boolean Identity'. The most prominent 'PHP Remote File Include attack' is one that looks for a very small HTTP request that includes a link to another website as a parameter that contains a very specific evasion technique used by a number of attacks to increase the reliability of their attacks. Also of note is a very specific attack against the 'Zeroboard PHP' application, the only single application that made the top attacks. The final type of attack included in these statistics is one of the more popular 'HTTP Connect Tunnel' attacks, which remains a staple in the Server-Side HTTP category. The HTTP connect tunnels are used for sending spam emails via mis-configured HTTP servers.
  - Application developers should ensure that all input received from remote sources is sanitized of data meaningful to backend database systems.
  - buffer overflow vulnerabilities in Windows... constituted over 90% of attacks seen against the Windows operating system.
  - Rising numbers of zero-day vulnerabilities. Some vulnerabilities have remained unpatched for as long as two years. (mostly client-side issue?)
  - Application Vulnerabilities Exceed OS Vulnerabilities
- checklists:
  - Oracle database security checklist
  - Firewall checklist
  - Web application checklist
  - A Security Checklist for Web Application Design
  - Web application security checklist
  - Linux security checklist
  - Firewall checklist
  - I did not find an Apache security checklist.
- SSL Man-in-the-Middle Attacks, February, 2002. 13 page pdf.
- Mass SQL Injection for Malware Distribution, April, 2011. 15 page pdf.
- A Multi-Perspective View of PHP Remote File Include Attacks, November, 2009.
- Web servers. 21 articles, mostly 2003 - 2005.
- Penetration testing. 27 articles, 2003 - 2011.
  - Penetration Testing in the Financial Services Industry, March, 2010.
- Auditing and assessment. 67 articles, 2002 - 2011.
  - Effective Use Case Modeling for Security Information & Event Management, March, 2010.
- Top 25 software errors (MITRE). subset:
- 20 Critical Security Controls: seems like a hypertext version of the Center for Strategic and International Studies document that I commented on below, here.
Open Web Application Security Project (OWASP)
- Top 10 Web Application Security Risks, April, 2010.
  - Injection: SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. requires checking the code; automated pentesting may not catch all cases.
  - Cross-Site Scripting (XSS)
  - Broken Authentication and Session Management
  - Insecure Direct Object References
  - Cross-Site Request Forgery (CSRF)
  - Security Misconfiguration
  - Insecure Cryptographic Storage
  - Failure to Restrict URL Access
  - Insufficient Transport Layer Protection
  - Unvalidated Redirects and Forwards
- What's Next For Developers
- What's Next For Organizations
- What's Next For Verifiers
National Security Agency (NSA)
- Information Assurance / Guidance
  - Security Configuration Guides
    - Applications
      - not Apache
    - Database Servers
      - Oracle
      - Microsoft SQL Server
    - Fact Sheets
      - Service Oriented Architecture Security Vulnerabilities Web Services, November, 2008. Four page pdf.
        
        Injection flaws
        
        XML Denial of Service Issues
        
        Insecure Communications
        
        Information Leakage
        
        Replay Attack Flaws
        
        Insufficient Authentication
        
        Inadequate Testing
        
        Insecure Configuration
        
        Insufficient Logging
      - Minimize the Effectiveness of SQL Injection Attacks , May, 2008. Two page pdf.
      - Data Execution Prevention (DEP), October, 2007. Two page pdf.
        
        ExecShield is enabled by default for RHEL3.3+.
    - Operating Systems
      - Guide to the Secure Conﬁguration of Red Hat Enterprise Linux 5, February, 2011. 184 page pdf.
      - Hardening Tips For Default Installation of Red Hat Enterprise Linux 5, November, 2007. Two page pdf.
    - Supporting Documents
      - Web Application Security Overview, reviewed March, 2009. Four page pdf.
      - Defense in Depth, reviewed March, 2009. Four page pdf.
  - Standards Profiles
    - Net-Centric Enterprise Services (NCES) Profile of Web Service Security: Simple Object Access Protocol (SOAP) Message Security (WSSE).
- I did not find a document about how to secure Apache v2+ though there were multiple references within RHEL documents. There was a MITRE 2001 document about securing Apache 1.3.3.
Web Application Security Consortium (WASC).
- The WASC Threat Classification v2.0, last edited January, 2010. Lists and explains 34 attacks and 15 vulnerabilities.
- Web security articles, 2004 - 2007.
US-CERT
- SOFTWARE SECURITY ASSURANCE: A FRAMEWORK FOR SOFTWARE VULNERABILITY MANAGEMENT AND AUDIT, 2005. 61 page report. subset of points:
  - Many positions within an organization have responsibilities for ensuring the security of online applications – from the programmer writing the source code all the way through the audit committee of the board that must assess the reliability of assurance regarding information reliability and security. As audit represents an essential element for controls assurance, this guide also provides guidance for audits of software security vulnerability management as well as an example audit program that can be modified to fit an organization’s specific needs.
  - VI. The Solution: A Framework for Software Security Assurance
    - VI.A.1. Risk assessment (pp 9-12): penetration testing; manual review of program code; automated code scanning tools.
  - Appendix A: Audit Program and Internal Control Questionnaire for Source Code Vulnerability Management
    - A.3. Questions (pp 19-20).
  - Appendix B: Roles and Responsibilities for Software Security Assurance
  - Appendix C: Control Objectives and Practices
    - Software Security Assurance and Related Control Frameworks, Requirements, Standards, and Guidance: COSO, SOx, COBIT, AND ISO/IEC 17799. pp 29-51. audit controls.
  - Appendix D: Identifying Vulnerabilities in Web Applications: The Top Sources of Exposure to Locate and Remediate
    1. Unvalidated Sources of Input: URL parameters; form fields; cookies; HTTP headres; database queries.
    2. Use of Unvalidated Input
    3. Unvalidated Output Streams. (risk to client.)
    4. Flawed Authorization and Access Control
    5. Flawed Authorization and Session Management
    6. Native Code and Buffer Overflows
    7. Dynamic Code
    8. Weak Encryption
    9. Application Configuration
    10. Denial of Service
    11. Network Communications
    12. Unsupported Application Interfaces
    13. Improper Administrative and Exception Handling
Center for Strategic and International Studies (CSIS)
- Twenty Critical Controls for Effective Cyber Defense: Consensus Audit Guidelines, August, 2009. 49 page pdf. Written for federal context. 20 specific technical security controls that are viewed as effective in blocking currently known high-priority attacks, as well as those attack types expected in the near future. These map directly to about one third of the 145 controls identified in NIST Special Publication 800-53, revision 3. Though few of these points are specific to web servers, they seem useful nevertheless. (Hypertext version here.) subset of points:
  - for those attacks that are successful, defenses must be capable of detecting, thwarting, and responding to follow-on attacks on internal enterprise networks as attackers spread inside a compromised network.
  - “offense must inform defense.” In other words, knowledge of actual attacks that have compromised systems provides the essential foundation on which to construct effective defenses.
  - these controls are meant to deal with multiple kinds of computer attackers, including but not limited to malicious internal employees and contractors, independent individual external actors, organized crime groups, terrorists, and nation state actors, as well as mixes of these different threats.
  - The first fifteen of these twenty controls can be monitored, at least in part, automatically and continuously.
  - Critical Control 1: Inventory of Authorized and Unauthorized Devices
    - ... Secure the asset inventory database and related systems, ensuring that they are included in periodic vulnerability scans and that asset information is encrypted. Limit access to these systems to authorized personnel only, and carefully log all such access.
    - To evaluate the effectiveness of automated asset inventory tools, periodically attach several hardened computer systems not already included in asset inventories to the network and measure the delay before each device connection is disabled or the installers confronted.
  - Critical Control 2: Inventory of Authorized and Unauthorized Software
    - To evaluate the effectiveness of automated software inventory tools, periodically install several software updates and new packages on hardened control machines in the network and measure the delay before the software inventory indicates the changes. Such updates should be chosen for the control machines so that they do not negatively impact production systems on the network.
  - Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers
    - At least once per month, run assessment programs on a varying sample of systems to measure the number that are and are not configured according to the secure configuration guidelines.
    - Utilize file integrity checking tools on at least a weekly basis to ensure that critical system files (including sensitive system and application executables, libraries, and configurations) have not been altered. All alterations to such files should be automatically reported to security personnel.
  - Critical Control 4: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
    - Network devices that filter unneeded services or block attacks (including firewalls, network-based Intrusion Prevention Systems, routers with access control lists, etc.) should be tested under laboratory conditions with each given organization’s configuration to ensure that these devices exhibit failure behavior in a closed/blocking fashion under significant loads with traffic including a mixture of legitimate, allowed traffic for that configuration intermixed with attacks at line speeds.
    - All new configuration rules beyond a baseline-hardened configuration that allow traffic to flow through network security devices, such as firewalls and network-based IPSs, should be documented and recorded in a configuration management system, with a specific business reason for each change, a specific individual’s name responsible for that business need, and an expected duration of the need. At least once per quarter, these rules should be reviewed to determine whether they are still required from a business perspective. Expired rules should be removed.
    - Network filtering technologies employed between networks with different security levels (firewalls, network-based IPS tools, and routers with ACLs) should be deployed with capabilities to filter IPv6 traffic. Even if IPv6 is not explicitly used on the network, many operating systems today ship with IPv6 support activated, and therefore filtering technologies need to take it into account.
    - Network devices should be managed using two-factor authentication and encrypted sessions. Only true two-factor authentication mechanisms should be used, such as a password and a hardware token, or a password and biometric device. Requiring two different passwords for accessing a system is not two-factor authentication.
  - Critical Control 5: Boundary Defense
    - Organizations should deny communications with (or limit data flow to) known malicious IP addresses (blacklists). Periodically, test packets from bogon source IP addresses should be sent into the network to verify that they are not transmitted through network perimeters.
  - Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs
    - Sometimes logging records are the only evidence of a successful attack. Many organizations keep audit records for compliance purposes but attackers rely on the fact that such organizations rarely look at the audit logs so they do not know that their systems have been compromised. Because of poor or non-existent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.
    - Operating systems should be configured to log access control events associated with a user attempting to access a resource (e.g., a file or directory) without the appropriate permissions.
    - Security personnel and/or system administrators should run bi-weekly reports that identify anomalies in logs. They should then actively review the anomalies, documenting their findings.
    - Network boundary devices, including firewalls, network-based IPSs, and inbound and outbound proxies should be configured to log verbosely all traffic (both allowed and blocked) arriving at the device.
    - Organizations should periodically test the audit analysis process by creating controlled, benign events in logs and monitoring devices and measuring the amount of time that passes before the events are discovered and action is taken.
  - Critical Control 7: Application Software Security
    - Organizations should protect web applications by deploying web application firewalls that inspect all traffic flowing to the web application for common web application attacks, including but not limited to Cross-Site Scripting, SQL injection, command injection, and directory traversal attacks.
    - Organizations should test in-house developed and third-party procured web and other application software for coding errors and malware insertion, including backdoors prior to deployment using automated static code analysis software. ... In particular, input validation and output encoding routines of application software should be carefully reviewed and tested.
    - Organizations should test in-house developed and third-party procured web applications for common security weaknesses using automated remote web application scanners prior to deployment, whenever updates are made to the application, and on a regular recurring basis, such as weekly.
    - For applications that rely on a database, organizations should conduct a configuration review of both the operating system housing the database and the database software itself, checking settings to ensure that the database system has been hardened using standard hardening templates.
    - Organizations should ensure that all software development personnel receive training in writing secure code for their specific development environment.
  - Critical Control 8: Controlled Use of Administrative Privileges
    - The second common technique used by attackers to spread inside a target enterprise is elevation of privileges by guessing or cracking a password for an administrative user to gain access to a target machine.
    - Organizations should inventory all administrative passwords and validate that each person with administrative privileges on ... servers is authorized by a senior executive and that his/her administrative password has at least 12 semirandom characters.
    - Organizations should ensure all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis as is done for traditional user and administrator passwords.
    - Remote access directly to a machine should be blocked for administrator-level accounts. Instead, administrators should be required to access a system remotely using a fully logged and non-administrative account. Then, once logged in to the machine without admin privileges, the administrator should then 28 transition to administrative privileges using tools such as sudo on Linux/UNIX, runas on Windows, and other similar facilities for other types of systems.
  - Critical Control 9: Controlled Access Based on Need to Know
  - Critical Control 10: Continuous Vulnerability Assessment and Remediation
    - Organizations should run automated vulnerability scanning tools against all systems on their networks on a weekly or more frequent basis. Where feasible, vulnerability scanning should occur on a daily basis using an up-to-date vulnerability scanning tool.
    - Organizations should ensure that vulnerability scanning is performed in authenticated mode (i.e., configuring the scanner with administrator credentials) at least quarterly, either with agents running locally on each end system to analyze the security configuration or with remote scanners that are given administrative rights on the system being tested, to overcome limitations of unauthenticated vulnerability scanning.
  - Critical Control 11: Account Monitoring and Control
  - Critical Control 12: Malware Defenses
  - Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services
    - Host-based firewalls or port filtering tools should be applied on end systems, with a default-deny rule that drops all traffic except those services and ports that are explicitly allowed.
  - Critical Control 14: Wireless Device Control
  - Critical Control 15: Data Loss Prevention
    - Network monitoring tools should analyze outbound traffic looking for a variety of anomalies, including large file transfers, long-time persistent connections, connections at regular repeated intervals, unusual protocols and ports in use, and possibly the presence of certain keywords in the data traversing the network perimeter.
  - Critical Control 16: Secure Network Engineering
    - To support rapid response and shunning of detected attacks, the network architecture and the systems that make it up should be engineered for rapid deployment of new access control lists, rules, signatures, blocks, blackholes, and other defensive measures.
  - Critical Control 17: Penetration Tests and Red Team Exercises
    - Penetration tests typically provide a deeper analysis of security flaws than the vulnerability assessments described in Control #10. Vulnerability assessments focus on identifying potential vulnerabilities, while penetration testing goes deeper with controlled attempts at exploiting vulnerabilities, approaching target systems as an attacker would. The result provides deeper insight into the business risks of various vulnerabilities, by showing whether and how an attacker can compromise machines, pivot to other systems inside a target organization, and gain access to sensitive information assets.
    - Organizations should conduct regular penetration tests to identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully. Penetration testing should occur from outside the network perimeter (i.e., the Internet or wireless frequencies around an organization) as well from within its boundaries (i.e., on the internal network) to simulate both outsider and insider attacks.
    - Organizations should perform periodic red team exercises to test the readiness of organizations to identify and stop attacks or to respond quickly and effectively.
  - Critical Control 18: Incident Response Capability
    - Organizations should ensure that they have written incident response procedures, which include a definition of personnel roles for handling incidents. (See NIST Special Publication 800-61.)
    - Organizations should conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that personnel understand current threats and risks, as well as their responsibilities in supporting the incident handling team.
  - Critical Control 19: Data Recovery Capability
  - Critical Control 20: Security Skills Assessment and Appropriate Training to Fill Gaps
    - Organizations should develop security awareness training for various personnel job descriptions. The training should include specific, incident-based scenarios showing the threats an organization faces. The training should reflect proven defenses for the latest attack techniques.
focus.com
- Best Practices for Web 2.0 Security, April 30, 2009. one page article briefly listing five best practice areas. subset of points:
  - user-input validation attacks: failure to perform thorough validation of user-input screens. (not mentioned: all form fields must be validated server-side, even if pre-validated client-side with JavaScript.)
  - insecure system default configurations
  - data storage security
  - Testing and evaluating applications for potential weaknesses whenever they have been changed or updated is particularly important.
  - vendor-issued security patches and updates
  - maintain a security culture that makes the protection of data and end users a top priority.
Information Security Forum (ISF)
- Standard of Good Practice for Information Security, 2007. 372 page pdf. chapters include computer installations, networks, systems development, et al. Internet is referenced on 36 pages but primarily concerning user environment; I did not see a systems development section particular to Internet. 'Specialised technical security controls should be applied to the development of web-enabled applications' - but no detail given.
  
  'SD5.2.3 Acceptance tests should: ... (e) involve independent security assessments of critical code, to detect vulnerabilities (eg ‘back doors’ or ‘time bombs’) and insecure use of programming features; (f) include attempts to compromise the security of the system (eg by performing penetration tests).'
  
  'SM4.3.3/SD4.4.4 The risk of potential security weaknesses in hardware / software should be reduced by: (a) obtaining external assessments from trusted sources (eg auditors’ opinions and specified security criteria, such as the ‘Common Criteria’ and FIPS (Federal Information Processing Standards))'
Yahoo
- Security Best Practices - Yahoo! Developer Network. one page article listing five guidelines. subset of points:
  - Ensure you have installed the latest operating system security patches.
  - Keep your web server software up-to-date
  - Never store passwords in clear text.
  - cookies: generate a unique signature for the user based on the login and password and store that in the cookie. (but this does not address MITM, encrypting, and auto-expiring cookies on server side).
  - Carefully check any parameters you pass to SQL statements in your application. Untreated user input can easily be hijacked to clear out your database.
  - Purge unused/unnecessary user data from your system regularly.
  - Protect Against Request Forgeries: Ensure that requests coming in to your application originated from your application. (gives examples.)
  - Protect Against Cross-Site-Scripting
Security Week
- Best Practices for Web Application Security, April 06, 2011. one page article briefly listing ten best practice areas. subset of points:
  - Taking an inventory of your applications is the most important step.
  - categorize and prioritize your apps
  - myth busting: firewall and IDS do not prevent hackers from exploiting your Web vulnerabilities
  - Use a quantitative score for prioritization of vulnerabilities
IBM
- The Application Security Space.

less useful for my needs:

National Institute of Standards and Technology (NIST)
- 800-53 rev3, 'Guide for Assessing the Security Controls in Federal Information Systems', updated in August 2009, specifically addresses the 194 security controls that are applied to a system to make it 'more secure.'
- 800-12 provides a broad overview of computer security and control areas
- 800-14 describes common security principles that are used
- 800-26 provides advice on how to manage IT security
- 800-37 'Guide for Applying the Risk Management Framework to Federal Information Systems'
Internet Engineering Task Force (IETF)
- Site Security Handbook: 1997 framework for setting security policies and procedures. 63 page document. general, old, and little or nothing about securing web servers.
  - Chapter 5: Security Incident Handling
International Standards Organization (ISO)
- ISO 15408 (Common Criteria): 'Information technology -- Security techniques -- Evaluation criteria for IT security'. index of downloadable docs
- ISO 15443: 'Information technology - Security techniques - A framework for IT security assurance' (not publicly available)
- ISO/IEC 27001: 'Information technology - Security techniques - Information security management systems - Requirements' (not publicly available)
- ISO/IEC 27002: 'Information technology - Security techniques - Code of practice for information security management' (not publicly available)
- ISO-20000: 'Information technology - Service management' (not publicly available)
North American Electric Reliability Corporation (NERC)
- NERC 1300 CIP-002-1 through CIP-009-2 (Critical Infrastructure Protection)
German IT Baseline Protection Catalogs
ISA: The International Society of Automation
- ISA-99: Industrial Automation and Control Systems Security
  - ISA-99.03.03 defines detailed technical requirements for IACS security. This standard is currently under development.
  - ISA-99.03.04 addresses the requirements for the development of secure IACS products and solutions. This standard is currently under development.
  - Standards in the ISA-99.04.xx series address detailed technical requirements at the component level. These standards are currently under development.