CNIT 129S: Securing Web Applications Ch 1-2
4 likes2,146 views
This document discusses securing web applications. It describes how modern web apps allow two-way information flow and user login/content submission, which introduces security risks if user input is not properly validated. It emphasizes that the core security problem is that users can submit arbitrary input, and outlines common attacks like modifying prices or session tokens. The document then covers core defense mechanisms like authentication, session management, access control, input validation at boundaries, and handling errors and attacks through logging, alerts and responses.
CNIT 129S: Securing Web Applications Ch 1-2
- 1. CNIT 129S: Securing Web Applications Ch 1: Web Application (In)security
- 2. Web Applications • E-commerce, Social networks, Online banking, etc. • Fundamental security problem: • Users can supply arbitrary input • Malicious input can compromise the site
- 3. Static Website: Web 1.0 • Information flows one-way • Users don't log in, shop, or submit comments • An attacker who exploits flaws in the Web server software can • Steal data on the Web server (usually only public data anyway) • Deface the site
- 4. Modern Web App • Two-way information flow • Users log in, submit content • Content dynamically generated and tailored for each user • Much data is sensitive and private (e.g. passwords) • Most apps developed in-house • Developers often naive about security
- 5. Common Web App Functions • Shopping (Amazon) • Social networking (Facebook) • Banking (Citibank) • Web search (Google) • Auctions (eBay) • Gambling (Betfair) • Web logs (Blogger) • Web mail (Gmail) • Interactive information (Wikipedia)
- 6. Internal Web Apps ("Cloud" Services) • HR -- payroll information, performance reviews • Admin interfaces to servers, VMs, workstations • Collaboration software (SharePoint) • Enterprise Resource Planning (ERP) • Email web interfaces (Outlook Web Access) • Office apps (Google Apps, MS Office Live)
- 7. Benefits of Web Apps • HTTP is lightweight and connectionless • Resilient in event of communications errors • Can be proxied and tunneled over other protocols • Web browsers run on many devices, highly functional, easy to use • Many platforms and development tools available
- 8. Web App Security • Breaches are common • Attackers gets sensitive data, possibly complete control of back-end systems • Denial of Service at Application Level
- 9. This Site is Secure
- 11. Study by Text Authors
- 13. • Link Ch 1c
- 14. • Link Ch 1d
- 15. The Core Security Problem • Users Can Submit Arbitrary Input • Alter parameters, cookies, HTTP headers • Client-side controls can't be trusted • Developers must assume all input is malicious • Attackers have attack tools like Burp; they are not restricted to using browsers
- 16. Possible Attacks • Change the price of an item • Modify a session token to enter another user's account • Remove parameters to exploit logic flaws • SQL injection • SSL doesn't stop any of these
- 17. Key Problem Factors • Underdeveloped Security Awareness • Custom Development • Deceptive Simplicity • Easy to make a website, but hard to secure it • Rapidly Evolving Threat Profile • Resource and Time Constraints • Overextended Technologies • Increasing Demands on Functionality
- 18. The New Security Perimeter • Edge firewalls and "bastion hosts" are no longer enough • Keeping the attacker out of critical systems • Customers can now send transactions to servers holding private data • Via the Web app • Web app must act as a security barrier • Often it includes components from others, like widgets • Errors by other companies can compromise your servers
- 19. • Attackers can attack users instead of servers • XSS, drive-by downloads, etc. • E-mail used for password recovery • A compromised email account exposes many other services also The New Security Perimeter
- 20. The Future • Some vulnerabilities are decreasing • #1 security measure: UPDATES • Logic flaws and failure to use controls properly are not decreasing • Link Ch 1e
- 21. CNIT 129S: Securing Web Applications Ch 2: Core Defense Mechanisms
- 22. Core Defense Elements • Limiting user access to app's data and functionality • Limiting user input to prevent exploits that use malformed input • Frustrating attackers with appropriate behavior when targeted • Administrative monitoring and configuring the application
- 23. Handling User Access • Authentication • Session management • Access Control
- 24. Authentication • Username and password is most common method • Better: additional credentials and multistage login • Best: client certificates, smartcards, challenge- response tokens • Also: self-registration, account recovery, password change
- 26. Common Login Problems • Predictable usernames • Password that can be guessed • Defects in logic
- 27. Session Management • Session: a set of data structures that track the state of the user • A token identifies the session, usually a cookie • Can also use hidden form fields or the URL query string • Sessions expire
- 28. Common Session Problems • Tokens are predictable (not random) • Tokens poorly handled, so an attacker can capture another user's token
- 29. Access Control • Each request must be permitted or denied • Multiple roles within application • Frequent logic errors and flawed assumptions
- 30. Handling User Input • "Input Validation" is the most common solution
- 31. Types of Input • Arbitrary text, like blog posts • Cookies • Hidden form fields • Parameters • HTTP header fields, like User-Agent
- 32. "Reject Known Bad" • Also called "blacklisting" • Least effective method • Difficult to identify all bad inputs
- 33. "Accept Known Good" • Also called "whitelisting" • Most effective technique, where feasible • However, sometimes you can't do it • Human names really contain apostrophes, so you can't filter them out
- 34. Sanitization • Render dangerous input harmless • HTML-Encoding: Space becomes %20, etc. • Difficult if several kinds of data may be present within an item of input • Boundary validation is better (four slides ahead)
- 35. Safe Data Handling • Write code that can't be fooled by malicious data • SQL parameterized queries • Don't pass user input to an OS command line • Effective when it can be applied
- 36. Semantic Checks • Some malicious input is identical to valid input • Such as changing an account number to another customer's number • Data must be validated in context • Does this account number being to the currently logged-in user?
- 37. Difficulties with Simple Input Validation • Data coming from user is "bad" or "untrusted" • The server-side app is "good" and trusted • Many different types of input with different filtering requirements • Apps may chain several processing steps together • Data may be harmless at one stage, but be transformed into harmful data at another stage
- 38. Boundary Validation • Trust boundary • Divides a trusted zone from an untrusted zone • Clean data that passes a boundary • Such as from the user into an application
- 39. Boundary Validation • Each component treats its input as potentially malicious • Data validation performed at each trust boundary • Not just between client and server
- 40. Example
- 41. Example SOAP Request • Link Ch 2a
- 42. Boundary Validation Example • 1. App gets login: username and password • Allows only good characters, limits length, removes known attack signatures • 2. App performs a SQL query to verify credentials • Escape dangerous characters
- 43. Boundary Validation Example • 3. Login succeeds; app passes data from user profile to a SOAP service • XML metacharacters are encoded to block SOAP injection • 4. App displays user's account information back to the user's browser • User-supplied data is HTML-encoded to block XSS
- 44. Filtering Problems • App removes this string: • <script> • So attacker sends this • <scr<script>ipt>
- 45. Multistep Validation • App first removes ../ • Then removes .. • Attacker sends ..../
- 46. Canonicalization • App gets URL-encoded data from Web browser • Apostrophe is %27 • Percent is %25 • To block apostrophes, app filters %27 • But URL is decoded twice by mistake • %2527 becomes %27 becomes apostrophe
- 47. Handling Attackers • Handling errors • Maintaining audit logs • Alerting administrators • Reacting to attacks
- 48. Handling Errors • Show appropriate error messages • Unhanded errors lead to overly-informative error messages like this
- 49. Audit Logs • Authentication events: login success and failure, change of password • Key transactions, such as credit card payments • Access attempts that are blocked by access control mechanisms • Requests containing known attack strings • For high security, log every client request in full
- 50. Protecting Logs • Logs should contain time, IP addresses, and username • May contain cookies and other sensitive data • Attackers will try to erase and/or read logs • Log must be protected • Place on an autonomous system that only accepts update messages • Flush logs to write-once media
- 51. Alerting Administrators • Usage anomalies, like a large number of requests from the same IP address or user • Business anomalies, such as a large number of funds transfers to/from the same account • Requests containing known attack strings • Requests where hidden data has been modified
- 52. Firewalls • Web App Firewalls can detect generic attacks • But not subtle ones that are specific to your app • Most effective security control is integrated with app's input validation mechanisms • Check for valid values of your parameters
- 53. Reacting to Attacks • Attackers probe for vulnerabilities • Sending many similar requests • Automated defenses • Respond increasingly slowly to requests • Terminate the attacker's session
- 54. Managing the Application • Management interface allows administrator to control user accounts, roles, access monitoring, auditing, etc.
- 55. Attacking the Administration Panel • Defeat weak authentication • Some administrative functions might not require high privileges • XSS flaws can allow cookie theft and session hijacking