Vor etwa einem Jahr haben wir bei DataLine einen Dienst zur Suche und Analyse von Schwachstellen in IT-Anwendungen gestartet. Basis des Dienstes ist die Cloud-Lösung Qualys, über die wir bereits . Im Laufe eines Jahres haben wir 291 Scans für verschiedene Websites durchgeführt und Statistiken zu verbreiteten Schwachstellen in Webanwendungen gesammelt.
Im folgenden Artikel werde ich zeigen, welche Sicherheitslücken auf Websites hinter verschiedenen Kritikalitätsstufen verborgen sind. Lassen Sie uns ansehen, welche Schwachstellen der Scanner besonders häufig gefunden hat, warum sie auftreten können und wie man sich schützen kann.
Qualys klassifiziert alle Schwachstellen von Webanwendungen in drei Kritikalitätsstufen: niedrig, mittel und hoch. Betrachtet man die Verteilung nach „Schweregrad“, scheint es nicht so schlimm zu sein. Hochkritische Schwachstellen sind rar, die meisten sind nicht kritisch:
Aber nicht kritische Schwachstellen sind nicht gleich harmlos. Auch sie können erheblichen Schaden anrichten.
Top „nicht kritische“ Schwachstellen
- Schwachstellen im Zusammenhang mit gemischtem Inhalt.
Der Sicherheitsstandard für Websites ist die Übertragung von Daten zwischen Client und Server über das HTTPS-Protokoll, das Verschlüsselung unterstützt und Informationen vor Abhörung schützt.
Einige Websites verwenden gemischten Inhalt: sie übertragen Teile der Daten über das ungesicherte HTTP-Protokoll. Häufig übertragen sie passiven Inhalt – Informationen, die nur das Erscheinungsbild der Seite beeinflussen: Bilder, CSS-Stile. Aber manchmal wird auch aktiver Inhaltübertragen: Skripte, die das Verhalten der Website steuern. In diesem Fall kann spezielle Software die vom Server empfangenen Informationen mit aktivem Inhalt analysieren, die Antworten in Echtzeit modifizieren und die Maschine dazu bringen, anders zu arbeiten, als von ihren Schöpfern vorgesehen.
Webbrowser neuerer Versionen warnen die Benutzer, dass Websites mit gemischtem Inhalt unsicher sind, und blockieren Inhalte. Webentwickler erhalten ebenfalls Warnungen vom Browser in der Konsole. So sieht das beispielsweise aus in :
Wie gefährlich ist: Angreifer verwenden das ungesicherte Protokoll, um Benutzerinformationen abzufangen, Skripte zu manipulieren und Anfragen im Namen der Website zu senden. Selbst wenn ein Besucher der Website keine Daten eingegeben hat, schützt das nicht vor Phishing – Über das Herausfiltern vertraulicher Informationen durch betrügerische Methoden. Beispielsweise kann mit einem Skript der Benutzer auf eine unsichere Website umgeleitet werden, die sich als bekannt ausgibt. In einigen Fällen sieht die böswillige Website sogar besser aus als das Original, und der Benutzer kann das Formular selbst ausfüllen und vertrauliche Daten übermitteln.Was Webentwickler beachten sollten: Selbst wenn der Website-Administrator ein SSL/TLS-Zertifikat installiert und konfiguriert hat, kann eine Schwachstelle durch den menschlichen Faktor entstehen. Zum Beispiel, wenn auf einer der Seiten kein relativer, sondern ein absoluter Link mit http gesetzt wurde und zudem keine Weiterleitungen von http nach https eingerichtet wurden.
Gemischte Inhalte auf einer Website können mithilfe des Browsers festgestellt werden: durch Durchsuchen des Quellcodes der Seite oder Lesen von Benachrichtigungen in der Entwicklerkonsole. Allerdings wird der Entwickler lange und mühsam im Code wühlen müssen. Der Prozess kann mit automatisierten Analysetools wie folgt beschleunigt werden: , kostenlose Software Lighthouse oder kostenpflichtige Software Screaming Frog SEO Spider.
Eine Schwachstelle kann auch durch Probleme mit Legacy-Code entstehen – Code, der geerbt wurde. Zum Beispiel, wenn Teile der Seiten nach einer alten Vorlage generiert werden, die den Übergang der Websites zu https nicht berücksichtigt.
- Cookies ohne die Flags „HTTPOnly“ und „secure“.
Das Attribut „HTTPOnly“ schützt Cookies vor der Verarbeitung durch Skripte, die von Angreifern zur Stehlen von Benutzerdaten verwendet werden. Das Flag „secure“ erlaubt die Übertragung von Cookies nicht im Klartext. Der Datenaustausch ist nur erlaubt, wenn für die Übertragung von Cookies das sichere Protokoll HTTPS verwendet wird.
Beide Attribute werden in den Eigenschaften der Cookies festgelegt:
Set-Cookie: Secure; HttpOnlyWie gefährlich ist: Wenn der Website-Entwickler diese Attribute nicht angegeben hat, kann ein Angreifer Benutzerdaten aus den Cookies abfangen und missbrauchen. Wenn Cookies zur Authentifizierung und Autorisierung verwendet werden, kann er die Benutzersitzung übernehmen und im Namen des Benutzers auf der Website handeln.
Was Webentwickler beachten sollten: In der Regel werden diese Attribute in beliebten Frameworks automatisch gesetzt. Aber überprüfen Sie dennoch die Konfiguration des Webservers und setzen Sie das Flag: Set-Cookie HttpOnly; Secure.
Dabei macht das Attribut „HTTPOnly“ die Cookies auch für Ihr eigenes JavaScript unsichtbar.
- Path-Based Vulnerabilities („pfadbasierte“ Schwachstellen).
Der Scanner meldet solche Sicherheitsanfälligkeiten, wenn er eine öffentlich zugängliche Datei oder ein Verzeichnis der Website mit potenziell vertraulichen Informationen findet. Zum Beispiel entdeckt er einzelne Dateien mit Systemkonfigurationen oder den Zugriff auf das gesamte Dateisystem. Diese Situation kann auftreten, wenn die Zugriffsrechte auf der Website falsch eingestellt sind.
Wie gefährlich ist: Wenn das Dateisystem "nach außen zeigt", kann ein Angreifer in die Benutzeroberfläche des Betriebssystems eindringen und versuchen, Ordner mit Passwörtern zu finden, falls sie im Klartext gespeichert sind (so sollte man es nicht machen!). Oder er kann Passwort-Hashes stehlen und versuchen, das Passwort zu knacken, sowie versuchen, Privilegien im System zu erhöhen und tiefer in die Infrastruktur vorzudringen.
Was Webentwickler beachten sollten: Vergessen Sie nicht die Zugriffsrechte und konfigurieren Sie die Plattform, den Webserver, die Webanwendung so, dass es nicht möglich ist, aus dem Webverzeichnis "zu entweichen".
- Formulare zur Eingabe vertraulicher Daten mit aktivierter Auto-Completion-Funktion.
Wenn ein Benutzer häufig Formulare auf Websites ausfüllt, speichert sein Browser diese Informationen mithilfe der Auto-Completion-Funktion.
Formulare auf Websites können Felder mit vertraulichen Informationen enthalten, beispielsweise Passwörter oder Kreditkartennummern. Für solche Felder sollte die Auto-Completion-Funktion auf der Website deaktiviert werden.
Wie gefährlich ist: Wenn der Browser des Benutzers vertrauliche Informationen speichert, kann ein Angreifer sie später abfangen, beispielsweise durch Phishing. Im Grunde genommen setzen Webentwickler, die diesen Aspekt vergessen, ihre Benutzer einem Risiko aus.
Was Webentwickler beachten sollten: In diesem Fall haben wir einen klassischen Konflikt: Komfort vs. Sicherheit. Wenn der Webentwickler an den Komfort des Benutzers denkt, kann er bewusst die Auto-Completion wählen. Beispielsweise wenn es wichtig ist, den – Richtlinien zur Barrierefreiheit von Inhalten für Benutzer mit Behinderungen.
Für die meisten Browser kann die Auto-Completion mit dem Attribut autocompete="off" deaktiviert werden, beispielsweise:
<body> <form action="/de/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="Vorname"> </div> <div> <input type="text" id="lname" placeholder="Nachname" autocomplete="on"> </div> <div> <input type="number" placeholder="Kreditkartennummer"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="de"/></form> </body>Aber für Chrome funktioniert das nicht. Dies wird durch JavaScript umgangen, eine Rezeptvariante findet man .
- Im Code der Website ist der Header X-Frame-Options nicht gesetzt.
Dieser Header beeinflusst die Tags frame, iframe, embed oder object. Mit ihm kann das Einbetten Ihrer Website in ein Frame vollständig untersagt werden. Dazu muss der Wert X-Frame-Options: deny angegeben werden. Alternativ kann X-Frame-Options: sameorigin verwendet werden, wodurch das Einbetten in ein iframe nur auf Ihrer Domain möglich ist.
Wie gefährlich ist: Das Fehlen eines solchen Headers kann auf bösartigen Websites für Clickjackingverwendet werden. Bei einem solchen Angriff erstellt der Angreifer ein transparentes Frame über Schaltflächen und täuscht den Benutzer. Zum Beispiel platzieren Betrüger ein Frame auf der Website sozialer Netzwerke. Der Benutzer denkt, er klickt auf eine Schaltfläche auf dieser Website. Stattdessen wird der Klick abgefangen und die Anfrage des Benutzers wird an das soziale Netzwerk gesendet, in dem eine aktive Sitzung besteht. Auf diese Weise versenden die Angreifer Spam im Namen des Benutzers oder manipulieren Abonnenten und Likes.
Wenn diese Möglichkeit nicht untersagt wird, kann ein Angreifer die Schaltfläche Ihrer Anwendung auf einer bösartigen Website platzieren. Er könnte an Ihrem Partnerprogramm oder an Ihren Benutzern interessiert sein.
Was Webentwickler beachten sollten: Eine Schwachstelle kann auftreten, wenn X-Frame-Options mit einem konfliktreichen Wert auf dem Webserver oder dem Lastenverteilerserver gesetzt wird. In diesem Fall werden der Server und der Lastenverteilerserver den Header einfach überschreiben, da sie eine höhere Priorität im Vergleich zum Backend-Code haben.
Die Werte deny und sameorigin des Headers X-Frame-Options würden die Arbeit des Yandex Webvisors behindern. Um die Verwendung von iframe für den Webvisor zu ermöglichen, muss eine separate Regel in den Einstellungen geschrieben werden. Zum Beispiel kann man für nginx folgendes konfigurieren:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Schwachstellen PRSSI (Path-relative stylesheet import).
Dies ist eine Schwachstelle in den Styles der Website. Sie tritt auf, wenn relative Links wie href="/somefolder/styles.css/" verwendet werden, um auf Stylesheets zuzugreifen. Ein Angreifer wird dies ausnutzen, wenn er einen Weg findet, den Benutzer auf eine bösartige Seite zu leiten. Die Seite wird den relativen Link in ihrer URL unterbringen und den Zugriff auf die Styles imitieren. Es ergibt sich eine Anfrage wie badsite.ru/…/somefolder/styles.css/, die unter dem Vorwand eines Styles bösartige Aktionen durchführen kann.
Wie gefährlich ist: Ein Betrüger kann diese Schwachstelle ausnutzen, wenn er eine weitere Sicherheitslücke findet. Dadurch können Benutzerdaten aus Cookies oder Tokens gestohlen werden.
Was Webentwickler beachten sollten: Setzen Sie den Header X-Content-Type-Options: nosniff. In diesem Fall überprüft der Browser den Inhaltstyp für Styles. Wenn der Typ von text/css abweicht, blockiert der Browser die Anfrage.
Kritische Schwachstellen
- Die Seite mit dem Passwortfeld wird über einen ungesicherten Kanal bereitgestellt (HTML-Formular mit Passwortfeld(en) wird über HTTP bereitgestellt).
Die Antwort vom Server über einen unverschlüsselten Kanal ist anfällig für Man-in-the-Middle-Angriffe. Ein Angreifer kann den Verkehr abfangen und sich zwischen Client und Server schalten, während die Seite vom Server zum Client übertragen wird.
Wie gefährlich ist: Ein Betrüger kann die Seite manipulieren und dem Benutzer ein Formular für vertrauliche Daten senden, die an den Server des Angreifers gesendet werden.
Was Webentwickler beachten sollten: Einige Websites senden anstelle eines Passworts einen Einmal-Code an die E-Mail/Telefonnummer der Benutzer. In diesem Fall ist die Schwachstelle nicht so kritisch, jedoch erschwert der Mechanismus den Benutzern das Leben.
- Absenden des Formulars mit Benutzername und Passwort über einen ungesicherten Kanal (Login-Formular wird nicht über HTTPS gesendet).
In diesem Fall wird vom Benutzer ein Formular mit Benutzername und Passwort über einen unverschlüsselten Kanal an den Server gesendet.
Wie gefährlich ist: Im Gegensatz zum vorherigen Fall handelt es sich hierbei um eine kritische Schwachstelle. Es ist einfacher, vertrauliche Daten abzufangen, da hierfür nicht einmal Code geschrieben werden muss.
- Verwendung von JavaScript-Bibliotheken mit bekannten Schwachstellen.
Während der Scanzeit wurde jQuery zur am häufigsten verwendeten Bibliothek mit einer breiten Palette von Versionen. In jeder der Versionen gibt es mindestens eine, wenn nicht sogar mehrere bekannte Schwachstellen. Die Auswirkungen können unterschiedlich sein – abhängig von der Art der Schwachstelle.
Wie gefährlich ist: Für bekannte Schwachstellen gibt es Exploits, zum Beispiel diese:
Was Webentwickler beachten sollten: Kehren Sie regelmäßig zum Zyklus zurück: Suche nach bekannten Schwachstellen – Behebung – Überprüfung. Wenn Sie veraltete Bibliotheken bewusst verwenden, beispielsweise um alte Browser zu unterstützen oder um Kosten zu sparen, suchen Sie nach Möglichkeiten, bekannte Schwachstellen zu beheben. - Cross-Site Scripting (XSS).
Cross-Site Scripting (XSS), oder Cross-Site-Skripte, sind Angriffe auf Webanwendungen, bei denen schädlicher Code in der Datenbank erscheint. Wenn Qualys eine solche Schwachstelle findet, kann ein potenzieller Angreifer einen eigenen JS-Skript-Code in die Seite einfügen oder hat dies bereits getan, um schädliche Aktionen durchzuführen.Stored XSS (Gespeicherte XSS) sind gefährlicher, da das Skript auf dem Server eingefügt wird und jedes Mal ausgeführt wird, wenn die angegriffene Seite im Browser geöffnet wird.
Reflected XSS (Reflektierte XSS) ist einfacher durchzuführen, da ein böswilliges Skript in eine HTTP-Anfrage eingesetzt werden kann. Die Anwendung erhält die HTTP-Anfrage, überprüft die Daten nicht, packt sie ein und sendet sie sofort. Wenn der Angreifer den Datenverkehr abfängt und ein Skript vom Typ
<script>/*+что+то+плохое+*/</script>einfügt, wird eine schädliche Anfrage im Namen des Clients gesendet.
Ein prägnantes Beispiel für XSS sind JS-Sniffer, die Seiten zum Eingeben von CVC, Ablaufdatum der Karte usw. imitieren.
Was Webentwickler beachten sollten: Im Header Content-Security-Policy verwenden Sie das Attribut script-src, damit der Client-Browser nur Code von einer vertrauenswürdigen Quelle lädt und ausführt. Zum Beispiel setzt script-src 'self' alle Skripte von unserer Website auf die Whitelist.
Als beste Praxis gilt Inline-Code: Erlauben Sie nur Inline-Javascript mit dem Wert unsafe-inline. Dieser Wert erlaubt die Verwendung von Inline-JS/CSS, verbietet jedoch nicht das Einfügen von JS-Dateien. In Kombination mit script-src 'self' verbieten wir die Ausführung externer Skripte.Loggen Sie unbedingt alles über report-uri und beobachten Sie die Versuche, in die Webseite einzudringen.
- SQL-Injection.
Eine Schwachstelle zeigt die Möglichkeit an, SQL-Code auf die Website einzubringen, der direkt auf die Datenbank der Website zugreift. Eine SQL-Injektion ist möglich, wenn Benutzerdaten nicht escapes werden: Sie werden nicht auf Gültigkeit geprüft und direkt in der Anfrage verwendet. Zum Beispiel passiert dies, wenn ein Formular auf der Website die Eingaben nicht auf den Datentyp überprüft.Wie gefährlich ist: Wenn ein Angreifer in ein solches Formular eine SQL-Anfrage eingibt, kann er die Datenbank zum Absturz bringen oder vertrauliche Informationen preisgeben.
Was Webentwickler beachten sollten: Vertrauen Sie nicht dem, was vom Browser kommt. Schutzmaßnahmen sollten sowohl auf der Client- als auch auf der Serverseite ergriffen werden.
Auf der Client-Seite implementieren Sie eine Überprüfung der Felder mit JavaScript.
Integrierte Funktionen in beliebten Frameworks helfen ebenfalls dabei, verdächtige Zeichen auf dem Server zu maskieren. Es wird auch empfohlen, parametrische Abfragen für Datenbanken auf dem Server zu verwenden.
Bestimmen Sie, wo genau die Interaktion mit der Datenbank in der Webanwendung stattfindet.
Interaktion entsteht, wenn wir Informationen erhalten: eine Anfrage mit einer ID (Änderung der ID), die Erstellung eines neuen Benutzers, ein neuer Kommentar – neue Einträge in der Datenbank. Hier können SQL-Injektionen auftreten. Selbst beim Löschen eines Eintrags aus der Datenbank ist eine SQL-Injektion möglich.
Allgemeine Empfehlungen
Erfinden Sie das Rad nicht neu – verwenden Sie bewährte Frameworks.. In der Regel sind beliebte Frameworks sicherer. Für .NET sind das 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 Spring MVC.
Achten Sie auf die Updates des Anbieters und aktualisieren Sie regelmäßig.. Eine Schwachstelle wird gefunden, dann wird ein Exploit geschrieben, öffentlich gemacht, und alles beginnt von neuem. Melden Sie sich für Updates zu stabilen Versionen vom Softwareanbieter an.
Überprüfen Sie die Zugriffsrechte.. Auf der Serverseite sollten Sie immer Ihren Code so behandeln, als wäre er von Ihrem ärgsten Feind verfasst, der darauf aus ist, Ihre Website zu zerstören und die Integrität Ihrer Daten zu verletzen. Zumal es manchmal tatsächlich so ist.
Verwenden Sie Klone, Testumgebungen, und gehen Sie erst dann in die Produktion.. Das hilft, um Fehler in der Produktionsumgebung zu vermeiden: die Produktionsumgebung bringt Geld, Ausfallzeiten sind kritisch. Bei der Hinzufügung, Korrektur oder Behebung eines Problems sollte die Arbeit zunächst in einer Testumgebung durchgeführt, die Funktionalität und entdeckten Schwachstellen überprüft und anschließend die Arbeit mit der Produktionsumgebung geplant werden.
Schützen Sie die Webanwendung mithilfe von und integrieren Sie damit Berichte von Schwachstellenscannern.. Beispielsweise werden bei DataLine als Verbindung zwischen den Diensten Qualys und FortiWeb verwendet.
Quelle: habr.com
