1
00:00:01,300 --> 00:00:04,156
‫Jadi, semua yang kami lakukan di bagian

2
00:00:04,156 --> 00:00:06,514
‫ini sejauh ini adalah

3
00:00:06,514 --> 00:00:10,320
‫mengamankan semua aplikasi dan data pengguna kami sebaik mungkin.

4
00:00:10,320 --> 00:00:12,290
‫Dan saya berbicara tentang banyak hal yang

5
00:00:12,290 --> 00:00:14,170
‫dapat kita lakukan untuk mencapai itu.

6
00:00:14,170 --> 00:00:16,430
‫Tapi semua informasi ini

7
00:00:16,430 --> 00:00:18,860
‫tersebar di seluruh kuliah ini.

8
00:00:18,860 --> 00:00:21,311
‫Jadi saya memutuskan untuk membuat ringkasan singkat

9
00:00:21,311 --> 00:00:24,717
‫ini dengan banyak praktik terbaik yang telah kami terapkan

10
00:00:24,717 --> 00:00:26,960
‫dan yang masih akan kami terapkan

11
00:00:26,960 --> 00:00:28,860
‫di sisa bagian ini.

12
00:00:28,860 --> 00:00:32,100
‫Karena keamanan sangat penting,

13
00:00:32,100 --> 00:00:36,010
‫tetapi sayangnya, banyak kursus tidak cukup membahasnya.

14
00:00:36,010 --> 00:00:37,490
‫Sekarang, saya juga

15
00:00:37,490 --> 00:00:40,660
‫tidak mengubah Node ini. js kursus menjadi kursus keamanan.

16
00:00:40,660 --> 00:00:44,170
‫Ada kursus dan ahli yang lebih baik untuk itu.

17
00:00:44,170 --> 00:00:46,490
‫Tetapi saya akan menunjukkan kepada Anda

18
00:00:46,490 --> 00:00:51,490
‫beberapa hal yang dapat Anda lakukan untuk mengamankan aplikasi dan data Anda dengan benar.

19
00:00:51,650 --> 00:00:54,200
‫Dan saya akan melihat beberapa serangan

20
00:00:54,200 --> 00:00:57,010
‫umum dan memberikan beberapa saran untuk mencegahnya.

21
00:00:57,010 --> 00:01:00,780
‫Dan pertama-tama, kami memiliki peristiwa database yang dikompromikan,

22
00:01:00,780 --> 00:01:04,980
‫yang berarti bahwa penyerang memperoleh akses ke database kami.

23
00:01:04,980 --> 00:01:07,970
‫Tentu saja, ini adalah masalah yang sangat parah, tetapi

24
00:01:07,970 --> 00:01:10,430
‫untuk mencegah masalah yang lebih besar,

25
00:01:10,430 --> 00:01:14,550
‫kita harus selalu mengenkripsi kata sandi dan token pengaturan ulang kata sandi

26
00:01:14,550 --> 00:01:17,660
‫seperti yang kita lakukan di video di bagian ini.

27
00:01:17,660 --> 00:01:19,800
‫Dengan cara ini, penyerang setidaknya

28
00:01:19,800 --> 00:01:24,320
‫tidak dapat mencuri kata sandi pengguna kami dan juga tidak dapat mengatur ulang.

29
00:01:24,320 --> 00:01:26,720
‫Sekarang, tentang benar-benar mencegah serangan, mari

30
00:01:26,720 --> 00:01:29,110
‫kita bicara tentang serangan brute force

31
00:01:29,110 --> 00:01:32,290
‫di mana penyerang pada dasarnya mencoba menebak kata

32
00:01:32,290 --> 00:01:35,660
‫sandi dengan mencoba jutaan kata sandi acak sampai

33
00:01:35,660 --> 00:01:37,850
‫mereka menemukan yang benar.

34
00:01:37,850 --> 00:01:42,160
‫Dan yang bisa kita lakukan adalah membuat permintaan login menjadi sangat lambat.

35
00:01:42,160 --> 00:01:44,586
‫Dan paket bcrypt yang

36
00:01:44,586 --> 00:01:47,020
‫kami gunakan sebenarnya melakukan hal itu.

