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

Charlotte Developers Guild

Sean Rhone
January 23, 2018

Charlotte Developers Guild

Charlotte Developers Guild

Sean Rhone

January 23, 2018
Tweet

Other Decks in Technology

Transcript

  1. WEB SECURITY 101
    THE SIMPLE THINGS EVERYONE CAN DO
    Sean Rhone
    Application Development Manager, Cardinal Innovations Healthcare
    [email protected]
    Twitter: @SeanRhone

    View full-size slide

  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

    View full-size slide

  3. WHAT WE ARE COVERING TONIGHT
    • Simple things you can implement without having to be a security
    expert

    View full-size slide

  4. GIVING CREDIT WHERE IT IS DUE
    • Troy Hunt (https://www.TroyHunt.com)
    • Microsoft Regional Director & MVP
    • https://www.youtube.com/user/troyhuntdotcom
    • Scott Helme (https://scotthelme.co.uk)
    • Security researcher & international speaker
    • PluralSight.com
    • Google / Bing

    View full-size slide

  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

    View full-size slide

  6. BIG HACKS & SECURITY BREACHES
    • Charlotte Mecklenburg County (2017)
    • Equifax (2017 – 143M)
    • Adult Friend Finder (2016 – 412M)
    • Anthem (2015 – 78M)
    • eBay (2014 – 145M)

    View full-size slide

  7. MAN IN THE MIDDLE

    View full-size slide

  8. HSTS (HTTP STRICT TRANSPORT SECURITY)
    • Can’t use if you 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

    View full-size slide

  9. STATS ON HEADER USAGE
    SRC HTTPS://SCOTTHELME.CO.UK/ALEXA-TOP-1-MILLION-ANALYSIS-
    FEB-2017/

    View full-size slide

  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
    • https://www.owasp.org/index.php/Cross-
    Site_Request_Forgery_(CSRF)

    View full-size slide

  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.

    View full-size slide

  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) –
    https://someExternalSite.com

    View full-size slide

  13. CONTENT SECURITY POLICY
    DIRECTIVES
    • default-src ‘self’ - White list so that our site can only pull
    content from itself
    • script-src ‘self’ https://www.google.com https://www.google-
    analytics.com
    • Frame-ancestors ‘self’

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  19. DISPLAYING SYSTEM PATHS
    • File paths
    • System information

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  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 -
    • Http Errors are just as bad if not properly handled. Fix these at the
    IIS level

    View full-size slide

  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).

    View full-size slide

  24. PASSWORD STORAGE – WHAT NOT TO DO
    • Store passwords in plain text
    • Store in an encrypted format
    • Roll your encryption algorithm

    View full-size slide

  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”.

    View full-size slide

  26. COOKIES
    • Don’t store anything important in cookies.
    • Mark cookies HttpOnly ( 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.
    • Encrypt all cookies
    (System.Web.Security.FormsAuthentication.Encrypt)

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide