Building Secure Web Applications

Presentation for TechnoWise meetup in Pune on 28th April 2018

Transcript

1. BUILDING SECURE WEB APPLICATIONS Shirish Padalkar (@truthyvalue) @TechnoWise - Saturday, April 28, 2018 1
2. ABOUT ME 2
3. AGENDA ▫︎Why should I care? ▫︎Vocabulary ▫︎OWASP Top 10 ▫︎ Break ▫︎Building secure web applications ▫︎How do I get started? 3
4. SOME QUESTIONS FIRST 4 https://flic.kr/p/2vgyWN
5. IS SECURITY IMPORTANT FOR YOUR PROJECT? 5
6. ARE YOU BUILDING A SECURE WEB APPLICATION? 6
7. WHO IS RESPONSIBLE FOR BUILDING A SECURE APPLICATION? 7
8. WHY SHOULD YOU CARE? 8
9. MEDIA COVERAGE OF MAJOR HACKS ▫︎Office of Personnel Management data breach ▫︎Uber Covered Up Hack On 57 Million People ▫︎Airline outage causes massive delays for British Airways travelers ▫︎Equifax Hack: Who Is At Risk? ▫︎Target Identity Theft Case Three Times Bigger Than Reported 9
10. CURRENT STATE 10
11. 11 https://flic.kr/p/dq38oj
12. Security review? We will do it before we go live! 12
13. Penetration testing? What’s the hurry? We still have a week to go live! 13
14. IDEAL STATE 14
15. 15 https://flic.kr/p/34T4Z Everything is SECURE!
16. VOCABULARY 16
17. 17 SECURE
18. … certain to remain safe and unthreatened. 18
19. In computer security, “secure” is relative, not absolute. 19
20. 20 VULNERABILITY
21. Vulnerability refers to the inability of a system to withstand the effects of a hostile environment. 21
22. In computer security: A vulnerability is a weakness which allows an attacker to reduce a system's information assurance. 22
23. 23 EXPLOIT
24. Exploit means to take advantage of something for one's own end, especially unethically or unjustifiably. 24
25. An exploit is a piece of software that takes advantage of a bug or vulnerability in order to cause unintended behaviour to occur on computer software or hardware 25
27. OWASP ▫︎Open Web Application Security Project ▫︎Not-for-profit charitable organisation ▫︎Focused on improving the security of software ▫︎All materials are available under a FOSS license ▫︎Currently has around 133 active projects 27
28. 28 https://www.owasp.org
29. OWASP TOP 10 ▫︎List of the 10 most critical web application security risks ▫︎A powerful awareness document ▫︎Reference document for project security analysis ▫︎Published at regular intervals ▫︎Approximately once in 3 years ▫︎Last published in 2017 29
30. OWASP TOP 10, 2017 1. Injection 2. Broken authentication 3. Sensitive Data Exposure 4. XML External Entities (XXE) 5. Broken Access Control 6. Security Misconfiguration 7. Cross Site Scripting (XSS) 8. Insecure Deserialization 9. Using components with known vulnerability 10.Insufficient Logging & Monitoring 30
31. DELTA FROM OWASP TOP 10 (2013) ▫︎New issues, supported by data: ▫︎A4:2017 - XML External Entities (XXE) ▫︎New issues, supported by the community: ▫︎A8:2017 - Insecure Deserialization ▫︎A10:2017 - Insufficient Logging and Monitoring ▫︎Merged or retired, but not forgotten: ▫︎A4 - Insecure Direct Object References and A7 - Missing Function Level Access Control merged into A5:2017 - Broken Access Control ▫︎A8 - Cross Site Request Forgery (CSRF) ▫︎A10 - Unvalidated Redirects and Forwards 31
32. LET’S UNDERSTAND 
 OWASP TOP 10 32
