Designing Secure Web Applications

Document Sample
Designing Secure Web Applications Powered By Docstoc
					Delaware Technology
 Conference 2004

Secure Web

    Erin Mulder
   Software Architect
   Chariot Solutions
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

             Designing Secure Web Applications       2
Application Security
     Applications are part of your
         security perimeter.


            Web Application                 BUSINESS

           Partner Integration

            Designing Secure Web Applications          3
Application Security

   Applications are soft and chewy.


            Web Application                 BUSINESS

           Partner Integration

            Designing Secure Web Applications          4
Application Security

 Attackers won‟t attack your firewall.
   They‟ll attack your applications.


            Web Application                 BUSINESS

           Partner Integration

            Designing Secure Web Applications          5
Application Security

   …or they‟ll walk through the door
  (developers, administrators, users)

            Web Application                 BUSINESS

           Partner Integration

            Designing Secure Web Applications          6
Application Security

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

            Web Application                 BUSINESS
INTERNET        Information Leaks

           Partner Integration

            Designing Secure Web Applications          7
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

          Designing Secure Web Applications   8
• Security in 21 Seconds or Less

• Application Architecture

• Development Processes

• Code-Level Exploits

• Discussion

         Designing Secure Web Applications   9
Security Overview
Security is about protecting the:
  – Availability
  – Integrity
  – Confidentiality

of your organization‟s assets from
  – Users
  – Administrators
  – Developers
  – Regulators
  – The rest of the world

            Designing Secure Web Applications   10
Different flavors
• Physical security
• Operations security
• Access control
• Cryptography
• Legal security
• Business continuity planning
• Network security
• Systems architecture
• Application security

            Designing Secure Web Applications   11
Application Architecture
• Network security is well-known
• Application security isn‟t
• Find (or become) an application security
• Develop guidelines for other architects
• Develop checklists for architects and
• Don‟t just wing it… create a plan for proving
  an acceptable level of security

          Designing Secure Web Applications   12
Step 1: Know what you have

• It‟s not just about servers and data
   – Understand what it would cost to recreate a corrupted
     sales database
   – Calculate how many millions you‟d lose if the nightly
     transaction job didn‟t run
   – Try to quantify the loss of reputation if credit card numbers
     were stolen

• You can‟t know how much to spend
  protecting something until you know what
  it‟s worth
• For each asset, prioritize availability,
  integrity and confidentiality
             Designing Secure Web Applications                  13
Step 2: Know the enemy
• Hackers, Crackers, Social Engineers

• Users, Developers, Administrators,
  Employees, Interns, Employees‟ kids

• Accidents

• Regulations, including:
  – Sarbanes-Oxley (SOX)
  – Gramm-Leach-Bliley Act (GLBA)

            Designing Secure Web Applications   14
 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. Don’t skimp on Intranet security!!

             Designing Secure Web Applications      15
Step 4: Follow through
• Have a security plan from the beginning
• Understand the principle of the weakest
• 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

          Designing Secure Web Applications      16
Architect’s Checklist
• Modularity
• Systems Integration
• Identity Management
• Performance
• Logging / Auditing
• Privacy
• Frameworks / Code Reuse
• Patch Management
• Separation of Domains

            Designing Secure Web Applications   17
• Don‟t try to secure a big ball of mud
• Limit complexity so that everyone can
  understand what‟s 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

            Designing Secure Web Applications   18
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

            Designing Secure Web Applications   19
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

          Designing Secure Web Applications   20
• 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

             Designing Secure Web Applications    21
• 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 don‟t forget about privacy)
          Designing Secure Web Applications   22
• Understand which data is private
• Encrypt private data in storage
• Encrypt private data in transport
• Only process private data in a secure
• Wherever possible, store one-way
  hashes instead
   – Passwords
   – Log Files

            Designing Secure Web Applications   23
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

            Designing Secure Web Applications     24
Patch Management
• Security degrades over time
• A system is not secure unless there‟s 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

            Designing Secure Web Applications        25
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.)

            Designing Secure Web Applications   26
Development Processes
• Okay, our architecture is secure, but now it‟s
  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 => temporary backdoor
• Frequent data entry => validation bypass

            Designing Secure Web Applications      27
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

           Designing Secure Web Applications   28
Developer Education
• Developers need freedom to be productive
• Don‟t 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

              Designing Secure Web Applications   29
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 you‟re writing unmanaged code, read:
  Secure Coding Principles & Practices
  by Mark G. Graff & Kenneth R. van Wyk
  O‟Reilly 2003 – ISBN: 0-596-00242-4

               Designing Secure Web Applications          30
Web Application Exploits
• Footprinting
• URL Manipulation
• Cross-Site Scripting (XSS)
• SQL Injection
• Session Hijacking
• Error Exploitation

         Designing Secure Web Applications   31
• CNN mentions your website

• Instant traffic jam

• Database gets overloaded and goes down

• Web application can‟t get a connection