37
00:01:47,020 --> 00:01:50,180
‫Strategi lain adalah menerapkan pembatasan tarif, yang

38
00:01:50,180 --> 00:01:52,340
‫membatasi jumlah permintaan yang

39
00:01:52,340 --> 00:01:54,640
‫datang dari satu IP tunggal.

40
00:01:54,640 --> 00:01:56,330
‫Dan yang satu ini akan

41
00:01:56,330 --> 00:01:58,460
‫kita terapkan di salah satu video berikutnya.

42
00:01:58,460 --> 00:02:01,690
‫Juga, strategi yang bagus adalah dengan

43
00:02:01,690 --> 00:02:05,470
‫benar-benar menerapkan jumlah maksimum upaya login untuk setiap pengguna.

44
00:02:05,470 --> 00:02:07,660
‫Sebagai contoh, kita dapat membuatnya

45
00:02:07,660 --> 00:02:10,540
‫sehingga setelah 10 kali percobaan gagal, pengguna

46
00:02:10,540 --> 00:02:14,020
‫harus menunggu satu jam sampai ia dapat mencoba lagi.

47
00:02:14,020 --> 00:02:16,360
‫Sekarang, saya tidak akan

48
00:02:16,360 --> 00:02:18,760
‫menerapkan fungsi ini di bagian

49
00:02:18,760 --> 00:02:21,340
‫ini, tetapi silakan bereksperimen sendiri.

50
00:02:21,340 --> 00:02:24,350
‫Ini mungkin pengalaman belajar yang sangat keren untuk

51
00:02:24,350 --> 00:02:26,120
‫membuat kode ini sendiri, dan

52
00:02:26,120 --> 00:02:27,890
‫sebenarnya tidak terlalu sulit.

53
00:02:27,890 --> 00:02:29,210
‫Baiklah.

54
00:02:29,210 --> 00:02:32,580
‫Selanjutnya, ada serangan skrip lintas situs, di

55
00:02:32,580 --> 00:02:34,020
‫mana penyerang

56
00:02:34,020 --> 00:02:38,430
‫mencoba menyuntikkan skrip ke halaman kami untuk menjalankan kode berbahayanya.

57
00:02:38,430 --> 00:02:41,280
‫Di sisi klien, ini sangat berbahaya

58
00:02:41,280 --> 00:02:44,810
‫karena memungkinkan penyerang membaca penyimpanan lokal, itulah

59
00:02:44,810 --> 00:02:46,500
‫alasan mengapa kita

60
00:02:46,500 --> 00:02:50,360
‫tidak boleh menyimpan token web JSON di penyimpanan lokal.

61
00:02:50,360 --> 00:02:54,110
‫Sebaliknya, itu harus disimpan dalam cookie khusus HTTP yang membuatnya

62
00:02:54,110 --> 00:02:55,950
‫sehingga browser hanya dapat

63
00:02:55,950 --> 00:02:58,110
‫menerima dan mengirim cookie tetapi

64
00:02:58,110 --> 00:03:01,400
‫tidak dapat mengakses atau memodifikasinya dengan cara apa pun.

65
00:03:01,400 --> 00:03:04,360
‫Jadi, hal itu membuat penyerang tidak

66
00:03:04,360 --> 00:03:08,460
‫mungkin mencuri token web JSON yang disimpan dalam cookie.

67
00:03:08,460 --> 00:03:11,590
‫Sekali lagi, kami menerapkan ini dalam hitungan detik.

68
00:03:11,590 --> 00:03:15,780
‫Sekarang, di sisi backend, untuk mencegah serangan XSS, kita harus

69
00:03:15,780 --> 00:03:18,170
‫membersihkan data input pengguna

70
00:03:18,170 --> 00:03:20,660
‫dan mengatur beberapa header HTTP khusus

71
00:03:20,660 --> 00:03:24,470
‫yang membuat serangan ini sedikit lebih sulit terjadi.

72
00:03:24,470 --> 00:03:27,040
‫Dan Express tidak datang dengan praktik terbaik

73
00:03:27,040 --> 00:03:29,560
‫ini, jadi kami akan menggunakan middleware untuk

