Vor etwa einem Jahr haben wir bei DataLine gestartet zur Suche und Analyse von Schwachstellen in IT-Anwendungen. Der Dienst basiert auf der Cloud-Lösung Qualys, über deren Betrieb . Im Laufe eines Jahres, in dem wir mit der Lösung arbeiteten, führten wir 291 Scans für verschiedene Websites durch und sammelten Statistiken zu häufigen Schwachstellen in Webanwendungen.
Im folgenden Artikel zeige ich Ihnen genau, welche Lücken in der Website-Sicherheit sich hinter verschiedenen Kritikalitätsstufen verbergen. Sehen wir uns an, welche Schwachstellen der Scanner besonders häufig gefunden hat, warum sie auftreten können und wie Sie sich schützen können.
Qualys unterteilt alle Schwachstellen von Webanwendungen in drei Kritikalitätsstufen: niedrig, mittel und hoch. Wenn man sich die Verteilung nach „Schweregrad“ ansieht, scheint es, dass nicht alles so schlimm ist. Es gibt wenige Schwachstellen mit hoher Kritikalität, meist sind alle unkritisch:
Aber unkritisch heißt nicht harmlos. Sie können auch schwere Schäden verursachen.
Top „unkritische“ Schwachstellen
- Schwachstellen bei gemischten Inhalten.
Der Standard für die Website-Sicherheit ist die Datenübertragung zwischen Client und Server über das HTTPS-Protokoll, das Verschlüsselung unterstützt und Informationen vor dem Abfangen schützt.
Einige Websites verwenden gemischter Inhalt: Einige Daten werden über das unsichere HTTP-Protokoll übertragen. So wird es am häufigsten vermittelt passiver Inhalt – Informationen, die nur die Anzeige der Website betreffen: Bilder, CSS-Stile. Aber manchmal wird es auf diese Weise übertragen aktiver Inhalt: Skripte, die das Verhalten der Website steuern. In diesem Fall können Sie mithilfe einer speziellen Software Informationen mit aktiven Inhalten analysieren, die vom Server kommen, Ihre Antworten im Handumdrehen ändern und die Maschine auf eine Weise arbeiten lassen, die von ihren Erstellern nicht vorgesehen war.
Neuere Browserversionen warnen Benutzer, dass Websites mit gemischten Inhalten unsicher sind, und blockieren den Inhalt. Website-Entwickler erhalten außerdem Browserwarnungen in der Konsole. So sieht es zum Beispiel hier aus :
Was ist gefährlich?: Angreifer verwenden ein unsicheres Protokoll, um Benutzerinformationen abzufangen, Skripte zu ersetzen und in seinem Namen Anfragen an die Site zu senden. Auch wenn ein Seitenbesucher keine Daten eingegeben hat, schützt ihn dies nicht davor Phishing – Erlangung vertraulicher Informationen mit betrügerischen Methoden. Mithilfe eines Skripts können Sie den Benutzer beispielsweise auf eine unsichere Site umleiten, die sich als eine dem Benutzer bekannte Site ausgibt. In manchen Fällen sieht die bösartige Website sogar besser aus als das Original, und der Benutzer kann das Formular selbst ausfüllen und vertrauliche Daten übermitteln.Was ein Webentwickler beachten sollte: Auch wenn der Site-Administrator ein SSL/TLS-Zertifikat installiert und konfiguriert hat, kann aufgrund menschlicher Fehler eine Sicherheitslücke entstehen. Wenn Sie beispielsweise auf einer der Seiten keinen relativen, sondern einen absoluten Link von http setzen und außerdem keine Weiterleitungen von http nach https eingerichtet haben.
Sie können gemischte Inhalte auf einer Website mithilfe eines Browsers erkennen: Durchsuchen Sie den Quellcode der Seite und lesen Sie Benachrichtigungen in der Entwicklerkonsole. Allerdings muss der Entwickler lange und mühsam am Code herumbasteln. Sie können den Prozess mit automatisierten Analysetools beschleunigen, zum Beispiel: , kostenlose Lighthouse-Software oder kostenpflichtige Software Screaming Frog SEO Spider.
Die Sicherheitslücke kann auch durch Probleme mit Legacy-Code entstehen, also Code, der geerbt wurde. Wenn beispielsweise einige Seiten mit einer alten Vorlage generiert werden, die die Umstellung von Websites auf https nicht berücksichtigt.
- Cookies ohne die Flags „HTTPOnly“ und „secure“.
Das Attribut „HTTPOnly“ schützt Cookies vor der Verarbeitung durch Skripte, mit denen Angreifer Benutzerdaten stehlen. Das Flag „sicher“ erlaubt nicht, dass Cookies im Klartext gesendet werden. Die Kommunikation ist nur zulässig, wenn zum Senden des Cookies das sichere HTTPS-Protokoll verwendet wird.
Beide Attribute werden in den Cookie-Eigenschaften angegeben:
Set-Cookie: Secure; HttpOnlyWas ist gefährlich?: Wenn der Website-Entwickler diese Attribute nicht angegeben hat, könnte ein Angreifer die Benutzerinformationen aus dem Cookie abfangen und ausnutzen. Wenn Cookies zur Authentifizierung und Autorisierung verwendet werden, kann er die Sitzung des Benutzers kapern und in seinem Namen Aktionen auf der Website ausführen.
Was ein Webentwickler beachten sollte: In gängigen Frameworks werden diese Attribute in der Regel automatisch gesetzt. Überprüfen Sie aber trotzdem die Webserverkonfiguration und setzen Sie das Flag: Set-Cookie HttpOnly; Sicher.
In diesem Fall macht das Attribut „HTTPOnly“ Cookies für Ihr eigenes JavaScript unsichtbar.
- Pfadbasierte Schwachstellen.
Der Scanner meldet eine solche Schwachstelle, wenn er eine öffentlich zugängliche Datei oder ein Website-Verzeichnis mit potenziell vertraulichen Informationen findet. Es erkennt beispielsweise einzelne Systemkonfigurationsdateien oder Zugriffe auf das gesamte Dateisystem. Diese Situation ist möglich, wenn die Zugriffsrechte auf der Site falsch eingestellt sind.
Was ist gefährlich?: Wenn das Dateisystem „herausragt“, kann ein Angreifer in die Betriebssystemoberfläche eindringen und versuchen, Ordner mit Passwörtern zu finden, wenn diese im Klartext gespeichert sind (tun Sie das nicht!). Oder Sie können Passwort-Hashes stehlen und das Passwort brutal erzwingen und außerdem versuchen, die Privilegien im System zu erhöhen und tiefer in die Infrastruktur einzudringen.
Was ein Webentwickler beachten sollte: Vergessen Sie nicht die Zugriffsrechte und konfigurieren Sie die Plattform, den Webserver und die Webanwendung so, dass ein „Entkommen“ aus dem Webverzeichnis unmöglich ist.
- Formulare zur Eingabe sensibler Daten mit aktivierter automatischer Ausfüllung.
Wenn ein Benutzer häufig Formulare auf Websites ausfüllt, speichert sein Browser diese Informationen mithilfe der Autofill-Funktion.
Formulare auf Websites können Felder mit vertraulichen Informationen wie Passwörtern oder Kreditkartennummern enthalten. Für solche Felder lohnt es sich, die Funktion zum automatischen Ausfüllen von Formularen auf der Website selbst zu deaktivieren.
Was ist gefährlich?: Wenn der Browser des Benutzers vertrauliche Informationen speichert, kann ein Angreifer diese später abfangen, beispielsweise durch Phishing. Im Wesentlichen richtet ein Webentwickler, der diese Nuance vergessen hat, seine Benutzer ein.
Was ein Webentwickler beachten sollte: In diesem Fall haben wir einen klassischen Konflikt: Bequemlichkeit vs. Sicherheit. Wenn ein Webentwickler über die Benutzererfahrung nachdenkt, kann er sich bewusst für die automatische Vervollständigung entscheiden. Zum Beispiel, wenn es wichtig ist, zu folgen – Empfehlungen zur Zugänglichkeit von Inhalten für Benutzer mit Behinderungen.
Bei den meisten Browsern können Sie die automatische Vervollständigung mit dem Attribut autocompete="off" deaktivieren, zum Beispiel:
<body> <form action="/de/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Aber es wird nicht für Chrome funktionieren. Dies wird mit JavaScript umgangen, eine Variante des Rezepts lässt sich finden .
- Der X-Frame-Options-Header ist nicht im Site-Code festgelegt.
Dieser Header betrifft Frame-, Iframe-, Embed- oder Objekt-Tags. Mit seiner Hilfe können Sie die Einbettung Ihrer Website in einen Frame vollständig verhindern. Dazu müssen Sie den Wert X-Frame-Options:deny angeben. Oder Sie können X-Frame-Options: sameorigin angeben, dann ist die Einbettung in einen Iframe nur auf Ihrer Domain verfügbar.
Was ist gefährlich?: Das Fehlen eines solchen Headers kann auf bösartigen Websites ausgenutzt werden Clickjacking. Bei diesem Angriff erstellt der Angreifer einen transparenten Rahmen über den Schaltflächen und täuscht den Benutzer. Beispiel: Betrüger rahmen Social-Networking-Seiten auf einer Website ein. Der Benutzer glaubt, dass er auf dieser Website auf eine Schaltfläche klickt. Stattdessen wird der Klick abgefangen und die Anfrage des Benutzers an das soziale Netzwerk gesendet, in dem eine aktive Sitzung besteht. Auf diese Weise versenden Angreifer im Auftrag des Nutzers Spam oder gewinnen Abonnenten und Likes.
Wenn Sie diese Funktion nicht deaktivieren, kann ein Angreifer die Schaltfläche Ihrer Anwendung auf einer bösartigen Website platzieren. Möglicherweise interessiert er sich für Ihr Empfehlungsprogramm oder Ihre Benutzer.
Was ein Webentwickler beachten sollte: Die Sicherheitslücke kann auftreten, wenn X-Frame-Options mit einem widersprüchlichen Wert auf dem Webserver oder Load Balancer festgelegt ist. In diesem Fall schreiben Server und Balancer einfach den Header neu, da sie im Vergleich zum Backend-Code eine höhere Priorität haben.
Die Werte „deny“ und „sameorigin“ des Headers „X-Frame-Options“ beeinträchtigen den Betrieb des Yandex-Webviewers. Um die Verwendung von Iframes für den Web Viewer zu ermöglichen, müssen Sie in den Einstellungen eine separate Regel schreiben. Für Nginx können Sie es beispielsweise so konfigurieren:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI-Schwachstellen (Pfadrelativer Stylesheet-Import).
Dies ist eine Schwachstelle im Design der Website. Dies tritt auf, wenn relative Links wie href="/de/somefolder/styles.css/" für den Zugriff auf Stildateien verwendet werden. Dies macht sich ein Angreifer zunutze, wenn er einen Weg findet, den Benutzer auf eine bösartige Seite umzuleiten. Die Seite fügt einen relativen Link in ihre URL ein und simuliert einen Stilaufruf. Sie erhalten eine Anfrage wie badsite.ru/…/somefolder/styles.css/, die unter dem Deckmantel eines Stils böswillige Aktionen ausführen kann.
Was ist gefährlich?: Ein Betrüger könnte diese Sicherheitslücke ausnutzen, wenn er eine weitere Sicherheitslücke findet. Dadurch ist es möglich, Benutzerdaten aus Cookies oder Token zu stehlen.
Was ein Webentwickler beachten sollte: Setzen Sie den X-Content-Type-Options-Header auf: nosniff. In diesem Fall prüft der Browser den Inhaltstyp der Stile. Wenn der Typ ein anderer als Text/CSS ist, blockiert der Browser die Anfrage.
Kritische Schwachstellen
- Eine Seite mit einem Passwortfeld wird vom Server über einen unsicheren Kanal übertragen (HTML-Formulare mit Passwortfeldern werden über HTTP bereitgestellt).
Die Antwort des Servers über einen unverschlüsselten Kanal ist anfällig für „Man-in-the-Middle“-Angriffe. Ein Angreifer kann den Datenverkehr abfangen und sich zwischen Client und Server einklemmen, während die Seite vom Server zum Client gelangt.
Was ist gefährlich?: Der Betrüger kann die Seite ersetzen und dem Benutzer ein Formular mit vertraulichen Daten senden, das an den Server des Angreifers gesendet wird.
Was ein Webentwickler beachten sollte: Einige Websites senden Benutzern anstelle eines Passworts einen Einmalcode per E-Mail/Telefon. In diesem Fall ist die Sicherheitslücke nicht so kritisch, aber der Mechanismus wird das Leben der Benutzer erschweren.
- Senden eines Formulars mit Login und Passwort über einen unsicheren Kanal (Anmeldeformular wird nicht über HTTPS übermittelt).
In diesem Fall wird ein Formular mit Login und Passwort vom Benutzer über einen unverschlüsselten Kanal an den Server gesendet.
Was ist gefährlich?: Im Gegensatz zum vorherigen Fall handelt es sich hierbei bereits um eine kritische Schwachstelle. Es ist einfacher, sensible Daten abzufangen, da Sie dafür nicht einmal Code schreiben müssen.
- Verwendung von JavaScript-Bibliotheken mit bekannten Schwachstellen.
Während des Scans war jQuery die am häufigsten verwendete Bibliothek mit einer großen Anzahl an Versionen. Jede Version weist mindestens eine oder sogar mehrere bekannte Schwachstellen auf. Die Auswirkungen können je nach Art der Schwachstelle sehr unterschiedlich sein.
Was ist gefährlich?: Es gibt Exploits für bekannte Schwachstellen, zum Beispiel:
Was ein Webentwickler beachten sollte: Regelmäßig zum Zyklus zurückkehren: nach bekannten Schwachstellen suchen – beheben – prüfen. Wenn Sie absichtlich veraltete Bibliotheken verwenden, beispielsweise um ältere Browser zu unterstützen oder Geld zu sparen, suchen Sie nach einer Möglichkeit, eine bekannte Schwachstelle zu beheben. - Cross-Site-Scripting (XSS).
Cross-Site Scripting (XSS) oder Cross-Site-Scripting ist ein Angriff auf eine Webanwendung, der dazu führt, dass Malware in die Datenbank eingeschleust wird. Wenn Qualys eine solche Schwachstelle findet, bedeutet das, dass ein potenzieller Angreifer sein eigenes js-Skript in den Site-Code eingefügt hat oder bereits eingefügt hat, um böswillige Aktionen auszuführen.Gespeichertes XSS gefährlicher, da das Skript auf dem Server eingebettet ist und jedes Mal ausgeführt wird, wenn die angegriffene Seite im Browser geöffnet wird.
Reflektiertes XSS einfacher durchzuführen, da ein bösartiges Skript in eine HTTP-Anfrage eingeschleust werden kann. Die Anwendung empfängt eine HTTP-Anfrage, validiert die Daten nicht, packt sie und sendet sie sofort. Wenn ein Angreifer den Datenverkehr abfängt und ein Skript wie einfügt
<script>/*+что+то+плохое+*/</script>Dann wird im Namen des Kunden eine böswillige Anfrage gesendet.
Ein markantes Beispiel für XSS:js-Sniffer, die Seiten zur Eingabe von CVC, Kartenablaufdatum usw. simulieren.
Was ein Webentwickler beachten sollte: Verwenden Sie im Header „Content-Security-Policy“ das Attribut „script-src“, um zu erzwingen, dass der Client-Browser nur Code von einer vertrauenswürdigen Quelle herunterlädt und ausführt. Beispielsweise führt script-src „self“ nur alle Skripte unserer Website auf die Whitelist.
Die beste Vorgehensweise ist Inline-Code: Erlauben Sie Inline-Javascript nur mit dem Wert „unsafe-inline“. Dieser Wert ermöglicht die Verwendung von Inline-JS/CSS, verbietet jedoch nicht die Einbindung von JS-Dateien. In Kombination mit script-src 'self' verhindern wir die Ausführung externer Skripte.Stellen Sie sicher, dass Sie alles mit „report-uri“ protokollieren und versuchen, es auf der Website zu implementieren.
- SQL-Injektionen.
Die Sicherheitslücke weist auf die Möglichkeit hin, SQL-Code in eine Website einzuschleusen, der direkt auf die Datenbank der Website zugreift. Eine SQL-Injection ist möglich, wenn die Daten des Benutzers nicht überprüft werden: Sie werden nicht auf Richtigkeit überprüft und sofort in der Abfrage verwendet. Dies geschieht beispielsweise, wenn ein Formular auf einer Website nicht prüft, ob die Eingabe mit dem Datentyp übereinstimmt.Was ist gefährlich?: Wenn ein Angreifer in dieses Formular eine SQL-Abfrage eingibt, kann er die Datenbank zum Absturz bringen oder vertrauliche Informationen preisgeben.
Was ein Webentwickler beachten sollte: Vertraue nicht dem, was vom Browser kommt. Sie müssen sich sowohl auf der Client- als auch auf der Serverseite schützen.
Schreiben Sie auf der Clientseite die Feldvalidierung mit JavaScript.
Integrierte Funktionen in gängigen Frameworks helfen auch dabei, verdächtige Zeichen auf dem Server zu entkommen. Es wird außerdem empfohlen, parametrisierte Datenbankabfragen auf dem Server zu verwenden.
Bestimmen Sie, wo genau die Interaktion mit der Datenbank in der Webanwendung stattfindet.
Eine Interaktion findet statt, wenn wir Informationen erhalten: eine Anfrage mit einer ID (Änderung der ID), die Erstellung eines neuen Benutzers, einen neuen Kommentar oder neue Einträge in der Datenbank. Hier können SQL-Injections auftreten. Selbst wenn wir einen Datensatz aus der Datenbank löschen, ist eine SQL-Injection möglich.
Allgemeine Empfehlungen
Erfinden Sie das Rad nicht neu – nutzen Sie bewährte Frameworks. Im Allgemeinen sind gängige Frameworks sicherer. Für .NET – ASP.NET MVC und ASP.NET Core, für Python – Django oder Flask, für Ruby – Ruby on Rails, für PHP – Symfony, Laravel, Yii, für JavaScript – Node.JS-Express.js, für Java - Frühlings-MVC.
Befolgen Sie die Aktualisierungen der Anbieter und aktualisieren Sie sie regelmäßig. Sie werden eine Schwachstelle finden, dann einen Exploit schreiben, ihn öffentlich zugänglich machen und alles wird wieder passieren. Abonnieren Sie Updates für stabile Versionen vom Softwareanbieter.
Zugriffsrechte prüfen. Behandeln Sie Ihren Code auf der Serverseite immer so, als ob er vom ersten bis zum letzten Buchstaben von Ihrem am meisten gehassten Feind geschrieben worden wäre, der Ihre Website zerstören und die Integrität Ihrer Daten verletzen möchte. Darüber hinaus ist dies manchmal wahr.
Verwenden Sie Klone, testen Sie Standorte und verwenden Sie sie dann für die Produktion. Dies wird erstens dazu beitragen, Fehler und Irrtümer in einer produktiven Umgebung zu vermeiden: Eine produktive Umgebung bringt Geld, eine einfache produktive Umgebung ist entscheidend. Beim Hinzufügen, Beheben oder Schließen eines Problems lohnt es sich, in einer Testumgebung zu arbeiten, dann die gefundenen Funktionen und Schwachstellen zu überprüfen und dann die Arbeit mit der Produktionsumgebung zu planen.
Schützen Sie Ihre Webanwendung mit und integrieren Sie Berichte des Schwachstellenscanners damit. DataLine nutzt beispielsweise Qualys und FortiWeb als Leistungsbündel.
Source: habr.com