CSCE 548 Secure Software Development Web Application Security

CSCE 548 CSCE 548 Secure Software Secure Software

DevelopmentDevelopment

Web Application SecurityWeb Application Security

ReadingReading

19/24 Deadly sins of software security:– Web Server Related Vulnerabilities– Web Client Related Vulnerabilities

Recommended:– R. Rosenbaum, Richard Clarke on Who Was Behind the Stuxnet

Attack, Smithsonian, April 2012, http://www.smithsonianmag.com/history-archaeology/Richard-Clarke-on-Who-Was-Behind-the-Stuxnet-Attack.html

– N. Antunes, M. Vierira, The Devils Behind Web Application Vulnerabilities, IEEE Computer, Febr. 2012, http://www.uc.pt/en/fctuc/dei/ensino/doctoral_program/nunoantunes

CSCE 548 - Farkas 2

Survey RequestSurvey Request

Smart Phone Apps Security project– Conducting a survey to get an understanding of how

most users currently use security software and features with their phone

– Results from the survey will be used to find common usage features and create a best practices guide

link to survey:https://docs.google.com/spreadsheet/viewform?

formkey=dHNiRDlPQ2U2SjlOektubnZVUXYyelE6MQ

CSCE 548 - Farkas 3

4

Web Application Security Web Application Security ConcernsConcerns

What do we want to protect?What do we want to protect?

CSCE 548 - Farkas

5

Security LayersSecurity Layers

1. Data- and metadata-level security

2. Software-level (application) security

3. Business-level security

4. National security

Security Technologies, authentication, secure communication, policies, etc.

CSCE 548 - Farkas

Web Data and Metadata Web Data and Metadata SecuritySecurity

Structured data, XML, …, html, unstructured dataStructured data, XML, …, html, unstructured dataER model,RDF, …, OWLER model,RDF, …, OWL

Workflow, BPEL, WSBPEL, …Workflow, BPEL, WSBPEL, …

6CSCE 548 - Farkas

Secure XML Views - ExampleSecure XML Views - Example

<medicalFiles> UC <countyRec> S <patient> S <name>John Smith </name> UC <phone>111-2222</phone> S </patient> <physician>Jim Dale </physician> UC </countyRec> <milBaseRec> TS <patient> S <name>Harry Green</name> UC <phone>333-4444</phone> S </patient> <physician>Joe White </physician> UC <milTag>MT78</milTag> TS </milBaseRec></medicalFiles>

medicalFiles

countyRec

patient

nameJohn Smith

milBaseRec

physicianJim Dale

physicianJoe White

nameHarry Green

milTagMT78

patient

phone111-2222

phone333-4444

View over UC dataCSCE 548 - Farkas

Transformation - ExampleTransformation - Example

MPG

<medicalFiles>

<milTag>

<phone>

<milBaseRec>

<countyRec><patient>

<physician> <name>

TS

S

UC SP

<emrgRec>

medicalFiles

emergencyRec

namephysician

Data Structure

Delete - ExampleDelete - Example

Report

Title

Data

Date

Temperature

Images

Water Resources

Concrete Location

Civil Area

Defense Sector

P

P

P

P

P

S

S

S

S

TS

?

Report

Title

Data

Date

Temperature

Images

Concrete Location

Defense Sector

(S,{Del})

(S,{Del})

TS

P

P

P

P

P

Example - Top Secret ViewExample - Top Secret View

Subject clearances:

(TS, {}) { (TS, {}) , (S, {Del}), (P, {Del}) }

(S, {}) { (S, {}), (P, {Del}) }

(P, {}) { (P, {}) }

Node Association - ExampleNode Association - Example

DTD of Patient Health Record

MedicalDb

Patient*

Allergies

Allergen*

Phone

Birthdate

Name

SSN

Race

DateDiagnosis

Physician

Prescription

*

Comments

Patient

Phone

Name

Patient

Birthdate

Race

DateDiagnosis

Comments

Simple Security ObjectSimple Security Object

t1

t4t3

t2

o ti : (ti) = (o)

t1

t4t3

t2

o ti : (ti) < (o)

Association Security ObjectAssociation Security Object

The Inference ProblemThe Inference Problem

General Purpose Database:

Non-confidential data + Metadata Undesired Inferences

Semantic Web:

• Non-confidential data + Metadata (data and application semantics) + Computational Power +

Connectivity Undesired Inferences

Correlated Inference Correlated Inference

Object[]. waterSource :: Object basin :: waterSource place :: Object district :: place address :: place base :: Object fort :: base

address fortPublic

Water source base

Confidential

district basinPublic

?

Concept Generalization: weighted concepts, concept abstraction level, range of allowed abstractions

Correlated Inference Correlated Inference (cont.)(cont.)

address fortPublic

district basinPublic

Object[]. waterSource :: Object basin :: waterSource place :: Object district :: place address :: place base :: Object fort :: base

placebase

Water SourceWater source

Base

Place

Water source base

Confidential

17

Software Security Software Security

CSCE 548 - Farkas

18

Web ApplicationsWeb Applications

• Aggregated services each component is vulnerable

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

• Security Patterns– Exception Shielding

– Message Screening

– Trusted subsystem

– Service Perimeter Guard

CSCE 548 - Farkas

19

Exception ShieldingException Shielding

GoalGoal: prevent the disclosure of information about the service’s internal implementation via exception data

ProblemProblem: – Exception data released by a service may contain

internal implementation details – Malicious users may exploit this data to compromise

the service and its environment SolutionSolution: replace unsafe data with data that is safe by

design

CSCE 548 - Farkas

20

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

CSCE 548 - Farkas

21

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

CSCE 548 - Farkas

22