74
00:03:29,560 --> 00:03:31,713
‫mengatur semua header khusus ini.

75
00:03:32,710 --> 00:03:35,620
‫Selanjutnya, kami memiliki serangan penolakan layanan.

76
00:03:35,620 --> 00:03:37,510
‫Dan mungkin Anda pernah mendengar tentang ini.

77
00:03:37,510 --> 00:03:39,330
‫Itu terjadi ketika

78
00:03:39,330 --> 00:03:42,600
‫penyerang mengirim begitu banyak permintaan ke server yang

79
00:03:42,600 --> 00:03:45,450
‫rusak dan aplikasi menjadi tidak tersedia.

80
00:03:45,450 --> 00:03:47,470
‫Sekali lagi, menerapkan pembatasan tingkat

81
00:03:47,470 --> 00:03:49,530
‫adalah solusi yang baik untuk ini.

82
00:03:49,530 --> 00:03:51,970
‫Selain itu, kami harus membatasi jumlah

83
00:03:51,970 --> 00:03:55,810
‫data yang dapat dikirim dalam badan di pos atau permintaan tambalan.

84
00:03:55,810 --> 00:03:57,950
‫Dan juga, kita harus menghindari menggunakan

85
00:03:57,950 --> 00:04:01,110
‫apa yang disebut ekspresi reguler jahat dalam kode kita.

86
00:04:01,110 --> 00:04:03,590
‫Dan ini hanyalah ekspresi reguler

87
00:04:03,590 --> 00:04:07,550
‫yang membutuhkan waktu eksponensial untuk dijalankan untuk input yang

88
00:04:07,550 --> 00:04:11,680
‫tidak cocok dan dapat dieksploitasi untuk menurunkan seluruh aplikasi kita.

89
00:04:11,680 --> 00:04:15,960
‫Oke, selanjutnya, kita memiliki serangan injeksi kueri NoSQL.

90
00:04:15,960 --> 00:04:18,510
‫Dan injeksi kueri terjadi ketika penyerang,

91
00:04:18,510 --> 00:04:22,240
‫alih-alih memasukkan data yang valid, menyuntikkan beberapa kueri untuk

92
00:04:22,240 --> 00:04:24,330
‫membuat ekspresi kueri

93
00:04:24,330 --> 00:04:26,600
‫yang akan diterjemahkan menjadi true.

94
00:04:26,600 --> 00:04:28,920
‫Misalnya, untuk masuk bahkan tanpa

95
00:04:28,920 --> 00:04:32,120
‫memberikan nama pengguna atau kata sandi yang valid.

96
00:04:32,120 --> 00:04:33,380
‫Ini agak rumit

97
00:04:33,380 --> 00:04:36,330
‫dan Anda harus mencarinya di Google untuk mempelajari lebih lanjut.

98
00:04:36,330 --> 00:04:38,940
‫Tetapi yang perlu Anda ketahui adalah bahwa menggunakan

99
00:04:38,940 --> 00:04:40,810
‫Mongoose sebenarnya adalah strategi

100
00:04:40,810 --> 00:04:43,300
‫yang cukup bagus untuk mencegah serangan semacam

101
00:04:43,300 --> 00:04:46,110
‫ini karena skema yang baik memaksa setiap nilai untuk

102
00:04:46,110 --> 00:04:48,410
‫memiliki tab data yang terdefinisi dengan baik.

103
00:04:48,410 --> 00:04:50,190
‫Yang kemudian secara efektif

104
00:04:50,190 --> 00:04:53,640
‫membuat serangan jenis ini sangat sulit untuk dieksekusi.

105
00:04:53,640 --> 00:04:56,000
‫Namun, itu selalu merupakan ide yang

106
00:04:56,000 --> 00:04:59,280
‫baik untuk tetap membersihkan data input, hanya untuk memastikan.

107
00:04:59,280 --> 00:05:02,300
‫Dan kami akan mengurusnya nanti.

108
00:05:02,300 --> 00:05:04,360
‫Baiklah, dan sekarang

109
00:05:04,360 --> 00:05:07,822
‫untuk menyelesaikannya, saya hanya memiliki beberapa praktik

