1 00:00:01,300 --> 00:00:04,156 ‫Alles, was wir in diesem Abschnitt bisher getan 2 00:00:04,156 --> 00:00:06,514 ‫haben, war also, alle Anwendungen 3 00:00:06,514 --> 00:00:10,320 ‫und die Daten unserer Benutzer so gut wie möglich zu sichern. 4 00:00:10,320 --> 00:00:12,290 ‫Und ich habe über viele Dinge gesprochen, die 5 00:00:12,290 --> 00:00:14,170 ‫wir tun können, um das zu erreichen. 6 00:00:14,170 --> 00:00:16,430 ‫Aber all diese Informationen 7 00:00:16,430 --> 00:00:18,860 ‫waren über diese Vorlesungen verteilt. 8 00:00:18,860 --> 00:00:21,311 ‫Daher habe ich beschlossen, diese kurze Zusammenfassung 9 00:00:21,311 --> 00:00:24,717 ‫mit vielen bewährten Methoden zu erstellen, die wir bereits implementiert 10 00:00:24,717 --> 00:00:26,960 ‫haben und die wir im Rest 11 00:00:26,960 --> 00:00:28,860 ‫dieses Abschnitts noch implementieren werden. 12 00:00:28,860 --> 00:00:32,100 ‫Weil Sicherheit so extrem wichtig ist, 13 00:00:32,100 --> 00:00:36,010 ‫aber leider viele Kurse nicht genug darauf eingehen. 14 00:00:36,010 --> 00:00:37,490 ‫Jetzt drehe ich 15 00:00:37,490 --> 00:00:40,660 ‫diesen Node auch nicht. js-Kurs in einen Sicherheitskurs. 16 00:00:40,660 --> 00:00:44,170 ‫Dafür gibt es bessere Kurse und Experten. 17 00:00:44,170 --> 00:00:46,490 ‫Aber ich zeige Ihnen ein paar 18 00:00:46,490 --> 00:00:51,490 ‫Dinge, die Sie tun können, um Ihre Anwendungen und Daten richtig zu sichern. 19 00:00:51,650 --> 00:00:54,200 ‫Und ich werde mir ein paar gängige Angriffe 20 00:00:54,200 --> 00:00:57,010 ‫ansehen und einige Vorschläge machen, um sie zu verhindern. 21 00:00:57,010 --> 00:01:00,780 ‫Und als erstes haben wir den Fall einer kompromittierten 22 00:01:00,780 --> 00:01:04,980 ‫Datenbank, dh ein Angreifer hat sich Zugriff auf unsere Datenbank verschafft. 23 00:01:04,980 --> 00:01:07,970 ‫Dies ist natürlich ein äußerst schwerwiegendes Problem, aber 24 00:01:07,970 --> 00:01:10,430 ‫um noch größere Probleme zu vermeiden, 25 00:01:10,430 --> 00:01:14,550 ‫müssen wir Passwörter und Passwort-Reset-Token immer verschlüsseln, genau wie wir es 26 00:01:14,550 --> 00:01:17,660 ‫in den Videos in diesem Abschnitt getan haben. 27 00:01:17,660 --> 00:01:19,800 ‫Auf diese Weise kann der 28 00:01:19,800 --> 00:01:24,320 ‫Angreifer nicht zumindest die Passwörter unserer Benutzer stehlen und auch nicht zurücksetzen. 29 00:01:24,320 --> 00:01:26,720 ‫Kommen wir nun zum eigentlichen Verhindern von 30 00:01:26,720 --> 00:01:29,110 ‫Angriffen, sprechen wir über den Brute-Force-Angriff, 31 00:01:29,110 --> 00:01:32,290 ‫bei dem der Angreifer im Grunde versucht, ein Passwort 32 00:01:32,290 --> 00:01:35,660 ‫zu erraten, indem er Millionen und Abermillionen zufälliger Passwörter ausprobiert, 33 00:01:35,660 --> 00:01:37,850 ‫bis er das richtige findet. 34 00:01:37,850 --> 00:01:42,160 ‫Und was wir tun können, ist, die Anmeldeanforderung wirklich langsam zu machen. 35 00:01:42,160 --> 00:01:44,586 ‫Und das bcrypt-Paket, das 36 00:01:44,586 --> 00:01:47,020 ‫wir verwenden, tut genau das. 37 00:01:47,020 --> 00:01:50,180 ‫Eine andere Strategie besteht darin, eine Ratenbegrenzung zu implementieren, 38 00:01:50,180 --> 00:01:52,340 ‫die die Anzahl der Anfragen 39 00:01:52,340 --> 00:01:54,640 ‫begrenzt, die von einer einzelnen IP kommen. 40 00:01:54,640 --> 00:01:56,330 ‫Und dieses werden wir 41 00:01:56,330 --> 00:01:58,460 ‫in einem der nächsten Videos implementieren. 42 00:01:58,460 --> 00:02:01,690 ‫Außerdem ist es eine gute Strategie, für 43 00:02:01,690 --> 00:02:05,470 ‫jeden Benutzer eine maximale Anzahl von Anmeldeversuchen zu implementieren. 44 00:02:05,470 --> 00:02:07,660 ‫Zum Beispiel könnten wir es so 45 00:02:07,660 --> 00:02:10,540 ‫machen, dass der Benutzer nach 10 fehlgeschlagenen Versuchen 46 00:02:10,540 --> 00:02:14,020 ‫eine Stunde warten muss, bis er es erneut versuchen kann. 47 00:02:14,020 --> 00:02:16,360 ‫Nun, ich werde diese Funktionalität 48 00:02:16,360 --> 00:02:18,760 ‫in diesem Abschnitt nicht implementieren, aber 49 00:02:18,760 --> 00:02:21,340 ‫Sie können gerne selbst damit experimentieren. 50 00:02:21,340 --> 00:02:24,350 ‫Es ist wahrscheinlich eine wirklich coole Lernerfahrung, dies selbst 51 00:02:24,350 --> 00:02:26,120 ‫zu programmieren, und es ist 52 00:02:26,120 --> 00:02:27,890 ‫eigentlich nicht so schwer. 53 00:02:27,890 --> 00:02:29,210 ‫Gut. 54 00:02:29,210 --> 00:02:32,580 ‫Als nächstes gibt es den Cross-Site-Scripting-Angriff, bei dem 55 00:02:32,580 --> 00:02:34,020 ‫der Angreifer 56 00:02:34,020 --> 00:02:38,430 ‫versucht, Skripte in unsere Seite einzuschleusen, um seinen Schadcode auszuführen. 57 00:02:38,430 --> 00:02:41,280 ‫Auf Client-Seite ist dies besonders gefährlich, 58 00:02:41,280 --> 00:02:44,810 ‫da es dem Angreifer ermöglicht, den lokalen 59 00:02:44,810 --> 00:02:46,500 ‫Speicher auszulesen, weshalb 60 00:02:46,500 --> 00:02:50,360 ‫wir das JSON-Webtoken niemals im lokalen Speicher speichern sollten. 61 00:02:50,360 --> 00:02:54,110 ‫Stattdessen sollte es in einem reinen HTTP-Cookie gespeichert werden, das es dem 62 00:02:54,110 --> 00:02:55,950 ‫Browser ermöglicht, das Cookie nur 63 00:02:55,950 --> 00:02:58,110 ‫zu empfangen und zu senden, aber 64 00:02:58,110 --> 00:03:01,400 ‫nicht darauf zuzugreifen oder es in irgendeiner Weise zu ändern. 65 00:03:01,400 --> 00:03:04,360 ‫Damit ist es dann für einen 66 00:03:04,360 --> 00:03:08,460 ‫Angreifer unmöglich, das im Cookie gespeicherte JSON-Webtoken zu stehlen. 67 00:03:08,460 --> 00:03:11,590 ‫Auch hier implementieren wir dies in einer Sekunde. 68 00:03:11,590 --> 00:03:15,780 ‫Um XSS-Angriffe zu verhindern, sollten wir nun auf 69 00:03:15,780 --> 00:03:18,170 ‫der Backend-Seite Benutzereingabedaten 70 00:03:18,170 --> 00:03:20,660 ‫bereinigen und einige spezielle HTTP-Header 71 00:03:20,660 --> 00:03:24,470 ‫setzen, die diese Angriffe etwas schwieriger machen. 72 00:03:24,470 --> 00:03:27,040 ‫Und Express enthält diese Best Practices nicht 73 00:03:27,040 --> 00:03:29,560 ‫sofort, daher werden wir Middleware verwenden, um 74 00:03:29,560 --> 00:03:31,713 ‫all diese speziellen Header festzulegen. 75 00:03:32,710 --> 00:03:35,620 ‫Als nächstes haben wir Denial-of-Service-Angriffe. 76 00:03:35,620 --> 00:03:37,510 ‫Und vielleicht haben Sie davon gehört. 77 00:03:37,510 --> 00:03:39,330 ‫Dies geschieht, wenn der 78 00:03:39,330 --> 00:03:42,600 ‫Angreifer so viele Anfragen an einen Server sendet, dass dieser 79 00:03:42,600 --> 00:03:45,450 ‫zusammenbricht und die Anwendung nicht mehr verfügbar ist. 80 00:03:45,450 --> 00:03:47,470 ‫Auch hier ist die Implementierung 81 00:03:47,470 --> 00:03:49,530 ‫einer Ratenbegrenzung eine gute Lösung dafür. 82 00:03:49,530 --> 00:03:51,970 ‫Außerdem sollten wir die Datenmenge begrenzen, die 83 00:03:51,970 --> 00:03:55,810 ‫in einem Textkörper in einem Beitrag oder einer Patch-Anfrage gesendet werden kann. 84 00:03:55,810 --> 00:03:57,950 ‫Außerdem sollten wir es vermeiden, 85 00:03:57,950 --> 00:04:01,110 ‫sogenannte böse reguläre Ausdrücke in unserem Code zu verwenden. 86 00:04:01,110 --> 00:04:03,590 ‫Und dies sind nur reguläre 87 00:04:03,590 --> 00:04:07,550 ‫Ausdrücke, deren Ausführung für nicht übereinstimmende Eingaben exponentiell dauert, 88 00:04:07,550 --> 00:04:11,680 ‫und sie können ausgenutzt werden, um unsere gesamte Anwendung herunterzufahren. 89 00:04:11,680 --> 00:04:15,960 ‫Okay, als nächstes haben wir den NoSQL-Query-Injection-Angriff. 90 00:04:15,960 --> 00:04:18,510 ‫Und Abfrageinjektion geschieht, wenn ein Angreifer, 91 00:04:18,510 --> 00:04:22,240 ‫anstatt gültige Daten einzugeben, eine Abfrage einfügt, um 92 00:04:22,240 --> 00:04:24,330 ‫Abfrageausdrücke zu erstellen, 93 00:04:24,330 --> 00:04:26,600 ‫die in wahr übersetzt werden. 94 00:04:26,600 --> 00:04:28,920 ‫Zum Beispiel, um sich auch 95 00:04:28,920 --> 00:04:32,120 ‫ohne Angabe eines gültigen Benutzernamens oder Passworts anzumelden. 96 00:04:32,120 --> 00:04:33,380 ‫Es ist ein bisschen 97 00:04:33,380 --> 00:04:36,330 ‫komplex und Sie sollten es unbedingt googeln, um mehr zu erfahren. 98 00:04:36,330 --> 00:04:38,940 ‫Was Sie jedoch wissen müssen, ist, dass die 99 00:04:38,940 --> 00:04:40,810 ‫Verwendung von Mongoose tatsächlich eine 100 00:04:40,810 --> 00:04:43,300 ‫ziemlich gute Strategie ist, um diese Art von 101 00:04:43,300 --> 00:04:46,110 ‫Angriffen zu verhindern, da ein gutes Schema erzwingt, dass 102 00:04:46,110 --> 00:04:48,410 ‫jeder Wert eine gut definierte Datenregisterkarte hat. 103 00:04:48,410 --> 00:04:50,190 ‫Was die Ausführung 104 00:04:50,190 --> 00:04:53,640 ‫dieser Art von Angriff dann effektiv erschwert. 105 00:04:53,640 --> 00:04:56,000 ‫Es ist jedoch immer eine gute 106 00:04:56,000 --> 00:04:59,280 ‫Idee, Eingabedaten zu bereinigen, nur um sicher zu gehen. 107 00:04:59,280 --> 00:05:02,300 ‫Und darum kümmern wir uns etwas später. 108 00:05:02,300 --> 00:05:04,360 ‫In Ordnung, und 109 00:05:04,360 --> 00:05:07,822 ‫jetzt zum Schluss noch ein paar Best 110 00:05:07,822 --> 00:05:10,150 ‫Practices und Vorschläge zur 111 00:05:10,150 --> 00:05:14,009 ‫Verbesserung der von uns implementierten Authentifizierungs- und Autorisierungsmechanismen. 112 00:05:14,009 --> 00:05:16,350 ‫Das erste, was ich 113 00:05:16,350 --> 00:05:18,760 ‫immer und immer wieder wiederholen 114 00:05:18,760 --> 00:05:21,370 ‫muss, ist, dass in einer 115 00:05:21,370 --> 00:05:24,310 ‫Produktionsanwendung die gesamte Kommunikation zwischen Server 116 00:05:24,310 --> 00:05:26,980 ‫und Client über HTTPS erfolgen muss. 117 00:05:26,980 --> 00:05:30,010 ‫Andernfalls kann jeder in die Unterhaltung mithören 118 00:05:30,010 --> 00:05:32,520 ‫und unser JSON-Webtoken stehlen. 119 00:05:32,520 --> 00:05:35,540 ‫Als nächstes erstellen Sie immer zufällige Passwort-Token. 120 00:05:35,540 --> 00:05:38,660 ‫Nicht aus Daten oder ähnlichem generiert. 121 00:05:38,660 --> 00:05:40,920 ‫Da es sich im Grunde genommen um 122 00:05:40,920 --> 00:05:43,470 ‫Passwörter handelt, sollten sie auch als solche behandelt werden. 123 00:05:43,470 --> 00:05:45,860 ‫Geben Sie ihnen außerdem immer Ablaufdaten an, so 124 00:05:45,860 --> 00:05:47,750 ‫wie wir es implementiert haben. 125 00:05:47,750 --> 00:05:48,910 ‫Gut? 126 00:05:48,910 --> 00:05:52,340 ‫Und wir haben auch implementiert, dass ein bestimmter JSON-Webtoken 127 00:05:52,340 --> 00:05:56,480 ‫nicht mehr gültig ist, nachdem der Benutzer sein Passwort geändert hat. 128 00:05:56,480 --> 00:05:58,660 ‫Wir widerrufen also grundsätzlich den 129 00:05:58,660 --> 00:06:01,410 ‫Token, sobald der Nutzer das Passwort ändert. 130 00:06:01,410 --> 00:06:04,070 ‫Das macht sehr viel Sinn, aber 131 00:06:04,070 --> 00:06:07,650 ‫auch hier tun viele Tutorials da draußen einfach nicht. 132 00:06:07,650 --> 00:06:10,470 ‫Eine andere große Sache ist, niemals 133 00:06:10,470 --> 00:06:14,060 ‫eine Konfigurationsdatei, wie für Umgebungsvariablen, an eine Versionskontrolle 134 00:06:14,060 --> 00:06:16,460 ‫wie Git zu übergeben. 135 00:06:16,460 --> 00:06:19,020 ‫Laden Sie sie nirgendwo hoch, da 136 00:06:19,020 --> 00:06:20,500 ‫diese Datei 137 00:06:20,500 --> 00:06:23,780 ‫die sensibelsten Daten der gesamten Anwendung enthält. 138 00:06:23,780 --> 00:06:26,340 ‫Wenn beispielsweise jemand Zugriff 139 00:06:26,340 --> 00:06:28,260 ‫auf Ihr JSON-Webtoken-Geheimnis 140 00:06:28,260 --> 00:06:32,083 ‫erhält, ist Ihr gesamter Authentifizierungsprozess kompromittiert. 141 00:06:32,083 --> 00:06:35,950 ‫Okay, und jetzt nur ein kleines Detail, um bei einem 142 00:06:35,950 --> 00:06:37,560 ‫Fehler nicht den 143 00:06:37,560 --> 00:06:40,560 ‫gesamten Fehler an den Client zu senden. 144 00:06:40,560 --> 00:06:44,010 ‫Dinge wie der Stack-Trace können dem Angreifer also 145 00:06:44,010 --> 00:06:46,920 ‫wertvolle Einblicke in Ihr System geben, und 146 00:06:46,920 --> 00:06:49,650 ‫das wollen wir natürlich nicht. 147 00:06:49,650 --> 00:06:52,480 ‫Als nächstes können wir das csurf-Paket verwenden, um 148 00:06:52,480 --> 00:06:57,200 ‫eine Angriffsart namens Cross-Site Request Forgery zu bekämpfen, bei der es sich um 149 00:06:57,200 --> 00:06:59,750 ‫einen Angriff handelt, der einen Benutzer 150 00:06:59,750 --> 00:07:03,530 ‫dazu zwingt, unerwünschte Aktionen in einer Webanwendung auszuführen, in der 151 00:07:03,530 --> 00:07:05,330 ‫er gerade angemeldet ist. 152 00:07:05,330 --> 00:07:07,600 ‫Das werden wir in diesem Abschnitt jedoch nicht tun. 153 00:07:07,600 --> 00:07:10,140 ‫Aber ich wollte es hier trotzdem erwähnen. 154 00:07:10,140 --> 00:07:12,280 ‫Als Nächstes könnten wir verlangen, dass 155 00:07:12,280 --> 00:07:16,180 ‫sich der Benutzer erneut authentifiziert, bevor er eine hochwertige Aktion ausführt. 156 00:07:16,180 --> 00:07:19,730 ‫Zum Beispiel eine Zahlung leisten oder etwas löschen. 157 00:07:19,730 --> 00:07:22,070 ‫Auch dies ist nur ein Vorschlag, den 158 00:07:22,070 --> 00:07:23,810 ‫Sie selbst ausprobieren können. 159 00:07:23,810 --> 00:07:26,630 ‫Eine weitere coole Funktion, die Sie implementieren 160 00:07:26,630 --> 00:07:29,460 ‫können, ist eine schwarze Liste nicht vertrauenswürdiger Token. 161 00:07:29,460 --> 00:07:31,660 ‫Wir wissen also bereits, dass 162 00:07:31,660 --> 00:07:34,910 ‫es nicht wirklich eine Möglichkeit gibt, Benutzer von der 163 00:07:34,910 --> 00:07:37,220 ‫Anwendung abzumelden, wenn sie böswillige Aktivitäten zeigen. 164 00:07:37,220 --> 00:07:41,260 ‫Was wir jedoch tun können, ist eine Liste nicht vertrauenswürdiger Token zu 165 00:07:41,260 --> 00:07:44,370 ‫erstellen, die dann bei jeder Anfrage validiert werden. 166 00:07:44,370 --> 00:07:47,920 ‫Als nächstes hätten wir eine Funktion implementieren können, die 167 00:07:47,920 --> 00:07:51,810 ‫die E-Mail-Adresse bestätigt, nachdem ein Konto zum ersten Mal erstellt wurde. 168 00:07:51,810 --> 00:07:54,665 ‫Im Grunde also, indem Sie einen Link an die E-Mail 169 00:07:54,665 --> 00:07:57,520 ‫des Benutzers senden, wie es viele echte Apps tatsächlich tun. 170 00:07:57,520 --> 00:08:00,190 ‫Aber ich wollte es hier einfach halten, deshalb 171 00:08:00,190 --> 00:08:02,600 ‫habe ich das hier nicht gemacht. 172 00:08:02,600 --> 00:08:05,400 ‫Aber setzen Sie dies gerne einfach selbst um, 173 00:08:05,400 --> 00:08:07,360 ‫wenn Sie Lust dazu haben. 174 00:08:07,360 --> 00:08:09,900 ‫Ein großes Feature, das viele 175 00:08:09,900 --> 00:08:12,580 ‫Apps haben, ist das Konzept der Aktualisierungstoken. 176 00:08:12,580 --> 00:08:15,050 ‫Welche sind im Grunde, um sich an Benutzer zu erinnern. 177 00:08:15,050 --> 00:08:17,150 ‫Also, um sie für immer 178 00:08:17,150 --> 00:08:19,720 ‫eingeloggt zu halten oder bis sie sich abmelden. 179 00:08:19,720 --> 00:08:22,170 ‫Unsere aktuelle Implementierung sieht 180 00:08:22,170 --> 00:08:25,020 ‫vor, dass sich der Benutzer nach Ablauf 181 00:08:25,020 --> 00:08:27,480 ‫des JSON-Webtokens grundsätzlich erneut anmelden muss. 182 00:08:27,480 --> 00:08:30,720 ‫Mit Aktualisierungstoken ist dies jedoch nicht mehr erforderlich. 183 00:08:30,720 --> 00:08:33,490 ‫Und es ist ein bisschen komplex zu implementieren und daher ist 184 00:08:33,490 --> 00:08:35,343 ‫es ein Feature für ein anderes Mal. 185 00:08:36,270 --> 00:08:37,950 ‫Als letztes hätten 186 00:08:37,950 --> 00:08:41,530 ‫wir schließlich die Zwei-Faktor-Authentifizierung implementieren können, mit der 187 00:08:41,530 --> 00:08:43,770 ‫Sie sicher vertraut sind. 188 00:08:43,770 --> 00:08:46,079 ‫Grundsätzlich muss der Benutzer bei der 189 00:08:46,079 --> 00:08:48,750 ‫Zwei-Faktor-Authentifizierung nach der Anmeldung bei der 190 00:08:48,750 --> 00:08:50,050 ‫Anwendung eine 191 00:08:50,050 --> 00:08:53,110 ‫zweite Aktion ausführen, um wirklich authentifiziert zu werden. 192 00:08:53,110 --> 00:08:55,750 ‫Und normalerweise ist das das Einfügen eines 193 00:08:55,750 --> 00:08:58,980 ‫Codes, der per SMS an ein Mobiltelefon gesendet wird. 194 00:08:58,980 --> 00:09:01,420 ‫Dies sind also viele Funktionen, die 195 00:09:01,420 --> 00:09:03,580 ‫unsere Authentifizierung haben könnte. 196 00:09:03,580 --> 00:09:05,730 ‫Und wenn Sie möchten, dass ich eine davon implementiere, 197 00:09:05,730 --> 00:09:08,160 ‫teilen Sie mir dies bitte im Abschnitt Fragen und Antworten mit. 198 00:09:08,160 --> 00:09:10,640 ‫Und wenn einer von ihnen stark nachgefragt wird, dann 199 00:09:10,640 --> 00:09:12,740 ‫zeige ich Ihnen, wie es funktioniert. 200 00:09:12,740 --> 00:09:15,210 ‫Okay, aber noch einmal, ich wollte diesen Node 201 00:09:15,210 --> 00:09:17,270 ‫nicht umdrehen. js-Kurs 202 00:09:17,270 --> 00:09:20,760 ‫in einen kompletten Sicherheits- und Authentifizierungskurs. 203 00:09:20,760 --> 00:09:24,230 ‫Und zum Schluss noch etwas, das wir im Rest 204 00:09:24,230 --> 00:09:26,200 ‫des Abschnitts implementieren werden, 205 00:09:26,200 --> 00:09:28,320 ‫um die Parameterverschmutzung zu verhindern. 206 00:09:28,320 --> 00:09:32,450 ‫Versuchen Sie beispielsweise, einfach zwei Feldparameter in die Abfragezeichenfolge 207 00:09:32,450 --> 00:09:36,030 ‫einzufügen, die nach allen Touren sucht. 208 00:09:36,030 --> 00:09:38,290 ‫Und wenn Sie das tun, werden Sie feststellen, 209 00:09:38,290 --> 00:09:39,770 ‫dass es zu einem 210 00:09:39,770 --> 00:09:42,150 ‫Fehler kommt, weil unsere Anwendung darauf nicht vorbereitet ist. 211 00:09:42,150 --> 00:09:45,790 ‫Und so versuchen Angreifer, diese Art von Schwächen auszunutzen, um Anwendungen 212 00:09:45,790 --> 00:09:49,330 ‫zum Absturz zu bringen, was natürlich nicht gut ist. 213 00:09:49,330 --> 00:09:51,530 ‫Und das müssen wir also beheben. 214 00:09:51,530 --> 00:09:56,286 ‫Okay, das war also viel länger als ich erwartet hatte. 215 00:09:56,286 --> 00:09:59,231 ‫Und es gibt ganze Kurse zum Thema Sicherheit, wenn 216 00:09:59,231 --> 00:10:01,560 ‫Sie sich wirklich für Sicherheit interessieren. 217 00:10:01,560 --> 00:10:04,074 ‫In Ordnung, aber ich belasse es dabei, 218 00:10:04,074 --> 00:10:07,283 ‫und so gehen wir jetzt direkt zum nächsten über.