Message ScreeningMessage Screening

GoalGoal: protect a service from malformed or malicious input

ProblemProblem: – Malicious user may violate service security or

take over the control of the service and its environment

SolutionSolution: assume all input data is harmful and screen before using it

CSCE 548 - Farkas

23

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

CSCE 548 - Farkas

24

Trusted SubsystemTrusted Subsystem

GoalGoal: prevent customers from circumventing a service and directly accessing the resources of the service

ProblemProblem: – Customer may perform incorrect modifications– May lead to undesirable forms of implementation

coupling SolutionSolution: service is designed to use own credentials for

authentication with backend resources

CSCE 548 - Farkas

25

ImpactImpact

Compromised serviceCompromised service may allow access to unauthorized users

Protocol for accessing remote resourcesProtocol for accessing remote resources1. Authenticate and authorize the message

2. Send a request to the remote resource, accompanied with the services’ own credentials

3. Issue the appropriate issue to the customer

CSCE 548 - Farkas

26

Implementation VariantsImplementation Variants

Service accounts within the trusted subsystem

Local accounts are used on each hostUse digital certificate (e.g., X509 PKI) for

authentication in the trusted subsystemUse IPSec to provide secure

communications.

CSCE 548 - Farkas

27

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 service at the perimeter of the private network as a secure contact point

CSCE 548 - Farkas

28

Network-Level SecurityNetwork-Level Security

Messaging middleware – Communication security– End point security

Protocol assuranceAuthentication and identificationCross-domain communication security

CSCE 548 - Farkas

29

Service-Level SecurityService-Level Security

Ongoing research:– Business process execution across heterogeneous

domains– Identity management– Trust management

Upcoming research areas:– Web Services Composition– Web Service Transactions– Service-Level Dependencies

CSCE 548 - Farkas

30

Web Services CompositionWeb Services Composition

Create complex applications on the fly from individual services

BPEL4WS, WSBPELHow to express security and reliability

needs?How to verify that these needs are satisfied?How to resolve conflict between business

needs and security requirements?CSCE 548 - Farkas

31

Web Services TransactionsWeb Services TransactionsTraditional database transaction managements vs.

SOA application needsHow can we evaluate correct execution? ACID

properties? Serializability?WS transaction framework:

– Atomic (short-term) transactions– Business activity (long-term) transactions

What are the security implications of WS transactions?

CSCE 548 - Farkas

32

Service-Level DependenciesService-Level Dependencies

Old threats reappearing in new context: deadlocks, denial-of-service, network flooding, etc.

How to detect and prevent the occurrence of these threats? In composition, independently developed services are

dependent on each other No information about internal processing of the workflow

components

CSCE 548 - Farkas

Web Technologies and Web Technologies and SecuritySecurity

CSCE 548 - Farkas 33

Topics and ConceptsTopics and ConceptsThreats unique to web applicationsForgery for web application inputManagement of web-specific languagesCross-site scripting and cross-site forgery

requestRules for web-based system inputManagement of file uploads and system access


@@

Hidden symbol in URL Change IP address (only the info to the

right of @ is used)Browser vulnerability

– “You are about to log in to the site “cse.sc.edu” with the username “farkas”, but the website does not require authentication. This may be an attempt to trick you.”

Twitter – executable JavaScript after @


Who is at risk?Who is at risk?Client: browsers

– Complex systems– Plug-ins, extensions– Server authentication

JavaScript and paid ads ease of propagating malicious code

Never trust a client on the server sideNever trust a browser on the client side


Improve client securityImprove client security

Install patches to the browser Update commonly used plug-ins Eliminate unused plug-ins Heed your browser warnings Make antivirus software watch browser and

downloads Clear history, stored files, and cookies If a file is not signed and trusted, don’t download it


Improve server side securityImprove server side security Never execute client input as code Never allow client input to pass into the system without

validating it internally Scrub client input for any known exploits and suspect

characters Keep a layer of indirection between client input received and

the system Manage sessions from inside the trust boundary and not on the

client side Never encode secrets of functional variables in information

sent to the clies.


Biggest Threats to Web Biggest Threats to Web ApplicationsApplications

Cross-site scripting (XSS)Cross-site request forgeries (CSRF)Remote file uploads, (buffer overflow, SQL

injection, etc.)

Trust between the client’s machine and the web applications.


How to avoid XSS?How to avoid XSS?

Scrub all inputEscape output for displayUse trusted solutions when availableUse separate variables for scrubbed input


Cross-site request forgeryCross-site request forgery

Exploits the trust between server and client machine

Mostly http requests and responsesBased on how web pages are delivered

along with images and other web content


Prevent CSRFPrevent CSRF

Require verification and stages for sensitive applications

Use anti-CSRF tokens in your forms and processing

Use post as the mean of taking form input– Get: encodes the data of the form into the url of

the recipient, appending it to the query string of the request

– Post: encodes it as a messageCSCE 548 - Farkas 42

Unrestricted file uploadUnrestricted file upload

Users may upload malicious filesUploaded files can be called by a url (if

stored on the web server)Example: php

– Embedded in image files– Compile php code


Avoid file upload problemsAvoid file upload problems

System should determine file name Do not allow users to access the folders where

content is uploaded Parse file extensions carefully or set your own file

parser White list extensions Be secure with the .htaccess file (controls accesses

to the files on the server


Adobe FlashAdobe Flash

99% of all internet connected machines use AdobeFlesh

No internal automated update capabilityFlash security policy: Same Origin

– Can be modified by XML cross-domain policy declaration

Can facilitate XSS, CSRF, DNS rebiding



Next ClassNext Class

Student Presentations

Documents

CSCE 548 Secure Software Development Web Application Security