110
00:05:07,822 --> 00:05:10,150
‫terbaik dan saran tentang cara

111
00:05:10,150 --> 00:05:14,009
‫meningkatkan mekanisme otentikasi dan otorisasi yang kami terapkan.

112
00:05:14,009 --> 00:05:16,350
‫Jadi, hal pertama

113
00:05:16,350 --> 00:05:18,760
‫yang harus saya ulangi

114
00:05:18,760 --> 00:05:21,370
‫berulang-ulang adalah bahwa dalam aplikasi

115
00:05:21,370 --> 00:05:24,310
‫produksi, semua komunikasi antara server dan

116
00:05:24,310 --> 00:05:26,980
‫klien perlu terjadi melalui HTTPS.

117
00:05:26,980 --> 00:05:30,010
‫Jika tidak, siapa pun dapat mendengarkan percakapan dan

118
00:05:30,010 --> 00:05:32,520
‫mencuri token web JSON kami.

119
00:05:32,520 --> 00:05:35,540
‫Selanjutnya, selalu buat token kata sandi acak.

120
00:05:35,540 --> 00:05:38,660
‫Tidak dihasilkan dari tanggal atau sesuatu seperti itu.

121
00:05:38,660 --> 00:05:40,920
‫Karena mereka adalah kata sandi yang

122
00:05:40,920 --> 00:05:43,470
‫efektif dan karenanya, mereka harus diperlakukan seperti itu.

123
00:05:43,470 --> 00:05:45,860
‫Plus, selalu beri mereka tanggal kedaluwarsa,

124
00:05:45,860 --> 00:05:47,750
‫seperti yang kami terapkan.

125
00:05:47,750 --> 00:05:48,910
‫Baiklah?

126
00:05:48,910 --> 00:05:52,340
‫Dan kami juga menerapkan bahwa token web

127
00:05:52,340 --> 00:05:56,480
‫JSON tertentu tidak lagi valid setelah pengguna mengubah kata sandinya.

128
00:05:56,480 --> 00:05:58,660
‫Jadi, pada dasarnya kami mencabut

129
00:05:58,660 --> 00:06:01,410
‫token segera setelah pengguna mengubah kata sandi.

130
00:06:01,410 --> 00:06:04,070
‫Yang sangat masuk akal, tetapi sekali

131
00:06:04,070 --> 00:06:07,650
‫lagi, banyak tutorial di luar sana tidak melakukan itu.

132
00:06:07,650 --> 00:06:10,470
‫Hal besar lainnya adalah jangan pernah

133
00:06:10,470 --> 00:06:14,060
‫melakukan file konfigurasi, seperti untuk variabel lingkungan, ke

134
00:06:14,060 --> 00:06:16,460
‫kontrol versi seperti Git.

135
00:06:16,460 --> 00:06:19,020
‫Bahkan, jangan mengunggahnya di mana pun

136
00:06:19,020 --> 00:06:20,500
‫karena file

137
00:06:20,500 --> 00:06:23,780
‫ini berisi data paling sensitif dari seluruh aplikasi.

138
00:06:23,780 --> 00:06:26,340
‫Misalnya, jika seseorang mendapatkan akses ke

139
00:06:26,340 --> 00:06:28,260
‫rahasia token web

140
00:06:28,260 --> 00:06:32,083
‫JSON Anda, maka seluruh proses autentikasi Anda akan terganggu.

141
00:06:32,083 --> 00:06:35,950
‫Oke, dan sekarang hanya detail kecil adalah setiap

142
00:06:35,950 --> 00:06:37,560
‫kali ada kesalahan,

143
00:06:37,560 --> 00:06:40,560
‫jangan kirim seluruh kesalahan ke klien.

144
00:06:40,560 --> 00:06:44,010
‫Jadi, hal-hal seperti pelacakan tumpukan dapat memberi penyerang

145
00:06:44,010 --> 00:06:46,920
‫beberapa wawasan berharga ke dalam sistem Anda,

146
00:06:46,920 --> 00:06:49,650
‫jadi, tentu saja, kami tidak menginginkannya.

