Die 10 häufigsten Sicherheitslücken im Internet

Für allzu viele Unternehmen werden Best Practices für die Websicherheit erst nach einer Sicherheitsverletzung zu einer Priorität. Während meiner jahrelangen Tätigkeit als IT-Sicherheitsexperte habe ich immer wieder erlebt, wie undurchsichtig die Welt der Sicherheitsprobleme bei der Webentwicklung für so viele meiner Programmierkollegen sein kann.

Ein effektiver Ansatz für Internet-Sicherheitsbedrohungen muss per Definition proaktiv und defensiv sein. Zu diesem Zweck zielt dieser Beitrag darauf ab, eine Sicherheitsdenkweise zu wecken und dem Leser hoffentlich eine gesunde Dosis Paranoia zu injizieren.

Dieser Leitfaden konzentriert sich insbesondere auf 10 häufige und wichtige Fallstricke bei der Websicherheit, die Sie kennen sollten, einschließlich Empfehlungen, wie sie gemildert werden können. Der Schwerpunkt liegt auf den Top 10 Web-Schwachstellen, die vom Open Web Application Security Project (OWASP) identifiziert wurden, einer internationalen, gemeinnützigen Organisation, deren Ziel es ist, die Softwaresicherheit weltweit zu verbessern.

Eine kleine Einführung in die Cybersicherheit, bevor wir beginnen – Authentifizierung und Autorisierung

Wenn ich mit anderen Programmierern und IT-Experten spreche, stoße ich oft auf Verwirrung hinsichtlich der Unterscheidung zwischen Autorisierung und Authentifizierung. Und natürlich trägt die Tatsache, dass die Abkürzung auth oft für beide verwendet wird, dazu bei, diese allgemeine Verwirrung zu verschlimmern. Diese Verwirrung ist so verbreitet, dass dieses Problem vielleicht in diesem Beitrag als „Common Web Vulnerability Zero“ aufgenommen werden sollte.

Bevor wir fortfahren, wollen wir den Unterschied zwischen diesen beiden Begriffen klären:

• Authentifizierung: Überprüfung, ob eine Person ein bestimmter Benutzer ist (oder zumindest so aussieht), da sie ihre Sicherheitsdaten (Passwort, Antworten auf Sicherheitsfragen, Fingerabdruckscan usw.) korrekt angegeben hat.
• Autorisierung: Bestätigen, dass ein bestimmter Benutzer Zugriff auf eine bestimmte Ressource hat oder die Berechtigung zum Ausführen einer bestimmten Aktion erhalten hat.

Anders ausgedrückt bedeutet die Authentifizierung zu wissen, wer eine Entität ist, während die Autorisierung zu wissen bedeutet, was eine bestimmte Entität tun kann. Lassen Sie uns in diesem Sinne auf die Top 10 der Internet-Sicherheitsprobleme eingehen.

Häufiger Web-Sicherheitsfehler Nr. 1: Injektionsfehler

Injektionsfehler resultieren aus einem klassischen Versäumnis, nicht vertrauenswürdige Eingaben zu filtern. Es kann passieren, wenn Sie ungefilterte Daten an den SQL-Server (SQL-Injection), an den Browser (XSS – wir werden später darüber sprechen), an den LDAP-Server (LDAP-Injection) oder sonstwo weitergeben. Das Problem dabei ist, dass der Angreifer Befehle an diese Entitäten einschleusen kann, was zu Datenverlust und der Übernahme von Client-Browsern führt.

Alles, was Ihre Anwendung von nicht vertrauenswürdigen Quellen erhält, muss gefiltert werden, vorzugsweise gemäß einer Whitelist. Sie sollten fast nie eine schwarze Liste verwenden, da es sehr schwierig ist, dies richtig zu machen, und normalerweise leicht zu umgehen ist. Antivirus-Softwareprodukte bieten in der Regel herausragende Beispiele für fehlgeschlagene Blacklists. Der Musterabgleich funktioniert nicht.

