Charlotte Developers Guild

8d2a24325f249c46734caadf22cd51b5?s=47 Sean Rhone
January 23, 2018

Charlotte Developers Guild

Charlotte Developers Guild


Sean Rhone

January 23, 2018



    Rhone Application Development Manager, Cardinal Innovations Healthcare Twitter: @SeanRhone
  2. WHAT WE ARE NOT COVERING TONIGHT • Crafting Javascript to

    bypass filters • How to hack your site for SQL injection • Deep dives into serious Pen testing
  3. WHAT WE ARE COVERING TONIGHT • Simple things you can

    implement without having to be a security expert

    • Microsoft Regional Director & MVP • • Scott Helme ( • Security researcher & international speaker • • Google / Bing
  5. ASSUMPTIONS • No site is 100% secure. It’s not about

    being “unhackable” it’s about making it so difficult it’s not worth their time. Layers of security, like an onion, make them want to cry trying to get in and go somewhere else instead • Don’t think in terms of “how do I prevent” and instead “how do I mitigate” • You’re not a security expert but want to write safer code
  6. BIG HACKS & SECURITY BREACHES • Charlotte Mecklenburg County (2017)

    • Equifax (2017 – 143M) • Adult Friend Finder (2016 – 412M) • Anthem (2015 – 78M) • eBay (2014 – 145M)


    want to serve any contents on the same domain as http • Can only be set during a secure request • Trust on first user (TOFU) – Make one insecure request to get HSTS header then all future requests are always sent over secure https • Strict-Transport-Security: max-age:31536000; includeSubdomains; preload

  10. CROSS-SITE REQUEST FORGERY (CSRF) • OWASP Definition - Cross-Site Request

    Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request • Site_Request_Forgery_(CSRF)
  11. CROSS-SITE REQUEST FORGERY (CSRF) How the attack can occur –

    The end user is tricked into clicking an email link, clicking an invisible frame or by visiting a site with malicious scripts while logged into the target site. Ways to mitigate • Do not allow Cross-Origin Resource Sharing (CORS) • http header X-Frame-Options - DENY, SAMEORIGIN, ALLOW-FROM. Not all browser version honor all three of these. • http header Content-Security-Policy: frame-ancestors none, self, self (list of sites). Not all browser versions honor all three of these and X-Frame-Options will be ignored if CSP is defined. • Anti-forgery tokens. Microsoft helps out with this if you’re using MVC and scaffolding in the razor file.
  12. CONTENT SECURITY POLICY • Allows you to declare content sources.

    Where can your site pull resources for • Takes some work to get the header correct, but worth the effort once done • Keywords (None, Self, *) - There are more keywords • Hosts (ability to specify source of content) –
  13. CONTENT SECURITY POLICY DIRECTIVES • default-src ‘self’ - White list

    so that our site can only pull content from itself • script-src ‘self’ • Frame-ancestors ‘self’
  14. UPCERTS • Same method used to insert or update a

    record based on value of id field • User could over-ride the id field on post-back using a proxy application
  15. AUTHENTICATION • Do not give indication of user name format.

    Don’t have any sort of client-side regex or validation indicating the user name entered is not in a correct format. Whatever the user enters should always be sent to the server. • Only one error message for failed authentication, doesn’t matter if the username was not found or the password was incorrect. Any difference between error messages indicate some sort of success. • Never send credentials to client-side for validation.
  16. AUTHENTICATION • Consider server-side storage of important information. Username, user

    id, account numbers etc. All information coming from client should be considered suspect. Most developers don’t like session state but it’s better to keep certain information server side. • Always perform all steps in authentication even if username doesn’t exist. The more complex your authentication steps are the more important this step becomes. (Timing attacks)
  17. FORGOT PASSWORD • Same concept as authentication, do not give

    any indication of username format. • Do not give any indication of failed / success on finding user account
  18. EXPOSING TOO MUCH INFORMATION • Displaying system paths • Elmah

    log • Displaying too much system information when an error occurs • Yellow screen of death • 404 or other uncaught errors • Response Headers
  19. DISPLAYING SYSTEM PATHS • File paths • System information

  20. RESPONSE HEADERS • Another place where too much information is

    sent to the user • Server, X-AspNet-Version, X-AspNetMvc-Version, X-Powered-By • X-Frame-Options (Not supported by all browsers/versions) – Deny/SameOrigin/Allow-From • Cache-Control, “No-Cache, No-Store, Must-Revalidate” • Pragma, No-Cache (Older version of Cache-Control)
  21. ELMAH LOGS • Great for catching error and diagnosing issues

    and horrible if not secured • Setting “allowRemoteAccess” to false is your friend • Inurl: elmah.axd
  22. YELLOW SCREEN & OTHER ERRORS • Yellow Screen of death

    exposes too much system information and should never be shown to end users • Easy to hide - <customErrors mode=“{On}{Off}{RemoteOnly}”/> • Http Errors are just as bad if not properly handled. Fix these at the IIS level
  23. PASSWORD STRENGTH • Require as long of a password you

    can get away with. The Open Web Application Security Project (OWASP) suggest minimum length of 10 allowing special characters and suggest encouraging passphrases. • Password complexity, make password case sensitive, allow special characters (,./;:?-+[]\| *), require a mix of upper and lower case characters ([A-Z][a-z]) and require numbers ([0-9]). Don’t allow know words (baseball) or variations of them (b@seb@ll) and don’t allow repeating characters (111).
  24. PASSWORD STORAGE – WHAT NOT TO DO • Store passwords

    in plain text • Store in an encrypted format • Roll your encryption algorithm
  25. PASSWORDS STORAGE – THE RIGHT WAY • Passwords should be

    stored using a one-way transform; passwords should never be reversible! • Transforming passwords should include latest hash algorithm, a salt and a “work factor”. • Packages such as bcrypt and PBKDF2 are available and make it almost “plug and play”.
  26. COOKIES • Don’t store anything important in cookies. • Mark

    cookies HttpOnly (<httpCookies httpOnlyCookies="true" /> in .NET). This helps mitigate client-side code from accessing cookies. • Mark cookies secure, means cookie is only sent over https. Anything not sent over https can be stolen. <httpCookies requireSSL=“true”/> • Encrypt all cookies (System.Web.Security.FormsAuthentication.Encrypt)
  27. CROSS-SITE SCRIPTING (XSS) OWASP Definition: Attack consists of insertion or

    “injection” or a SQL query via the input data from the client to the application. How the attack can occur: Developers create dynamic SQL based on user input or output un-encoded user input. Ways to mitigate • Use prepared statements – Parameterized queries • Use stored procedures • Whitelist user input • Encoding of output data
  28. INJECTION ISSUES OWASP Definition: Attack consists of insertion or “injection”

    or a SQL query via the input data from the client to the application. How the attack can occur: Developers create dynamic SQL based on user input or output un-encoded user input. Ways to mitigate • Encoding output is the most effective way to mitigate • Use prepared statements – Parameterized queries • Use stored procedures • Whitelist user input
  29. LOGGING • IIS logs. Great idea as long as you

    know about the risks. • Potential sensitive information in the logs if you’re query strings contains information. • Hard drive space, logs can become very large.