Ermahgerd Werb Verlns

0a6d9b1ad59ad436bf9d9d16b2a7133e?s=47 lanmaster53
November 16, 2016
140

Ermahgerd Werb Verlns

0a6d9b1ad59ad436bf9d9d16b2a7133e?s=128

lanmaster53

November 16, 2016
Tweet

Transcript

  1. None
  2. Husband, Father and Veteran A hacker serving people by working,

    coding, teaching, and sharing, for the glory of God. Tim Tomes
  3. Ermahgerd, Werb Verlns [omg, web vulnerabilities] 1: Common, easily discovered

    weaknesses that reduce a web application's information assurance.
  4. None
  5. Transport Layer Security (TLS) • The "S" in HTTPS. •

    Prevents eavesdropping and tampering attacks by providing end-to-end encryption. • Uses long-term asymmetric encryption to establish short-term symmetric encryption. • Standards change at the pace of technology. • Testing this is actually hard, so use... – https://www.ssllabs.com/ssltest/
  6. None
  7. None
  8. None
  9. Response Headers • Provide the browser with information. – Often

    as behavioral instructions. • Good headers (when configured properly): – X-Frame-Options: DENY – Strict-Transport-Security: max-age=31536000; includeSubDomains; preload – X-XSS-Protection: 1; mode=block – Content-Security-Policy: default-src 'self'; – Cache-Control: private, no-cache, no-store, max- age=0
  10. Response Headers • Bad headers: – Server: <server type and

    version> – X-Powered-By: <technology and version> – X-AspNet-Version: <framework version> – X-AspNetMvc-Version: <framework version> • Adding and removing headers requires minimal engineering. • Validate with https://securityheaders.io/.
  11. None
  12. None
  13. Cookie Flags • Flags that instruct the browser how to

    treat the domain's cookies. • Secure – Restrict the cookie to TLS encrypted connections. • HttpOnly – Prevent JavaScript from accessing the cookie. • Never a good reason not to use these. • Minor configuration change or minimal code.
  14. None
  15. None
  16. User Enumeration • The ability to enumerate user information through

    variable responses from requests using valid and invalid information. • Response variations include error messages, lockouts, query string parameters, spacing, timing, anything really. • Can exist anywhere the application formulates a response based on user-specific information. – Login, account recovery, registration, messaging, etc. • Be consistent. – Not always easy to do.
  17. None
  18. Insecure Direct Object Reference (IDOR) • The ability to access

    information belonging to other users by tampering with direct object references. • Not always an integer. – GUIDs, encoded DORs, etc. – Almost always indicates an IDOR issue. • One of the most common and easily exploitable flaws, yet impossible for scanners to find. • Check ownership of the referenced object.
  19. None
  20. Missing Function Level Access Control • The ability to access

    higher privilege functionality by force browsing to obscured resources. • Access controls in the view must match the access controls on the controller. • Another common and easily exploitable flaw that is impossible for scanners to find. • Check the permission level of the requested resource.
  21. None
  22. None
  23. Password Security • An application should NEVER be able to

    tell a user their password. • Encoding != Encryption != Hashing • Key management for encryption is hard. – Access to the cipher usually means access to the key. • Not all hashing algorithms are created equal. – Fast hashing vs. Adaptive hashing • Design storage systems assuming eventual compromise.
  24. Summary • TLS - https://www.ssllabs.com/ssltest/ • Response Headers - https://securityheaders.io/

    • Cookie Flags - Developer tools. • User Enumeration - Check known goods vs. known bads. • Insecure Direct Object Reference - Change the DORs. • Missing Function Level Access Control - Force browse. • Password Security - Look for evidence.
  25. Tim Tomes @lanmaster53 tim.tomes@nvisium.com http://www.lanmaster53.com https://nvisium.com