Prävention: Die gute Nachricht ist, dass der Schutz vor Infizierung „einfach“ eine Frage der richtigen Filterung Ihrer Eingabe ist und darüber nachdenkt, ob einer Eingabe vertraut werden kann. Aber die schlechte Nachricht ist, dass alle Eingaben richtig gefiltert werden müssen, es sei denn, man kann ihnen zweifelsfrei vertrauen (aber das Sprichwort „Sag niemals nie“ kommt mir hier in den Sinn).

In einem System mit 1.000 Eingaben reicht es beispielsweise nicht aus, 999 davon erfolgreich zu filtern, da dies immer noch ein Feld übrig lässt, das als Achilles-Heilung dienen kann, um Ihr System zum Erliegen zu bringen. Und Sie denken vielleicht, dass das Einfügen eines SQL-Abfrageergebnisses in eine andere Abfrage eine gute Idee ist, da der Datenbank vertraut wird, aber wenn der Perimeter dies nicht ist, kommt die Eingabe indirekt von Leuten mit böswilliger Absicht. Dies wird als SQL-Injektion zweiter Ordnung bezeichnet, falls Sie interessiert sind.

Da das Filtern ziemlich schwierig ist (wie Krypto), empfehle ich normalerweise, sich auf die Filterfunktionen Ihres Frameworks zu verlassen: Sie funktionieren nachweislich und werden gründlich geprüft. Wenn Sie keine Frameworks verwenden, müssen Sie sich wirklich gut überlegen, ob deren Verzicht in Ihrem Serversicherheitskontext wirklich sinnvoll ist. Zu 99% ist das nicht der Fall.

Häufiger Web-Sicherheitsfehler Nr. 2: Defekte Authentifizierung

Dies ist eine Sammlung mehrerer Probleme, die während einer fehlerhaften Authentifizierung auftreten können, aber nicht alle auf dieselbe Ursache zurückzuführen sind.

Angenommen, jemand will 2014 noch seinen eigenen Authentifizierungscode rollen (was denken Sie??), rate ich davon ab. Es ist extrem schwer, es richtig zu machen, und es gibt eine Vielzahl möglicher Fallstricke, um nur einige zu nennen:

1. Die URL kann die Sitzungs-ID enthalten und sie im Referrer-Header an jemand anderen weitergeben.
2. Die Kennwörter werden möglicherweise weder beim Speichern noch beim Übertragen verschlüsselt.
3. Die Sitzungs-IDs können vorhersehbar sein, daher ist der Zugriff trivial.
4. Eventuell ist eine Sitzungsfixierung möglich.
5. Session-Hijacking könnte möglich sein, Timeouts nicht richtig implementiert oder HTTP (keine SSL-Sicherheit) verwendet werden, etc…

Prävention: Der einfachste Weg, diese Web-Sicherheitslücke zu vermeiden, ist die Verwendung eines Frameworks. Sie können dies möglicherweise korrekt implementieren, aber ersteres ist viel einfacher. Falls Sie Ihren eigenen Code erstellen möchten, seien Sie extrem paranoid und informieren Sie sich über die Fallstricke. Es gibt ziemlich viele.

Häufiger Websicherheitsfehler Nr. 3: Cross Site Scripting (XSS)

Dies ist ein ziemlich weit verbreiteter Fehler bei der Eingabebereinigung (im Wesentlichen ein Sonderfall des häufigen Fehlers Nr. 1). Ein Angreifer gibt Ihrer Webanwendung bei der Eingabe JavaScript-Tags. Wenn diese Eingabe unsauber an den Benutzer zurückgegeben wird, führt sie der Browser des Benutzers aus. Es kann so einfach sein, einen Link zu erstellen und einen Benutzer davon zu überzeugen, darauf zu klicken, oder es kann etwas viel Finstereres sein. Beim Laden der Seite wird das Skript ausgeführt und kann beispielsweise verwendet werden, um Ihre Cookies an den Angreifer zu senden.

