SQuAD: Application Security Testing Terry Morreale Ben Whaley June 8, 2010
Why talk about security? There has been exponential growth of networked digital systems in the past 15 years The great things about technology progress are also the things that make security harder: The ability to encapsulate knowledge (software) The ability to easily traverse geographic borders (networking) The ability to automate t a difficult task (software & networking)
Moore s Law for processers: old hat Yeah, we ve heard about (and experienced) Moore s Law for a long time. So what about NOW? Storage is getting cheaper faster than computing Bandwidth is getting cheaper faster than storage
Networks have become the 21 st driver century per Do ollar Sp pent Perfor rmance Optical Fiber (bits per second) (Doubling time 9 Months) Data Storage (bits per square inch) (Doubling time 12 Months) 0 1 2 3 4 5 Number of Years Scientific American, January 2001, slide by Larry Smarr, 2005
What is security? Vigilance Knowledge Risk management Methodology and policies Applied science ce / forensics Architecture Implementation Operations 3 risks and 3 priorities: Disclosure -> Confidentiality Corruption -> Integrity Unavailability -> Availability Multi-layered defense We have to deal with application and host security
Common security myths Myth #1: We aren t a likely target of attack. Fact: 42% of the 2009 CSI/FBI Computer Crime Survey respondents reported detecting a breach in the prior 12 months.
Common security myths Myth #2: A small percent of attacks/breaches involve insiders. id Fact: Actually, today nearly half of all attacks/breaches involve insiders.
Common security myths Myth #3: We re secure because we have a firewall. Fact: Almost nothing could be further from the truth. Multiple surveys have established that 95% of organizations that had a break-in had a standard commercial firewall in place.
Common security myths Myth #4: We haven t been broken into, therefore we are secure. Fact: Most break-ins go undetected for more than six months.
Types of breaches in 2009
Key trends One-third of CSI Survey Respondents organizations were fraudulently represented as the sender of a phishing message Incidents increasing in frequency: financial fraud, malware infection, denials of service, password sniffing, and Web site defacement Incidents decreasing in frequency: wireless exploits and instant messaging abuse Regulations, standards, and rules, oh my! HIPAA and HITECH Sarbanes-Oxley (SOX) FISMA Gramm-Leach-Bliley Act (Financial Services Modernization) SAS70 PCI/DSS COBIT
Which standards affect software developers and testers? Many standards specifically reference information system development and testing ISO27002 Accepted industry best practices NIST 800 series A collection of Special Publications developed accepted as IT security standards by the federal government PCI DSS compliance required for all organizations that process credit card payments HIPAA compliance required for all organizations that store or process EPHI While HIPAA does not specifically address coding or testing requirements, in order for organizations using software to be compliant, the products must meet certain standards
Some examples ISO27002 Section 12.2.1 Input data validation Data input to applications should be validated to ensure that this data is correct and appropriate. Checks should be applied to the input of business transactions, standing data, and parameter tables. The following guidelines should be considered: Dual input or other input checks, such as boundary checking or limiting fields to specific ranges of input data, to detect the following errors: Out of range values Invalid characters in data fields Missing or incomplete data Exceeding upper and lower data volume limits Unauthorized or inconsistent control data Periodic review of the content of key fields or data files to confirm their validity and integrity Procedures for responding to validation errors Procedures for testing the plausibility of the input data Etc.
ISO27002 continued Section 12.2.2 Control of internal processing Validation checks should be incorporated into applications to detect any corruption of information through processing errors or deliberate acts. Section 12.2.3 Message integrity Requirements for ensuring authenticity and protecting message integrity in applications should be identified and appropriate controls identified and implemented. Section 12.2.4 Output data validation Data output from an application should be validated to ensure that the processing of stored information is correct and appropriate to the circumstances.
NIST 800-53 Section SC-2 Application Partitioning The information i system separates user functionality (including user interface services) from information system management functionality. The information system prevents the presentation of information system management-related functionality at an interface for general users. Section SC-3 Security Function Isolation The information system isolates security functions from nonsecurity functions. Section SC-4 Information in Shared Resources The information system prevents unauthorized and unintended information transfer via shared system resources. Section SC-5 Denial of Service Protection The information system protects against or limits the effects of denial of service attacks.
NIST 800-53 continued The list goes on and on A few more examples Resource priority (limit use of resources by priority) Boundary protection (control communication at the boundaries) Transmission integrity (protect transmitted information from modification) Transmission confidentiality (protect from disclosure)
Open Web Application Security Project The OWASP guide is the de-facto authoritative resource for web application security For example, the PCI DSS standard requires that applications are developed according to OWASP Too loose to be called a standard, but still a wonderful resource Lots of resources: OWASP Guide Top 10 Lists WebGoat training application WebScarab b and more!
OWASP Top 10 A1 Injection OWASP Description SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command query. A2 Cross-Site Scripting XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation. A3 Broken authentication ti ti and Application functions related to session management authentication and session management are often not implemented correctly. A4 Insecure Direct Object Reference Exposure of an internal implementation object to the consumer.
OWASP Top 10 OWASP Description A5 Cross Site Request Forgery A6 Security Misconfiguration A7 Insecure Cryptographic Storage A pre-authenticated session that coerces a vulnerable web application to execute arbitrary actions on behalf of the attacker. The application, framework dependencies, server, or platform are not security configured and/or are poorly maintained. Sensitive data is not protected by encryption or hashing.
OWASP Top 10 OWASP Description A8 Failure to Restrict URL Access Access to sensitive data restricted only by URL obfuscation (security through obscurity). A9 Insufficient Transport Layer Protection A10 Unvalidated Redirects or Forwards. Lack of authentication, encryption, or other security controls for data in transit. Redirects and forwards are not properly validated, allowing attackers to trick users in to visiting iii malicious lii pages.
OWASP Top 10 versus MITRE Vulnerability Trends
Finding vulnerabilities Jeremiah Grossman 4/2007
Finding vulnerabilities continued Jeremiah Grossman 4/2007
Real World SQL Injection Attacks April 13, 2008: Oklahoma Department of Corrections leaks 10,597 SSNs from the sex offender registry web site A printer friendly link used a raw SQL string as a URL parameter Trivially manipulating the parameters allowed arbitrary database queries, including SSN Site last modified in 2005, so 3 years of exposure
Real World XSS Attack April 18, 2008 Barack Obama s official site hacked Javascript and malicious HTML passed to the URL was not properly validated Clicking certain links redirected to hillaryclinton.com
OWASP Testing Guide Defines 10 categories for testing web applications Information Gathering Config. Management Testing Business Logic Testing Authentication Testing Authorization Testing Session Management Testing Data Validation Testing Denial of Service Testing Web Services Testing Ajax Testing
Security testing techniques Manual Inspection and Review Pros: Flexible, low cost of entry, improves communication Cons: Extremely time consuming, high level of skill req d Threat Modeling Decompose, Define/Classify, Explore vulnerabilities and threats, Mitigate Pros: Practical attacker view of the system/process, standards based (NIST 800-30) Cons: New, somewhat vague Source Code Review Pros: Complete coverage, Accurate Cons: Requires extreme skill, may miss vulnerabilities in dependencies Pen Testing Pros: Fast, test code directly Cons: Late in the life cycle, lower coverage
Questions? Contact us any time! Terry Morreale terry@appliedtrust.com 303-245-4507 Ben Whaley ben@appliedtrust.com 303-245-4521