Ermahgerd Werb Verlns

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