Vorbeugung: Es gibt eine einfache Web-Sicherheitslösung: Keine HTML-Tags an den Client zurücksenden. Dies hat den zusätzlichen Vorteil, dass es sich gegen HTML-Injection verteidigt, einen ähnlichen Angriff, bei dem der Angreifer einfachen HTML-Inhalt (wie Bilder oder laute unsichtbare Flash-Player) einfügt – nicht sehr wirkungsvoll, aber sicher ärgerlich („Bitte lass es aufhören!“). Normalerweise besteht die Problemumgehung einfach darin, alle HTML-Entitäten zu konvertieren, sodass <script> als <script> . Die andere häufig verwendete Bereinigungsmethode ist die Verwendung regulärer Ausdrücke, um HTML-Tags mit regulären Ausdrücken auf < und > zu entfernen, aber dies ist gefährlich, da viele Browser stark beschädigtes HTML problemlos interpretieren. Es ist besser, alle Zeichen in ihre entkommenen Gegenstücke umzuwandeln.

Häufiger Web-Sicherheitsfehler Nr. 4: Unsichere direkte Objektreferenzen

Dies ist ein klassischer Fall, in dem Benutzereingaben vertraut und der Preis für eine daraus resultierende Sicherheitslücke bezahlt wird. Eine direkte Objektreferenz bedeutet, dass dem Benutzer ein internes Objekt wie eine Datei oder ein Datenbankschlüssel offengelegt wird. Das Problem dabei ist, dass der Angreifer diese Referenz bereitstellen kann und, wenn die Autorisierung entweder nicht erzwungen (oder gebrochen) wird, der Angreifer auf Dinge zugreifen oder Dinge tun kann, von denen er ausgeschlossen sein sollte.

Zum Beispiel hat der Code ein download.php -Modul, das Dateien liest und dem Benutzer erlaubt, sie herunterzuladen, indem es einen CGI-Parameter verwendet, um den Dateinamen anzugeben (z. B. download.php?file=something.txt ). Entweder aus Versehen oder aus Faulheit hat der Entwickler die Autorisierung aus dem Code weggelassen. Der Angreifer kann damit nun alle Systemdateien herunterladen, auf die der Benutzer, der PHP ausführt, Zugriff hat, wie den Anwendungscode selbst oder andere Daten, die auf dem Server herumliegen, wie Backups. Uh-oh.

Ein weiteres häufiges Beispiel für eine Schwachstelle ist eine Funktion zum Zurücksetzen von Passwörtern, die auf Benutzereingaben angewiesen ist, um festzustellen, wessen Passwort wir zurücksetzen. Nachdem er auf die gültige URL geklickt hat, kann ein Angreifer einfach das username in der URL ändern, um so etwas wie „admin“ zu sagen.

Beide Beispiele sind übrigens Dinge, die ich selbst oft „in freier Wildbahn“ gesehen habe.

Prävention: Führen Sie die Benutzerautorisierung ordnungsgemäß und konsistent durch und setzen Sie die Auswahlmöglichkeiten auf die Whitelist. In den meisten Fällen kann das ganze Problem jedoch vermieden werden, indem Daten intern gespeichert werden und sich nicht darauf verlassen, dass sie vom Client über CGI-Parameter übergeben werden. Sitzungsvariablen in den meisten Frameworks sind für diesen Zweck gut geeignet.

Häufiger Web-Sicherheitsfehler Nr. 5: Fehlkonfiguration der Sicherheit

Meiner Erfahrung nach sind falsch konfigurierte Webserver und Anwendungen viel häufiger als richtig konfigurierte. Vielleicht liegt es daran, dass es an Möglichkeiten zum Vermasseln nicht mangelt. Einige Beispiele:

1. Ausführen der Anwendung mit aktiviertem Debugging in der Produktion.
2. Auf dem Server aktivierte Verzeichnisliste, wodurch wertvolle Informationen verloren gehen.
3. Ausführen veralteter Software (denken Sie an WordPress-Plugins, altes PhpMyAdmin).
4. Unnötige Dienste, die auf dem Computer ausgeführt werden.
5. Standardschlüssel und Passwörter nicht ändern. (Passiert viel häufiger als Sie glauben!)
6. Offenlegung von Informationen zur Fehlerbehandlung für die Angreifer, z. B. Stack-Traces.

Prävention: Haben Sie einen guten (vorzugsweise automatisierten) „Build and Deploy“-Prozess, der Tests bei der Bereitstellung durchführen kann. Die Sicherheitsfehlkonfigurationslösung des armen Mannes sind Post-Commit-Hooks, um zu verhindern, dass der Code mit Standardpasswörtern und/oder eingebautem Entwicklungsmaterial ausgeht.

