Post on 22-Dec-2015
transcript
Computer Science and Engineering 1
Web Application Security
ReadingReading
• Required:– Stuttard and Pinto: Chapter 1 and 2
• Recommended: – OWASP Top Ten Project,
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
• See presentation at the end of class http://blip.tv/owasp-appsec-conference-in-europe/day2_track1_1430-1505-3936900
Computer Science and Engineering 2
TCP/IP LayersTCP/IP Layers
• Goal: support secure communication: key management and authentication– Network Access Layer: L2TP tunneling– Networking Layer: IPSec– Transport Layer: SSL– Application Layer: SSh
• Limitations: lack of applications specific context
Computer Science and Engineering 3
4
Web EvolutionWeb Evolution
• Past: Human usage – HTTP– Static Web pages (HTML)
• Current: Human and some automated usage – Interactive Web pages– Web Services (WSDL, SOAP, SAML)– Semantic Web (RDF, OWL, RuleML, Web databases)– XML technology (data exchange, data representation)
• Future: Semantic Web Services
5
ARE THE EXISTING SECURITYARE THE EXISTING SECURITY MECHANISMS SUFFICIENT TO MECHANISMS SUFFICIENT TO
PROVIDE DATA AND APPLICATION SECURITY OF PROVIDE DATA AND APPLICATION SECURITY OF THE NEXT GENERATION WEB?THE NEXT GENERATION WEB?
6
Information Assurance Information Assurance
Inference Control
Privacy
Security Trust
Applications
Policy making
Formal models
Negotiation Protocol Analysis
Anonymity
Access control
Semantic web security
Encryption
Information hiding
Data mining Computer epidemic
Data provenance
Fraud
BiometricsAccess Control
Inference Control
Common Web ApplicationsCommon Web Applications
Common attacks against Web Applications: access to sensitive information, DoS attacks, compromise of back-end systems
Sample applications:– Shopping– Social Networking– Banking– Web Search– Web mail– Etc…
Computer Science and Engineering 7
Benefits of Web ApplicationsBenefits of Web Applications
• Convenience: – Web browser-based applications replace traditional
client-server applications– Browser software readily available– Highly functional browsers
• HTTP connectionless and can be tunneled or proxied• Web application core technologies are relatively
“simple” (next class)
Computer Science and Engineering 8
Computer Science and Engineering 9
Web Application SecurityWeb Application Security
Layered security:
1. Software-level (single service) security
2. Business-level (service composition) security
3. Network-level security
Example SDLCExample SDLC
CSCE 548 - Farkas
10
How the customer imagined How the customer imagined itit
CSCE 548 - Farkas
11
Copyright: This and the following slides onSDLC are modified from Project Cartoonhttp://www.projectcartoon.com/cartoon/1078
What the business analyst What the business analyst understoodunderstood
CSCE 548 - Farkas
12
How the architect designed How the architect designed itit
CSCE 548 - Farkas
13
What development believed What development believed the architect was describingthe architect was describing
CSCE 548 - Farkas
14
How the programmer How the programmer implemented itimplemented it
CSCE 548 - Farkas
15
How the project manager How the project manager explained itexplained it
CSCE 548 - Farkas
16
How the project wasHow the project wasdocumenteddocumented
CSCE 548 - Farkas
17
What operations installedWhat operations installed
CSCE 548 - Farkas
18
How the client was billedHow the client was billed
CSCE 548 - Farkas
19
Portion of original code that Portion of original code that still can be usedstill can be used
CSCE 548 - Farkas
20
What the client really What the client really neededneeded
CSCE 548 - Farkas
21
So if software engineering is hard So if software engineering is hard already, why do we want to make it already, why do we want to make it
harder by adding security harder by adding security considerations?considerations?
CSCE 548 - Farkas
22
OWASP Top 10 + Chapter 1OWASP Top 10 + Chapter 1
• Broken authentication – faulty application login (A2 and session management)
• Broken access control – application lack of proper access control (A3)
• SQL Injection – not validated input data (A1)• Cross-site scripting – shared application enables attacks
on other users (A2)• Cross-site request forgery – trick application users to
carry out unintended actions (A5)
Computer Science and Engineering 23
OWASP CategoritesOWASP Categorites
• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards
Computer Science and Engineering 24
Source of the ProblemSource of the Problem
• User supplied input• Fundamental assumption: all input is malicious• Attacker’s capabilities:
– Interfere with messages between client and server– Send messages in any sequence and in an unexpected
manner– Access applications directly without a web browser
Computer Science and Engineering 25
Key Problem FactorsKey Problem Factors
• Underdeveloped security awareness– Web applications vs. OS, network, databases
• Custom development– In-house or third-party contractors development
• Deceptive simplicity– Application frameworks: quick and easy
development by novice programmers– Shared framework among organizations, shared
vulnerabilities
Computer Science and Engineering 26
Key Problem Factors cont.Key Problem Factors cont.
• Resource and time constraints• Overextended technologies• Increased demands on functionality
Computer Science and Engineering 27
New Security PerimeterNew Security Perimeter
• Before web applications:
– Network perimeter protection (DMZ)
– Firewall
• With web applications:
– Firewall must allow access to the application server
– Server may connect to back-end systems
– Back-end system is behind several layers of defensive technologies
– Web application vulnerability may allow the attacker to access back-end system
Computer Science and Engineering 28
Vulnerable Applications, Vulnerable Applications, Victimized UsersVictimized Users
• Honest users may use compromised applications• Compromised applications allow malicious attacker to
access the victim’s back-end system• Malicious user gains privileges of the victimized user• Client-side attacks• Weakness of authentication via email notifications (e.g.,
forgotten password)
Computer Science and Engineering 29
Security Concerns
• Expanded number of service points• Expanded number of users• Perimeter security is not sufficient• Dynamic service relationships• Access across trust domains• Electronic documents• Indirect access via service invocation
Computer Science and Engineering 31
Application DevelopmentApplication Development
• Inherent Security of Applications
• Security granularity
Security Software Software Security
Computer Science and Engineering 32
WS Security Standards
• OASISOASIS Web Services Security (WSS) Web Services Security (WSS) – Integrity and authentication: sign SOAP msgs.– Confidentiality: encrypt SOAP msgs.– Attach security tokens
• Security tokensSecurity tokens• Security Assertion Markup Language (SAML) assertions• Kerberos tickets• User credentials• X.509 certificate• Custom defined tokens
Computer Science and Engineering 33
Software Security Software Security
Computer Science and Engineering 34
ApplicationsApplications
• Aggregated services each component is vulnerable
• What is the level of security provided by the aggregate?– Trust management
Computer Science and Engineering 35
Secure Software DevelopmentSecure Software Development
• Develop software that is free of flawsDevelop software that is free of flaws
– Software engineering – functional requirements
– Security, reliability, QoS – non-functional requirements
• Protect against malicious code
• ReadingReading:
– G. McGraw, Software Security , http://www.cigital.com/papers/download/bsi1-swsec.pdf
– US National Security Agency: System Security Engineering CMM (SSE CMM), http://www.sse-cmm.org/index.html
Computer Science and Engineering 35
Computer Science and Engineering 36
Software Security during Software Security during SDLCSDLC
Requirement and Use cases
Architecture and Design
Test Plans Code Tests andTest Results
Feedback fromthe Field
5. Abuse cases
6. Security Requirements
2. Risk Analysis
External Review
4. Risk-Based Security Tests
1. Code Review(Tools)
2. Risk Analysis
3. Penetration Testing
7. Security Operations
From: G. McGraw, Software Security
Computer Science and Engineering 37
Open Web Application Security Open Web Application Security Project (OWASP)Project (OWASP)
• Non-for-profit, worldwide organizations• GoalGoal: improve the security of application software• All materials: available under a free and open software
license• Common Weakness Enumeration (CWE): Common Weakness Enumeration (CWE): list of
software weaknesses– Full dictionary view– Development view– Research view
Computer Science and Engineering 38
Improper Error HandlingImproper Error Handling
• OWASP “A7 Improper Error handling,” 2007, http://cwe.mitre.org/data/definitions/728.html
• Variants:– Yielding too much information– Ignoring errors– Misinterpreting errors– Using useless error values– Handling the wrong exception– Handling all exceptions together
Computer Science and Engineering 39
Redemptions – SDLCRedemptions – SDLC
• Handle exceptions in application code• Do not group exceptions• Check return values when appropriate
• Time to target problem:– Design– Code review– Testing
Computer Science and Engineering 40
Sanitization ProcessSanitization Process
Customer
Server
Customer submits a request message
Server: attempts to processThe request and throws anException
Exception Shielding Routines: Evaluates exception data and Replaces it if unsafe
Server returns safe exception message
Computer Science and Engineering 41
Input ValidationInput Validation
• OWASP: CWE-20: improper Input Validation, http://cwe.mitre.org/data/definitions/20.html
• ProblemProblem: no or improper validation of input that can affect control flow or data flow of a program
• VariantsVariants:– Buffer overrun– Integer overflow– Command injection– SQL injection
• Reading: G. Hoglund and G. McDraw, Exploiting Software: How to Break Code, Chapter 7 Buffer Overflow, http://searchsecurity.techtarget.com/searchSecurity/downloads/Exploiting Software-Ch07.pdf
Computer Science and Engineering 42
ImpactImpact
• AvailabilityAvailability: malicious input may– Crash the program– Exhaust resources (e.g., memory, CPU)
• ConfidentialityConfidentiality: attacker may be able to access confidential resources
• IntegrityIntegrity: attacker may– Modify data– Alter control flow– Execute arbitrary commands
Computer Science and Engineering 43
Redemption – SDLC Redemption – SDLC
• Always validate dataAlways validate data• Stop using unsafe commands, e.g., strcpy, strncat, etc.• Understand casting and operators• Use “white listwhite list”• Static analysis tool• Manual analysis – design level
Computer Science and Engineering 44
Other Considerations about Other Considerations about Screening RoutinesScreening Routines
• Screening requires the decryptiondecryption of encrypted traffic• Must be able to handle all types of attachmentshandle all types of attachments to
evaluate malicious content• Must be very efficientefficient – not a bottleneck• Vulnerabilities of XML messages (data types, data
content, limited XML parser support)
Computer Science and Engineering 45
2010 CWE/SANS Top 25 Most 2010 CWE/SANS Top 25 Most Dangerous Programming Dangerous Programming
ErrorsErrors• URL: http://cwe.mitre.org/top25/
• List of 25 most dangerous programming errors List of 25 most dangerous programming errors leading to software vulnerable to malicious attacks
• Result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe
• Aims to helpAims to help– Programmers to prevent well known software vulnerabilities
– Software customers to ask for more secure software
– Researchers to focus on important problems
– Software managers and CIOs to measure their improvement in software security
Computer Science and Engineering 46
Network-Level SecurityNetwork-Level Security
• Authentication and identification • Access Control• Messaging middlewaremiddleware
– Communication security– End point security
• Protocol assurance
Single Sign-On
• Authentication of a user within multiple systems: use Digital Certificates and private keys
• Reduces security administration• Services can pass requester’s identity to other services
Access ControlExtended RBAC
• Extend RBAC with authorization attributes• AttributesAttributes are referenced within policies
– Credentials, certifications, etc.• Role hierarchy: inheritance of privileges• Security roles vs. access control roles• Other issues:
– Grant and revoke– Delegation of privileges
Access Control Administration
• Centralized access controlCentralized access control– Role engineering– Optimal role allocation and assignments– Protecting access control documents– Dealing with grant and revoke, and delegation
• Distributed access controlDistributed access control– Global consistency– User identification– Role assignments/subject switching
Federation of Trust Domains
• Participants from multiple trust domains• Establish trustworthinessEstablish trustworthiness using other domains• WS-FederationWS-Federation
– Cooperative relationship between trust domains– Simplified protocol for cross domain credentials:
1. P: Participant (P) requests access to domain (R)2. R: locates the participant’s (P) home domain (H)3. H: provides P’s credentials according to sharing policy4. R: accept the identity of P (temporary entry)5. R: transforms P’s credentials from H to its local requirements,
preserves credentials for subsequent requests6. R: responds to P’s initial request
Computer Science and Engineering 51
Perimeter GuardPerimeter Guard
• GoalGoal: protect internal resources from users that remotely access internal computers
• ProblemProblem: – External attacker may gain access to services running
within a private network, and thus to the resources within the private network
• SolutionSolution: establish an intermediate application at the perimeter of the private network as a secure contact point
Demilitarized Zone (DMZ)
• Perimeter Service:– Operates at application layer– Work in conjunction with existing firewall
technologies– Hide internal application details
• External customerExternal customer: corresponds with the perimeter service’s external contracts
• Internal applicationInternal application: response is relayed to the customer by the perimeter service
Impact
• Extra cost ofExtra cost of– Processing overhead– Complexity
• Single point of failureSingle point of failure• Perimeter service represents a point of isolation.
EffectsEffects: direct authentication, brokered authentication, and message screening
Next ClassNext Class
• Web Application Technologies
• Interesting read: Web application development, Wikipedia, http://en.wikipedia.org/wiki/Web_application_development – Notice: No link for security testing
Computer Science and Engineering 54