-
Notifications
You must be signed in to change notification settings - Fork 35
/
Copy pathindex.html
253 lines (236 loc) · 16.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
<!DOCTYPE html>
<html lang="en">
<head>
<!-- Required meta tags -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<!-- Bootstrap CSS -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/css/bootstrap.min.css" integrity="sha384-rwoIResjU2yc3z8GV/NPeZWAv56rSmLldC3R/AZzGRnGxQQKnKkoFVhFQhNUwEyJ"
crossorigin="anonymous">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/vs2015.min.css">
<link rel="stylesheet" href="../common/css/style.css">
</head>
<body>
<div class="container">
<div class="row">
<div class="col">
<p class="text-center header-text bold">Application Security and Hardening</p>
<p class="text-center header-text">Geekwise Academy</p>
<br>
<p class="text-center header-subtext italic">Week 7 - Refresh Tokens, Roles, and Session Hijacking</p>
<br>
<p class="text-center header-subtext bold">Instructors:</p>
<p class="text-center header-subtext">Corey Shuman</p>
<p class="text-center header-subtext ta-name-full"></p>
<br>
<p class="text-center header-subtext bold">Slack Channel:</p>
<p class="text-center header-subtext"><a href="https://geekwise.slack.com/messages/C8SHHJQLU/">#application-security</a></p>
<p class="text-center header-subtext bold">Github Repo:</p>
<p class="text-center header-subtext"><a href="https://github.com/coreyshuman/GeekwiseApplicationSecurity">https://github.com/coreyshuman/GeekwiseApplicationSecurity</a></p>
<p class="text-center header-subtext bold">Lecture Notes:</p>
<p class="text-center header-subtext"><a href="http://coreyshuman.github.io/GeekwiseApplicationSecurity/LectureNotes">http://coreyshuman.github.io/GeekwiseApplicationSecurity/LectureNotes</a></p>
<hr><br>
</div>
</div>
<div class="row">
<div class="col">
<p class="header-subtext bold">Table of Contents:</p>
<ul id="table-of-contents"></ul>
<hr><br>
</div>
</div>
<div class="row">
<div class="col">
<h1>Thinking Critically - Some Security Articles</h1>
<h2>Article 1: Four Security Principles that Software Developers Should Follow</h2>
<p>[Article Link](https://dev.to/robdwaller/four-security-principles-that-software-developers-should-follow-24gi)</p>
<div class="outline">
<h3>Discussion: 4 Principles</h3>
<p>
<ul>
<li>Avoiding dogma and absolutism</li>
<li>"There is no such thing as security"</li>
<li>Understanding the threats</li>
<li>Implementing a proportionate solution</li>
</ul>
</p>
</div>
<h2>Article 2: Please Stop Using Local Storage</h2>
<p>[Article Link](https://dev.to/rdegges/please-stop-using-local-storage-1i04)</p>
<p>While this article goes against item 1 from our previous article (and was specifically called out for it), it is
a thought-provoking read. Now I certainly don't agree with the absolutist idea to abolish using Local Storage.
Angular recommends Local Storage as a potential place to [store tokens](https://blog.angular-university.io/angular-jwt-authentication/),
for example. But after reading this article, I decided we could better with our secure application.
</p>
<div class="outline">
<h3>Discussion: How can we harden our token storage?</h3>
</div>
<h1>Session Hijacking</h1>
<p>Let's look at why Local Storage could be a bad place for an access token. [Session Hijacking](https://www.owasp.org/index.php/Session_hijacking_attack)
is a type of attack where a malicious attacker is able steal or predict the session token to gain unauthorized
access to a Web Server. Common ways in which a session token could be compromised include:
</p>
<p>
<ul>
<li>Physical access to the machine</li>
<li>Predictable session token</li>
<li>Session Sniffing</li>
<li>Client-side attacks (XSS, malicous JS code, computer viruses, etc)</li>
<li>[Man-in-the-middle attack](https://www.owasp.org/index.php/Man-in-the-middle_attack)</li>
<li>[Man-in-the-browser attack](https://www.owasp.org/index.php/Man-in-the-browser_attack)</li>
</ul>
</p>
<p>For example, an external resource (such as jQuery from a CDN) could be hijacked and turned malicious, sending all
Local Storage variables to an attacker.</p>
<h1>Refresh Tokens</h1>
<p>[Auth0: Refresh Tokens](https://auth0.com/learn/refresh-tokens/)</p>
<p>A Refresh Token is a special kind of token that can be used to obtain a renewed access token —that allows accessing
a protected resource— at any time. You can request new access tokens until the refresh token is blacklisted.
Refresh tokens must be stored securely by an application because they essentially allow a user to remain authenticated
forever.
</p>
<p>Here is the document I used to help me implement Refresh Tokens in our application: [Medium: Using Refresh Tokens](https://medium.com/hyphe/using-refresh-tokens-in-node-to-stay-authenticated-ad0c9d2b444f)
</p>
<h1>Security Stamp / Token Invalidation</h1>
<p>A security stamp is a piece of data used to verify and invalidate access tokens. It in used in the ASP.NET Identity
library. While I haven't seen it used by anyone else in NodeJS projects, I've started including it in my JWT
projects as a mechanism to invalidate old tokens. Similar to ASP.NET, I like to use a snapshot of the user's
credentials as the payload of this data. As a result, any time the user's credentials or access level changes,
the current tokens are invalidated.
</p>
<p>Security stamps also give you the ability to "log out everywhere" in your application.</p>
<h1>Cross-Origin Resource Sharing (CORS)</h1>
<p>[OWASP: Testing CORS](https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007))</p>
<p></p>
<p>[OWASP CORS Security Cheat Sheet](https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Cross_Origin_Resource_Sharing):</p>
<p>Cross Origin Resource Sharing (CORS) is a mechanism that allows browsers to support "cross-domain" requests in
a controlled, more secure manner. Starting with the XMLHttpRequest L2 API, browsers have gained the ability to
send requests to cross origins. CORS defines the protocol used between a web browser and a server to determine
whether a cross-orign request is allowed. It is important to note that CORS only affects how the <em>browser</em> behaves. It does not have any effect on what or who the server will respond or send data to.
</p>
<p>The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests
that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will
have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and
if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request
is allowed or not.</p>
<h2>CORS Headers</h2>
<p>CORS is defined using a series of headers sent in both the request and the response:</p>
<h3>Origin Access-Control-Allow-Origin</h3>
<p>The `Origin` header is always sent by the browser in a CORS request and indicates the origin of the request. The
`Origin` header can not be changed from JavaScript however relying on this header for Access Control checks is
not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols
are used to protect sensitive data.</p>
<p>`Access-Control-Allow-Origin` is a response header used by a server to indicate which domains are allowed to read
the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction
of whether the client has access to the response data based on this header.</p>
<p>From a penetration testing perspective you should look for insecure configurations as for example using a `*` wildcard
as value of the `Access-Control-Allow-Origin` header that means all domains are allowed. Other insecure example
is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive
data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case
of a public API that is intended to be accessible by everyone.</p>
<h3>Access-Control-Request-Method & Access-Control-Allow-Method</h3>
<p>The `Access-Control-Request-Method` header is used when a browser performs a preflight `OPTIONS` request and let
the client indicate the request method of the final request. On the other hand, the `Access-Control-Allow-Method`
is a response header used by the server to describe the methods the clients are allowed to use.</p>
<h3>Access-Control-Request-Headers & Access-Control-Allow-Headers</h3>
<p>These two headers are used between the browser and the server to determine which headers can be used to perform
a cross-origin request.</p>
<h3>Access-Control-Allow-Credentials</h3>
<p>This header as part of a preflight request indicates that the final request can include user credentials.</p>
<p>
<ul>
<li>Validate URLs passed to `XMLHttpRequest.open`. Current browsers allow these URLs to be cross domain; this behavior
can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.</li>
<li>Ensure that URLs responding with `Access-Control-Allow-Origin: *` do not include any sensitive content or information
that might aid attacker in further attacks. Use the `Access-Control-Allow-Origin` header only on chosen URLs
that need to be accessed cross-domain. Don't use the header for the whole domain.</li>
<li>Allow only selected, trusted domains in the `Access-Control-Allow-Origin` header. Prefer whitelisting domains
over blacklisting or allowing any domain (do not use `*` wildcard nor blindly return the `Origin` header
content without any checks).</li>
<li>Keep in mind that CORS does not prevent the requested data from going to an unauthenticated location. It's
still important for the server to perform usual CSRF prevention.</li>
<li>While the RFC recommends a pre-flight request with the `OPTIONS` verb, current implementations might not perform
this request, so it's important that "ordinary" (`GET` and `POST`) requests perform any access control necessary.</li>
<li>Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.</li>
<li>Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests,
but may be spoofed outside the browser. Application-level protocols should be used to protect sensitive data.</li>
</ul>
</p>
<p>View the OWASP link at the beginning of this section for examples of insecure/ vulnerable JavaScript code.</p>
<h1>Roles and Access Level</h1>
<p>In this class we will look at an approach to restricting system access called <em>role-based access control (RBAC)</em>.
An RBAC system is built around relationships between users, roles, and permissions. A user can have one or more
roles, and a role can allow one or more permissions. This system allows for simple user assignment, while being
flexible enough to support thousands of users and permissions.</p>
<p>In the table below, we see the simplified and actual structure of our roles system in the database. Each user can
have multiple roles, while each role belongs to multiple users. We call this a [many-to-many relationship](https://en.wikipedia.org/wiki/Many-to-many_(data_model)).
The roles and permission share a similar structure.
</p>
<p>To create this type of structure in our database, we need a way to associate our many users to many roles, and
many roles to many permissions. To do this, we use [associative tables](https://en.wikipedia.org/wiki/Associative_entity)
or *linking tables*.
</p>
<img src="../common/images/UserRoles.svg">
<p>For an example, a user could have the roles `subscriber` and `publisher`. The `subscriber` role could give them
access to the `view` method, while the `publisher` role could give them access to the `create`, `edit`, and `delete`
methods.
</p>
<div class="outline">
<h1>Assigned Reading: Angular JWT Authentication</h1>
<p>[Angular University: Angular JWT Authentication](https://blog.angular-university.io/angular-jwt-authentication/)</p>
</div>
<div class="outline">
<h1>Homework: Implement Permissions</h1>
<p>Using the existing User, Role, and Permission tables, accomplish the following:</p>
<p>
<ul>
<li>Validate the `GET /post` action against the user's permissions</li>
<li>If the user has the matching permission from the Permission's table, the server can return the posts</li>
<li>If the user does not have the permission, return a 403 status</li>
<li>Hint: The `GET /post` permission is tied to the `subscriber` role</li>
<li>Hint: The user's roles and permissions can be found in the JWT Token (access token)</li>
</ul>
</p>
</div>
</div>
<!-- End Col-->
</div>
<div class="row">
<div class="col">
<br>
<hr>
<h1 class="header-subtext bold">Resources</h1>
<ul id="resources"></ul>
</div>
</div>
</div>
<!--Footer-->
<br><br>
<footer class="page-footer">
<div style="background-color: #b9b9b9;">
<!-- Copyright-->
<div class="footer-copyright">
<div class="container-fluid text-center">
© 2017 -
<script type="text/javascript">
document.write(new Date().getFullYear());
</script>
<a href="https://geekwiseacademy.com">Geekwise Academy</a> & <a href="http://coreyshuman.com">Corey Shuman</a>
</div>
</div>
<!--/.Copyright -->
</div>
</footer>
<!--/.Footer-->
<!-- jQuery first, then Tether, then Bootstrap JS. -->
<script src="https://code.jquery.com/jquery-3.1.1.slim.min.js" integrity="sha384-A7FZj7v+d/sdmMqp/nOQwliLvUsJfDHW+k9Omg/a/EheAdgtzNs3hpfag6Ed950n"
crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/tether/1.4.0/js/tether.min.js" integrity="sha384-DztdAPBWPRXSA/3eYEEUWrWCy7G5KFbe8fFjk5JAIxUYHKkDx6Qin1DkWx51bBrb"
crossorigin="anonymous"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/js/bootstrap.min.js" integrity="sha384-vBWWzlZJ8ea9aCX4pEW3rVHjgjt7zpkNpZk+02D9phzyeVkE+jo0ieGizqPLForn"
crossorigin="anonymous"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
<script src="../common/js/scripts.js"></script>
<script src="../common/js/ta-name.js"></script>
</body>
</html>