Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web Application Security: Introduction to common classes of security flaws and testing methodologies

Web Application Security
Introduction to common classes of security flaws and testing methodologies
Cade Cairns
Feb 2014

  • Login to see the comments

Web Application Security: Introduction to common classes of security flaws and testing methodologies

  1. 1. Feb 2014 Web Application Security Presented to: Introduction to common classes of security faws and testing methodologies ThoughtWorks Quito Noche Geek Cade Cairns <>
  2. 2. Outline Intent: • • • • Discuss common classes of web security faws Demonstrate tools that developers and testers can use to harden web applications Describe other ways to mitigate risks Show what a professional tester (or attacker) might do 2
  3. 3. About me ThoughtWorks Canada Software Developer REcon Security Conference ( Conference Organizer Past: SecurityFocus – threat analyst, software developer IGSN – security analyst for gaming companies Subgraph – software developer for Vega (and various others) 3
  4. 4. Threat evolution As the web continues to evolve, so do the threats Attack surface keeps increasing Developers want features to enhance their web application functionality, but that comes at a cost Many more massive online services Exploit markets now exist; value of vulnerabilities increasing Result: much higher motivation to break security 4
  5. 5. Agenda Testing methodology with overviews of common security faws Attacks against servers Attacks against clients 5
  6. 6. Testing plan Information gathering ● Map application content ● Identify hidden content ● Identify hints for attack vectors ● Look for accidental leakage ● Enumerate other resources Analysis ● Target analysis ● Research Automated scanning Test authentication mechanisms Verify access controls Test input validation Look for XSS, CSRF 6
  7. 7. Toolkit Types of tools: ● ● ● ● ● ● ● ● ● Intercepting proxy (supporting SSL MITM) Web application spider (passive, active) Content discovery Data analysis Fuzzing Automated vulnerability scanning (passive, active) Automated attacks Network scanners Resource scanner Tools lists: More reading: 7
  8. 8. Burp Suite Popular choice for use by security testers Integrates a lot of tools: ● Intercepting proxy ● Spider (active and passive) ● Scanner (active and passive) ● Fuzzer ● Discovery and test attack automation ● HTTP request tester (repeater) ● Data analysis and comparison ● Content encoders/decoders Supports third-party plug-ins Multi-platform: written in Java Free version with crippled features; $299 USD/year 8
  9. 9. OWASP Zed Attack Proxy (ZAP) Highly-rated security tool [1] Provides many useful functions: ● Intercepting proxy ● Spider (active and passive; supports Ajax) ● Scanner (active and passive) ● Fuzzer ● File/directory brute forcer Supports third-party add-ons; online marketplace Multi-platform: Swing Java Open source; Apache License 2.0 [1] 9
  10. 10. Subgraph Vega Software attempting to integrate more features than Burp, for free Has several useful features: ● Intercepting proxy ● Spider (active and passive) ● Scanner (active and passive) ● Well-designed probes for security faws ● Scanner modules are written in Javascript; easily extensible Multi-platform: Eclipse RCP Open source; Eclipse Public License 1.0 10
  11. 11. skipfsh Web application security reconnaissance tool Features: ● Scanner (active) ● Well-designed probes for security faws ● Attempts to do non-disruptive checks ● Brute force resource identifcation using a dictionary: combinations of ${keyword}.$ {extension} Multi-platform: Linux, FreeBSD, Mac OS X, Windows Open source; Apache License 2.0 11
  12. 12. sqlmap Simplifes detecting and exploiting SQL injection faws Features: ● Detecting, exploiting SQL injection faws ● Full support for many DBMSs ● Supports multiple SQL injection techniques ● Database fngerprinting ● Fetching data from database ● Executing arbitrary OS commands Multi-platform: Python 2.6.x and 2.7.x Open source; GPLv2 12
  13. 13. Nikto Tool to identify dangerous applications, fles, and confgurations Features: ● Large database of dangerous fles/web apps ● Common web server misconfgurations ● Fingerprinting web servers Multi-platform: Perl Open source; GPL 13
  14. 14. Kali Linux Linux penetration testing distribution Formerly known as BackTrack Linux Contains most of the tools used in this presentation and many more Open source; various licenses 14
  15. 15. More tools Some more helpful tools: ● ● ● ● nmap DNSenum netcat stunnel 15
  16. 16. Test target: OWASP BWA OWASP BWA (Broken Web Applications) Linux virtual machine running applications with known vulnerabilities Useful for learning about web application security testing and testing tools For this presentation, focus on testing WackoPicko, which was used for the paper “Why Johnny Can't Pentest: An Analysis of Black-box Web Vulnerability Scanners” 16
  17. 17. Information gathering Step 1: mapping the application Purpose: ● Get a thorough view of the target ● Identify common misconfgurations ● Can reuse information later as you discover problems Methodology: ● Passive spidering: explore visible content using a security proxy tool ● Map the application using multiple users (privileged, non-privileged) if applicable ● Check against public resources e.g. Google ● Active spidering (if desired) Tools: ● Burp Proxy or ZAP Proxy 17
  18. 18. Demo Mapping the application 18
  19. 19. Information gathering Step 2: identify hidden content Purpose: ● Find content that wasn't linked to publicly ● Find default content Methodology: ● Scan the web site using tools Tools: ● Nikto 19
  20. 20. Demo Identifying hidden content 20
  21. 21. Analysis Step 3: target analysis Purpose: ● Figure out what you're up against ● Gain insight to better tune later attacks Methodology: ● Identify the technologies used ● Identify functionality ● Determine how core functionality works, URL style, etc. ● Enumerate inputs ● Identify redirects ● Understand security model ● Review use of cookies OWASP A10-Unvalidated redirects and fowards 21
  22. 22. Analysis Step 4: identify hints for attack vectors Purpose: ● Look for anything the that unintentionally identifes weak functionality Methodology: ● Review robots.txt ● Look for commented out code, links ● Review cross-domain fles: Flash, Silverlight 22
  23. 23. Example robots.txt User-agent: * Disallow: /admin/ Disallow: /site-old/ Disallow: /api/ # new API Disallow: /partner/ # partner API 23
  24. 24. Analysis Step 5: look for accidental leakage Purpose: ● Look for content that should not be accessible Methodology: ● Identify error handling with information leakage ● Search for copies of edited script fles, i.e. where extension was changed (fle.php~, .fle.php.swp) ● Look for the .DS_Store fle or other fles that index a directory ● Guess flenames: AnnualReport2014.pdf when AnnualReport2013.pdf exists 24
  25. 25. Avoiding leakage How much does your site need to reveal? Do any components actually need to know your web server version or version of Rails? Principle of least privilege: every module must be able to access only the information and resources that are necessary for its legitimate purpose Protect sensitive information; use access controls where it must be disclosed Use generic error messages 25
  26. 26. Information gathering Step 6: enumerate other resources Purpose: ● Look for other network resources – web sites, etc. Methodology: ● Enumerate DNS hostnames, network blocks of other systems ● Identify other systems related to the target Tools: ● nmap ● DNSenum 26
  27. 27. Automated scanning Step 7: scan the target for security faws Warning: do not run an automated scanner in a production environment! Purpose: ● Identify possible security faws in the target web application Caveats: ● Scanners lack intuition and understanding of requirements ● Scanners cannot improvise ● False positives and false negatives are common Tools: ● Vega ● skipfsh 27
  28. 28. Demo Automated scanning 28
  29. 29. Authentication OWASP A2-Broken Authentication and Session Management Authentication is the main defense against unauthorized access and typically core to security Easy to make mistakes Common types: ● Form-based authentication ● HTTP authentication (basic, digest, Windows) ● Multifactor authentication ● SSL certifcates ● Authentication services 29
  30. 30. Authentication Step 8: test authentication mechanisms Methodology: ● Test password quality ● Attempt to enumerate usernames ● Attempt to brute force passwords ● Test account recovery function for enumerated users ● Examine cookies if 'remember me' option exists ● Verify credentials are submitted securely ● If multi-phase athentication is used, test for logic faws Tools: ● Web browser ● Burp 30
  31. 31. Authentication Most common passwords of 2013 [1] 1. 123456 (up 1) 2. password (down 1) 3. 12345678 (unchanged) 4. qwerty (up 1) 5. abc123 (down 1) 6. 123456789 (new) 7. 111111 (up 2) 8. 1234567 (up 5) 9. iloveyou (up 2) 10. adobe123 (new) 11. 123123 (up 5) 12. Admin (new) 13. 1234567890 (new) 14. letmein (down 7) 15. photoshop (new) [1] 31
  32. 32. Authentication Basic guidelines for safer authentication ● ● ● ● ● ● ● ● Passwords should be of a minimum length and contain a combination of alphabetic, numeric, uppercase, lowercase characters Don't limit the characters that can be used Avoid verbose authentication failure messages: use a single, generic error message Consider requiring periodic password changes Prevent brute force: lockout, CAPTCHAs Don't use unsafe questions for forgotten password Don't generate predictable usernames or passwords Transmit credentials using HTTPS 32
  33. 33. Session Management Guidelines to prevent sessions of legitimate users from being hijacked ● ● ● ● ● ● ● Generate strong random tokens: do not use predictable values or elements Transmit session tokens using HTTPS; use the 'Secure' attribute when setting the cookie Do not permit concurrent logins for the same user; invalidate older sessions Enforce inactivity timeouts Do not expose session identifers in URLs Invalidate session identifers during logout Verify information e.g. user-agent is valid throughout session 33
  34. 34. Session Fixation Attack where one person attempts to set another person's session identifer Example: ● An airline includes session tokens in its URLs. An authenticated user shares a URL with his friend, allowing the friend to book a trip using his credit card. More guidelines: ● Do not accept session identifers from GET or POST query data ● Assign a new session identifer when a user logs in 34
  35. 35. Access control OWASP A4-Insecure Direct Object References Applications often expose references to: ● Database keys ● Files ● Directories Avoid exposing resources directly. When these resources are exposed, it is important checks exist to ensure a user is authorized to access them. Example: ● Enumerating customers of a system by changing the customer ID on an account details page ● Request parameter used in a flesystem path 35
  36. 36. Demo Site map comparison 36
  37. 37. Example simple flesystem traversal Example: Some possible attacks: ?fle=../../../etc/passwd ?fle=/etc/passwd ?fle=/etc/passwd%00 ?fle=../get_image.php 37
  38. 38. Access control Cookie scope: Specify the domain when setting a cookie. A cookie set via will otherwise be sent to any host Restrict the cookie path when possible 38
  39. 39. Access control Step 9: verify access controls Purpose: ● Verify access controls are properly applied to sensitive functionality Methodology: ● Map the site using a diferent user 39
  40. 40. Data exposure OWASP A6-Sensitive Data Exposure Protect user data in transit: ● Use HTTPS ● Hardening data: ● Encrypt sensitive data (ex. passwords, credit cards) ● Use strong encryption and rotate keys where applicable ● PBKDBF2 for salted passwords Backups: ● Make sure backups are protected 40
  41. 41. Verifying client input Assume all input from a client is malicious. Even if the client is trusted, it may be under control of an attacker Do not use the client to relay sensitive parameters, ex. price of an item in a shopping cart. ● Users can see hidden input ● Requests can be intercepted ● Obfuscation isn't sufcient (e.g. ViewState) ● Browser extensions can be decompiled or debugged Verify input on both the client side and server side for usability, reliability Attacks can come from surprising sources 41
  42. 42. Demo Request manipulation 42
  43. 43. Attack from an unexpected source 43
  44. 44. Injection OWASP A1-Injection There are many types of injection: ● SQL injection ● NoSQL injection ● XPath injection ● LDAP injection ● SOAP injection ● OS command injection ● SMTP injection ● Back-end request injection Attackers can use these attacks to steal data, execute arbitrary commands, or even to be destructive Mitigation: ● Separate untrusted data from commands or queries 44
  45. 45. SQL Injection (SQLi) The most prevalent injection attack Typically trivial to exploit: Applying escape characters to parameters before using them works, but it is easy to let a parameter fall through the cracks Mitigation: ● Use parameterized queries 45
  46. 46. Demo SQL injection 46
  47. 47. XSS OWASP A3-Cross-site Scripting (XSS) An attacker can execute scripts in a user's web browser, performing any action the user can Two main types of XSS: ● Refected: script is refected of the web server ● Stored: scripts are permanently stored, displayed when a resource is loaded Same-origin policy: prevents an app from accessing the DOM on another site ● Same origin: protocol, host, port ● Policy applies to XMLHttpRequest ● Cross-origin resource sharing (CORS) permits access across domain boundaries ● <script> tag can load data from another site; executes in context of loading site (ex. JSONP) 47
  48. 48. XSS Same-origin policy with CORS: ● For many requests, a “prefight request” is sent to verify the cross-origin request can be made ● For “simple” GET, HEAD, and POST the request is sent, but script cannot access the response ● Credentials (ex. cookies) are included in requests (except prefight) ● XMLHttpRequest can be used for blind injection as a result Mitigation: ● Perform validation and escaping on the server side against any untrusted data that gets output in HTML ● OWASP XSS Prevention Cheat Sheet 48
  49. 49. Demo Cross-site scripting 49
  50. 50. CSRF OWASP A8-Cross-Site Request Forgery (CSRF) An attacker causes a user's browser to submit a request to a website the user is authenticated with. Exploits the website's trust in the user. Example: ● Cause the user's browser to submit a request to send a malicious message to another user General Mitigation: ● Include an unpredictable token as a parameter of any request that performs sensitive actions ● Do not exposure the token in the URL ● Password-protect exceptionally sensitive actions (ex. changing account details) ● Reject all requests that do not contain the token 50
  51. 51. Example CSRF Attacker gets user to open a link containing a malicious <img> tag: 51
  52. 52. CSRF Mitigation Including a token bound to the session in the form: 52
  53. 53. Web Resources OWASP: MITRE CWE: SSL Server Test: Securityheaders: Reddit netsec: 53
  54. 54. Books Web Application Hacker's Handbook edition 2: Dafydd Stuttard, Marcus Pinto Tangled Web: Michal Zalewski 54
  55. 55. Questions? 55