Nun, da wir wissen, wie wir unsere Schwachstellen erkennen und ausnutzen können.
Lassen Sie uns darüber sprechen, wie Sie Websites vor ihnen schützen können.
Wenn wir also jetzt zur GVW 8 zurückkehren und sagen, die Sicherheit ist zu hoch, werden Sie feststellen, dass sie eine sehr einfache Möglichkeit haben, sich
dagegen zu schützen, aber dieser Weg funktioniert tatsächlich.
Und sie fragen Sie nach dem aktuellen Passwort.
Selbst wenn wir dieses Formular erhalten und all das Schmieden und all das tun, was wir getan haben, und
es dann an die Zielperson senden, können wir das nicht wirklich verbergen und es automatisch übergeben, da wir
den Strom nicht kennen Passwort.
Sie werden also nach dem aktuellen Passwort gefragt und können dann ein neues Passwort hinzufügen.
Das ist also eine wirklich gute Lösung für diesen Fall.
Obwohl, was passiert, wenn das Formular Ihr Passwort tatsächlich nicht ändert.
Was ist, wenn wir nur Nachrichten senden, die vorgeben, diese Person zu sein?
Was ist, wenn wir Dinge an die Wand dieser Person senden?
Was ist, wenn wir Dinge im Blog dieser Person veröffentlichen?
Da Aref also für viele Dinge ausgenutzt werden kann.
Wie ich bereits in früheren Videos gesagt habe, schützt diese Methode nur vor einer Änderung des Passworts.
Sie können die Person nicht wirklich jedes Mal nach ihrem Passwort fragen, wenn sie etwas posten oder etwas
mit ihrem Profil machen möchte.
Jetzt neuere Versionen von DVDs, wenn Sie brauchen, die nicht mit mir Testprotokoll kommen, um eine sicherere Option zu
haben, die die Methode implementiert, die ich mit Ihnen darüber sprechen werde.
Jetzt heißt es eigentlich unmöglich statt hoch, aber es ist egal, dass es sowieso nicht ausnutzbar ist.
Wir müssen es also nicht wirklich installieren.
Lassen Sie uns also darüber sprechen, wie Sie diese Sicherheitsanfälligkeiten tatsächlich verhindern können, ohne
den Benutzer aufzufordern, Informationen erneut einzugeben oder das Kennwort erneut einzugeben.
Wenn Sie davon ausgehen, wie wir dies ausnutzen konnten, konnten wir einfach das von der
Website verwendete Formular kopieren und an die Zielperson senden und von dieser Person ausführen lassen oder automatisch auf dem
Computer der Zielperson ausführen.
Sobald die Anforderung an den Server gesendet wird oder der Server keine Art von Überprüfung durchführt,
um sicherzustellen, dass der Benutzer sein Kennwort tatsächlich ändern möchte.
Der beste Weg, um s r f zu verhindern, besteht also darin, sicherzustellen, dass der Benutzer Daten über eine Seite
sendet, die ihm von der Webanwendung zur Verfügung gestellt wurde und nicht von anderen Personen.
Eine gute Möglichkeit, dies zu implementieren, ist die Verwendung von Synchronisierungstoken.
Jetzt weiß ich, dass der Name kompliziert klingt, aber die Idee ist sehr einfach.
Grundsätzlich möchten wir auf Server-Seite ein eindeutiges und zufälliges Token generieren.
Wenn dann die Seite geladen wird, wenn das Formular geladen wird, werden wir das bereits generierte
Token als verstecktes Formular in diese Seite einbetten.
Wenn das Formular gesendet wird, stellen wir sicher, dass das Formular mit dem Token gesendet wurde,
das wir an diesen bestimmten Benutzer gesendet haben.
Im Grunde geben wir dem Benutzer ein Token und warten dann darauf, dass er das Formular mit dem Token absendet, das wir
ihm gegeben haben.
Auf diese Weise funktioniert das Token, das der Hacker erhält, nur für ihn.
Das heißt, selbst wenn er eine Seite generiert und an das Ziel sendet und das
Ziel die Seite auslöst, wird das Formular gesendet. Der Server lehnt es jedoch ab, da es dem
Benutzer nicht dieses Token gab, das er dem Hacker gegeben hat Zum Beispiel haben wir diesen Benutzer hier und
hier kostet es das Facebook-Punkt-com-Passwort BHB.
Es geht zum Server.
Der Server generiert eine Antwort für diese Anfrage.
Es wird also die E-Mail-Seite zurückgegeben, die die Passwörter darstellt, die sich auf dieser Seite befinden.
Es wird ein einzigartiges Token enthalten.
Wenn die Seite auf der Clientseite geladen wird, hat sie also bereits das Formular, nach dem
der Benutzer sucht, sowie ein eindeutiges Token, das vom Server generiert wurde.
Wenn der Benutzer dann sendet, was er übermitteln möchte, akzeptiert der Server nur das Formular und wird oder wird auf
die Antwort auf das, was der Benutzer anfordert, antworten.
Wenn der Benutzer das gleiche Token zurückgibt.
Wenn dies nicht ordnungsgemäß implementiert ist, kann es dennoch ausgenutzt werden.
Wenn also das Token vorhersehbar war oder das gleiche Token verwendet wurde, kann der Hacker herausfinden, welches
Token im HDMI-Code eingebettet ist, und es an den Benutzer senden.
Das Token muss also bestimmte Eigenschaften haben, damit es sicher ist.
Grundsätzlich ist es wichtig, dass Sie daran denken, dass das Token unvorhersehbar sein muss
und nicht verwendet werden kann, unabhängig davon, wie Sie dies implementieren.
Dies sind die beiden wichtigsten Dinge, die Sie im Hinterkopf behalten möchten. Wenn dies vorhersehbar
ist, kann der Hacker eigene Token erstellen, diese dann in den Code einbetten und den Angriff ausführen.
Dasselbe Token kann verwendet werden.
Dann können die Hacker einfach ihr Token oder das Token eines anderen verwenden, um auf ihr Ziel zu zielen.
Um das Token unvorhersehbar zu machen und es so verwenden zu können, dass es verwendet werden
kann, muss das Token einen hohen Wert haben, damit der Hacker keinen Brute-Force-Angriff ausführen kann und herausfinden kann, dass das
Token das Token ist, das zufällig ist Der Hacker kann also keine eigenen Token erstellen, und er muss
für jeden Benutzer eindeutig sein. Wenn Benutzer dasselbe Token oder ähnliche Token erhalten, können sie diese weitergeben,
und das für den Hacker funktionierende Token funktioniert andere Leute.
Das definiert also den ganzen Punkt.
Sie können die Sicherheit des Tokens auch erhöhen, indem Sie ihn in andere Faktoren und den Algorithmus zum Generieren
von Token einbeziehen.
So können Sie zum Beispiel Datum und Uhrzeit angeben.
Kombinieren Sie es dann mit einem sicheren Zufallsgenerator und verschlüsseln Sie das dann.
All dies geschieht offensichtlich auf der Serverseite.
Der Hacker kann also nicht wissen, welchen Algorithmus Sie verwenden, da der Code
serverseitig ausgeführt wird.
Sie müssen dies nicht unbedingt mit einer sicheren großen und eindeutigen Zufallszahl tun.
Wenn Sie jedoch die Sicherheit erhöhen möchten, können Sie einfach weitere Faktoren hinzufügen und das Token verschlüsseln, bevor Sie es
an den Benutzer senden.
Dies ist tatsächlich in Matile Day implementiert.
Lassen Sie mich es Ihnen in Aktion zeigen.
Also werde ich hier zu Matile Day gehen.
Ich gehe dann auf eine Wespe, dann ja oder als Ergänzung zum Blog.
Auf diese Weise können Sie einen Blogeintrag hinzufügen, sodass Sie weder Ihr Kennwort ändern
noch alles, was anonyme Personen an unseren Blogeinträgen erlaubt.
Man kann also nicht wirklich nach einem Passwort fragen.
Ich werde tatsächlich die Sicherheit wechseln, so dass es am höchsten ist, weil es gerade bei Null ist.
Jetzt ist es am sichersten.
Wenn Sie mit der rechten Maustaste darauf klicken und fortfahren, können Sie das Element inspizieren.
Jetzt scrolle ich nach oben und wie Sie sehen, haben wir das Forum hier und wir haben eine versteckte Eingabe mit einem
sehr langen Wert.
Und das ist das Zeichen.
Dies wurde also bereits vom Server generiert und der Server lehnt alle Anfragen ab, die wir an
ihn senden, sofern er nicht über ein bestimmtes Token verfügt.
Und wenn ich dieses Formular verwende und es an jemanden anderen sende.
Dann werden die Anfragen, die sie senden werden, erneut abgelehnt, da sie ein anderes Token erhalten, das dieses
Token nur für mich und nur für mich generiert hat.
Lassen Sie mich Ihnen zeigen, ob ich gerade jetzt eine Aktualisierung durchführe, ich werde ein anderes Token bekommen.
Und wenn ich noch einmal auffrische, bekomme ich ein anderes Token, wenn ich das modifiziere.
Nehmen wir also an, ich werde am Ende des Kapitels ein kleines Ich setzen, wenn ich das jetzt
reiche, was einen Fehler ergibt.
Aber lasst mich das nicht ändern, also habe ich jetzt ein anderes Token bekommen und wenn ich nur die Art und
Weise eingereicht habe, wird es funktionieren und jetzt haben wir einen Blogeintrag namens test.
So, das war es.
Es ist eigentlich sehr sehr einfach.
Ich wollte nicht zu sehr auf Details eingehen, wie ein zufälliges Token erstellt wird, und das alles,
weil dies von der Programmiersprache abhängig sein wird.
Das ist die Webanwendung, in der programmiert ist.
Ich wollte Ihnen aber nur das Konzept oder die Idee zeigen, wie Sie Webanwendungen vor dieser Art
von Sicherheitsanfälligkeit schützen können.
Die ganze Idee ist, dass Sie sicherstellen möchten, dass der Benutzer seine Daten über eine Seite übermittelt, die Sie ihm zur Verfügung
stellen, und nicht über eine Seite, die er von einer anderen Person erhalten hat.
Um dies zu erreichen, generieren wir ein Token auf der Serverseite. Dieses Token muss lange zufällig und eindeutig
sein. Senden Sie dieses Token zusammen mit der Seite mit dem Formular und als verstecktes Formular.
Wenn ein Benutzer die Antwort übermittelt, stellen Sie sicher, dass er dasselbe Token übermittelt, das ihm
gegeben wurde.