Häufiger Web-Sicherheitsfehler Nr. 6: Offenlegung sensibler Daten

Bei dieser Sicherheitslücke im Internet geht es um Krypto- und Ressourcenschutz. Sensible Daten sollten jederzeit verschlüsselt werden, auch während der Übertragung und im Ruhezustand. Keine Ausnahmen. Kreditkarteninformationen und Benutzerpasswörter sollten niemals unverschlüsselt übertragen oder gespeichert werden, und Passwörter sollten immer gehasht werden. Natürlich darf der Krypto-/Hashing-Algorithmus nicht schwach sein – im Zweifelsfall empfehlen Web-Sicherheitsstandards AES (256 Bit und höher) und RSA (2048 Bit und höher).

Und obwohl es selbstverständlich ist, dass Sitzungs-IDs und sensible Daten nicht in den URLs reisen sollten und sensible Cookies das sichere Flag haben sollten, ist dies sehr wichtig und kann nicht genug betont werden.

Verhütung:

• Bei der Übertragung: Verwenden Sie HTTPS mit einem geeigneten Zertifikat und PFS (Perfect Forward Secrecy). Akzeptieren Sie nichts über Nicht-HTTPS-Verbindungen. Haben Sie das sichere Flag auf Cookies.

• In der Lagerung: Das ist schwieriger. In erster Linie müssen Sie Ihre Exposition senken. Wenn Sie keine sensiblen Daten benötigen, schreddern Sie sie. Daten, die Sie nicht haben, können nicht gestohlen werden. Speichern Sie niemals Kreditkarteninformationen, da Sie sich wahrscheinlich nicht damit befassen möchten, PCI-konform zu sein. Melden Sie sich bei einem Zahlungsabwickler wie Stripe oder Braintree an. Zweitens, wenn Sie sensible Daten haben, die Sie wirklich brauchen, speichern Sie sie verschlüsselt und stellen Sie sicher, dass alle Passwörter gehasht sind. Für das Hashing wird die Verwendung von bcrypt empfohlen. Wenn Sie bcrypt nicht verwenden, informieren Sie sich über Salting- und Rainbow-Tables.

Und auf die Gefahr hin, das Offensichtliche zu sagen, speichern Sie die Verschlüsselungsschlüssel nicht neben den geschützten Daten . Das ist, als ob Sie Ihr Fahrrad mit einem Schloss aufbewahren, in dem der Schlüssel steckt. Schützen Sie Ihre Backups mit Verschlüsselung und halten Sie Ihre Schlüssel sehr privat. Und natürlich die Schlüssel nicht verlieren!

Häufiger Web-Sicherheitsfehler Nr. 7: Fehlende Zugriffskontrolle auf Funktionsebene

Dies ist einfach ein Autorisierungsfehler. Dies bedeutet, dass beim Aufruf einer Funktion auf dem Server keine ordnungsgemäße Autorisierung durchgeführt wurde. Häufig verlassen sich Entwickler darauf, dass die Benutzeroberfläche vom Server generiert wurde, und glauben, dass der Client nicht auf die Funktionalität zugreifen kann, die nicht vom Server bereitgestellt wird. So einfach ist das nicht, da ein Angreifer immer Anfragen an die „versteckte“ Funktionalität fälschen kann und sich nicht dadurch abschrecken lässt, dass die Benutzeroberfläche diese Funktionalität nicht leicht zugänglich macht. Stellen Sie sich vor, es gibt ein /admin -Panel und die Schaltfläche ist nur dann in der Benutzeroberfläche vorhanden, wenn der Benutzer tatsächlich ein Administrator ist. Nichts hält einen Angreifer davon ab, diese Funktionalität zu entdecken und bei fehlender Autorisierung zu missbrauchen.

Vorbeugung: Serverseitig muss immer eine Autorisierung erfolgen. Ja immer. Keine Ausnahmen oder Schwachstellen führen zu ernsthaften Problemen.

Häufiger Websicherheitsfehler Nr. 8: Cross Site Request Forgery (CSRF)