33. 33 INJECTION
34. INJECTION ▫︎SQL Injection ▫︎Most prevalent ▫︎Databases like Oracle, MySQL ▫︎NoSQL Injection ▫︎Comparatively recent ▫︎Databases like MongoDB ▫︎Command Injection ▫︎LDAP Injection 34
35. 35 DEMO http://sqlidemo.altervista.org/index.php
36. SQL INJECTION TESTING TOOL - SQLMAP 36
37. SQL INJECTION TESTING TOOL - SQL NINJA 37
38. PROTECTION AGAINST SQL INJECTION ▫︎Use of Prepared Statements (with Parameterized Queries) ▫︎Use Stored Procedures if possible ▫︎White List input validation ▫︎Escape all user supplied input ▫︎ESAPI ▫︎https://www.owasp.org/index.php/ SQL_Injection_Prevention_Cheat_Sheet ▫︎https://www.owasp.org/index.php/ Category:OWASP_Enterprise_Security_API 38
39. 39 BROKEN AUTHENTICATION
40. BROKEN AUTHENTICATION ▫︎Weak passwords / no defined password policy ▫︎Allows brute force or other automated attacks ▫︎Default, weak, or well-known passwords ▫︎"Password1" or “admin/admin” ▫︎Weak or ineffective credential recovery ▫︎Recovery questions like birthday, first car, … ▫︎Session IDs in the URL ▫︎PHPSESSID ▫︎JSESSIONID 40
41. BROKEN AUTHENTICATION ▫︎Unencrypted passwords in storage or transit ▫︎Login over HTTP ▫︎Email password in plain text ▫︎Predictable session IDs ▫︎Reusing same session IDs 41
42. TOOLS FOR BRUTE FORCE ATTACK ▫︎Aircrack-ng ▫︎Cain and Abel ▫︎Crack ▫︎DaveGrohl ▫︎Hashcat ▫︎John the Ripper ▫︎L0phtCrack ▫︎Ophcrack ▫︎RainbowCrack 42
43. 43 SENSITIVE DATA EXPOSURE
44. SENSITIVE DATA EXPOSURE ▫︎Allowing man-in-the-middle attacks ▫︎Use of weak encryption algorithms ▫︎Hashing vs Encryption ▫︎MD5 is NOT encryption ▫︎Not verifying certificates / signatures ▫︎Transparent db encryption is still dangerous ▫︎The most common flaw is simply not encrypting sensitive data 44
45. 45 BROKEN ACCESS CONTROL
46. BROKEN ACCESS CONTROL ▫︎Elevation of privilege. ▫︎Tampering with a JWT / SessionID or hidden field ▫︎Using actual name or key of an object when generating web pages ▫︎Don’t verify the user is authorised for the target object ▫︎Attackers can easily manipulate parameter values to access another object ▫︎http://photos.com/download.php?file=personal.jpg ▫︎http://mybank.com/accountInfo?accNumber=123456 46
47. 47 SECURITY MISCONFIGURATION
48. SECURITY MISCONFIGURATION ▫︎Running the application with debug enabled in production. ▫︎Directory listing enabled on the server ▫︎Running outdated versions of software / dependencies ▫︎Equifax was running older version of struts ▫︎Unnecessary services running on the machine ▫︎Not changing default keys and passwords 48
49. SECURITY MISCONFIGURATION ▫︎Disabled latest security features ▫︎Real developers don’t use password! ▫︎Public AWS S3 buckets ▫︎Revealing error handling information to the attackers, such as stack traces. ▫︎Default accounts and passwords enabled and unchanged. 49
50. SECURITY MISCONFIGURATION 50
51. 51 CROSS SITE SCRIPTING
52. CROSS SITE SCRIPTING (XSS) ▫︎Inject client-side script into pages viewed by other users ▫︎No HTML or Javascript escaping ▫︎Can steal cookies, change page location, etc. ▫︎Script executes with same permission as current page 52
53. XSS TYPES ▫︎Reflected ▫︎Non-persistent ▫︎The most common type ▫︎Is typically delivered via email or a neutral web site ▫︎Display a page of results for a user, without properly sanitising the request. ▫︎Ex. Search result with search term without sanitisation 53
54. XSS TYPES ▫︎Stored ▫︎Persistent ▫︎A more devastating variant ▫︎Permanently displayed on "normal" pages returned to other users ▫︎Example: Online message boards / Forums, Post on Facebook wall 54
55. 55 DEMO https://xss-game.appspot.com/
56. CROSS SITE SCRIPTING (XSS) 56
57. OWASP TOP 10, 2017 1. Injection 2. Broken authentication 3. Sensitive Data Exposure 4. XML External Entities (XXE) 5. Broken Access Control 6. Security Misconfiguration 7. Cross Site Scripting (XSS) 8. Insecure Deserialization 9. Using components with known vulnerability 10.Insufficient Logging & Monitoring 57
58. BUILDING SECURE WEB APPLICATIONS 58
59. WHAT WILL WE LEARN? ▫︎What’s in the Development Mode ▫︎Encryption in transit ▫︎Browser’s Origin-based Threat Model ▫︎Access Control ▫︎Input / Output ▫︎Business Logic Security 59
60. DEVELOPMENT MODE ▫︎Dev endpoints can leak information ▫︎Express: x-powered-by ▫︎.NET IIS: x-aspnet-version ▫︎Spring Boot: /mappings, /configprops, … ▫︎Dev endpoints can be used for attacks ▫︎Spring Boot: /shutdown ▫︎Tomcat: 8005 shutdown port, manager webapp ▫︎Find out what your server does and disable it. 60
61. TRANSPORT LAYER SECURITY (TLS) ▫︎Provides ▫︎Encryption in transit ▫︎Message integrity, ▫︎The “S” in https ▫︎SSL vs. TLS ▫︎Certificates are issued by Certificate Authorities (CAs) ▫︎Cipher suites & negotiation 61
62. HTTP STRICT TRANSPORT SECURITY (HSTS) ▫︎Sent as HTTP header ▫︎Deploy with caution ▫︎ Once received, the browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS ▫︎If you get this wrong, the impact can be catastrophic ▫︎HSTS not an option? Use HTTP 301 to forward to https 62
63. BROWSER’S THREAT MODEL ▫︎Browser’s threat model is based on origin. ▫︎Browser represents the origin’s interests. ▫︎Same Origin Policy - If a request shouldn’t be read, the browser would not let you read it. ▫︎Cross Origin Resource Sharing - If a server won’t accept a request, the browser won’t send it. ▫︎A browser does not necessarily secure the user. ▫︎Browsers try to not be instruments of abuse to servers. 63
64. SAME ORIGIN POLICY ▫︎Same-Origin Policy prevents scripts from reading content from a location that the script does not originate from 64 Scheme Domain Subdomain Port * depends checked checked ignored XHR depends checked checked checked Cookies depends checked depends ignored Web Sockets ignored ignored ignored ignored
65. CROSS ORIGIN RESOURCE SHARING (CORS) ▫︎Go to https://xyz.com ▫︎Make a POST request to https://google.com ▫︎Browser does pre-flight check whether the server will accept the request via OPTION request. ▫︎If server accepts from current origin, browser will do the request, otherwise drops the request. 65
66. SESSIONS ▫︎HTTP is stateless ▫︎Typically stored in cookies ▫︎Referenced by IDs ▫︎Sufficient length and entropy to prevent guessing and brute-force ▫︎Never include PII ▫︎Don’t accept user-initialised session ▫︎Re-authenticate on privilege level change ▫︎Expire sessions on client and server-side 66
67. COOKIES ▫︎expires ▫︎httpOnly ▫︎secure ▫︎domain ▫︎signed ▫︎sameSite 67
68. REST ▫︎Use the proper verbs ▫︎ Read: GET, Create: POST, Update: PATCH, Replace: PUT, Delete: DELETE ▫︎Restrict unused HTTP verbs ▫︎ Not Allowed: 405 Method Not Allowed ▫︎Validate content-type of submitted data as you accept ▫︎Don’t trust user-submitted MIME-types ▫︎Validate your JSON schema ▫︎Avoid insecure direct object references 68
69. USER INPUT ▫︎Never execute anything you receive ▫︎Escape whatever you use, e.g. in SQL statements ▫︎eval() in JS is EVIL ▫︎Avoid XSS and other injection attacks ▫︎Be wary of encodings and charsets ▫︎Make sure you understand what your frameworks are doing! 69
70. CROSS SITE SCRIPTING (XSS) ▫︎Never allow execution for third-party data ▫︎HTML entity-encode when not executed ▫︎Sanitise ▫︎Sandbox ▫︎Use the Content Security Policy 70
71. CONTENT SECURITY POLICY (CSP) ▫︎Instruct the browser from which location and/or which type of resources are allowed to be loaded. ▫︎Define a loading behaviour in CSP "directive": ▫︎ default-src: All resources type (fallback) ▫︎ script-src: specifies valid sources for JavaScript ▫︎ object-src: specifies valid sources for <object>, <embed>, <applet> elements. ▫︎ style-src: specifies valid sources for sources for stylesheets ▫︎ img-src, media-src, child-src, frame-src, font-src, connect-src, form- action, sandbox, … ▫︎ https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP 71
72. MISCELLANEOUS ▫︎Avoid MIME-type confusion ▫︎Validate content-type w.r.t. Accept header ▫︎Don’t reflect user-submitted MIME-types ▫︎X-Content-Type-Options: nosniff ▫︎Avoid clickjacking: X-Frame-Options: deny ▫︎Return the proper status codes ▫︎Do not leak information in response ▫︎Stack traces! 72
73. API SECURITY 73
74. API SECURITY ▫︎Avoid denial of service by thinking about how you handle inputs ▫︎Never block your endpoint ▫︎Offload expensive computation to workers or actors ▫︎Impose maximum input length on expensive operations ▫︎Impose maximum input length on expensive operations ▫︎Limit maximum password length to avoid DoS ▫︎Use caching, rate limiting where possible ▫︎Be a good citizen and don’t DoS others. 74
75. DEPENDENCIES ▫︎Know the versions of all components you use ▫︎Know if software is vulnerable, unsupported, or out of date ▫︎Includes OS, runtime, web/application server, DBMS, applications, APIs and components, and libraries. ▫︎Subscribe to security advisories for your tech stack ▫︎Automate vulnerability scanning for your dependencies ▫︎Automate version updates: Branch, test, merge ▫︎Test compatibility of upgraded/patched libraries ▫︎Secure the component configuration 75
76. STORING SECRETS 76
77. WHY MANAGING SECRETS IS HARD? ▫︎Automated distribution of secrets ▫︎Automated revocation of access ▫︎Automated detection of secrets ▫︎Continuous delivery pipelines ▫︎Promoting secrets to infrastructure components 77
78. 6 STAGES OF SECRET MANAGEMENT ▫︎Denial: No Solution ▫︎Reluctance: Emailing encrypted containers ▫︎Bargaining: Team Password Managers ▫︎Acceptance: Encrypted DVCs ▫︎Progress: Orchestration ▫︎Mastery: Secret Service 78
79. AUTOMATED SECRET DETECTION ▫︎Don’t commit passwords and other sensitive information ▫︎Tools: ▫︎https://github.com/michenriksen/gitrob ▫︎https://github.com/thoughtworks/talisman ▫︎https://github.com/awslabs/git-secrets ▫︎https://github.com/Stono/hawkeye 79
80. HOW DO I START? 80
81. VULNERABILITY SCANNING ▫︎Log management ▫︎data management 81
82. SECURITY TESTING - ZAP 82
83. SECURITY TESTING - ZAP 83 https://blog.codecentric.de/files/2013/10/zap-screenshot.png
84. CONTINUOUS SECURITY TESTING 84
85. CONTINUOUS SECURITY TESTING 85
86. GOOGLE GRUYERE 86 https://google-gruyere.appspot.com/
87. OWASP SECURE CODING PRACTICES 87 https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide
88. WEB APPLICATION SECURITY TESTING CHEAT SHEET 88 https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet
89. REMEMBER! 89
90. 90 EVERYONE CAN BE RESPONSIBLE FOR SECURITY
91. 91 PREFER BUILT-IN SECURITY OVER BLOAT-IN SECURITY
92. 92 SECURITY REQUIREMENTS SHOULD BE TESTABLE So that they can be automated.
93. 93 TRY TO INTEGRATE SECURITY TESTING INTO CI
94. ANY QUESTIONS? 94 @truthyvalue truthyvalue@gmail.com