Delaware Technology Conference 2004 Designing Secure Web Applications

Delaware Technology Conference 2004 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 Designing Secure Web Applications 2

Application Security Applications are part of your security perimeter. FIREWALL Web Application BUSINESS INTERNET Partner Integration Designing Secure Web Applications 3

Application Security Applications are soft and chewy. FIREWALL Web Application BUSINESS INTERNET Partner Integration Designing Secure Web Applications 4

Application Security Attackers won’t attack your firewall. They’ll attack your applications. FIREWALL Web Application BUSINESS INTERNET Partner Integration Designing Secure Web Applications 5

Application Security or they’ll walk through the door (developers, administrators, users) FIREWALL Web Application BUSINESS INTERNET Partner Integration Designing Secure Web Applications 6

Application Security or maybe just listen at the door (wireless, newsgroups, job ads) FIREWALL Web Application INTERNET BUSINESS 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

Agenda 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 expert Develop guidelines for other architects Develop checklists for architects and developers 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) – HIPAA – 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 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 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

Modularity 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 are! Designing Secure Web Applications 20

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

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 don’t forget about privacy) Designing Secure Web Applications 22

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 oneway 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 Path Manipulation Replays 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

Footprinting 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-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 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 unexpected) Don’t give out specific product/version information, either in error messages or advertisements Designing Secure Web Applications 36

URL Manipulation User gets an email notification with an invitation to visit her online profile at: http://www.acme.com/profile?userid 2249 Cuts and pastes the link into the browser Accidentally leaves off the 9 http://www.acme.com/profile?userid 224 Gets a page with somebody else’s personal information 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 information – 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 password Asks company for ransom Uses email addresses to launch cross-site scripting attacks against users 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 serverside 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 hacked!” 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 http://ebay.com/SendFeedback?feedback %22%3e%3c %73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e %2e%6e – 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 them 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 occurred: 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 parameters Designing Secure Web Applications 50

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

Session hijacking/replay What a boring presentation Brian pops open his laptop and connects to the hotel’s wireless network Browses his web mail Designing Secure Web Applications 52

Session hijacking in Action Attacker: – Fires up a wireless cracking program like Kismet – Watches Brian’s information go by – Notices him making requests to a webbased 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 server – 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 HTTPS Don’t 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 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 taken 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 booked – 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 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 Designing Secure Web Applications 60

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!) 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 Designing Secure Web Applications Discussion Get the slides online at: http://www.chariotsolutions.com/slides