Share
Dank HTML5 werden immer mehr Anwendungslogiken von Server zu Client übertragen. Dies erfordert, dass Front-End-Entwickler sich mehr auf die Sicherheit konzentrieren. In diesem Artikel werde ich Ihnen zeigen, wie Sie Ihre Apps sicherer machen können. Ich werde mich auf Techniken konzentrieren, von denen Sie vielleicht noch nichts gehört haben, anstatt Ihnen zu sagen, dass Sie die von Benutzern eingegebenen HTML-Daten schützen müssen.
Natürlich möchte ich nicht, dass Sie Ihre Inhalte mit FTP oder einfachem TCP bereitstellen. Ich meine damit, dass Sie SSL (HTTPS) verwenden müssen, wenn Sie möchten, dass Ihre Benutzer bei der Verwendung Ihrer Website sicher sind. Und das nicht nur für Login-Sites oder wertvolle Informationen. Für alle Inhalte. Andernfalls, wenn jemand über ein öffentliches Netzwerk auf Ihre App zugreift, kann das, was er sieht, von einem Hacker innerhalb dieses Netzwerks verfälscht werden. Dies wird als Main-in-the-Middle-Angriff bezeichnet:
Wenn Sie SSL verwenden, werden alle Daten vor dem Senden verschlüsselt. Selbst wenn der Angreifer sie erhält, kann er sie nicht ändern oder erfassen. Dies ist bei weitem der wichtigste Schritt zur Sicherung Ihrer App.
Dieser HTTP-Header kann nützlich sein, wenn Sie Ihre Inhalte nur mit SSL bereitstellen möchten. Wenn es vom Server ausgegeben wird (oder a tag, aber damit mindestens eine Anforderung HTTP ist), wird kein unsicherer Datenverkehr vom Browser zu Ihrem Server kommen. Es wird so verwendet:
Strict-Transport-Security: maximales Alter = 3600; includeSubDomains
Das includeSubDomains Teil ist optional, damit können Sie festlegen, dass auch alle Subdomains über HTTPS angesprochen werden sollen. Das Maximalalter Diese Option legt fest, wie lange (in Sekunden) die Seiten mit SSL bereitgestellt werden sollen. Leider unterstützen nur Firefox, Chrome und Opera Strict Transport Security.
Eine weitere Möglichkeit, die Sicherheit sowohl für HTTP als auch für HTTPS weiter zu verbessern, sind diese beiden Cookie-Attribute: Sichern und HttpOnly. Beim ersten können Cookies nur bei einer SLL-Verbindung gesendet werden. Das zweite hört sich vielleicht genau umgekehrt an, ist es aber nicht. Dem Browser wird mitgeteilt, dass auf das Cookie nur über das HTTP (S) -Protokoll zugegriffen werden kann, sodass es beispielsweise nicht mithilfe von JavaScript gestohlen werden kann document.cookie.
Mit der Inhaltssicherheitsrichtlinie können Sie den Ursprung aller Skripts, Bilder usw. auf Ihrer Website festlegen.
Wenn Sie glauben, dass Ihr XSS-Filter alle möglichen XSS-Angriffe stoppt, prüfen Sie, wie viele Möglichkeiten bestehen, um diese Angriffe durchzuführen, und überlegen Sie noch einmal. Natürlich kann es ein Problem sein, Ihre App zu stoppen, um alle diese Anwendungen zu stoppen, und sie kann sich verlangsamen, aber es gibt eine Lösung.
Es heißt Content Security Policy. Hier können Sie den Ursprung aller Skripte, Bilder usw. auf Ihrer Site festlegen. Außerdem werden alle Inline-Skripts und -Stile blockiert. Selbst wenn ein Skripttag in einen Kommentar oder Beitrag eingefügt werden kann, wird der Code nicht ausgeführt. Der CSP ist ein HTTP-Header (der auch über HTML gesetzt werden kann) tag), das so aussieht:
Content-Security-Policy: Richtlinie
Woher Politik ist eine Reihe von CSP-Richtlinien. Hier sind die möglichen Optionen:
Wenn keine Direktive festgelegt ist, geht der Browser davon aus, dass alle Ursprünge zulässig sind. Dies kann durch Einstellen von geändert werden default-src Möglichkeit. Was Sie dort einstellen, wird auf alle nicht gesetzten Anweisungen angewendet. Da ist auch ein Sandkasten Option, die die Webseite als iframe mit der lädt Sandkasten Attribut. Ein Beispiel für die Verwendung des CSP-Headers würde folgendermaßen aussehen:
Inhalts-Sicherheits-Richtlinie: default-src: 'self'; script-src: https://apis.google.com;
Es ermöglicht, dass alle Assets nur vom Ursprung der Anwendung (der 'selbst' Attribut) und ermöglicht Ihnen außerdem das Laden von Skripts vom Google-APIs-Server. Die Definition von CSP ist sehr flexibel und führt bei richtiger Anwendung zu einer erheblichen Verbesserung der Sicherheit Ihrer Webseite.
Bei der Verwendung von CSP ist zu beachten, dass standardmäßig nicht alle Inline-JavaScript ausgeführt werden. Dies beinhaltet auch:
Accentsconagua
Javascript URLs: mögen Dies liegt daran, dass der Browser Ihren Inline-Code nicht vom Inline-Code des Hackers unterscheiden kann. Sie müssen sie ersetzen, indem Sie Ereignis-Listener mit hinzufügen addEventListener oder ein gleichwertiges Framework. Dies ist letztlich keine schlechte Sache, da Sie dazu gezwungen werden, die Logik Ihrer Anwendung von der grafischen Darstellung zu trennen, die Sie auf jeden Fall ausführen sollten. CSP blockiert (standardmäßig) auch alle eval ()-ISH-Code, einschließlich Zeichenfolgen setInterval/setTimeout und Code mögen neue Funktion ('return false').
CSP ist in den meisten modernen Browsern verfügbar. Firefox, Chrome und Opera (auch mobil) verwenden den Standard Content-Security-Policy Header. Safari (auch iOS) und Chrome für Android nutzen die X-WebKit-CSP Header. IE10 (mit Unterstützung nur für den Sandkasten Direktive) verwendet X-Content-Security-Policy. Dank Internet Explorer können Sie also nicht nur CSP verwenden (es sei denn, Sie verwenden etwas wie Google Chrome Frame), Sie können es jedoch weiterhin verwenden, um die Sicherheit der echten Browser zu verbessern und Ihre App auf die Zukunft vorzubereiten.
JSONP ist derzeit das am häufigsten verwendete Verfahren, um Ressourcen von anderen Servern trotz der Richtlinie mit demselben Ursprung abzurufen. Normalerweise erstellen Sie einfach die Rückruffunktion in Ihrem Code und übergeben den Namen dieser Funktion an die URL, von der Sie die Daten abrufen möchten, wie folgt:
Funktion parseData (Daten) …
Dadurch entsteht jedoch ein großes Sicherheitsrisiko. Wenn der Server, von dem Sie Daten erhalten, gefährdet ist, kann ein Hacker seinen bösartigen Code hinzufügen und beispielsweise die privaten Daten Ihres Benutzers stehlen, da Sie tatsächlich JavaScript mit dieser Anforderung erhalten - und der Browser führt den gesamten Code einfach aus wie bei einer normalen Skriptdatei.
Die Lösung hier ist Cross Origin Resource Sharing. Ihr Datenprovider kann Ihren Antworten einen speziellen Header hinzufügen, sodass Sie diese Daten mithilfe von XHR abrufen, analysieren und überprüfen können. Dadurch wird das Risiko vermieden, dass auf Ihrer Website schädlicher Code ausgeführt wird.
Für die Implementierung muss der Anbieter nur den folgenden speziellen Header in den Antworten hinzufügen:
Access-Control-Allow-Origin: zulässige Herkunft
Dies können nur einige erlaubte Ursprungspunkte sein, die durch Leerzeichen getrennt sind, oder ein Platzhalterzeichen: * jeden Ursprung die Daten abfragen zu lassen.
Alle aktuellen Versionen moderner Browser unterstützen CORS mit Ausnahme von Opera Mini.
Natürlich besteht das größere Problem darin, dass Dienstanbieter CORS-Unterstützung hinzufügen müssten, sodass sie nicht vollständig vom Entwickler abhängig ist.
Ein iframe mit der
SandkastenDas Attribut kann nicht im Fenster navigieren, Skripts ausführen, den Zeiger sperren, Popups anzeigen oder Formulare senden.
Wenn Sie iframes verwenden, um Inhalte von externen Sites zu laden, möchten Sie diese möglicherweise auch sichern. Dies kann mit der Sandkasten iframe-Attribut Ein iframe mit einem solchen Attribut leer (aber vorhanden) darf nicht im Fenster navigieren, Skripts ausführen, den Zeiger sperren, Popups anzeigen oder Formulare übermitteln. Der Rahmen hat auch einen eindeutigen Ursprung und kann daher nicht verwendet werden lokaler Speicher oder irgendetwas im Zusammenhang mit der Richtlinie mit demselben Ursprung. Sie können natürlich einige davon zulassen, indem Sie einen oder mehrere dieser Werte zum Attribut hinzufügen:
Das Sandkasten Das iframe-Attribut wird in allen modernen Browsern mit Ausnahme von Opera Mini unterstützt.
So, das war es. Ich hoffe, Sie haben einige neue Techniken kennen gelernt, die Sie in Ihren zukünftigen Projekten zum Schutz Ihrer Anwendungen verwenden können. Dank HTML5 können wir jetzt erstaunliche Dinge mit unseren Websites tun, aber wir müssen über die Sicherheit der ersten Codezeile nachdenken, wenn sie wollen, dass sie gegen Angriffe resistent sind.
