Designing Secure Web Applications


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Designing Secure Web Applications

  1. 1. Designing Secure Web Applications Erin Mulder Software Architect Chariot Solutions
  2. 2. About the Speaker <ul><li>Developing dynamic, public-facing web applications since 1995 </li></ul><ul><li>Java, J2EE, Python, Ruby, PHP, Flash, Cold Fusion, ASP, CGI, Perl, etc. </li></ul><ul><li>Author, Speaker, Education Volunteer </li></ul><ul><li>Software Architect with Chariot Solutions </li></ul><ul><ul><li>Focused on Java and related technologies </li></ul></ul><ul><ul><li>Technology Architecture, Strategy & Mentoring </li></ul></ul><ul><ul><li>Application Diagnostics, Rescue Missions </li></ul></ul><ul><ul><li>Full Lifecycle Software Development </li></ul></ul>
  3. 3. Application Security <ul><li>Applications are part of your </li></ul><ul><li>security perimeter. </li></ul>INTERNET FIREWALL BUSINESS Web Application Partner Integration
  4. 4. Application Security <ul><li>Applications are soft and chewy. </li></ul>INTERNET FIREWALL BUSINESS Web Application Partner Integration
  5. 5. Application Security <ul><li>Attackers won’t attack your firewall. </li></ul><ul><li>They’ll attack your applications. </li></ul>INTERNET FIREWALL BUSINESS Web Application Partner Integration
  6. 6. Application Security <ul><li>… or they’ll walk through the door </li></ul><ul><li>(developers, administrators, users) </li></ul>INTERNET FIREWALL BUSINESS Web Application Partner Integration
  7. 7. Application Security <ul><li>… or maybe just listen at the door (wireless, newsgroups, job ads) </li></ul>INTERNET FIREWALL BUSINESS Information Leaks Partner Integration Web Application
  8. 8. Plan of Attack <ul><li>Gather information </li></ul><ul><li>Enlist developers & administrators </li></ul><ul><li>Plug the development process leaks </li></ul><ul><li>Design for security </li></ul><ul><li>Bulletproof the code </li></ul><ul><li>Review, test, measure </li></ul><ul><li>Create a security feedback loop </li></ul>
  9. 9. Agenda <ul><li>Security in 21 Seconds or Less </li></ul><ul><li>Application Architecture </li></ul><ul><li>Development Processes </li></ul><ul><li>Code-Level Exploits </li></ul><ul><li>Discussion </li></ul>
  10. 10. Security Overview <ul><li>Security is about protecting the: </li></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Integrity </li></ul></ul><ul><ul><li>Confidentiality </li></ul></ul><ul><li>of your organization’s assets from </li></ul><ul><ul><li>Users </li></ul></ul><ul><ul><li>Administrators </li></ul></ul><ul><ul><li>Developers </li></ul></ul><ul><ul><li>Regulators </li></ul></ul><ul><ul><li>The rest of the world </li></ul></ul>
  11. 11. Different flavors <ul><li>Physical security </li></ul><ul><li>Operations security </li></ul><ul><li>Access control </li></ul><ul><li>Cryptography </li></ul><ul><li>Legal security </li></ul><ul><li>Business continuity planning </li></ul><ul><li>Network security </li></ul><ul><li>Systems architecture </li></ul><ul><li>Application security </li></ul>
  12. 12. Application Architecture <ul><li>Network security is well-known </li></ul><ul><li>Application security isn’t </li></ul><ul><li>Find (or become) an application security expert </li></ul><ul><li>Develop guidelines for other architects </li></ul><ul><li>Develop checklists for architects and developers </li></ul><ul><li>Don’t just wing it… create a plan for proving an acceptable level of security </li></ul>
  13. 13. Step 1: Know what you have <ul><li>It’s not just about servers and data </li></ul><ul><ul><li>Understand what it would cost to recreate a corrupted sales database </li></ul></ul><ul><ul><li>Calculate how many millions you’d lose if the nightly transaction job didn’t run </li></ul></ul><ul><ul><li>Try to quantify the loss of reputation if credit card numbers were stolen </li></ul></ul><ul><li>You can’t know how much to spend protecting something until you know what it’s worth </li></ul><ul><li>For each asset, prioritize availability, integrity and confidentiality </li></ul>
  14. 14. Step 2: Know the enemy <ul><li>Hackers, Crackers, Social Engineers </li></ul><ul><li>Users, Developers, Administrators, Employees, Interns, Employees’ kids </li></ul><ul><li>Accidents </li></ul><ul><li>Regulations, including: </li></ul><ul><ul><li>Sarbanes-Oxley (SOX) </li></ul></ul><ul><ul><li>HIPAA </li></ul></ul><ul><ul><li>Gramm-Leach-Bliley Act (GLBA) </li></ul></ul>
  15. 15. Step 3: Manage Risk <ul><li>Understand the current situation </li></ul><ul><li>Decide on acceptable levels of risk </li></ul><ul><li>Budget for security to cover the gap </li></ul>WARNING: Intranet apps manipulate the most sensitive data. Most applications are attacked by insiders. Don’t skimp on Intranet security!!
  16. 16. Step 4: Follow through <ul><li>Have a security plan from the beginning </li></ul><ul><li>Understand the principle of the weakest link </li></ul><ul><li>Know how secure the application is right now , not just if the project goes as planned </li></ul><ul><li>Appoint at least one security advocate with the power to delay a release </li></ul>
  17. 17. Architect’s Checklist <ul><li>Modularity </li></ul><ul><li>Systems Integration </li></ul><ul><li>Identity Management </li></ul><ul><li>Performance </li></ul><ul><li>Logging / Auditing </li></ul><ul><li>Privacy </li></ul><ul><li>Frameworks / Code Reuse </li></ul><ul><li>Patch Management </li></ul><ul><li>Separation of Domains </li></ul>
  18. 18. Modularity <ul><li>Don’t try to secure a big ball of mud </li></ul><ul><li>Limit complexity so that everyone can understand what’s going on </li></ul><ul><li>Use well defined interfaces </li></ul><ul><li>Limit resource consumption of each piece </li></ul><ul><li>Minimize privileges of each piece </li></ul><ul><li>Watch out for unintended interactions between otherwise secure components </li></ul>
  19. 19. Systems Integration <ul><li>Only as secure as the weakest link </li></ul><ul><li>Understand the security of each system </li></ul><ul><li>Interfaces should follow least privilege, not just open the floodgates </li></ul><ul><li>Information needs to be classified before it is integrated </li></ul><ul><li>Manage directionality so that information flows most securely </li></ul><ul><li>Consider application-level defenses </li></ul>
  20. 20. Identity Management <ul><li>Still building user management into every single application? </li></ul><ul><li>Yellow, sticky password storage? </li></ul><ul><li>Single sign-on (SSO) makes management easier </li></ul><ul><li>Federated identity management integrates with partners too </li></ul><ul><li>Just be careful who your partners are! </li></ul>
  21. 21. Performance <ul><li>Performance Testing </li></ul><ul><ul><li>Users find slow pages annoying </li></ul></ul><ul><ul><li>Attackers find slow pages inviting </li></ul></ul><ul><li>Graceful Degradation </li></ul><ul><ul><li>Create fast lanes for high priority traffic </li></ul></ul><ul><ul><li>Be careful about chatty error messages </li></ul></ul><ul><li>Fail Secure </li></ul>
  22. 22. Logging/Auditing <ul><li>Until you have a performance or space problem, audit everything! </li></ul><ul><li>Log on all tiers </li></ul><ul><li>Provides accountability </li></ul><ul><li>Easier to support users </li></ul><ul><li>Easier to debug </li></ul><ul><li>Easier to recover from disaster </li></ul><ul><li>Easier to detect attacks </li></ul><ul><li>(But don’t forget about privacy) </li></ul>
  23. 23. Privacy <ul><li>Understand which data is private </li></ul><ul><li>Encrypt private data in storage </li></ul><ul><li>Encrypt private data in transport </li></ul><ul><li>Only process private data in a secure environment </li></ul><ul><li>Wherever possible, store one-way hashes instead </li></ul><ul><ul><li>Passwords </li></ul></ul><ul><ul><li>Log Files </li></ul></ul>
  24. 24. Frameworks / Reuse <ul><li>Security testing is not cheap </li></ul><ul><li>Regulatory validation costs are skyrocketing </li></ul><ul><li>Do not rewrite secure code </li></ul><ul><li>Test once, run over and over again </li></ul><ul><li>Provide a trusted application base and secure services for all applications in development </li></ul><ul><li>Continuously test, validate and improve this single framework </li></ul>
  25. 25. Patch Management <ul><li>Security degrades over time </li></ul><ul><li>A system is not secure unless there’s a plan for handling future vulnerabilities </li></ul><ul><li>Patches are often built under pressure, in response to critical situations </li></ul><ul><li>Plan early for how they will be tested and promoted quickly and securely </li></ul><ul><li>Plan for secure distribution </li></ul><ul><li>Plan to support multiple framework versions </li></ul>
  26. 26. Separation of Domains <ul><li>Most breaches come from inside </li></ul><ul><li>Limit what one person can do </li></ul><ul><li>Design systems to be maintained by at least three distinct roles (e.g. web admin, app server admin, DBA) </li></ul><ul><li>Build in logging/auditing in each piece </li></ul><ul><li>At least 2-3 sets of eyes on everything (design, code, logs, etc.) </li></ul>
  27. 27. Development Processes <ul><li>Okay, our architecture is secure, but now it’s time to get to work! </li></ul><ul><li>Developers need access to real test data </li></ul><ul><li>So they grab some from a live system and change a few characters here and there </li></ul><ul><li>Frequent logins => temporary backdoor </li></ul><ul><li>Frequent data entry => validation bypass </li></ul>
  28. 28. At deploy time… <ul><li>Project is running behind </li></ul><ul><li>Schedules are hectic </li></ul><ul><li>Developers or contractors are given “temporary” privileges </li></ul><ul><li>No record of what they do with them </li></ul><ul><li>Data conversions allow tampering </li></ul><ul><li>Staging rules are bent or broken </li></ul><ul><li>Last minute patches are never reviewed </li></ul>
  29. 29. Developer Education <ul><li>Developers need freedom to be productive </li></ul><ul><li>Don’t cage them, enlist them! </li></ul><ul><ul><li>Security is cool to geeks  </li></ul></ul><ul><ul><li>Start security research groups </li></ul></ul><ul><ul><li>Brown bag lunches </li></ul></ul><ul><li>Certify developers and code </li></ul><ul><li>Classify data and algorithms </li></ul><ul><li>Create guideline & checklists, review code </li></ul><ul><li>Plan for tight schedules & high pressure </li></ul>
  30. 30. Classic Insecurities <ul><li>Applications have historically fallen prey to: </li></ul><ul><ul><li>Buffer Overflows Eavesdropping </li></ul></ul><ul><ul><li>Race Conditions Man in the Middle </li></ul></ul><ul><ul><li>Input Validation Session Hijacking </li></ul></ul><ul><ul><li>Memory Residue Replays </li></ul></ul><ul><ul><li>Path Manipulation Backdoors </li></ul></ul><ul><li>If you’re writing unmanaged code, read: </li></ul><ul><li>Secure Coding Principles & Practices </li></ul><ul><li>by Mark G. Graff & Kenneth R. van Wyk </li></ul><ul><li>O’Reilly 2003 – ISBN: 0-596-00242-4 </li></ul>
  31. 31. Web Application Exploits <ul><li>Footprinting </li></ul><ul><li>URL Manipulation </li></ul><ul><li>Cross-Site Scripting (XSS) </li></ul><ul><li>SQL Injection </li></ul><ul><li>Session Hijacking </li></ul><ul><li>Error Exploitation </li></ul>
  32. 32. Footprinting <ul><li>CNN mentions your website </li></ul><ul><li>Instant traffic jam </li></ul><ul><li>Database gets overloaded and goes down </li></ul><ul><li>Web application can’t get a connection </li></ul><ul><li>(Developer couldn’t do much about it, so the code lets it bubble up to the server) </li></ul><ul><li>The user sees a big, ugly Tomcat error message with all the gory details </li></ul>
  33. 33. Footprinting in Action <ul><li>Pointy-haired boss: </li></ul><ul><ul><li>Finds it annoying and unprofessional </li></ul></ul><ul><ul><li>Calls you in to interpret technical mumbo-jumbo </li></ul></ul><ul><li>Knowledgeable user: </li></ul><ul><ul><li>Learns which server versions are running </li></ul></ul><ul><ul><li>Learns the name of JavaServer Pages (JSPs) and other code components </li></ul></ul><ul><ul><li>Learns details about the database structure and naming </li></ul></ul>
  34. 34. Footprinting in Action <ul><li>Attacker: </li></ul><ul><ul><li>Looks up server vulnerabilities </li></ul></ul><ul><ul><li>Tries accessing default server config pages </li></ul></ul><ul><ul><li>Tries to cause other kinds of errors to collect more information </li></ul></ul><ul><ul><li>Tries accessing JSPs directly without the surrounding business/security logic </li></ul></ul><ul><ul><li>Tries SQL injection attack </li></ul></ul><ul><ul><li>Uses information to appear “in-the-know” during social engineering attack </li></ul></ul>
  35. 35. Footprinting – Flavors <ul><li>Errors (default application server behavior prints out all the ugly details) </li></ul><ul><li>HTTP Response Headers </li></ul><ul><li>“ Powered by” logos </li></ul><ul><li>Distinctive URL patterns </li></ul><ul><li>Default stylesheets/skins </li></ul><ul><li>Press releases </li></ul><ul><li>Job ads </li></ul><ul><li>Newsgroup or message board postings </li></ul>
  36. 36. Footprinting – Fixes <ul><li>Configure default server-level error pages </li></ul><ul><li>Test what happens when: </li></ul><ul><ul><li>Resources are unavailable </li></ul></ul><ul><ul><li>Pages are not found </li></ul></ul><ul><ul><li>Bugs cause unhandled exceptions </li></ul></ul><ul><li>Don’t give details about errors the user can’t fix (where possible, don’t even admit that they’re unexpected) </li></ul><ul><li>Don’t give out specific product/version information, either in error messages or advertisements </li></ul>
  37. 37. URL Manipulation <ul><li>User gets an email notification with an invitation to visit her online profile at: </li></ul><ul><li> </li></ul><ul><li>Cuts and pastes the link into the browser </li></ul><ul><li>Accidentally leaves off the 9 </li></ul><ul><li> </li></ul><ul><li>Gets a page with somebody else’s personal information </li></ul>
  38. 38. URL Manipulation in Action <ul><li>Pointy-Haired Boss: </li></ul><ul><ul><li>Gets confused </li></ul></ul><ul><ul><li>Starts worrying about his own privacy </li></ul></ul><ul><li>Knowledgeable user: </li></ul><ul><ul><li>Removes her own personal info immediately </li></ul></ul><ul><ul><li>Gets curious and looks through the other person’s information </li></ul></ul><ul><ul><li>Tries a few more IDs to see what happens </li></ul></ul>
  39. 39. URL Manipulation in Action <ul><li>Attacker: </li></ul><ul><ul><li>Looks for other URLs on the site that can be manipulated </li></ul></ul><ul><ul><li>Finds admin functionality that shouldn’t be available </li></ul></ul><ul><ul><li>Writes a script to scrape confidential information </li></ul></ul><ul><ul><ul><li>Tries to guess other people’s usernames and passwords based on their personal details (username, birthday, etc.) </li></ul></ul></ul><ul><ul><ul><li>Uses personal info to impersonate others </li></ul></ul></ul><ul><ul><ul><li>Calls users and poses as company representative who is looking at the same profile screen and needs to confirm username and password </li></ul></ul></ul><ul><ul><ul><li>Asks company for ransom </li></ul></ul></ul><ul><ul><ul><li>Uses email addresses to launch cross-site scripting attacks against users </li></ul></ul></ul>
  40. 40. URL Manipulation – Flavors <ul><li>Manipulating cookies </li></ul><ul><li>Manipulating form data </li></ul><ul><ul><li>Both POSTs and GETs </li></ul></ul><ul><ul><li>Hidden form fields </li></ul></ul><ul><ul><li><select> values </li></ul></ul><ul><li>Fishing for errors (footprinting) </li></ul><ul><li>Fishing for directory listings </li></ul><ul><li>Fishing for admin pages </li></ul><ul><li>Fishing for temp files (index.old, index.html~) </li></ul>
  41. 41. URL Manipulation – Fixes <ul><li>Never trust client-side information </li></ul><ul><li>If you must rely on client-side tokens, sign and encrypt them </li></ul><ul><li>Use programmatic security checks to implement row-level security </li></ul><ul><li>Store authentication details in server-side session, or re-check every time </li></ul><ul><li>Watch out for temp files </li></ul>
  42. 42. Cross-Site Scripting (XSS) <ul><li>John visits an online bookstore </li></ul><ul><li>He copies the following book title from an HTML email message: </li></ul><ul><ul><li><b>Architect’s Checklist</b> </li></ul></ul><ul><li>Pastes it into the search box </li></ul><ul><li>Website displays search terms in bold along with results </li></ul>
  43. 43. XSS In Action <ul><li>Knowledgeable user: </li></ul><ul><ul><li>Plays with search terms to see what else can get through </li></ul></ul><ul><li>Attacker: </li></ul><ul><ul><li>Tries entering JavaScript and watches it get executed when the form is submitted </li></ul></ul><ul><ul><li>Looks at the name of the search form field and figures out how to specify it through the URL </li></ul></ul><ul><ul><li>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!” </li></ul></ul>
  44. 44. XSS In Action <ul><li>Attacker: </li></ul><ul><ul><li>Constructs some JavaScript that reads a cookie and resubmits it to a different site (under his control) </li></ul></ul><ul><ul><li>Hex encodes it so it’s not obvious in a URL </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>Emails the link to hundreds of users with a message asking them to participate in a survey </li></ul></ul><ul><ul><li>Expects many of them to click the link </li></ul></ul><ul><ul><li>Expects that many of them are configured to auto-login </li></ul></ul><ul><ul><li>Collects cookies as they’re sent to the site </li></ul></ul><ul><ul><li>Logs in and uses their accounts </li></ul></ul>
  45. 45. XSS – Flavors <ul><li>Code Flaws: </li></ul><ul><ul><li>Feedback, reviews, message boards, etc. </li></ul></ul><ul><ul><li>Error messages that quote user input </li></ul></ul><ul><ul><li>Search results (w/terms) </li></ul></ul><ul><ul><li>Public user profiles </li></ul></ul><ul><ul><li>“ Trusted” partner content </li></ul></ul><ul><li>Exploits: </li></ul><ul><ul><li>Cookie/session theft </li></ul></ul><ul><ul><li>Execution of fraudulent transactions </li></ul></ul><ul><ul><li>Access to confidential information </li></ul></ul>
  46. 46. XSS – Fixes <ul><li>Validate all user input </li></ul><ul><li>Never redisplay user input without cleaning out any HTML and JavaScript </li></ul><ul><li>Filter out whatever you can </li></ul><ul><li>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 </li></ul>
  47. 47. SQL Injection <ul><li>Erin visits a site and searches for: </li></ul><ul><li>Architect’s Checklist </li></ul><ul><li>She gets an error that says: </li></ul><ul><li>Sorry, an unexpected error has occurred: </li></ul><ul><ul><ul><li>Invalid SQL Syntax </li></ul></ul></ul>
  48. 48. SQL Injection in Action <ul><li>Pointy-haired boss: </li></ul><ul><ul><li>Tries the search again </li></ul></ul><ul><ul><li>Assumes site is broken </li></ul></ul><ul><li>Knowledgeable user: </li></ul><ul><ul><li>Realizes that the single quote is often used in SQL statements to surround text </li></ul></ul><ul><ul><li>Tries searching for: architect checklist </li></ul></ul><ul><ul><li>Gets results </li></ul></ul>
  49. 49. SQL Injection in Action <ul><li>Attacker: </li></ul><ul><ul><li>Views the HTML source for the page to look for field names that might match the database columns </li></ul></ul><ul><ul><li>Imagines the SQL to be something like: </li></ul></ul><ul><ul><li>select name, isbn from book where name like ‘%architect’s checklist%’ </li></ul></ul><ul><ul><li>Gets full list by searching for: foo’ or name like ‘ </li></ul></ul><ul><ul><li>Tries logging in as: foo’ and gets the error </li></ul></ul><ul><ul><li>Tries logging in as: </li></ul></ul><ul><ul><li>Username: foo </li></ul></ul><ul><ul><li>Password: bar’ or username=‘admin </li></ul></ul><ul><ul><li>Gets a page that says “Welcome, admin…” </li></ul></ul>
  50. 50. SQL Injection – Flavors <ul><li>Code for advanced searches and other criteria screens constructs query using string concatenation </li></ul><ul><li>Authentication module constructs login query using string concatenation </li></ul><ul><li>Database or driver doesn’t bind parameters </li></ul>
  51. 51. SQL Injection – Fixes <ul><li>Use PreparedStatements </li></ul><ul><li>Validate all user info </li></ul><ul><li>Strip out special characters </li></ul><ul><li>Never display SQL error messages to user </li></ul><ul><li>Use different field names for user interface and database </li></ul><ul><li>Turn off unused database features </li></ul><ul><li>Limit database user privileges </li></ul>
  52. 52. Session hijacking/replay <ul><li>What a boring presentation… </li></ul><ul><li>Brian pops open his laptop and connects to the hotel’s wireless network </li></ul><ul><li>Browses his web mail </li></ul>
  53. 53. Session hijacking in Action <ul><li>Attacker: </li></ul><ul><ul><li>Fires up a wireless cracking program like Kismet </li></ul></ul><ul><ul><li>Watches Brian’s information go by </li></ul></ul><ul><ul><li>Notices him making requests to a web-based mail service </li></ul></ul><ul><ul><li>Reads his email as it goes by… </li></ul></ul>
  54. 54. Session hijacking in Action <ul><li>Attacker (continued): </li></ul><ul><ul><li>Wonders what other mail Brian keeps on the server </li></ul></ul><ul><ul><li>Grabs Brian’s session cookie as it goes by </li></ul></ul><ul><ul><li>Makes her own request to the mail server with that cookie and is automatically logged in </li></ul></ul><ul><ul><li>Reads through Brian’s saved messages to find all sorts of usernames and passwords </li></ul></ul>
  55. 55. Session hijacking – Flavors <ul><li>Network sniffing </li></ul><ul><ul><li>To be fair, a lot of the 802.11 problem is on Brian’s side, since he’s browsing in the clear over airwaves </li></ul></ul><ul><ul><li>LAN/WAN taps are possible too, if a bit more difficult </li></ul></ul><ul><li>Cookie Theft (e.g. through XSS) </li></ul><ul><li>Brute forcing session IDs </li></ul><ul><ul><li>Trying over and over until a valid session is found </li></ul></ul><ul><ul><li>Computing the next session ID by observing the algorithm the server uses to generate them </li></ul></ul>
  56. 56. Session hijacking – Fixes <ul><li>Run everything over HTTPS </li></ul><ul><li>At least, run all confidential information over HTTPS </li></ul><ul><li>Don’t write your own simple session management </li></ul><ul><li>If you do write something: </li></ul><ul><ul><li>match session key to IP address </li></ul></ul><ul><ul><li>alter session on every request so that you can detect duplicates </li></ul></ul>
  57. 57. Error exploitation <ul><li>Erin visits a travel site and starts browsing for 8-day Alaskan cruises </li></ul><ul><li>She finds one she likes and sees that there are 40 cabins left </li></ul><ul><li>She starts to book the only remaining deluxe cabin, but her credit card is declined </li></ul><ul><li>She tries to rebook with a different credit card, but the deluxe cabin is taken </li></ul>
  58. 58. Error exploitation in Action <ul><li>Pointy-haired boss: </li></ul><ul><ul><li>Books an Economy cabin </li></ul></ul><ul><li>Knowledgeable user: </li></ul><ul><ul><li>Calls to verify that it’s not still reserved based on her aborted booking attempt </li></ul></ul><ul><ul><li>Finds out that the cabin was accidentally reserved and is really available </li></ul></ul>
  59. 59. Error exploitation in Action <ul><li>Attacker: </li></ul><ul><ul><li>Books a bunch of cabins </li></ul></ul><ul><ul><ul><li>Using fake credit card numbers </li></ul></ul></ul><ul><ul><ul><li>Through an anonymous web redirector </li></ul></ul></ul><ul><ul><li>Waits to see how long it takes for the company to realize they weren’t really booked </li></ul></ul><ul><ul><li>Calls at the last minute and gets a great deal since they’re so undersold </li></ul></ul>
  60. 60. Error exploitation – Flavors <ul><li>Time-consuming processes </li></ul><ul><li>Reliance on cached values of prices or other data (that may have been manipulated) </li></ul><ul><li>Broken/misconfigured transactions </li></ul><ul><ul><li>Multiple operations may not be correctly grouped into transactions </li></ul></ul><ul><ul><li>Transaction rollback may leave the database consistent, but not revert changes to cached data or other application state </li></ul></ul>
  61. 61. Error exploitation – Fixes <ul><li>Ensure that all modification is transactional </li></ul><ul><li>Be careful that cached values are properly flushed when transactions roll back </li></ul><ul><li>Enforce performance goals </li></ul><ul><li>Watch logs for unusual error patterns (automate this!) </li></ul>
  62. 62. Always remember… <ul><li>Don’t trust or display user input until you’ve cleaned and validated it </li></ul><ul><li>Don’t use HTML comments to describe dynamic code </li></ul><ul><li>Keep control over your error messages </li></ul><ul><li>Don’t advertise details about your network, servers, databases or code </li></ul><ul><li>Implement row-level security </li></ul><ul><li>Log everything (and analyze the logs) </li></ul>
  63. 63. Designing Secure Web Applications Discussion Get the slides online at: