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
t
• Malicious input can compromise the site

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

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

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
s
• Admin interfaces to servers, VMs, workstation
s
• Collaboration software (SharePoint
)
• Enterprise Resource Planning (ERP
)
• Email web interfaces (Outlook Web Access
)
• Of
fi
ce apps (Google Apps, MS Of
fi
ce Live)

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

Web App Security
• Breaches are commo
n
• Attackers gets sensitive data, possibly
complete control of back-end system
s
• Denial of Service at Application Level

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

Possible Attacks
• Change the price of an ite
m
• Modify a session token to enter another user's
accoun
t
• Remove parameters to exploit logic
fl
aw
s
• SQL injectio
n
• SSL doesn't stop any of these

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

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

• Attackers can attack users instead of server
s
• XSS, drive-by downloads, etc
.
• E-mail used for password recover
y
• A compromised email account exposes many
other services also
The New Security Perimeter

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

Ch 1

CNIT 129S: Securing
Web Applications
Ch 2: Core Defense Mechanisms

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

Handling User Access
• Authenticatio
n
• Session managemen
t
• Access Control

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

Common Login Problems
• Predictable username
s
• Password that can be guesse
d
• Defects in logic

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

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
d
• Multiple roles within applicatio
n
• Frequent logic errors and
fl
awed assumptions

Handling User Input
• "Input Validation" is the most common solution

Types of Input
• Arbitrary text, like blog post
s
• Cookie
s
• Hidden form
fi
eld
s
• Parameter
s
• HTTP header
fi
elds, like User-Agent

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

"Accept Known Good"
• Also called "whitelisting
"
• Most effective technique, where feasibl
e
• However, sometimes you can't do i
t
• Human names really contain apostrophes, so
you can't
fi
lter them out

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

Safe Data Handling
• Write code that can't be fooled by malicious
dat
a
• SQL parameterized querie
s
• Don't pass user input to an OS command lin
e
• Effective when it can be applied

Semantic Checks
• Some malicious input is identical to valid inpu
t
• Such as changing an account number to
another customer's number
• Data must be validated in contex
t
• Does this account number being to the
currently logged-in user?

Dif
fi
culties with Simple Input
Validation
• Data coming from user is "bad" or "untrusted
"
• The server-side app is "good" and truste
d
• Many different types of input with different
fi
ltering
requirement
s
• Apps may chain several processing steps togethe
r
• Data may be harmless at one stage, but be
transformed into harmful data at another stage

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

Boundary Validation
• Each component treats its input as potentially
maliciou
s
• Data validation performed at each trust
boundar
y
• Not just between client and server

Example

Example SOAP Request
• Link Ch 2a

• 1. App gets login: username and passwor
d
• Allows only good characters, limits length,
removes known attack signature
s
• 2. App performs a SQL query to verify
credential
s
• Escape dangerous characters
Boundary Validation Example

Boundary Validation Example
• 3. Login succeeds; app passes data from user
pro
fi
le to a SOAP servic
e
• XML metacharacters are encoded to block
SOAP injectio
n
• 4. App displays user's account information back
to the user's browse
r
• User-supplied data is HTML-encoded to block
XSS

Filtering Problems
• App removes this string
:
• <script
>
• So attacker sends thi
s
• <scr<script>ipt>

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

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

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

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

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

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

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

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

Reacting to Attacks
• Attackers probe for vulnerabilitie
s
• Sending many similar request
s
• Automated defense
s
• Respond increasingly slowly to request
s
• Terminate the attacker's session

Managing the Application
• Management interface allows administrator to
control user accounts, roles, access monitoring,
auditing, etc.

Attacking the Administration
Panel
• Defeat weak authenticatio
n
• Some administrative functions might not require
high privilege
s
• XSS
fl
aws can allow cookie theft and session
hijacking

Ch 2