Vor etwa einem Jahr haben wir bei DataLine ein Tool zur Suche und Analyse von Schwachstellen in IT-Anwendungen eingeführt. Die Grundlage des Services ist die Cloud-Lösung Qualys, über deren Funktionalitäten . Im Laufe eines Jahres haben wir 291 Scans für unterschiedliche Websites durchgeführt und eine Statistik zu häufigsten Schwachstellen in Webanwendungen gesammelt.
Im folgenden Artikel zeige ich Ihnen, welche Sicherheitslücken sich hinter den verschiedenen Kritikalitätsstufen verbergen. Lassen Sie uns die Schwachstellen betrachten, die der Scanner besonders häufig gefunden hat, warum sie auftreten können und wie man sich schützt.
Qualys kategorisiert alle Schwachstellen von Webanwendungen in drei Kritikalitätsstufen: niedrig, mittel und hoch. Wenn man sich die Verteilung nach ‚Schwere‘ anschaut, scheint es, als wäre die Lage nicht so schlecht. Es gibt nur wenige Schwachstellen mit hohem Kritikalitätsgrad, die Mehrheit ist unkritisch:
Aber unkritisch bedeutet nicht harmlos. Sie können ebenfalls erhebliche Schäden verursachen.
Die häufigsten „unkritischen“ Schwachstellen
- Schwachstellen im Zusammenhang mit gemischtem Inhalt.
Als Sicherheitsstandard für Websites gilt die Übertragung von Daten zwischen dem Client und dem Server über das HTTPS-Protokoll, das Verschlüsselung unterstützt und Informationen vor Abfangen schützt.
Einige Websites verwenden gemischte Inhalte: sie übertragen einen Teil der Daten über das ungeschützte HTTP-Protokoll. Oft handelt es sich dabei um statische Inhalte : Informationen, die nur die Darstellung der Website beeinflussen, wie Bilder und CSS-Stile. Manchmal werden jedoch auch dynamische Inhalte: Skripte, die das Verhalten der Website steuern, auf diese Weise übertragen. Dabei kann spezielle Software die vom Server kommenden Informationen mit dynamischen Inhalten analysieren, ihre Antworten in Echtzeit ändern und den Computer dazu bringen, anders zu funktionieren, als es seine Entwickler beabsichtigt hatten.
Moderne Browser warnen die Benutzer, dass Websites mit gemischten Inhalten unsicher sind, und blockieren den Inhalt. Auch die Entwickler von Websites erhalten Warnmeldungen vom Browser in der Konsole. So sieht das beispielsweise in :
aus. Was ist die Gefahr?: Angreifer nutzen ungesicherte Protokolle, um Benutzerdaten abzufangen, Skripte zu manipulieren und Anfragen im Namen des Nutzers an die Website zu senden. Selbst wenn der Besucher der Website keine Daten eingegeben hat, schützt ihn das nicht vor Phishing – dem Abgreifen von vertraulichen Informationen durch betrügerische Methoden. Beispielsweise kann ein Skript den Benutzer auf eine unsichere Website umleiten, die sich als für ihn vertraut ausgibt. In einigen Fällen sieht die bösartige Website sogar besser aus als das Original, und der Benutzer könnte die Formulare selbst ausfüllen und vertrauliche Informationen übermitteln.Was Webentwickler beachten sollten: Selbst wenn der Administrator der Website ein SSL/TLS-Zertifikat installiert und konfiguriert hat, können Schwachstellen aufgrund menschlicher Fehler entstehen. Zum Beispiel, wenn auf einer der Seiten ein absoluter Link mit http anstelle eines relativen Links gesetzt wurde und zusätzlich keine Weiterleitungen von http auf https eingerichtet wurden.
Mischinhalte auf einer Website können mithilfe des Browsers erkannt werden: Durchsuchen Sie den Quellcode der Seite oder lesen Sie Benachrichtigungen in der Entwicklerkonsole. Allerdings muss der Entwickler oft mühsam im Code suchen. Der Prozess kann mit automatisierten Analysetools beschleunigt werden, zum Beispiel: , das freie Tool Lighthouse oder die kostenpflichtige Software Screaming Frog SEO Spider.
Ein weiterer Schwachpunkt kann durch Probleme mit Legacy-Code entstehen – also Code, der vererbt wurde. Zum Beispiel, wenn einige Seiten mit einem alten Template generiert werden, das den Wechsel auf HTTPS nicht berücksichtigt.
- Cookies ohne die Flags "HTTPOnly" und "secure".
Das Attribut "HTTPOnly" schützt die Cookies vor der Verarbeitung durch Skripte, die von Angreifern verwendet werden, um Benutzerdaten zu stehlen. Das Flag „secure“ erlaubt nicht die Übertragung von Cookies im Klartext. Der Datenaustausch wird nur gestattet, wenn die Cookies über das sichere Protokoll HTTPS gesendet werden.
Beide Attribute werden in den Cookie-Eigenschaften festgelegt:
Set-Cookie: Secure; HttpOnlyaus. Was ist die Gefahr?: Wenn der Webentwickler diese Attribute nicht festgelegt hat, kann ein Angreifer Benutzerdaten aus Cookies abfangen und missbrauchen. Wenn Cookies für die Authentifizierung und Autorisierung verwendet werden, kann er die Benutzersitzung übernehmen und im Namen des Nutzers auf der Website agieren.
Was Webentwickler beachten sollten: In der Regel werden diese Attribute in gängigen Frameworks automatisch eingestellt. Überprüfen Sie dennoch die Konfiguration des Webservers und setzen Sie das Flag: Set-Cookie HttpOnly; Secure.
Das Attribut „HTTPOnly“ macht die Cookies jedoch auch für Ihr eigenes JavaScript unsichtbar.
- Path-Based Vulnerabilities („pfadbasierte“ Schwachstellen).
Der Scanner meldet eine solche Schwachstelle, wenn er eine öffentlich zugängliche Datei oder ein Verzeichnis der Website mit potenziell vertraulichen Informationen findet. Zum Beispiel, wenn er individuelle Dateien mit Systemkonfigurationen oder den vollständigen Zugriff auf das Dateisystem entdeckt. Eine solche Situation kann auftreten, wenn auf der Website die Zugriffsrechte falsch eingestellt sind.
aus. Was ist die Gefahr?: Wenn das Dateisystem "nach außen schaut", kann ein Angreifer in die Benutzeroberfläche des Betriebssystems eindringen und versuchen, Ordner mit Passwörtern zu finden, wenn diese unverschlüsselt gespeichert sind (das sollte man vermeiden!). Alternativ kann er Hashes von Passwörtern stehlen und durch Ausprobieren ein Passwort finden. Zudem könnte er versuchen, seine Berechtigungen im System zu erhöhen und sich tiefer in die Infrastruktur vorzuwagen.
Was Webentwickler beachten sollten: 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 vertraulicher Daten mit aktivierter Autocomplete-Funktion.
Wenn ein Benutzer häufig Formulare auf Websites ausfüllt, speichert sein Browser diese Informationen über die Autocomplete-Funktion.
Formulare auf Websites können Felder mit vertraulichen Informationen enthalten, wie z.B. Passwörter oder Kreditkartennummern. Für solche Felder sollte die Autocomplete-Funktion auf der Website deaktiviert werden.
aus. Was ist die Gefahr?: Wenn der Browser des Nutzers sensible Informationen speichert, kann ein Angreifer diese später abfangen, beispielsweise durch Phishing. Im Grunde genommen setzt ein Webentwickler, der diesen Faktor vergisst, seine Nutzer einem Risiko aus.
Was Webentwickler beachten sollten: In diesem Fall haben wir einen klassischen Konflikt: Komfort vs. Sicherheit. Wenn ein Webentwickler an den Komfort des Nutzers denkt, könnte er sich bewusst für die Autovervollständigung entscheiden. Zum Beispiel, wenn es wichtig ist, den Vorgaben zu folgen. – Richtlinien zur Barrierefreiheit von Inhalten für Nutzer mit Einschränkungen.
Für die meisten Browser kann die Autovervollständigung mit dem Attribut autocompete="off" deaktiviert werden, zum Beispiel:
<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>Doch für Chrome funktioniert das nicht. Dies wird in der Regel mit JavaScript umgangen, ein Rezept dafür findet sich .
- Im Code der Webseite ist der Header X-Frame-Options nicht festgelegt.
Dieser Header hat Auswirkungen auf die Tags frame, iframe, embed oder object. Damit kann man das Einbetten der eigenen Webseite innerhalb eines Frames vollständig verbieten. Dafür muss der Wert X-Frame-Options: deny festgelegt werden. Alternativ kann man X-Frame-Options: sameorigin angeben, wodurch das Einbetten im iframe nur auf der eigenen Domain möglich ist.
aus. Was ist die Gefahr?: Das Fehlen eines solchen Headers kann auf bösartigen Webseiten für Clickjackingverwendet werden. Bei einem solchen Angriff erstellt der Angreifer einen transparenten Frame über den Schaltflächen und täuscht den Benutzer. Beispielsweise platzieren Betrüger einen Frame auf der Webseite sozialer Netzwerke. Der Benutzer glaubt, er klickt auf eine Schaltfläche auf dieser Seite. Stattdessen wird der Klick abgefangen und eine Anfrage des Benutzers an das soziale Netzwerk gesendet, wo eine aktive Sitzung besteht. So versenden die Angreifer Spam im Namen des Benutzers oder manipulieren Abonnenten und Likes.
Wenn diese Möglichkeit nicht ausgeschlossen wird, kann der Angreifer eine Schaltfläche Ihrer Anwendung auf einer bösartigen Webseite platzieren. Er könnte an Ihrem Partnerprogramm oder an Ihren Benutzern interessiert sein.
Was Webentwickler beachten sollten: Eine Schwachstelle kann auftreten, wenn die X-Frame-Options mit einem konfliktierenden Wert auf dem Webserver oder Lastenausgleichsgerät festgelegt sind. In diesem Fall überschreibt der Server und der Lastenausgleich einfach den Header, da sie eine höhere Priorität haben im Vergleich zum Backend-Code.
Die Werte deny und sameorigin des X-Frame-Options-Headers beeinträchtigen die Funktion des Yandex-Webvisors. Um die Verwendung von iframes für den Webvisor zu ermöglichen, muss eine separate Regel in den Einstellungen erstellt werden. Zum Beispiel kann dies für nginx so konfiguriert werden:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI-Schwachstellen (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 kann dies ausnutzen, wenn er einen Weg findet, den Benutzer auf eine bösartige Seite umzuleiten. Die Seite fügt die relative URL in ihre Adresse ein und simuliert den Zugriff auf die Styles. Dadurch entsteht eine Anfrage wie badsite.ru/.../somefolder/styles.css/, die unter dem Vorwand eines Styles schädliche Aktionen durchführen kann.
aus. Was ist die Gefahr?: 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 prü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 vom Server übertragen (HTML-Formular mit Passwortfeld(en) wird über HTTP bereitgestellt).
Antworten vom Server über einen unverschlüsselten Kanal sind anfällig für Angriffe vom Typ "Man-in-the-Middle". Ein Angreifer kann den Datenverkehr abfangen und sich zwischen den Client und den Server schalten, während die Seite vom Server zum Client läuft.
aus. Was ist die Gefahr?: Ein Betrüger könnte die Seite manipulieren und dem Benutzer ein Formular für vertrauliche Daten senden, die dann an den Server des Angreifers gesendet werden.
Was Webentwickler beachten sollten: Einige Webseiten senden anstelle eines Passworts einen Einmalcode an die E-Mail/Telefonnummer der Benutzer. In diesem Fall ist die Schwachstelle nicht so kritisch, doch der Mechanismus erschwert den Nutzern das Leben.
- Das Senden des Formulars mit Benutzername und Passwort über einen ungesicherten Kanal (Anmeldeformular wird nicht über HTTPS übermittelt).
In diesem Fall wird vom Benutzer eine Formular mit Benutzername und Passwort über einen unverschlüsselten Kanal an den Server gesendet.
aus. Was ist die Gefahr?: Im Gegensatz zum vorherigen Fall handelt es sich hierbei bereits um eine kritische Sicherheitsanfälligkeit. Es ist einfacher, sensible Daten abzufangen, da hierfür nicht einmal Code geschrieben werden muss.
- Verwendung von JavaScript-Bibliotheken mit bekannten Sicherheitsanfälligkeiten.
Während des Scanvorgangs wurde jQuery zur meistgenutzten Bibliothek, die eine umfangreiche Versionenanzahl aufweist. In jeder Version gibt es mindestens eine, häufig jedoch mehrere bekannte Schwachstellen. Die Auswirkungen können unterschiedlich sein – abhängig von der Art der Sicherheitsanfälligkeit.
aus. Was ist die Gefahr?: Für bekannte Sicherheitsanfälligkeiten gibt es Exploits, wie beispielsweise:
Was Webentwickler beachten sollten: Kehren Sie regelmäßig zum Zyklus zurück: Suche nach bekannten Sicherheitsanfälligkeiten – Behebung – Überprüfung. Wenn Sie absichtlich veraltete Bibliotheken verwenden, etwa zur Unterstützung älterer Browser oder zur Kostensenkung, suchen Sie nach Möglichkeiten zur Behebung der bekannten Sicherheitsanfälligkeit. - Cross-Site-Skripte (XSS).
Cross-Site-Scripting (XSS) oder Cross-Site-Skripte sind Angriffe auf Webanwendungen, bei denen schadhafter Code in der Datenbank eingebettet wird. Wenn Qualys eine solche Sicherheitsanfälligkeit entdeckt, bedeutet das, dass ein potenzieller Angreifer seinen js-Skript in den Code der Website einfügen kann oder bereits eingefügt hat, um schädliche Aktionen auszuführen.Stored XSS (XSS gespeichert) sind gefährlicher, da das Skript auf dem Server implementiert wird und jedes Mal ausgeführt wird, wenn die angegriffene Seite im Browser geöffnet wird.
Reflected XSS (XSS reflektiert) sind einfacher durchzuführen, da das bösartige Skript in die HTTP-Anfrage eingebettet werden kann. Die Anwendung erhält die HTTP-Anfrage, überprüft die Daten nicht, verpackt sie und sendet sie sofort. Wenn der Angreifer den Datenverkehr abfängt und ein Skript wie
<script>/*+что+то+плохое+*/</script>einfügt, wird eine bösartige Anfrage im Namen des Clients gesendet.
Ein anschauliches Beispiel für XSS: JS-Sniffer, die Seiten zur Eingabe von CVC, Ablaufdatum der Karte usw. nachahmen.
Was Webentwickler beachten sollten: Verwenden Sie im Header Content-Security-Policy das Attribut script-src, damit der Browser des Clients nur Code von einer vertrauenswürdigen Quelle lädt und ausführt. Beispielsweise erlaubt script-src 'self' Skripte nur von unserer Website.
Die beste Praxis besteht darin, Inline-Code zu erlauben: Erlauben Sie nur Inline-JavaScript mit dem Wert unsafe-inline. Dieser Wert erlaubt die Verwendung von Inline-JS/CSS, aber verbietet nicht das Einbinden von JS-Dateien. In Kombination mit script-src 'self' verbieten wir das Ausführen von externen Skripten.Stellen Sie sicher, dass Sie alles mit report-uri protokollieren und versuchen, Einfügungen in die Website zu erkennen.
- SQL-Injektionen.
Diese Schwachstelle ermöglicht das Einfügen von SQL-Code in die Website, der direkt auf die Datenbank zugreift. Eine SQL-Injektion tritt auf, wenn Benutzerdaten nicht geprüft und direkt in Anfragen verwendet werden. Dies passiert beispielsweise, wenn ein Formular auf der Website keine Eingabewerte auf ihren Datentyp überprüft.aus. Was ist die Gefahr?: Wenn ein Angreifer eine solche Anfrage in ein Formular eingibt, kann er die Datenbank zum Absturz bringen oder vertrauliche Informationen preisgeben.
Was Webentwickler beachten sollten: Vertrauen Sie nicht darauf, was vom Browser kommt. Es ist wichtig, sowohl auf der Client- als auch auf der Serverseite Schutzmaßnahmen zu ergreifen.
Führen Sie auf der Client-Seite eine Überprüfung der Eingabefelder mit JavaScript durch.
Eingebaute Funktionen in gängigen Frameworks helfen ebenfalls, verdächtige Zeichen auf dem Server zu maskieren. Es wird auch empfohlen, auf dem Server parameterisierte Datenbankabfragen zu verwenden.
Bestimmen Sie, wo genau das Interagieren mit der Datenbank in der Webanwendung erfolgt.
Interaktion tritt auf, wenn wir Informationen erhalten: eine Anfrage mit der ID (ID-Änderung), die Erstellung eines neuen Benutzers, ein neuer Kommentar – neue Einträge in der Datenbank. Hier können SQL-Injection-Angriffe auftreten. Selbst wenn wir einen Eintrag aus der Datenbank löschen, könnte eine SQL-Injektion möglich sein.
Allgemeine Empfehlungen
Erfinden Sie das Rad nicht neu – verwenden Sie bewährte Frameworks. In der Regel sind populäre 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 mit Express.js, für Java – Spring MVC.
Achten Sie auf Vendor-Updates und aktualisieren Sie regelmäßig. Eine Schwachstelle wird entdeckt, dann wird ein Exploit geschrieben, veröffentlicht und alles wiederholt sich. Abonnieren Sie die Updates für stabile Versionen des Softwareanbieters.
Überprüfen Sie die Zugriffsrechte. Behandeln Sie Ihren Code von der Server-Seite immer so, als ob er von Ihrem ärgsten Feind geschrieben wurde, der versucht, Ihre Website zu hacken und die Integrität Ihrer Daten zu verletzen. Manchmal ist es tatsächlich so.
Verwenden Sie Klone, Testumgebungen und implementieren Sie Änderungen erst dann in die Produktionsumgebung. Das hilft, um in erster Linie Fehler und Pannen in der Produktivumgebung zu vermeiden: Die Produktivumgebung bringt Geld, und Ausfallzeiten sind in der Produktivumgebung kritisch. Bei der Hinzufügung, Korrektur oder Schließung eines Problems sollten Arbeiten in einer Testumgebung durchgeführt werden, dann die Funktionalität und entdeckte Schwachstellen überprüft werden, bevor die Arbeiten an der Produktivumgebung geplant werden.
Schützen Sie die Webanwendung mithilfe von und integrieren Sie Berichte von Vulnerability-Scannern. Zum Beispiel werden bei DataLine die Dienste Qualys und FortiWeb als Kombination genutzt.
Quelle: habr.com
