forked from volkanin/inet_protocols_slides
-
Notifications
You must be signed in to change notification settings - Fork 0
/
11 WWW Auth.html
776 lines (600 loc) · 24.1 KB
/
11 WWW Auth.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
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/white.css">
<style type="text/css">.reveal p { text-align: left; }</style>
<style type="text/css">.reveal blockquote { font-size: 50%; }</style>
<style type="text/css">.reveal table { font-size: 70%; }</style>
<style type="text/css">.reveal p img { border: 0px; }</style>
<style type="text/css">.reveal p.small { font-size: 80%; }</style>
</head>
<body>
<div class="reveal">
<div class="slides">
<section data-markdown>
# Разграничение доступа в HTTP
Протоколы Интернет, лекция 11
</section>
<section data-markdown>
### План
> Секта Свидетелей Драматического Отличия Авторизации От Аутентификации
> И Их Обоих От Идентификации
* Как различать пользователей
* Cookie
* Ограничения доступа в HTTP
* Интеграция с внешними серверами
* weel-known URL
</section>
<section data-markdown>
### AAA
Общее название процессов, связанных с обеспечением защиты данных в информационных системах
* Identification (идентификация)
* Authentication (аутентификация)
- я знаю (пароль)
- я имею (токен)
- я есть (биометрия)
* Authorization (авторизация, проверка полномочий)
- субьект + операция + объект -> да/нет
* Accounting (учёт) + Audit
</section>
<section data-markdown>
## Cookies
</section>
<section data-markdown>
### Как готовить печеньки?
[wiki/HTTP_cookie](https://ru.wikipedia.org/wiki/HTTP_cookie#История)
* 1995 г, Netscape Communications
RFC 6265 – HTTP State Management Mechanism
Многие пользователи уверены (2005 г):
* куки, как вирусы, могут стереть данные
* куки являются причиной всплывающих окон
* куки используются для почтового спама
* куки используются только для рекламы
</section>
<section data-markdown>
### Обзор
Устанавливает сервер
```
S -> UA Set-Cookie: SID=31d4d96e407aad42
UA -> S Cookie: SID=31d4d96e407aad42
```
Ограничение по URL
```
S -> UA Set-Cookie: SID=31d4d96e407aad42;
Path=/admin; Domain=example.com
UA -> S Cookie: SID=31d4d96e407aad42
```
Сложение
```
S -> UA Set-Cookie: SID=31d4d96e407aad42;
Path=/admin; Secure; HttpOnly
S -> UA Set-Cookie: lang=en-US; Path=/
UA -> S Cookie: SID=31d4d96e407aad42; lang=en-US
```
</section>
<section data-markdown>
### Set-Cookie
[Set-Cookie](https://developer.mozilla.org/ru/docs/Web/HTTP/Заголовки/Set-Cookie): имя=значение; атрибуты
* Expires = Sun, 01 Jan 1970 00:0:00 GMT
* Max-Age = TTL в секундах
* Domain = example.com
- включает поддомены (www.example.com)
- UA примет куки для example.com с сервера www.example.com
- игнорируются куки для TLD-доменов
* Path = путь
- если нет, Path = каталог Request URI
* Secure, HttpOnly
</section>
<section data-markdown>
### Cookie
Cookie: имя=значение; имя=значение
* Порядок пар не определён
* Набор зависит от http/https и Secure
* Отправляются только не устаревшие куки
Домен приводится к «каноническому» виду,
путь – «поглощающий»
Небольшой размер -
4096 байт на cookie (имя+значение+атрибуты),
по крайней мере 50 cookies на домен,
по крайней мере 3000 cookies всего
</section>
<section data-markdown>
### Зачем и как использовать
В пределах домена
* http-сессия (связанные запросы)
* сохраняемые на клиенте данные (корзина)
- сейчас есть API localStorage
```
<?php session_start();
if (!isset($_SESSION['time'])) {
$_SESSION['time'] = date("H:i:s");
}
echo $_SESSION['time'];
```
```
Set-Cookie: PHPSESSID=dap83arr6r3b56e0q7t5i0qf91; path=/
```
</section>
<section data-markdown>
### Авторизационная кука
Ввели на сайте логин-пароль один раз, сервер установил Cookie
При повторном открытии сайта нас уже знают
* примеры - почта, VK, и т.д.
* в профиле обычно есть список сеансов
Проблемы
* можно украсть
* CSRF (подделка HTTP-запросов)
</section>
<section data-markdown>
### Cross-Site Request Forgery
Уязвимость «подделка HTTP-запросов»
* вид атаки, использующий функцию браузера по автоматической отправке идентификатора сессии с каждым GET/POST-запросом к веб-приложению
Сложности при автоматизированном обнаружении, однако эта ошибка встречается во многих веб-приложениях
</section>
<section data-markdown>
### CSRF: как это работает
Пусть наш банк имеет API :) http://example.com/app/transferFunds?amount=1500&destAccount=12345
Разместим где-нибудь картинку ... PROFIT !
```
<img src="http://example.com/app/transferFunds?
amount=1500&destAccount=12345"/>
```
А можно просто «от имени пользователя» голосовать ВКонтакте
Читали историю «The Spider of Doom»?
www.thedailywtf.com/articles/The_Spider_of_Doom
</section>
<section data-markdown>
### CSRF: как бороться?
Уникальный непредсказуемый токен в каждом HTTP-запросе
в скрытом поле формы, CMS часто автоматически включают в URL
Привязка cookie к IP/браузеру и др.
Требование повторной аутентификации при подозрениях, и CAPTCHA
[OWASP/CSRF_Prevention_Cheat_Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
> Верить в наше время нельзя никому, порой даже самому себе (Мюллер)
</section>
<section data-markdown>
### Cookie: как использовать
За пределами домена - счётчик, сервисы «Яндекс.Вебмастер», «Google Analytics»
</section>
<section data-markdown>
### Cookie и приватность
[Директивы Евросоюза](https://www.cookiechoices.org/intl/ru/)
Хранение данных (в том числе cookie) может осуществляться если:
* пользователю предоставляется информация, как эти данные используются
* пользователь имеет возможность отказаться от этого
</section>
<section data-markdown>
## Проверка подлинности в HTTP
</section>
<section data-markdown>
### Аутентификация
RFC 7235 Hypertext Transfer Protocol: Authentication
Схемы проверки подлинности
Встроенные в протокол
* RFC 2617 - Basic и Digest
* RFC 4559 - Negotiate (не рекомендуется)
Внешние
* RFC 5849 - OAuth
* RFC 6749 - OAuth 2.0
* OpenID, OopenID Connect
</section>
<section data-markdown>
### Challenge / Response
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="simple"
Newauth realm="admin", type=1,
title="Login to \"admin\"",
```
```
GET /protected/ HTTP/1.1
Authorization: схема реквизиты_доступа
```
Аналогично
```
HTTP/1.1 407 Proxy Authentication Required
```
</section>
<section data-markdown>
### Схема Basic
Применять только через https !
```
WWW-Authenticate: Basic realm="admin"
```
Строка из Realm обычно показывается пользователю
```
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
```
Base64 (Aladdin:open sesame)
Клиент автоматически отправит заголовок Authorization, если код 401 и совпадает домен и realm
</section>
<section data-markdown>
### Схема Digest
```
WWW-Authenticate: Digest digest-challenge
```
```
digest-challenge = realm [domain] nonce [opaque]
[stale] [algorithm] [qop-options] [auth-param]
```
В простейшем случае («качество защиты» QoP не определено)
$$ 𝐻𝐴1=𝑀𝐷5(𝐴1)=𝑀𝐷5(𝑢𝑠𝑒𝑟𝑛𝑎𝑚𝑒:𝑟𝑒𝑎𝑙𝑚:𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) $$
$$ 𝐻𝐴2=𝑀𝐷5(𝐴2)=𝑀𝐷5(𝑚𝑒𝑡ℎ𝑜𝑑:𝑑𝑖𝑔𝑒𝑠𝑡𝑈𝑅𝐼) $$
$$ 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒=𝑀𝐷5(𝐻𝐴1:𝑛𝑜𝑛𝑐𝑒:𝐻𝐴2) $$
</section>
<section data-markdown>
### Схема Digest
```
digest-challenge = realm [domain] nonce [opaque]
[stale] [algorithm] [qop-options] [auth-param]
```
Если QoP = auth-int
$$ 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒=𝑀𝐷5(𝐻𝐴1:𝑛𝑜𝑛𝑐𝑒:𝑛𝑜𝑛𝑐𝑒𝐶𝑜𝑢𝑛𝑡: $$ $$ 𝑐𝑙𝑖𝑒𝑛𝑡𝑁𝑜𝑛𝑐𝑒:𝑞𝑜𝑝:𝐻𝐴2)$$
</section>
<section data-markdown>
### Схема Digest
```
GET /dir/index.html HTTP/1.1
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="[email protected]",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41“
GET /dir/index.html HTTP/1.1
Authorization: Digest username="Mufasa",
realm="[email protected]",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
```
</section>
<section data-markdown>
### Возможные атаки
Replay Attacks
* nonce может основываться на IP клиента, дате, Etag и private server key
Man in the Middle
* Например, прокси может оставить только Basic-проверку
Dictionary / Rainbow tables / Brute force
Не храним пароль в plaint text ?
</section>
<section data-markdown>
## Внешние сервисы
</section>
<section data-markdown>
 традиционно
 внешний сервис
</section>
<section data-markdown>
### OpenID
Стандарт децентрализованной системы аутентификации
* OpenID 1.1
* OpenID 2.0
* OpenID Connect
[OpenId Specifications](openid.net/developers/specs),
[Google/identity](developers.google.com/identity)
</section>
<section data-markdown>
### OAuth
Протокол авторизации, позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам без необходимости передавать ей (третьей стороне) логин и пароль
Результат авторизации - access token (набор символов), предъявление которого является пропуском к защищенным ресурсам
Обращение к ним по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token
</section>
<section data-markdown>
### OAuth
Далее под Oauth понимается версия 2
[RFC 6749](https://tools.ietf.org/html/rfc6749) OAuth 2.0 Framework
[RFC 8252](https://tools.ietf.org/html/rfc8252) OAuth 2.0 for Native Apps
Список стандартов - [oauth.net/2](https://oauth.net/2/)
Примеры:
* [yandex.ru/dev/passport](https://yandex.ru/dev/passport/)
* [vk.com/dev/access_token](https://vk.com/dev/access_token)
Note:
https://habr.com/ru/post/115163/
</section>
<section data-markdown>
### Роли OAuth
OAuth определяет четыре роли
* Владелец ресурса - пользователь
* Клиент - приложение
- доступ приложения ограничен областью видимости (scope)
* Сервер ресурсов, Resource Server (Provider)
- предоставляет API
* Авторизационный сервер
- часто совпадает с сервером ресурсов
</section>
<section data-markdown>
</section>
<section data-markdown>
### Регистрация приложения
Перед использованием OAuth нужно зарегистрировать приложение в сервисе (RS, AS),
присвоить client ID, иногда client secret
* Название приложения
* Сайт приложения
* Redirect URL / Callback URL
- сервис перенаправляет пользователя после авторизации (или отказа в авторизации) вашего приложения
</section>
<section data-markdown>
### Области видимости
Scope - набор действий и объектов
OAuth не фиксирует состав действий и названия
Примеры
* [Slack](https://api.slack.com/scopes)
- chat:write, dnd:read, groups:history и т.д.
* [Github](https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/)
- repo:status, write:public_key и т.д.
* [FitBit](https://dev.fitbit.com/build/reference/web-api/oauth2/#scope)
- activity, heartrate, location и т.д.
</section>
<section data-markdown>
### Схемы авторизации
* Authorization Code / Code Flow
- для приложений c серверной частью
* [PKCE](https://tools.ietf.org/html/rfc7636), Proof Key for Code Exchange
* Client Credentials
* Device Code
* Refresh Token
- обновление предыдущей авторизации
* Legacy: Implicit Flow
- для полностью клиентских приложений
* Legacy: Password Grant
- по логину и паролю
</section>
<section data-markdown>
### Authorization Code / Code Flow
Самый частый тип разрешения на авторизацию
Хорошо подходит для серверных приложений, где исходный код приложения и секрет клиента не доступны посторонним
Процесс строится на перенаправлении (redirection), HTTP 3xx
Предполагается, что приложение в состоянии взаимодействовать с UA (браузером)
и получать коды авторизации API, «слушая» Redirect URL
</section>
<section data-markdown>
</section>
<section data-markdown>
### Code Flow (шаги 1-3)
Эти операции - на клиенте,
scope в примере - некий по умолчанию
```
GET /oauth/authorize?response_type=code&client_id=464119
&redirect_uri=http%3A%2F%2Fexample.com%2Fu123%2F HTTP/1.1
Host: connect.mail.ru
```
Допустимые redirect_uri - в настройках
```
HTTP/1.1 302 Found
Location: http://example.com/u123/?code=DoRieb0y
```
уникальный ID против CSRF-атак - u123
</section>
<section data-markdown>
### Code Flow (шаги 4,5)
Эти операции - на сервере
```
POST /oauth/token HTTP/1.1
Host: connect.mail.ru
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=464119&client_secret=xxx&
code=DoRieb0y&redirect_uri=http%3A%2F%2Fexample.com%2Fu123
```
```
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token":"SlAV32hkKG",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8",
}
```
[Bearer Token](https://tools.ietf.org/html/rfc6750), «на предъявителя» / MAC Token
</section>
<section data-markdown>
### использование токена
```
GET /platform/api?oauth_token=SlAV32hkKG&
client_id=464119&format=json&
method=users.getInfo&sig=... HTTP/1.1
Host: appsmail.ru
```
Сервер ресурсов сверяет
* срок действия токена
* допустимость операции (соответствие scope)
Токен может передаваться в заголовках, не в URL
</section>
<section data-markdown>
### Зачем Refresh Token
* access token - при запросах к серверу
- многоразовый и короткоживущий
* refresh token - обновление access и refresh
- одноразовый и долгоживущий
Схема refresh + access ограничивает время, на которое атакующий может получить доступ
Случай 1: Боб узнал оба токена Алисы и не воспользовался refresh
Случай 2: Боб узнал оба токена Алисы и воспользовался refresh
</section>
<section data-markdown>
### Implicit Flow
Полностью клиентские приложения
Открытие браузера со страницей авторизации
* у пользователя запрашивается подтверждение выдачи прав
* в случае согласия пользователя, браузер редиректится на страницу-заглушку
- в URL после # пишется access token
- приложение перехватывает редирект и получает из адреса страницы access token
</section>
<section data-markdown>
</section>
<section data-markdown>
### Implicit Flow (шаги 1-3)
Запрос отличается параметром response_type
```
GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1
Host: connect.mail.ru
```
Если нет redirect_uri, используется «стандартный»
```
HTTP/1.1 302 Found
Location: http://connect.mail.ru/oauth/success.html
#access_token=FJQbwq9&token_type=bearer&
expires_in=3600&refresh_token=yaeFa0gu
```
</section>
<section data-markdown>
### OpenId Connect
Принципиально отличается от OpenId версий 1/2
[openid.net/connect](https://openid.net/connect/)
Надстройка над OAuth, описаны API и scope
API включает
* Authorization endpoint
* Token Endpoint
* Userinfo Endpoint
* CheckId Endpoint (необязательно)
* Registration Endpoint (необязательно)
</section>
<section data-markdown>
### Поиск настроек OpenId
Получение общей информации об источнике (site-wide metadata)
Ранние аналоги - [robots.txt](http://www.robotstxt.org/), метод [PROPFIND](https://tools.ietf.org/html/rfc4918)
[RFC 8615](https://tools.ietf.org/html/rfc8615) Well-Known Uniform Resource Identifiers
[iana.org/assignments/well-known-uris](https://www.iana.org/assignments/well-known-uris/)
* /.well-known/acme-challenge
* /.well-known/caldav
* /.well-known/openid-configuration
* /.well-known/webfinger
</section>
<section data-markdown>
### WebFinger
По необходимости (если известен только логин/email)
используем WebFinger,
[RFC 7033](https://tools.ietf.org/html/rfc7033)
```
GET /.well-known/webfinger?resource=acct%3Ajoe%40example.com&
rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1
Host: example.com
```
```
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "acct:[email protected]",
"links":
[{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://server.example.com"
}]
}
```
</section>
<section data-markdown>
### openid-configuration
Далее - запрос к эмитенту
```
GET /.well-known/openid-configuration HTTP/1.1
Host: server.example.com
```
Получаем файл конфигурации
```
{
"authorization_endpoint": "https://server.example.com/connect/authorize",
"issuer" : "https://server.example.com",
"token_endpoint": "https://server.example.com/connect/token",
"token_endpoint_auth_types_supported":["client_secret_basic", "private_key_jwt"],
"userinfo_endpoint": "https://server.example.com/connect/user",
"check_id_endpoint": "https://server.example.com/connect/check_id",
"registration_endpoint": "https://server.example.com/connect/register"
}
```
</section>
<section data-markdown>
### особенности OIDC
id_token - новый тип токена
* Implicit: response_type=id_token (id_token%20token)
* Code: grant_type=id_token (id_token%20token)
```
GET /authorize?grant_type=token%20id_token&scope=openid%20profile&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
```
</section>
<section data-markdown>
### OpenId scope
Обязательный scope=openid
* в ответе будет поле sub (Subject Identifier)
Дополнительные
* profile = name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.
* email
* phone
</section>
<section data-markdown>
### JSON Web Token
Ответный токен закодирован в формате JWT (JSON Web Token), [RFC 7519](https://tools.ietf.org/html/rfc7519)
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
```
Первая часть - заголовок, закодирован Base64url
```
{ "alg": "HS256", "typ": "JWT"}
```
Вторая часть - полезная нагрузка (Payload)
```
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
```
Третья часть - цифровая подпись (здесь - HS256)
</section>
<section data-markdown>
### UserInfo
Пример запроса вручную
```
curl -v -H 'Authorization: bearer ТОКЕН'
https://auth.usaaa.ru/auth/realms/master/protocol/openid-connect/userinfo
```
```
{
"sub":"f:a1785221-ee0b-4fc9-9c43-627b2a05d19e:Волканин Леонид Сергеевич",
"email_verified":true,
"name":"Леонид Волканин",
"preferred_username":"volkanin",
"given_name":"Леонид",
"family_name":"Волканин",
"email":"[email protected]"
}
```
</section>
<section data-markdown>
# Вопросы ?
</section>
</div>
</div>
<script src="js/reveal.js"></script>
<script>
Reveal.initialize({
hash: true,
slideNumber: true,
center: false,
dependencies: [
{ src: 'plugin/markdown/marked.js' },
{ src: 'plugin/markdown/markdown.js' },
{ src: 'plugin/math/math.js', async: true },
{ src: 'plugin/notes/notes.js', async: true },
{ src: 'plugin/highlight/highlight.js', async: true }
]
});
</script>
</body>
</html>