Dies ist ein schönes Beispiel für einen verwirrten Deputy-Angriff, bei dem der Browser von einer anderen Partei dazu verleitet wird, seine Autorität zu missbrauchen. Eine Website eines Drittanbieters kann beispielsweise den Browser des Benutzers dazu bringen, seine Autorität zu missbrauchen, um etwas für den Angreifer zu tun.

Im Fall von CSRF sendet eine Drittanbieter-Site Anfragen an die Ziel-Site (z. B. Ihre Bank) unter Verwendung Ihres Browsers mit Ihren Cookies/Sitzung. Wenn Sie beispielsweise auf einer Registerkarte auf der Homepage Ihrer Bank angemeldet sind und diese für diesen Angriff anfällig ist, kann eine andere Registerkarte dazu führen, dass Ihr Browser seine Anmeldeinformationen im Namen des Angreifers missbraucht, was zu einem verwirrten Stellvertreterproblem führt. Der Stellvertreter ist der Browser, der seine Autorität (Session-Cookies) missbraucht, um etwas zu tun, was der Angreifer anweist.

Betrachten Sie dieses Beispiel:

Die Angreiferin Alice will Todds Portemonnaie leichter machen, indem sie einen Teil seines Geldes an sie überweist. Todd's Bank ist anfällig für CSRF. Um Geld zu senden, muss Todd auf die folgende URL zugreifen:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

Nachdem diese URL geöffnet wurde, wird Todd eine Erfolgsseite angezeigt, und die Übertragung ist abgeschlossen. Alice weiß auch, dass Todd häufig eine Website unter ihrer Kontrolle bei blog.aliceisawesome.com besucht, wo sie den folgenden Ausschnitt platziert:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

Beim Besuch von Alices Website denkt Todds Browser, dass Alice auf ein Bild verweist, und sendet automatisch eine HTTP-GET-Anfrage, um das Bild abzurufen, aber dies weist Todds Bank tatsächlich an, 1500 $ an Alice zu überweisen.

Übrigens zeigt dieses Beispiel nicht nur die CSRF-Schwachstelle, sondern auch die Änderung des Serverstatus mit einer idempotenten HTTP-GET-Anforderung, was selbst eine schwerwiegende Schwachstelle darstellt. HTTP-GET-Anforderungen müssen idempotent (sicher) sein, was bedeutet, dass sie die Ressource, auf die zugegriffen wird, nicht ändern können. Verwenden Sie niemals, niemals, niemals idempotente Methoden, um den Serverstatus zu ändern.

Fun Fact: CSRF ist auch die Methode, die in der Vergangenheit zum Cookie-Stuffing verwendet wurde, bis die Affiliates klüger wurden.

Prävention: Speichern Sie ein geheimes Token in einem versteckten Formularfeld, auf das von der Website eines Drittanbieters nicht zugegriffen werden kann. Dieses versteckte Feld müssen Sie natürlich immer verifizieren. Einige Websites fragen auch nach Ihrem Passwort, wenn Sie vertrauliche Einstellungen ändern (z. B. Ihre Passwort-Erinnerungs-E-Mail), obwohl ich vermute, dass dies dazu dient, den Missbrauch Ihrer abgebrochenen Sitzungen (z. B. in einem Internetcafé) zu verhindern.

Häufiger Web-Sicherheitsfehler Nr. 9: Verwendung von Komponenten mit bekannten Schwachstellen

Der Titel sagt alles. Ich würde dies wiederum eher als Wartungs-/Bereitstellungsproblem einstufen. Bevor Sie neuen Code integrieren, führen Sie einige Nachforschungen durch, möglicherweise einige Audits. Die Verwendung von Code, den Sie von einer zufälligen Person auf GitHub oder einem Forum erhalten haben, kann sehr bequem sein, ist aber nicht ohne das Risiko einer ernsthaften Sicherheitslücke im Internet.

Ich habe zum Beispiel viele Fälle gesehen, in denen Websites in Besitz genommen wurden (dh wo ein Außenstehender administrativen Zugriff auf ein System erlangte), nicht weil die Programmierer dumm waren, sondern weil eine Software von Drittanbietern jahrelang in der Produktion ungepatcht blieb. Dies passiert zum Beispiel ständig mit WordPress-Plugins. Wenn Sie glauben, dass sie Ihre versteckte phpmyadmin Installation nicht finden, lassen Sie mich Ihnen Dirbuster vorstellen.

