Web Security in Node.js Applications

With billions of people using the Internet, the potential for nefarious or outright criminal users hitting your site is very high. With attacks ranging from MITM, CSRF, Script Injection, Clickjacking to name a few, it is imperative that we as developers understand these exploits, how they work, how they can be stopped, and how to implement the code or setup to do so. As developers, we tend to focus on the core of what our application does. Unfortunately, security tends to be overlooked or at best an afterthought.

In this talk we will cover best practices for securing your web applications. The focus will be on Express web applications in Node, but the principles shown can be applied to any framework or environment.

Some, but not all, of the topics we will cover are: securing your web traffic, proper cookie handling, preventing CSRF, stopping Script Injection, sanitizing data input and output, handling sensitive data, implementing CSP, HSTS, X-Frame-Options, preventing vulnerabilities in node modules, and more.

At the end, you will leave with a diverse understanding of how best to secure your application from most of the attacks that can occur.

Transcript

1. Web Security in Node.js Applications @scottksmith95 scottksmith.com
2. I’m Scott Smith VP of Product Development by Day Full Stack Node & .NET Developer by Night
4. • Injection • Broken Authentication and Session Management • Cross Site Scripting (XSS) • Cross Site Request Forgery (CSRF) • Using Components with Known Vulnerabilities
5. Injection
6. Attacker sends text-based attacks to exploit the syntax of targeted interpreter
11. Solution #1 Escape all user input for SQL statements
14. Solution #2 User parameterized SQL queries
18. eval(userInput) is dangerous
22. Don’t use eval() with user input
29. • Injection • Broken Authentication and Session Management • Cross Site Scripting (XSS) • Cross Site Request Forgery (CSRF) • Using Components with Known Vulnerabilities
30. Broken Authentication and Session Management
31. Scenario #1 Attacker gains access to database with plain text passwords
32. Solution Always hash passwords
34. Scenario #2 Site supports session ids within the URL
35. https://bank.com/account?sessionid=1234567
36. • Sharing of link grants others full access https://bank.com/account?sessionid=1234567
37. • Sharing of link grants others full access • Stored on cache servers https://bank.com/account?sessionid=1234567
38. • Sharing of link grants others full access • Stored on cache servers • Stored in browser history https://bank.com/account?sessionid=1234567
39. • Sharing of link grants others full access • Stored on cache servers • Stored in browser history • Leaked through the Referer header https://bank.com/account?sessionid=1234567
40. • Sharing of link grants others full access • Stored on cache servers • Stored in browser history • Leaked through the Referer header • Leaded through logs not properly protected https://bank.com/account?sessionid=1234567
41. • Sharing of link grants others full access • Stored on cache servers • Stored in browser history • Leaked through the Referer header • Leaded through logs not properly protected • Much more visible and dangerous https://bank.com/account?sessionid=1234567
42. Solution Store session ids in cookies and never in the URL
44. Scenario #3 Site employs long or no session timeouts
45. Solution Explicitly set expiration for session
46. Good
47. Better
48. Scenario #4 User accesses site on public unencrypted wifi over HTTP
49. Solution #1 Run your site over HTTPS
50. Solution #2 Do not allow cookies to be sent over HTTP
52. Solution #3 Tell the browser to never make requests over HTTP again
53. HTTP Strict Transport Security (HSTS) Response header telling user agent to prevent HTTP requests to domain
55. Strict-Transport-Security: max-age=7776000; includeSubDomains
56. Solution #4 Don’t let client scripts read your cookies
58. • Injection • Broken Authentication and Session Management • Cross Site Scripting (XSS) • Cross Site Request Forgery (CSRF) • Using Components with Known Vulnerabilities
59. Cross Site Scripting (XSS)
60. Attacker takes advantage of the user’s trust in websites
61. Non-persistent
62. Attacker Victim Site Non-persistent
63. Attacker Victim Site GET /index.html Non-persistent
64. Attacker Victim Site GET /index.html HTTP/1.1 200 OK <html> <a href=“https://site.com/search? q=<script>alert(‘hacked’)<script>”> Click Here </a> </html> Non-persistent
65. Attacker Victim Site GET /index.html HTTP/1.1 200 OK <html> <a href=“https://site.com/search? q=<script>alert(‘hacked’)<script>”> Click Here </a> </html> GET /search?q=… Non-persistent
66. Attacker Victim Site GET /index.html HTTP/1.1 200 OK <html> <a href=“https://site.com/search? q=<script>alert(‘hacked’)<script>”> Click Here </a> </html> GET /search?q=… Non-persistent HTTP/1.1 200 OK Payload with injected script
67. Attacker Victim Site GET /index.html HTTP/1.1 200 OK <html> <a href=“https://site.com/search? q=<script>alert(‘hacked’)<script>”> Click Here </a> </html> GET /search?q=… Non-persistent HTTP/1.1 200 OK Payload with injected script Send valuable data
68. Persistent
69. Attacker Victim Site Persistent
70. Attacker Victim Site Persistent POST /comment Payload with script
71. Attacker Victim Site GET /comment?id=1 Persistent POST /comment Payload with script
72. Attacker Victim Site GET /comment?id=1 Persistent HTTP/1.1 200 OK Payload with injected script POST /comment Payload with script
73. Attacker Victim Site GET /comment?id=1 Persistent HTTP/1.1 200 OK Payload with injected script Send valuable data POST /comment Payload with script
74. It’s all about injecting client-side script into web pages viewed by others
75. Solution #1 Escape all user input
77. <script>alert('hacked')</script> => &gt;script&lt;alert(&#x27;hacked&#x27;)&gt;/script&lt;
78. Solution #2 Tell the browser to allow content from trusted sources only
79. Content Security Policy (CSP) Response header telling the browser the domains it should consider as valid sources of content
81. * Newlines added for readability
82. • Injection • Broken Authentication and Session Management • Cross Site Scripting (XSS) • Cross Site Request Forgery (CSRF) • Using Components with Known Vulnerabilities
83. Cross Site Request Forgery (CSRF)
84. Attacker takes advantage of the websites’s trust in users
85. Scenario #1 Exploiting sites that support changes via GET requests
86. Attacker Victim Bank
87. Attacker Victim Bank POST /login
88. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234
89. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html
90. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <html> <img src=“https://bank.com/transfer? to=12345&dollars=1000000” width=“0” height=“0”> </html>
91. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <html> <img src=“https://bank.com/transfer? to=12345&dollars=1000000” width=“0” height=“0”> </html> GET /transfer?to… Cookie: SessionId=1234
92. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <html> <img src=“https://bank.com/transfer? to=12345&dollars=1000000” width=“0” height=“0”> </html> HTTP/1.1 200 OK GET /transfer?to… Cookie: SessionId=1234
93. Solution Never allow changes via GET … only POST
94. Scenario #2 Tricking users into posting exploited data to sites
95. Attacker Victim Bank
96. Attacker Victim Bank POST /login
97. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234
98. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html
99. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <form name=“bad” method=“post” action=“https://bank.com/transfer”> <input type=“hidden” name=“to” value=“12345”> <input type=“hidden” name=“dollars” value=“1000000”> </form> <script>document.bad.submit()</script>
100. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <form name=“bad” method=“post” action=“https://bank.com/transfer”> <input type=“hidden” name=“to” value=“12345”> <input type=“hidden” name=“dollars” value=“1000000”> </form> <script>document.bad.submit()</script> POST /transfer Cookie: SessionId=1234
101. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <form name=“bad” method=“post” action=“https://bank.com/transfer”> <input type=“hidden” name=“to” value=“12345”> <input type=“hidden” name=“dollars” value=“1000000”> </form> <script>document.bad.submit()</script> HTTP/1.1 200 OK POST /transfer Cookie: SessionId=1234
102. Solution Synchronizer token pattern
105. Scenario #3 Bypassing CSRF protections with click-jacking and HTTP parameter pollution
106. Attacker Victim Bank
107. Attacker Victim Bank POST /login
108. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234
109. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html
110. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <iframe src=“https://bank.com/transfer? to=12345&dollars=1000000”>
111. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <iframe src=“https://bank.com/transfer? to=12345&dollars=1000000”> GET /transfer?to=… Cookie: SessionId=1234
112. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <iframe src=“https://bank.com/transfer? to=12345&dollars=1000000”> GET /transfer?to=… Cookie: SessionId=1234 HTTP/1.1 200 OK <form method=“post”> <input type=“text” name=“to” value=“”> <input type=“text” name=“dollars” value=“”> <input type=“hidden” name=“csrf” value=“a0d73b12”> </form>
113. Attacker Victim Bank POST /login HTTP/1.1 200 OK Set-Cookie: SessionId=1234 GET /index.html HTTP/1.1 200 OK <iframe src=“https://bank.com/transfer? to=12345&dollars=1000000”> GET /transfer?to=… Cookie: SessionId=1234 HTTP/1.1 200 OK <form method=“post”> <input type=“text” name=“to” value=“”> <input type=“text” name=“dollars” value=“”> <input type=“hidden” name=“csrf” value=“a0d73b12”> </form> POST /transfer?to=… via Clickjacking
115. Solution #1 Explicitly set the form action
117. Solution #2 Do not use query string params for user input
119. Solution #3 Use X-Frame-Options response header
122. • Injection • Broken Authentication and Session Management • Cross Site Scripting (XSS) • Cross Site Request Forgery (CSRF) • Using Components with Known Vulnerabilities
123. Using Components with Known Vulnerabilities
124. Component vulnerabilities can cause almost any type of risk imaginable
125. Almost always run with the full privilege of the application
126. Source: http://blog.modulus.io/growth-of-npm-infographic
128. npm install nsp -g
130. npm install grunt-nsp-package -g
133. npm install david -g
135. david -g
136. Other OWASP top 10 • Insecure Direct Object Reference • Security Misconfigurations • Sensitive Data Exposure • Missing Function Level Access Control • Unvalidated Redirects and Forwards
137. npm packages • express-session • bcrypt-nodejs • helmet (check out Lusca as well) • express-validator • csurf • nsp and grunt-nap-package • david
138. Further reading • https://www.owasp.org/index.php/Top_10_2013-Top_10 • http://en.wikipedia.org/wiki/Cross-site_scripting • http://en.wikipedia.org/wiki/Content_Security_Policy • http://en.wikipedia.org/wiki/Cross-site_request_forgery • https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
139. Thank you @scottksmith95 scottksmith.com