• (Developer couldn‟t 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

            Designing Secure Web Applications         32
Footprinting in Action
• Pointy-haired boss:
  – Finds it annoying and unprofessional
  – Calls you in to interpret technical mumbo-

• 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

            Designing Secure Web Applications     33
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

            Designing Secure Web Applications         34
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
            Designing Secure Web Applications          35
Footprinting – Fixes
• Configure default server-level error pages
• Test what happens when:
   – Resources are unavailable
   – Pages are not found
   – Bugs cause unhandled exceptions

• Don‟t give details about errors the user can‟t fix
  (where possible, don‟t even admit that they‟re
• Don‟t give out specific product/version
  information, either in error messages or

             Designing Secure Web Applications         36
URL Manipulation
• User gets an email notification with an invitation to
  visit her online profile at:

• Cuts and pastes the link into the browser

• Accidentally leaves off the 9

• Gets a page with somebody else‟s personal

            Designing Secure Web Applications             37
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 person‟s
  – Tries a few more IDs to see what happens

            Designing Secure Web Applications           38
URL Manipulation in Action

• Attacker:
  – Looks for other URLs on the site that can be manipulated
  – Finds admin functionality that shouldn‟t be available
  – Writes a script to scrape confidential information
      • Tries to guess other people‟s 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
      • Asks company for ransom
      • Uses email addresses to launch cross-site scripting attacks against

             Designing Secure Web Applications                                39
URL Manipulation – Flavors

• Manipulating cookies
• Manipulating form data
   – Both POSTs and GETs
   – Hidden form fields
   – <select> values

• Fishing for errors (footprinting)
• Fishing for directory listings
• Fishing for admin pages
• Fishing for temp files (index.old, index.html~)

             Designing Secure Web Applications      40
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

          Designing Secure Web Applications      41
Cross-Site Scripting (XSS)
• John visits an online bookstore
• He copies the following book title from
  an HTML email message:
  <b>Architect‟s Checklist</b>

• Pastes it into the search box
• Website displays search terms in bold
  along with results

            Designing Secure Web Applications   42
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 “You‟ve been

            Designing Secure Web Applications                    43
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 it‟s not obvious in a URL

   – 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 they‟re sent to the site
   – Logs in and uses their accounts

              Designing Secure Web Applications                   44
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

            Designing Secure Web Applications   45
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 <pre>
  tags so that the browser won‟t interpret

          Designing Secure Web Applications     46
SQL Injection
• Erin visits a site and searches for:

  Architect‟s Checklist

• She gets an error that says:

  Sorry, an unexpected error has
      • Invalid SQL Syntax

            Designing Secure Web Applications   47
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

           Designing Secure Web Applications       48
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
     ‘%architect’s 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 username=„admin

  – Gets a page that says “Welcome, admin…”

             Designing Secure Web Applications             49
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 doesn‟t bind

          Designing Secure Web Applications   50
SQL Injection – Fixes
• Use PreparedStatements
• Validate all user info
• Strip out special characters
• Never display SQL error messages to
• Use different field names for user
  interface and database
• Turn off unused database features
• Limit database user privileges
          Designing Secure Web Applications   51
Session hijacking/replay
• What a boring

• Brian pops open his
  laptop and connects to
  the hotel‟s wireless

• Browses his web mail

         Designing Secure Web Applications   52
Session hijacking in Action

• Attacker:
  – Fires up a wireless cracking program like
  – Watches Brian‟s information go by
  – Notices him making requests to a web-
    based mail service
  – Reads his email as it goes by…

          Designing Secure Web Applications     53
Session hijacking in Action

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

          Designing Secure Web Applications         54
Session hijacking – Flavors

• Network sniffing
  – To be fair, a lot of the 802.11 problem is on Brian‟s
    side, since he‟s 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

            Designing Secure Web Applications                55
Session hijacking – Fixes
• Run everything over HTTPS
• At least, run all confidential information over
• Don‟t write your own simple session
• If you do write something:
   – match session key to IP address
   – alter session on every request so that you can detect

             Designing Secure Web Applications               56
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

            Designing Secure Web Applications   57
Error exploitation in Action

• Pointy-haired boss:
  – Books an Economy cabin

• Knowledgeable user:
  – Calls to verify that it‟s not still reserved
    based on her aborted booking attempt
  – Finds out that the cabin was accidentally
    reserved and is really available

           Designing Secure Web Applications       58
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 weren‟t really
  – Calls at the last minute and gets a great deal
    since they‟re so undersold

           Designing Secure Web Applications         59
Error exploitation – Flavors

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

            Designing Secure Web Applications               60
Error exploitation – Fixes
• Ensure that all modification is
• Be careful that cached values are
  properly flushed when transactions
  roll back
• Enforce performance goals
• Watch logs for unusual error
  patterns (automate this!)

         Designing Secure Web Applications   61
Always remember…
• Don‟t trust or display user input until you‟ve
  cleaned and validated it
• Don‟t use HTML comments to describe
  dynamic code
• Keep control over your error messages
• Don‟t advertise details about your network,
  servers, databases or code
• Implement row-level security
• Log everything (and analyze the logs)

            Designing Secure Web Applications      62
                                         Delaware Technology
                                          Conference 2004

                                         Secure Web


Get the slides online at: