Designing Secure Web Applications

1
Designing Secure Web Applications

• Erin Mulder
• Software Architect
• Chariot Solutions

2
About the Speaker

• Developing dynamic, public-facing web
  applications since 1995
• Java, J2EE, Python, Ruby, PHP, Flash, Cold
  Fusion, ASP, CGI, Perl, etc.
• Author, Speaker, Education Volunteer
• Software Architect with Chariot Solutions
• Focused on Java and related technologies
• Technology Architecture, Strategy Mentoring
• Application Diagnostics, Rescue Missions
• Full Lifecycle Software Development

3
Application Security

• Applications are part of your
• security perimeter.

FIREWALL
BUSINESS
INTERNET
4
Application Security

• Applications are soft and chewy.

FIREWALL
BUSINESS
INTERNET
5
Application Security

• Attackers wont attack your firewall.
• Theyll attack your applications.

FIREWALL
BUSINESS
INTERNET
6
Application Security

• or theyll walk through the door
• (developers, administrators, users)

FIREWALL
BUSINESS
INTERNET
7
Application Security

• or maybe just listen at the door (wireless,
  newsgroups, job ads)

FIREWALL
BUSINESS
INTERNET
Information Leaks
8
Plan of Attack

• Gather information
• Enlist developers administrators
• Plug the development process leaks
• Design for security
• Bulletproof the code
• Review, test, measure
• Create a security feedback loop

9
Agenda

• Security in 21 Seconds or Less
• Application Architecture
• Development Processes
• Code-Level Exploits
• Discussion

10
Security Overview

• Security is about protecting the
• Availability
• Integrity
• Confidentiality
• of your organizations assets from
• Users
• Administrators
• Developers
• Regulators
• The rest of the world

11
Different flavors

• Physical security
• Operations security
• Access control
• Cryptography
• Legal security
• Business continuity planning
• Network security
• Systems architecture
• Application security

12
Application Architecture

• Network security is well-known
• Application security isnt
• Find (or become) an application security expert
• Develop guidelines for other architects
• Develop checklists for architects and developers
• Dont just wing it create a plan for proving an
  acceptable level of security

13
Step 1 Know what you have

• Its not just about servers and data
• Understand what it would cost to recreate a
  corrupted sales database
• Calculate how many millions youd lose if the
  nightly transaction job didnt run
• Try to quantify the loss of reputation if credit
  card numbers were stolen
• You cant know how much to spend protecting
  something until you know what its worth
• For each asset, prioritize availability,
  integrity and confidentiality

14
Step 2 Know the enemy

• Hackers, Crackers, Social Engineers
• Users, Developers, Administrators, Employees,
  Interns, Employees kids
• Accidents
• Regulations, including
• Sarbanes-Oxley (SOX)
• HIPAA
• Gramm-Leach-Bliley Act (GLBA)

15
Step 3 Manage Risk

• Understand the current situation
• Decide on acceptable levels of risk
• Budget for security to cover the gap

WARNING Intranet apps manipulate the most
sensitive data. Most applications are attacked
by insiders. Dont skimp on Intranet security!!
16
Step 4 Follow through

• Have a security plan from the beginning
• Understand the principle of the weakest link
• Know how secure the application is right now, not
  just if the project goes as planned
• Appoint at least one security advocate with the
  power to delay a release

17
Architects Checklist

• Modularity
• Systems Integration
• Identity Management
• Performance
• Logging / Auditing
• Privacy
• Frameworks / Code Reuse
• Patch Management
• Separation of Domains

18
Modularity

• Dont try to secure a big ball of mud
• Limit complexity so that everyone can understand
  whats going on
• Use well defined interfaces
• Limit resource consumption of each piece
• Minimize privileges of each piece
• Watch out for unintended interactions between
  otherwise secure components

19
Systems Integration

• Only as secure as the weakest link
• Understand the security of each system
• Interfaces should follow least privilege, not
  just open the floodgates
• Information needs to be classified before it is
  integrated
• Manage directionality so that information flows
  most securely
• Consider application-level defenses

20
Identity Management