147
00:06:49,650 --> 00:06:52,480
‫Selanjutnya, kita dapat menggunakan paket csurf

148
00:06:52,480 --> 00:06:57,200
‫untuk melawan jenis serangan yang disebut Cross-Site Request Forgery, yaitu

149
00:06:57,200 --> 00:06:59,750
‫serangan yang memaksa pengguna untuk melakukan

150
00:06:59,750 --> 00:07:03,530
‫tindakan yang tidak diinginkan pada aplikasi web tempat

151
00:07:03,530 --> 00:07:05,330
‫mereka sedang login.

152
00:07:05,330 --> 00:07:07,600
‫Kami tidak akan melakukannya di bagian ini.

153
00:07:07,600 --> 00:07:10,140
‫Tapi saya masih ingin menyebutkannya di sini.

154
00:07:10,140 --> 00:07:12,280
‫Selanjutnya, kami dapat meminta

155
00:07:12,280 --> 00:07:16,180
‫pengguna untuk mengautentikasi ulang sebelum melakukan tindakan bernilai tinggi.

156
00:07:16,180 --> 00:07:19,730
‫Misalnya, melakukan pembayaran atau menghapus sesuatu.

157
00:07:19,730 --> 00:07:22,070
‫Sekali lagi, ini hanya saran yang

158
00:07:22,070 --> 00:07:23,810
‫bisa Anda coba sendiri.

159
00:07:23,810 --> 00:07:26,630
‫Fitur keren lainnya yang dapat Anda

160
00:07:26,630 --> 00:07:29,460
‫terapkan adalah daftar hitam token yang tidak dipercaya.

161
00:07:29,460 --> 00:07:31,660
‫Jadi, kita sudah tahu bahwa

162
00:07:31,660 --> 00:07:34,910
‫sebenarnya tidak ada cara untuk mengeluarkan pengguna dari

163
00:07:34,910 --> 00:07:37,220
‫aplikasi jika mereka menunjukkan aktivitas jahat.

164
00:07:37,220 --> 00:07:41,260
‫Tapi yang bisa kita lakukan adalah membuat daftar token tidak

165
00:07:41,260 --> 00:07:44,370
‫tepercaya yang kemudian divalidasi pada setiap permintaan.

166
00:07:44,370 --> 00:07:47,920
‫Dan selanjutnya, fitur yang bisa kita terapkan

167
00:07:47,920 --> 00:07:51,810
‫adalah mengkonfirmasi alamat email setelah akun pertama kali dibuat.

168
00:07:51,810 --> 00:07:54,665
‫Jadi, pada dasarnya dengan mengirimkan tautan ke email

169
00:07:54,665 --> 00:07:57,520
‫pengguna, seperti yang dilakukan oleh banyak aplikasi nyata.

170
00:07:57,520 --> 00:08:00,190
‫Tapi saya ingin membuat semuanya sederhana di sini,

171
00:08:00,190 --> 00:08:02,600
‫itulah sebabnya saya tidak melakukannya di sini.

172
00:08:02,600 --> 00:08:05,400
‫Tapi jangan ragu untuk menerapkan ini

173
00:08:05,400 --> 00:08:07,360
‫sendiri jika Anda mau.

174
00:08:07,360 --> 00:08:09,900
‫Sekarang, fitur besar yang dimiliki

175
00:08:09,900 --> 00:08:12,580
‫banyak aplikasi adalah konsep token penyegaran.

176
00:08:12,580 --> 00:08:15,050
‫Yang pada dasarnya adalah untuk mengingat pengguna.

177
00:08:15,050 --> 00:08:17,150
‫Jadi, untuk membuat mereka tetap

178
00:08:17,150 --> 00:08:19,720
‫masuk selamanya atau sampai mereka memilih untuk keluar.

179
00:08:19,720 --> 00:08:22,170
‫Implementasi kami saat ini

180
00:08:22,170 --> 00:08:25,020
‫membuatnya sehingga pengguna pada dasarnya harus masuk

181
00:08:25,020 --> 00:08:27,480
‫lagi setelah token web JSON kedaluwarsa.

