Ist Ihr Websystem mithilfe der JS-Erkennung wirklich sicher?

Verwandte Lernempfehlungen: Javascript

Ist Ihr Websystem wirklich sicher?

Der Damm von tausend Meilen ist im Ameisennest eingestürzt.

Im Websystem kann eine kleine Schwachstelle oft äußerst schwerwiegende Folgen haben. Daher ist Web-Sicherheit ein Thema, das jedes System bei Design, Entwicklung, Betrieb und Wartung berücksichtigen muss.

Heutzutage sind die von vielen Websystemen ergriffenen Abwehrmaßnahmen eher grundlegend und einfach und zielen oft nur auf häufige Sicherheitslücken ab, wie zum Beispiel:

• Csrf
• XSS
• SQL-Injection

und so weiter. Diese grundlegenden Abwehrmaßnahmen sind notwendig und nicht teuer in der Implementierung, aber sie sind nur der grundlegende Teil der Systemsicherheitsverteidigung. Viele Entwickler denken, dass diese Dinge ausreichen, um die meisten Situationen zu bewältigen. Diese Idee ist sehr gefährlich. Zusätzlich zu diesen grundlegenden und standardisierten Schwachstellen ist es wahrscheinlich, dass die Geschäftslogik jedes Geschäftssystems selbst zum Ziel von Hackerangriffen wird. Sobald sie entdeckt und zerstört wird, werden die Folgen sehr schwerwiegend sein. Im Folgenden werden wir einige häufige Lücken in der Geschäftslogik auflisten. Ich hoffe, dass sie alle bei der Entwicklung von Systemen inspirieren können.

Verwirrende Verwaltung von Sitzungsanmeldeinformationen

Wir alle wissen, dass HTTP selbst zustandslos ist. Damit Browser und Server die Identität des anderen kennen und sich gegenseitig vertrauen können, werden die meisten Websysteme mithilfe vereinbarter Anmeldeinformationen wie „Tokens“ implementiert Das Token wird generiert, nachdem sich der Benutzer angemeldet hat, und läuft ab, wenn sich der Benutzer aktiv abmeldet oder nach einer gewissen Zeit. Das heißt, wenn die Anfrage das entsprechende Token bringt, kann der Server das Token erhalten und die entsprechende Überprüfung durchführen. Wenn die Überprüfung erfolgreich ist, vertraut er der Anfrage und führt die entsprechende Geschäftslogik aus ein illegales oder abgelaufenes mitbringen wird als illegal angesehen. Dies scheint kein Problem zu sein, es kann jedoch zu versteckten Lücken in der tatsächlichen Implementierung kommen.

Sehen wir uns zwei Beispiele an:

1 Als der Frontend-Entwickler Xiao Ming die Logik für den Benutzer zum Klicken auf die Schaltfläche „Beenden“ schrieb, löschte er einfach den Token-Wert im Cookie oder im lokalen Speicher (Tokens werden im Allgemeinen in diesen beiden gespeichert). Orte) und hat keine Anfrage an das Backend initiiert, um das Ablaufen des Tokens im Unternehmen zuzulassen. Dann widerspricht die Gültigkeit dieses Tokens im Wesentlichen der Absicht des Benutzers und es besteht derzeit ein sehr hohes Risiko. Wenn der Benutzer spontan aussteigt, ist das Token immer noch gültig. Wenn das Token auf irgendeine Weise von anderen erhalten und aufgezeichnet wird, kann er die vom Benutzer ausgeführten Vorgänge, wie z. B. das Ändern von Benutzerinformationen, das Aufgeben von Bestellungen usw., perfekt wiedergeben.

2. Im obigen Beispiel haben wir erwähnt, dass der Token so eingestellt werden muss, dass er abläuft. Eine angemessene Ablaufzeit kann Risiken effektiv reduzieren. Aber der Backend-Entwickler kann beim Festlegen der Token-Ablaufkonfiguration verwirrt sein und seine Hände zittern, und er könnte eine zusätzliche Ziffer eingeben, oder er könnte die Einheit falsch verstehen und MS-Level-Werte für S-Level-Einheiten verwenden. dann wird die Ablaufzeit festgelegt. Die Bestellung ist sehr lang. Dies ist sehr gefährlich für Benutzer, die sich nicht aktiv abmelden möchten oder nach dem Anmelden längere Zeit auf der Seite bleiben. Der Token ist auch dann noch gültig, wenn der Benutzer ihn längere Zeit nicht verwendet. Wenn jemand anderes den Token erhält, kann er viele schlechte Dinge tun.

Verifizierung ungültig

Das Hochladen von Dateien sollte eine häufig verwendete Funktion in Webanwendungen sein, z. B. das Hochladen von Avataren, das Hochladen von Dateien auf Netzwerkfestplatten usw. Böswillige Benutzer können beim Hochladen Trojaner, Viren, schädliche Skripte und andere Dateien hochladen. Wenn solche Dateien auf dem Server ausgeführt werden, hat dies schwerwiegende Folgen. Diese Angriffsmethode ist relativ kostengünstig und kann von Angreifern relativ leicht ausgenutzt werden. Je mehr Dateitypen hochgeladen werden dürfen, desto größer ist das Angriffspotenzial. Wenn das Schadprogramm erfolgreich hochgeladen wurde, kann es vom Benutzer heruntergeladen und nach der Ausführung auf dem Computer des Benutzers vergiftet werden. Auf dem Server können auch Schadprogramme ausgeführt werden, die zu einer Kontrolle des Servers und damit zu einer Serverlähmung und Datenverlust führen.