Die Lektion hier ist, dass die Softwareentwicklung nicht endet, wenn die Anwendung bereitgestellt wird. Es muss Dokumentation, Tests und Pläne geben, wie es gewartet und auf dem neuesten Stand gehalten werden kann, insbesondere wenn es Komponenten von Drittanbietern oder Open Source enthält.

Verhütung:

• Seien Sie vorsichtig. Abgesehen davon, dass Sie bei der Verwendung solcher Komponenten offensichtlich Vorsicht walten lassen, seien Sie kein Copy-Paste-Codierer. Untersuchen Sie den Code, den Sie in Ihre Software einfügen möchten, sorgfältig, da er möglicherweise irreparabel beschädigt ist (oder in einigen Fällen absichtlich böswillig ist – Web-Sicherheitsangriffe werden manchmal unwissentlich auf diese Weise eingeladen).

• Auf dem Laufenden bleiben. Stellen Sie sicher, dass Sie die neuesten Versionen von allem verwenden, dem Sie vertrauen, und haben Sie einen Plan, diese regelmäßig zu aktualisieren. Abonnieren Sie zumindest einen Newsletter mit neuen Sicherheitslücken in Bezug auf das Produkt.

Häufiger Web-Sicherheitsfehler Nr. 10: Nicht validierte Um- und Weiterleitungen

Dies ist wieder einmal ein Problem mit der Eingangsfilterung. Angenommen, die Zielseite hat ein redirect.php -Modul, das eine URL als GET -Parameter akzeptiert. Durch die Manipulation des Parameters kann eine URL auf targetsite.com , die den Browser zu malwareinstall.com . Wenn der Benutzer den Link sieht, sieht targetsite.com/blahblahblah , die der Benutzer für vertrauenswürdig hält und auf die er sicher klicken kann. Sie wissen nicht, dass sie dadurch tatsächlich auf eine Malware-Drop-Seite (oder eine andere bösartige) Seite übertragen werden. Alternativ könnte der Angreifer den Browser zu targetsite.com/deleteprofile?confirm=1 .

Es ist erwähnenswert, dass das Einfügen von nicht bereinigten benutzerdefinierten Eingaben in einen HTTP-Header zu einer Header-Injektion führen kann, was ziemlich schlimm ist.

Prävention: Zu den Optionen gehören:

• Machen Sie überhaupt keine Weiterleitungen (sie sind selten notwendig).
• Haben Sie eine statische Liste gültiger Standorte, an die Sie umleiten können.
• Setzen Sie den benutzerdefinierten Parameter auf die Whitelist, aber das kann schwierig sein.

Epilog

Ich hoffe, dass ich es geschafft habe, Ihr Gehirn mit diesem Beitrag ein wenig zu kitzeln und eine gesunde Dosis Paranoia und Bewusstsein für Sicherheitslücken von Websites einzuführen.

Die Kernaussage hier ist, dass uralte Softwarepraktiken aus einem bestimmten Grund existieren und was damals für Pufferüberläufe galt, gilt auch heute noch für Pickled Strings in Python. Sicherheitsprotokolle helfen Ihnen, (mehr) korrekte Programme zu schreiben, die alle Programmierer anstreben sollten.

Bitte gehen Sie verantwortungsvoll mit diesem Wissen um und testen Sie Seiten nicht ohne Erlaubnis!

Weitere Informationen und spezifischere serverseitige Angriffe finden Sie unter: https://www.owasp.org/index.php/Category:Attack.

Feedback zu diesem Beitrag und seinen Empfehlungen zur Schadensbegrenzung ist willkommen und wird geschätzt. Zukünftige verwandte Beiträge sind geplant, insbesondere zum Thema Distributed Denial-of-Service (DDoS) und IT-Sicherheitslücken der alten Schule (nicht im Internet). Wenn Sie eine spezielle Anfrage haben, über welche Art von Web-Schutz Sie schreiben möchten, wenden Sie sich bitte direkt an mich unter [email protected].

Auf die Website-Sicherheit! Prost.