In Anbetracht der Tatsache, dass die ASP-Entwicklung zwei Sprachen verwenden kann: VBS und JS, werden hier Programmcodes in beiden Sprachen bereitgestellt (zweisprachige Version? YY-Medium ...) Ein letzter wortreicher Satz: Die Maschine, mit der ich diesen Artikel eingegeben habe, verfügt nicht über eine ASP-Umgebung, daher wurde der bereitgestellte Code nicht getestet, und ich entschuldige mich dafür. Wenn Sie Probleme im Code finden, können Sie gerne einen Kommentar abgeben ~Ich habe ein dickes Fell~
1. Angriffsprinzip
Cookie-Spoofing nutzt hauptsächlich die unsichere Praxis einiger Benutzerverwaltungssysteme im aktuellen Netzwerk aus, Benutzeranmeldeinformationen in Cookies zu speichern. Die Angriffsmethode ist im Vergleich zu Schwachstellen wie SQL-Injection-Schwachstellen relativ schwierig, aber dennoch sehr dumm.
Wir wissen, dass ein allgemeines Benutzersystem, das auf Cookies basiert, mindestens zwei Variablen in Cookies speichert: Benutzername und Benutzerebene, wobei Benutzername der Benutzername und Benutzerebene die Ebene des Benutzers ist. Wenn unser Browser auf eine ASP-Seite zugreift, sendet er so etwas wie
GET /.../file.asp HTTP 1.0
...
Cookies: Benutzername=Benutzer&Benutzerlevel=1
...
Paket, dann können wir übertragen, solange wir den Benutzernamen und die Benutzerebene des Administrators kennen (angenommen, es handelt sich um admin bzw. 5).
GET /.../file.asp HTTP 1.0
...
Cookies: Benutzername=admin&userlevel=5
...
um Administratorrechte zu erhalten. Sehr einfach, nicht wahr? Doch bevor diese Schwachstelle entdeckt wurde, setzten fast alle Benutzerverwaltungssysteme auf Cookies.
2. Speichern Sie Benutzerinformationen sicher
Da Cookies nicht sicher sind und wir Benutzeranmeldeinformationen speichern müssen, wo sollten diese gespeichert werden?
Wir haben festgestellt, dass es in ASP neben Cookies auch Sitzungen gibt, in denen Informationen gespeichert werden können. Die Sitzung wird auf dem Server gespeichert und kann vom Client nicht zufällig geändert werden. Daher ist die Sicherheit äußerst hoch. Auf diese Weise können Sie alle Cookies-Codes durch Session ersetzen.
3. Speichern Sie Benutzerinformationen über einen längeren Zeitraum
Durch die Verwendung der Sitzung zum Speichern von Benutzeranmeldeinformationen wird zwar das Problem der Cookie-Täuschung beseitigt, die Sitzung kann jedoch nicht für längere Zeit gespeichert werden (die IIS-Standardsitzung läuft 20 Minuten nach dem Ende der Reaktion des Benutzers ab), sodass die Hybridspeichermethode „Cookies + Sitzung“ beschrieben wird in diesem Abschnitt wird produziert.
Es gibt zwei Varianten dieser Methode. Die erste besteht darin, den Benutzernamen und das Passwort in Cookies zu speichern. Wenn der Benutzer eine Seite besucht, wird die Sitzung zuerst gelesen Die in den Cookies bereitgestellten Informationen müssen gelesen und verwendet werden. Melden Sie sich undurchsichtig mit Ihrem Benutzernamen und Passwort an, um festzustellen, ob der Inhalt der Cookies legal ist und in der Sitzung gespeichert wird. Der Code zur Implementierung dieser Methode lautet wie folgt:
vbs:
Kopieren Sie den Codecode wie folgt:
<%
Benutzername und Passwort dimmen
Benutzername = Sitzung(Benutzername)
wenn Benutzername = dann
' In der Sitzung sind keine Benutzeranmeldeinformationen vorhanden
Benutzername = Request.Cookies(Benutzername)
Passwort = Request.Cookies(Passwort)
„Beachten Sie, dass der in den beiden obigen Sätzen erhaltene Benutzername und das Kennwort vor SQL-Injection-Schwachstellen geschützt werden müssen (d. h. einfache Anführungszeichen werden herausgefiltert“), die hier weggelassen werden.
wenn Benutzername = oder Passwort = dann
„Der Benutzer ist nicht angemeldet
...
anders
' Dies setzt voraus, dass die Objekte conn und rs erstellt wurden
rs.Öffnen Sie SELECT TOP 1 * FROM [Benutzer] WHERE Benutzername=' & Benutzername & ' UND Passwort=' & Passwort & ', conn, 1, 3
wenn rs.eof dann
„Die Informationen in den Cookies sind illegal.“
...
anders
„Die Informationen in den Cookies sind legal, melden Sie sich automatisch an.“
Sitzung(Benutzername) = Benutzername
...
Ende wenn
Ende wenn
anders
„Benutzerinformationen sind bereits in Session vorhanden, lesen Sie sie direkt.“
...
Ende wenn
%>
js:
Kopieren Sie den Codecode wie folgt:
<%
var Benutzername, Passwort;
Benutzername = Sitzung(Benutzername) + ;
if (Benutzername == || Benutzername == undefiniert) {
// Es gibt keine Benutzerinformationen in der Sitzung
Benutzername = Request.Cookies(Benutzername) + ;
Passwort = Request.Cookies(Passwort) + ;
// Beachten Sie, dass der in den beiden obigen Sätzen erhaltene Benutzername und das Kennwort SQL-Injection-Schwachstellen verhindern müssen (d. h. die einfachen Anführungszeichen 'herausfiltern), die hier weggelassen werden.
if (Benutzername == || Benutzername == undefiniert || Passwort == || Passwort == undefiniert) {
//Der Benutzer ist nicht angemeldet
...
}
anders {
// Dies setzt voraus, dass die Objekte conn und rs erstellt wurden
rs.Open(SELECT TOP 1 * FROM [Benutzer] WHERE Benutzername=' + Benutzername + ' UND Passwort=' + Passwort + ', conn, 1, 3);
if (rs.eof) {
//Die Informationen in Cookies sind illegal
...
}
anders {
//Die Informationen in Cookies sind legal, melden Sie sich automatisch an
Sitzung(Benutzername) = Benutzername + ;
...
}
}
}
anders {
// Benutzerinformationen sind bereits in der Sitzung vorhanden, lesen Sie sie direkt
...
}
%>
Allerdings ist diese Methode für Benutzer nicht sehr sicher, da der Browser bei jedem Besuch der Seite Cookies überträgt und sobald die Cookies mit Passwörtern von anderen abgerufen werden, wird das Konto des Benutzers gestohlen. Für diese Situation gibt es eine zweite Methode, nämlich das Hinzufügen eines Felds „Verifycode“ zur Benutzerinformationsdatenbank. Wenn sich der Benutzer anmeldet, wird ein langer ganzzahliger Verifizierungswert zufällig generiert und im Feld „Verifycode“ sowie der Benutzername und dieser Verifizierungscode gespeichert Wert hinzugefügt. Cookies statt Passwort speichern. Bei der Überprüfung von Benutzerinformationen in Cookies werden nur Benutzername und Verifizierungscode überprüft. Der Vorteil dieser Methode besteht darin, dass ein Hacker, selbst wenn er die Cookies des Benutzers erhält, nur den vorübergehend generierten Verifizierungscode zum Anmelden verwenden kann, nicht jedoch das Kennwort des Benutzers erhalten kann. Solange sich dieser Benutzer erneut mit Benutzername und Passwort anmeldet, ändert sich der Verifizierungscode-Wert und Hacker können sich nicht mit dem ursprünglichen Verifizierungscode anmelden.
Die Implementierung dieser Methode erfordert nur geringfügige Änderungen am Code der oben genannten Methode 1. Zunächst müssen Sie in Ihrem Anmeldeprogramm einen Absatz hinzufügen, in dem die Benutzerinformationen nach der Überprüfung gespeichert werden:
vbs:
Kopieren Sie den Codecode wie folgt:
<%
Response.Cookies(verifycode) = int(rnd * 2100000000)
%>
js:
Kopieren Sie den Codecode wie folgt:
<%
Response.Cookies(verifycode) = Math.floor(Math.random() * 2100000000);
%>
Ändern Sie dann die Überprüfung von Cookies (Passwort) in die Überprüfung von Cookies (Verifizierungscode) im oben angegebenen Bestätigungscode.
4. Fazit
Durch unsere Analyse und Verarbeitung wurde die Schwachstelle durch Cookies-Spoofing vollständig behoben. Seitdem ist unser ASP-Programm sicherer geworden.