CNIT 129S: Securing

Web Applications

Ch 1: Web Application (In)security

Updated 1-19-21
 Web Applications

• E-commerce, Social networks, Online

banking, etc
• Fundamental security problem
• Users can supply arbitrary inpu
• Malicious input can compromise the site
.

 Static Website: Web 1.0

• Information ows
one-wa
• Users don't log in,
shop, or submit comment
• An attacker who exploits aws in the Web
server software ca
• Steal data on the Web server (usually
only public data anyway
• Deface the site
y

fl
n

fl
s

 Modern Web App

• Two-way
information o
• Users log in,
submit conten
• Content dynamically generated and tailored for
each use
• Much data is sensitive and private (e.g.
passwords
• Most apps developed in-hous
• Developers often naive about security
r

fl
t

 Common Web App

Functions
• Shopping (Amazon)
• Social networking (Facebook)
• Banking (Citibank)
• Web search (Google)
• Auctions (eBay)
• Gambling (Betfair)
• Web logs (Blogger)
• Web mail (Gmail)
• Interactive information (Wikipedia)

 Internal Web Apps

("Cloud" Services)
• HR -- payroll information, performance review
• Admin interfaces to servers, VMs, workstation
• Collaboration software (SharePoint
• Enterprise Resource Planning (ERP
• Email web interfaces (Outlook Web Access
• Of ce apps (Google Apps, MS Of ce Live)
fi
fi
)

 Bene ts of Web Apps

• HTTP is lightweight and connectionles
• Resilient in event of communications error
• Can be proxied and tunneled over other
protocol
• Web browsers run on many devices, highly
functional, easy to us
• Many platforms and development tools available
s

fi
e

 Web App Security

• Breaches are commo

• Attackers gets sensitive data, possibly
complete control of back-end system
• Denial of Service at Application Level
n

 This Site is Secure

• A frequent claim, very far from the truth

 100%
Secure
Online
Voting

• Link Ch 1b
Study by Text Authors
 SinVR Hack
• Unauthenticated request allows anyone to download
PII from users
• Link Ch 1f
PII
• Link Ch 1c
• Link Ch 1d
The Core Security Problem

• Users can submit arbitrary inpu

• Alter parameters, cookies, HTTP header
• Client-side controls can't be truste
• Developers must assume all input is
maliciou
• Attackers have attack tools like Burp; they are
not restricted to using browsers
s

 Possible Attacks

• Change the price of an ite

• Modify a session token to enter another user's
accoun
• Remove parameters to exploit logic aw
• SQL injectio
• SSL doesn't stop any of these
t

fl
s

 Key Problem Factors

• Underdeveloped security awarenes
• Custom developmen
• Deceptive simplicit
• Easy to make a website, but hard to secure i
• Rapidly evolving threat pro l
• Resource and time constraint
• Overextended technologie
• Increasing demands on functionality
y

fi
e

The New Security Perimeter

• Edge rewalls and "bastion hosts" are no longer
enoug
• Keeping the attacker out of critical system
• Customers can now send transactions to servers
holding private dat
• Via the Web ap
• Web app must act as a security barrie
• Often it includes components from others, like
widget
• Errors by other companies can compromise your
servers
fi
h

The New Security Perimeter

• Attackers can attack users instead of server

• XSS, drive-by downloads, etc
• E-mail used for password recover
• A compromised email account exposes many
other services also
.

 The Future
• Some vulnerabilities
are decreasin
• #1 security
measure:
UPDATE
• Logic aws and
failure to use
controls properly are
not decreasin
• Link Ch 1e
fl
S

Ch 1
 CNIT 129S: Securing
Web Applications

Ch 2: Core Defense Mechanisms

 Core Defense Elements
• Limiting user access to app's data and
functionalit
• Limiting user input to prevent exploits that use
malformed inpu
• Frustrating attackers with appropriate behavior
when targete
• Administrative monitoring and con guring the
application
y

fi
 Handling User Access

• Authenticatio
• Session managemen
• Access Control
n

 Authentication
• Username and password is most common
metho
• Better: additional credentials and multistage
logi
• Best: client certi cates, smart cards, challenge-
response token
• Also: self-registration, account recovery,
password change
n

fi
Common Login Problems

• Predictable username
• Password that can be guesse
• Defects in logic
s

 Session Management
• Session: a set of data structures that track the
state of the use
• A token identi es the session, usually a cooki
• Can also use hidden form elds or the URL
query strin
• Sessions expire
g

fi
r

fi
e

Common Session Problems

• Tokens are predictable (not random

• Tokens poorly handled, so an attacker can
capture another user's token

 Access Control
• Each request must be permitted or denie
• Multiple roles within applicatio
• Frequent logic errors and awed assumptions

fl
n

 Handling User Input

• "Input Validation" is the most common solution
 Types of Input

• Arbitrary text, like blog post

• Cookie
• Hidden form eld
• Parameter
• HTTP header elds, like User-Agent
s

fi
fi
s

 "Reject Known Bad"

• Also called "blacklisting
• Least effective metho
• Dif cult to identify all bad inputs
fi
d

"

 "Accept Known Good"

• Also called "whitelisting

• Most effective technique, where feasibl
• However, sometimes you can't do i
• Human names really contain apostrophes, so
you can't lter them out
fi
"

 Sanitization

• Render dangerous input harmles

• HTML-Encoding: Space becomes %20, etc
• Dif cult if several kinds of data may be present
within an item of inpu
• Boundary validation is better (four slides
ahead)
fi
t

 Safe Data Handling

• Write code that can't be fooled by malicious

dat
• SQL parameterized querie
• Don't pass user input to an OS command lin
• Effective when it can be applied
a

 Semantic Checks

• Some malicious input is identical to valid inpu

• Such as changing an account number to
another customer's number
• Data must be validated in contex
• Does this account number being to the
currently logged-in user?

 Dif culties with Simple Input

Validation

• Data coming from user is "bad" or "untrusted

• The server-side app is "good" and truste
• Many different types of input with different ltering
requirement
• Apps may chain several processing steps togethe
• Data may be harmless at one stage, but be
transformed into harmful data at another stage
fi
s

fi
"

 Boundary Validation

• Trust boundar
• Divides a trusted zone from an untrusted zon
• Clean data that passes a boundar
• Such as from the user into an application
y

 Boundary Validation

• Each component treats its input as potentially

maliciou
• Data validation performed at each trust
boundar
• Not just between client and server
y

Example
Example SOAP Request

• Link Ch 2a
 Boundary Validation Example

• 1. App gets login: username and passwor

• Allows only good characters, limits length,
removes known attack signature
• 2. App performs a SQL query to verify
credential
• Escape dangerous characters
s

 Boundary Validation Example

• 3. Login succeeds; app passes data from user

pro le to a SOAP servic
• XML metacharacters are encoded to block
SOAP injectio
• 4. App displays user's account information back
to the user's browse
• User-supplied data is HTML-encoded to block
XSS
fi
n

 Filtering Problems

• App removes this string

• <script
• So attacker sends thi
• <scr<script>ipt>
>

 Multistep Validation
• App rst removes
../
• Then remove
..\
• Attacker send
....\/
fi
s

 Canonicalization
• App gets URL-encoded data from Web browse
• Apostrophe is %2
• Percent is %2
• To block apostrophes, app lters %2
• But URL is decoded twice by mistak
• %2527 becomes %27 becomes apostrophe
5

fi
e

 Handling Attackers

• Handling error
• Maintaining audit log
• Alerting administrator
• Reacting to attacks
s

 Handling Errors
• Show appropriate error message
• Unhandled errors lead to overly-informative
error messages like this

 Audit Logs
• Authentication events: login success and
failure, change of passwor
• Key transactions, such as credit card payment
• Access attempts that are blocked by access
control mechanism
• Requests containing known attack string
• For high security, log every client request in full
s

 Protecting Logs
• Logs should contain time, IP addresses, and
usernam
• May contain cookies and other sensitive dat
• Attackers will try to erase and/or read log
• Log must be protecte
• Place on an autonomous system that only
accepts update message
• Flush logs to write-once media
e

 Alerting Administrators

• Usage anomalies, like a large number of

requests from the same IP address or use
• Business anomalies, such as a large number of
funds transfers to/from the same accoun
• Requests containing known attack string
• Requests where hidden data has been modi ed

fi
 Firewalls

• Web App Firewalls can detect generic attack

• But not subtle ones that are speci c to your
ap
• Most effective security control is integrated with
app's input validation mechanism
• Check for valid values of your parameters
p

fi
s

 Reacting to Attacks

• Attackers probe for vulnerabilitie

• Sending many similar request
• Automated defense
• Respond increasingly slowly to request
• Terminate the attacker's session
s

Managing the Application

• Management interface allows administrator to
control user accounts, roles, access monitoring,
auditing, etc.
 Attacking the Administration
Panel

• Defeat weak authenticatio

• Some administrative functions might not require
high privilege
• XSS aws can allow cookie theft and session
hijacking
fl
s

Ch 2