• Still building user management into every single
  application?
• Yellow, sticky password storage?
• Single sign-on (SSO) makes management easier
• Federated identity management integrates with
  partners too
• Just be careful who your partners are!

21
Performance

• Performance Testing
• Users find slow pages annoying
• Attackers find slow pages inviting
• Graceful Degradation
• Create fast lanes for high priority traffic
• Be careful about chatty error messages
• Fail Secure

22
Logging/Auditing

• Until you have a performance or space problem,
  audit everything!
• Log on all tiers
• Provides accountability
• Easier to support users
• Easier to debug
• Easier to recover from disaster
• Easier to detect attacks
• (But dont forget about privacy)

23
Privacy

• Understand which data is private
• Encrypt private data in storage
• Encrypt private data in transport
• Only process private data in a secure environment
• Wherever possible, store one-way hashes instead
• Passwords
• Log Files

24
Frameworks / Reuse

• Security testing is not cheap
• Regulatory validation costs are skyrocketing
• Do not rewrite secure code
• Test once, run over and over again
• Provide a trusted application base and secure
  services for all applications in development
• Continuously test, validate and improve this
  single framework

25
Patch Management

• Security degrades over time
• A system is not secure unless theres a plan for
  handling future vulnerabilities
• Patches are often built under pressure, in
  response to critical situations
• Plan early for how they will be tested and
  promoted quickly and securely
• Plan for secure distribution
• Plan to support multiple framework versions

26
Separation of Domains

• Most breaches come from inside
• Limit what one person can do
• Design systems to be maintained by at least three
  distinct roles (e.g. web admin, app server admin,
  DBA)
• Build in logging/auditing in each piece
• At least 2-3 sets of eyes on everything (design,
  code, logs, etc.)

27
Development Processes

• Okay, our architecture is secure, but now its
  time to get to work!
• Developers need access to real test data
• So they grab some from a live system and change a
  few characters here and there
• Frequent logins gt temporary backdoor
• Frequent data entry gt validation bypass

28
At deploy time

• Project is running behind
• Schedules are hectic
• Developers or contractors are given temporary
  privileges
• No record of what they do with them
• Data conversions allow tampering
• Staging rules are bent or broken
• Last minute patches are never reviewed

29
Developer Education

• Developers need freedom to be productive
• Dont cage them, enlist them!
• Security is cool to geeks ?
• Start security research groups
• Brown bag lunches
• Certify developers and code
• Classify data and algorithms
• Create guideline checklists, review code
• Plan for tight schedules high pressure

30
Classic Insecurities

• Applications have historically fallen prey to
• Buffer Overflows Eavesdropping
• Race Conditions Man in the Middle
• Input Validation Session Hijacking
• Memory Residue Replays
• Path Manipulation Backdoors
• If youre writing unmanaged code, read
• Secure Coding Principles Practices
• by Mark G. Graff Kenneth R. van Wyk
• OReilly 2003 ISBN 0-596-00242-4

31
Web Application Exploits

• Footprinting
• URL Manipulation
• Cross-Site Scripting (XSS)
• SQL Injection
• Session Hijacking
• Error Exploitation

32
Footprinting

• CNN mentions your website
• Instant traffic jam
• Database gets overloaded and goes down
• Web application cant get a connection
• (Developer couldnt do much about it, so the code
  lets it bubble up to the server)
• The user sees a big, ugly Tomcat error message
  with all the gory details

33
Footprinting in Action

• Pointy-haired boss
• Finds it annoying and unprofessional
• Calls you in to interpret technical mumbo-jumbo
• Knowledgeable user
• Learns which server versions are running
• Learns the name of JavaServer Pages (JSPs) and
  other code components
• Learns details about the database structure and
  naming

34
Footprinting in Action

• Attacker
• Looks up server vulnerabilities
• Tries accessing default server config pages
• Tries to cause other kinds of errors to collect
  more information
• Tries accessing JSPs directly without the
  surrounding business/security logic
• Tries SQL injection attack
• Uses information to appear in-the-know during
  social engineering attack

35
Footprinting Flavors

