Computer Science and Engineering 1 Web Application Security

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




http://blip.tv/owasp-appsec-conference-in-europe/day2_track1_1430-1505-3936900

http://blip.tv/owasp-appsec-conference-in-europe/day2_track1_1430-1505-3936900

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


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…


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)



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

http://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)


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


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


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


Key Problem Factors cont.Key Problem Factors cont.

• Resource and time constraints• Overextended technologies• Increased demands on functionality


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


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)


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


Application DevelopmentApplication Development

• Inherent Security of Applications

• Security granularity

Security Software Software Security


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


Software Security Software Security


ApplicationsApplications

• Aggregated services each component is vulnerable

• What is the level of security provided by the aggregate?– Trust management


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



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


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


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


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


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


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


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


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


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)


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


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


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


http://en.wikipedia.org/wiki/Web_application_development

http://en.wikipedia.org/wiki/Web_application_development

Documents

Computer Science and Engineering 1 Web Application Security