Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ermahgerd Werb Verlns

November 16, 2016

Ermahgerd Werb Verlns


November 16, 2016


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

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

    weaknesses that reduce a web application's information assurance.
  3. 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/
  4. 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
  5. 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/.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.