Charlotte Developers Guild

Charlotte Developers Guild

Transcript

1. WEB SECURITY 101 THE SIMPLE THINGS EVERYONE CAN DO Sean Rhone Application Development Manager, Cardinal Innovations Healthcare Srhone@Gmail.com 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
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
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)
7. MAN IN THE MIDDLE
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
9. STATS ON HEADER USAGE SRC HTTPS://SCOTTHELME.CO.UK/ALEXA-TOP-1-MILLION-ANALYSIS- FEB-2017/
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)
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) – https://someExternalSite.com
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’
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.