This document discusses core defense mechanisms for securing web applications, including limiting user access and input, and administrative monitoring. It covers authentication, session management, access control, input validation techniques like whitelisting and sanitization, boundary validation to divide trusted and untrusted zones, handling errors, maintaining audit logs, alerting administrators, and reacting to attacks. It also notes security risks of management interfaces and importance of securing the entire application, not just the user-facing parts.

1. CNIT 129S: Securing
Web Applications
Ch 1: Web Application (In)security
Updated 1-19-21

2. Web Applications
• E-commerce, Social networks, Online
banking, etc
.
• Fundamental security problem
:
• Users can supply arbitrary inpu
t
• Malicious input can compromise the site

3. 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

4. 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

5. 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)

6. 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)

7. 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

8. 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

9. This Site is Secure
• A frequent claim, very far from the truth

10. 100%
Secure
Online
Voting
• Link Ch 1b

11. Study by Text Authors

12. SinVR Hack
• Unauthenticated request allows anyone to download
PII from users
• Link Ch 1f

13. PII

15. • Link Ch 1c

16. • Link Ch 1d

17. 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

18. 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

19. 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

20. 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

21. • 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

22. 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

23. Ch 1

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

25. 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

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

27. 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

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

30. 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

31. Common Session Problems
• Tokens are predictable (not random
)
• Tokens poorly handled, so an attacker can
capture another user's token

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

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

34. 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

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

36. "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

37. 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)

38. 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

39. 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?

40. 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

41. 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

42. 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

43. Example

44. Example SOAP Request
• Link Ch 2a

45. • 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

46. 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

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

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

49. 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

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

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

52. 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

53. 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

54. 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

55. 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

56. 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

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

58. 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

59. Ch 2