Unter normalen Umständen beurteilt das Programm den Dateityp und lässt nur das Hochladen von Dateien auf den Server zu, die wir für legal halten. Bei einigen Webprogrammen wird diese Beurteilung jedoch nur im Frontend und nicht im Backend vorgenommen. Dadurch ergeben sich Möglichkeiten für Angreifer, die Anfragen zum Hochladen illegaler Dateien leicht ändern können.

Der richtige Ansatz sollte darin bestehen, eine Beurteilung der Dateierweiterung, eine MIME-Erkennung und Beschränkungen der Upload-Dateigröße im Backend durchzuführen, um sich dagegen zu schützen. Darüber hinaus können Dateien auf einem vom Unternehmen isolierten Server gespeichert werden, um zu verhindern, dass schädliche Dateien den Unternehmensserver angreifen und zur Nichtverfügbarkeit des Dienstes führen.

Datenaufzählung

Beim Anmelden am System ermitteln die meisten Systeme, ob der Benutzer existiert, wenn er sich anmeldet, und geben dann die Meldung „Diese Mobiltelefonnummer ist nicht registriert“ aus. Wenn diese Logik über eine separate Schnittstelle erfolgt, besteht die Gefahr einer Brute-Force-Aufzählung. Über diese Schnittstelle kann ein Angreifer die Mobiltelefonnummernbibliothek nutzen, um eine Anforderungsaufzählung durchzuführen und zu identifizieren, welche Mobiltelefonnummern im System registriert wurden, was im nächsten Schritt Möglichkeiten zum Brute-Force-Knacken von Passwörtern bietet.

Für dieses Problem wird empfohlen, dieses Urteil in die Benutzeroberfläche zur Anmeldeüberprüfung einzugeben und keine eindeutige Eingabeaufforderung zurückzugeben. Sie werden feststellen, dass auf gut gestalteten Websites normalerweise die Meldung „Die Mobiltelefonnummer ist nicht registriert oder das Passwort ist falsch“ angezeigt wird. Dies beeinträchtigt zwar das Benutzererlebnis, ist aber auch sicherer.

Wiedergabe des Datenschreibens

Nehmen wir als Beispiel einen Forumsbeitrag. Verwenden Sie ein Paketerfassungstool, um den Anforderungsprozess eines Forumsbeitrags zu erfassen. Durch den Tool-Wiedergabeprozess werden Sie feststellen, dass zwei identische Beiträge in der Beitragsliste angezeigt werden. Dies wird durch Wiederholung angegriffen. Wenn die Wiedergabehäufigkeit beschleunigt wird, werden nicht nur viele Junk-Daten im System generiert, sondern durch häufiges Schreiben wird auch die Geschäftsdatenbank enorm belastet.

Für solche Anfragen, bei denen das Risiko einer Wiederholung besteht, wird empfohlen, eine Begrenzung der Anfragehäufigkeit hinzuzufügen. Sie können beispielsweise die Zeitstempel zweier Anfragen ermitteln und diese auf gültig setzen, wenn sie größer als ein bestimmter Zeitwert sind.

Berechtigungsschwachstelle

Die Berechtigungsüberprüfung ist eine Grundfunktion des Websystems, beispielsweise eines Managementsystems für die Organisationsstruktur eines Unternehmens, das die Funktion zum Ändern von Abteilungsnamen und Abteilungsleitern bietet. Durch das Hinzufügen einer Berechtigungsüberprüfung kann effektiv verhindert werden, dass ein Benutzer über diese Funktionen Informationen ändert, zu deren Verwendung er keine Berechtigung hat. Die Berechtigungsüberprüfung wird in solchen Systemen auf jeden Fall implementiert, aber ist sie tatsächlich korrekt implementiert?

Angenommen, wir legen fest, dass ein Benutzer im System zwei Bedingungen erfüllen muss: Super-Management-Berechtigungen und Zugehörigkeit zu Abteilung A, um den Abteilungsnamen ändern zu können. Bei der tatsächlichen Codeimplementierung bestimmen Entwickler häufig nur, ob der Benutzer ein Superadministrator ist, nicht jedoch, ob der Benutzer der Abteilung angehört. In diesem Fall können wir den Namen von Abteilung A mit dem Superverwaltungskonto von Abteilung B ändern, was einer Namensänderung außerhalb unserer Befugnisse entspricht. Dies ist offensichtlich nicht das Ergebnis, das wir erwartet haben. Auch wenn der Superadministrator-Benutzer von Abteilung B den Eingang zum Ändern des Abteilungsnamens von Abteilung A auf der Schnittstelle nicht finden kann, kann er die Parameter dennoch ändern, indem er die Anforderung abruft.

Neben der unbefugten Änderung können Sie diese natürlich auch außerhalb Ihrer autorisierten Befugnisse einsehen. Wir erwarten definitiv nicht, dass der Supermanager von Abteilung A die Abteilungsinformationen von Abteilung B sehen kann, oder?

Es wird empfohlen, dass Ihr System die Benutzerzugriffsrechte auf Rollen streng prüft und einschränkt.

Sicherheit ist keine Kleinigkeit. Wie eingangs erwähnt, kann jede Sicherheitslücke verheerende Folgen haben. Wir sollten nicht nur auf das Geschäftsdesign achten, sondern auch auf die Codeüberprüfung, um durch die Implementierung verursachte Schwachstellen auf niedriger Ebene zu vermeiden.

Die oben genannten sind nur einige der vielen Sicherheitslücken. Weitere schwerwiegende Sicherheitsrisiken für Webanwendungen finden Sie in den Top 10 Sicherheitsproblemen, die in der OWASP Top 10 2017 veröffentlicht wurden. www.owasp.org.cn/owasp-proje…

Das obige ist der detaillierte Inhalt vonIst Ihr Websystem mithilfe der JS-Erkennung wirklich sicher?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!