182
00:08:27,480 --> 00:08:30,720
‫Namun, dengan token penyegaran, itu tidak lagi diperlukan.

183
00:08:30,720 --> 00:08:33,490
‫Dan itu agak rumit untuk diterapkan dan, ini

184
00:08:33,490 --> 00:08:35,343
‫adalah fitur untuk lain waktu.

185
00:08:36,270 --> 00:08:37,950
‫Dan terakhir, yang

186
00:08:37,950 --> 00:08:41,530
‫terakhir yang bisa kita terapkan adalah otentikasi dua faktor, yang

187
00:08:41,530 --> 00:08:43,770
‫saya yakin Anda sudah familiar dengannya.

188
00:08:43,770 --> 00:08:46,079
‫Pada dasarnya, dengan otentikasi

189
00:08:46,079 --> 00:08:48,750
‫dua faktor, setelah masuk ke aplikasi,

190
00:08:48,750 --> 00:08:50,050
‫pengguna perlu

191
00:08:50,050 --> 00:08:53,110
‫melakukan tindakan kedua untuk benar-benar mendapatkan otentikasi.

192
00:08:53,110 --> 00:08:55,750
‫Dan biasanya, yaitu memasukkan kode

193
00:08:55,750 --> 00:08:58,980
‫yang dikirim melalui pesan teks ke ponsel.

194
00:08:58,980 --> 00:09:01,420
‫Jadi, ini adalah banyak fungsi yang

195
00:09:01,420 --> 00:09:03,580
‫dapat dimiliki oleh otentikasi kami.

196
00:09:03,580 --> 00:09:05,730
‫Dan jika Anda ingin saya menerapkannya,

197
00:09:05,730 --> 00:09:08,160
‫beri tahu saya di bagian Tanya Jawab.

198
00:09:08,160 --> 00:09:10,640
‫Dan, jika ada banyak permintaan untuk salah satunya,

199
00:09:10,640 --> 00:09:12,740
‫maka saya akan menunjukkan cara kerjanya.

200
00:09:12,740 --> 00:09:15,210
‫Oke, tapi sekali lagi, saya tidak ingin mengubah

201
00:09:15,210 --> 00:09:17,270
‫Node ini. kursus js

202
00:09:17,270 --> 00:09:20,760
‫menjadi kursus keamanan dan otentikasi secara keseluruhan.

203
00:09:20,760 --> 00:09:24,230
‫Dan sebagai penutup, sesuatu yang akan kita terapkan

204
00:09:24,230 --> 00:09:26,200
‫di sisa bagian ini

205
00:09:26,200 --> 00:09:28,320
‫adalah untuk mencegah polusi parameter.

206
00:09:28,320 --> 00:09:32,450
‫Misalnya, coba masukkan dua parameter bidang saja ke dalam

207
00:09:32,450 --> 00:09:36,030
‫string kueri yang menelusuri semua tur.

208
00:09:36,030 --> 00:09:38,290
‫Dan jika Anda melakukan itu, Anda akan

209
00:09:38,290 --> 00:09:39,770
‫menemukan bahwa akan ada

210
00:09:39,770 --> 00:09:42,150
‫kesalahan karena aplikasi kami tidak siap untuk itu.

211
00:09:42,150 --> 00:09:45,790
‫Jadi, penyerang mencoba menggunakan kelemahan semacam ini untuk membuat

212
00:09:45,790 --> 00:09:49,330
‫aplikasi crash, yang tentu saja tidak bagus.

213
00:09:49,330 --> 00:09:51,530
‫Jadi, kita perlu memperbaikinya.

214
00:09:51,530 --> 00:09:56,286
‫Oke, jadi ini ternyata jauh lebih lama dari yang saya harapkan.

215
00:09:56,286 --> 00:09:59,231
‫Dan ada banyak kursus tentang keamanan jika

216
00:09:59,231 --> 00:10:01,560
‫Anda benar-benar menyukai keamanan.

217
00:10:01,560 --> 00:10:04,074
‫Baiklah, tapi saya akan berhenti di

218
00:10:04,074 --> 00:10:07,283
‫sini, jadi, sekarang mari kita lanjutkan ke yang berikutnya.