Designing Secure Web Applications - PowerPoint PPT Presentation


PPT – Designing Secure Web Applications PowerPoint presentation | free to view - id: a6dbf-MjJlY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Designing Secure Web Applications


Newsgroup or message board postings. Designing Secure Web Applications. 36 ... Feedback, reviews, message boards, etc. Error messages that quote user input ... – PowerPoint PPT presentation

Number of Views:290
Avg rating:3.0/5.0
Slides: 64
Provided by: erinm8


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Designing Secure Web Applications

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

Application Security
  • Applications are part of your
  • security perimeter.

Application Security
  • Applications are soft and chewy.

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

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

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

Information Leaks
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

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

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

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

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

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

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)

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

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

  • 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

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
  • Manage directionality so that information flows
    most securely
  • Consider application-level defenses

Identity Management
  • Still building user management into every single
  • 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!

  • 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

  • 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)

  • 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

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

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

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,
  • Build in logging/auditing in each piece
  • At least 2-3 sets of eyes on everything (design,
    code, logs, etc.)

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

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

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

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

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

  • 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

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

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

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

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

URL Manipulation
  • User gets an email notification with an
    invitation to visit her online profile at
  • http//
  • Cuts and pastes the link into the browser
  • Accidentally leaves off the 9
  • http//
  • Gets a page with somebody elses personal

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
  • Tries a few more IDs to see what happens

URL Manipulation in Action
  • Attacker
  • Looks for other URLs on the site that can be
  • Finds admin functionality that shouldnt be
  • Writes a script to scrape confidential
  • 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

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)

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

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

XSS In Action
  • Knowledgeable user
  • Plays with search terms to see what else can get
  • 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!

XSS In Action
  • Attacker
  • Constructs some JavaScript that reads a cookie
    and resubmits it to a different site (under his
  • Hex encodes it so its not obvious in a URL
  • http//
  • 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
  • Collects cookies as theyre sent to the site
  • Logs in and uses their accounts

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

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

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

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

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

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

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
  • Turn off unused database features
  • Limit database user privileges

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

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
  • Reads his email as it goes by

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

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
  • Cookie Theft (e.g. through XSS)
  • Brute forcing session IDs
  • Trying over and over until a valid session is
  • Computing the next session ID by observing the
    algorithm the server uses to generate them

Session hijacking Fixes
  • Run everything over HTTPS
  • At least, run all confidential information over
  • 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

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

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

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

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

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

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)

Designing Secure Web Applications
  • Discussion

Get the slides online at http//www.chariotsoluti