• Errors (default application server behavior
  prints out all the ugly details)
• HTTP Response Headers
• Powered by logos
• Distinctive URL patterns
• Default stylesheets/skins
• Press releases
• Job ads
• Newsgroup or message board postings

36
Footprinting Fixes

• Configure default server-level error pages
• Test what happens when
• Resources are unavailable
• Pages are not found
• Bugs cause unhandled exceptions
• Dont give details about errors the user cant
  fix (where possible, dont even admit that
  theyre unexpected)
• Dont give out specific product/version
  information, either in error messages or
  advertisements

37
URL Manipulation

• User gets an email notification with an
  invitation to visit her online profile at
• http//www.acme.com/profile?userid2249
• Cuts and pastes the link into the browser
• Accidentally leaves off the 9
• http//www.acme.com/profile?userid224
• Gets a page with somebody elses personal
  information

38
URL Manipulation in Action

• Pointy-Haired Boss
• Gets confused
• Starts worrying about his own privacy
• Knowledgeable user
• Removes her own personal info immediately
• Gets curious and looks through the other persons
  information
• Tries a few more IDs to see what happens

39
URL Manipulation in Action

• Attacker
• Looks for other URLs on the site that can be
  manipulated
• Finds admin functionality that shouldnt be
  available
• Writes a script to scrape confidential
  information
• Tries to guess other peoples usernames and
  passwords based on their personal details
  (username, birthday, etc.)
• Uses personal info to impersonate others
• Calls users and poses as company representative
  who is looking at the same profile screen and
  needs to confirm username and password
• Asks company for ransom
• Uses email addresses to launch cross-site
  scripting attacks against users

40
URL Manipulation Flavors

• Manipulating cookies
• Manipulating form data
• Both POSTs and GETs
• Hidden form fields
• ltselectgt values
• Fishing for errors (footprinting)
• Fishing for directory listings
• Fishing for admin pages
• Fishing for temp files (index.old, index.html)

41
URL Manipulation Fixes

• Never trust client-side information
• If you must rely on client-side tokens, sign and
  encrypt them
• Use programmatic security checks to implement
  row-level security
• Store authentication details in server-side
  session, or re-check every time
• Watch out for temp files

42
Cross-Site Scripting (XSS)

• John visits an online bookstore
• He copies the following book title from an HTML
  email message
• ltbgtArchitects Checklistlt/bgt
• Pastes it into the search box
• Website displays search terms in bold along with
  results

43
XSS In Action

• Knowledgeable user
• Plays with search terms to see what else can get
  through
• Attacker
• Tries entering JavaScript and watches it get
  executed when the form is submitted
• Looks at the name of the search form field and
  figures out how to specify it through the URL
• Sends an IM to a friend with a link that goes to
  that site and displays a funny pop-up saying
  Youve been hacked!

44
XSS In Action

• Attacker
• Constructs some JavaScript that reads a cookie
  and resubmits it to a different site (under his
  control)
• Hex encodes it so its not obvious in a URL
• http//ebay.com/SendFeedback?feedback223e3c7
  363726970743e646f63756d656e2e6e
• Emails the link to hundreds of users with a
  message asking them to participate in a survey
• Expects many of them to click the link
• Expects that many of them are configured to
  auto-login
• Collects cookies as theyre sent to the site
• Logs in and uses their accounts

45
XSS Flavors

• Code Flaws
• Feedback, reviews, message boards, etc.
• Error messages that quote user input
• Search results (w/terms)
• Public user profiles
• Trusted partner content
• Exploits
• Cookie/session theft
• Execution of fraudulent transactions
• Access to confidential information

46
XSS Fixes

• Validate all user input
• Never redisplay user input without cleaning out
  any HTML and JavaScript
• Filter out whatever you can
• If you must display it verbatim, escape all of
  the characters or display them within ltpregt tags
  so that the browser wont interpret them

47
SQL Injection

• Erin visits a site and searches for
• Architects Checklist
• She gets an error that says
• Sorry, an unexpected error has occurred
• Invalid SQL Syntax

48
SQL Injection in Action

• Pointy-haired boss
• Tries the search again
• Assumes site is broken
• Knowledgeable user
• Realizes that the single quote is often used in
  SQL statements to surround text
• Tries searching for architect checklist
• Gets results

49
SQL Injection in Action

• Attacker
• Views the HTML source for the page to look for
  field names that might match the database columns
• Imagines the SQL to be something like
• select name, isbn from book where name like
  architects checklist
• Gets full list by searching for foo or name
  like
• Tries logging in as foo and gets the error
• Tries logging in as
• Username foo
• Password bar or usernameadmin
• Gets a page that says Welcome, admin

50
SQL Injection Flavors

• Code for advanced searches and other criteria
  screens constructs query using string
  concatenation
• Authentication module constructs login query
  using string concatenation
• Database or driver doesnt bind parameters

51
SQL Injection Fixes

• Use PreparedStatements
• Validate all user info
• Strip out special characters
• Never display SQL error messages to user
• Use different field names for user interface and
  database
• Turn off unused database features
• Limit database user privileges

52
Session hijacking/replay

• What a boring presentation
• Brian pops open his laptop and connects to the
  hotels wireless network
• Browses his web mail

53
Session hijacking in Action

• Attacker
• Fires up a wireless cracking program like Kismet
• Watches Brians information go by
• Notices him making requests to a web-based mail
  service
• Reads his email as it goes by

54
Session hijacking in Action

• Attacker (continued)
• Wonders what other mail Brian keeps on the server
• Grabs Brians session cookie as it goes by
• Makes her own request to the mail server with
  that cookie and is automatically logged in
• Reads through Brians saved messages to find all
  sorts of usernames and passwords

55
Session hijacking Flavors

• Network sniffing
• To be fair, a lot of the 802.11 problem is on
  Brians side, since hes browsing in the clear
  over airwaves
• LAN/WAN taps are possible too, if a bit more
  difficult
• Cookie Theft (e.g. through XSS)
• Brute forcing session IDs
• Trying over and over until a valid session is
  found
• Computing the next session ID by observing the
  algorithm the server uses to generate them

56
Session hijacking Fixes

• Run everything over HTTPS
• At least, run all confidential information over
  HTTPS
• Dont write your own simple session management
• If you do write something
• match session key to IP address
• alter session on every request so that you can
  detect duplicates

57
Error exploitation

• Erin visits a travel site and starts browsing for
  8-day Alaskan cruises
• She finds one she likes and sees that there are
  40 cabins left
• She starts to book the only remaining deluxe
  cabin, but her credit card is declined
• She tries to rebook with a different credit card,
  but the deluxe cabin is taken

58
Error exploitation in Action

• Pointy-haired boss
• Books an Economy cabin
• Knowledgeable user
• Calls to verify that its not still reserved
  based on her aborted booking attempt
• Finds out that the cabin was accidentally
  reserved and is really available

59
Error exploitation in Action

• Attacker
• Books a bunch of cabins
• Using fake credit card numbers
• Through an anonymous web redirector
• Waits to see how long it takes for the company to
  realize they werent really booked
• Calls at the last minute and gets a great deal
  since theyre so undersold

60
Error exploitation Flavors

• Time-consuming processes
• Reliance on cached values of prices or other data
  (that may have been manipulated)
• Broken/misconfigured transactions
• Multiple operations may not be correctly grouped
  into transactions
• Transaction rollback may leave the database
  consistent, but not revert changes to cached data
  or other application state

61
Error exploitation Fixes

• Ensure that all modification is transactional
• Be careful that cached values are properly
  flushed when transactions roll back
• Enforce performance goals
• Watch logs for unusual error patterns (automate
  this!)

62
Always remember

• Dont trust or display user input until youve
  cleaned and validated it
• Dont use HTML comments to describe dynamic code
• Keep control over your error messages
• Dont advertise details about your network,
  servers, databases or code
• Implement row-level security
• Log everything (and analyze the logs)

63
Designing Secure Web Applications

• Discussion

Get the slides online at http//www.chariotsoluti
ons.com/slides