2017-12-31 45 views
1

Ich arbeite an Hash Rechner Kursarbeit. Dies ist eine einfache Web-Anwendung, die auf der Hauptseite zwei Formulare enthält, in denen Benutzer Hash-Code eingeben und Text zurück erhalten und einen Vers sperren können.ist CSRF eine Bedrohung in einfachen Hash Calculator PHP-Anwendung?

Obwohl die Anwendung trivial ist, müssen Sicherheitsfunktionen implementiert werden. Es gelang mir, SQL- und XSS-Angriffe zu reduzieren. Dann entschied ich mich, zwei Schwachstellenbewertungsscanner "Acunetix" und "Nessus" zu verwenden. Beide Scanner zeigten mir, dass meine Anwendung für CSRF anfällig ist, und der Schutz vor diesem Angriff besteht darin, Sitzungen und zufällige Token in PHP zu implementieren.

Ich habe über diesen Angriff gelesen und was es tut. Allerdings bin ich sehr verwirrt wegen der Tatsache, dass dieser Angriff sich hauptsächlich auf bereits authentifizierte Benutzer und Cookies konzentriert, so dass meine Frage ist? Muss ich Sessions und Token in meine Anwendung einbetten, die einfach zurückgehen und Hash und Klartext wiederherstellen? Wenn ja, warum sollte ich das tun und welche potenziellen Bedrohungen gibt es?

Vielen Dank!

+0

CSRF-Schutz ist wirklich eine Möglichkeit, sicherzustellen, dass jede Anfrage von Ihrem Formular kommt (also niemand kann von irgendwo anders zu Ihrem Back-End posten). Ohne CSRF könnte jeder Ihr Backend mit seinem eigenen Frontend nutzen. Wenn Sie sich also darum kümmern, fügen Sie CSRF hinzu. Wenn es Ihnen egal ist, ob jemand von Ihrer eigenen Site/Ihrem eigenen Skript an Ihr Backend schreibt, dann brauchen Sie CSRF nicht. –

+0

@MagnusEriksson Anti-CSRF schützt nicht vor MitM/Proxies. – user2864740

+0

@ user2864740 Natürlich nicht. Es gibt nicht nur einen Schutz, der dich vor allem schützt. Aber in einer Anwendung wie dieser denke ich, dass Mann in der Mitte Angriffe wirklich keine große Bedrohung sind. –

Antwort

1

Kurze Antwort: Nein, Sie nicht, da Sie keine "Benutzer" (Authentifizierung) haben, benötigen Sie kein csrf-Token.

+1

Jeder Cookie-basierte Sitzungszustand ist für CSRF anfällig. In diesem Fall klingt es so, als gäbe es keinen Sitzungszustand. (Während die meisten "sensiblen Operationen" durch Authentifizierung geschützt sind, ist Authentifizierung nicht unbedingt eine Voraussetzung.) – user2864740

+1

die meisten von ihnen ist es, aber in dieser Ursache braucht er nicht csrf Schutz – azjezz

+0

Ich stimme mit der Schlussfolgerung in diesem Fall. – user2864740

2

Sie haben Recht in Ihrer Frage, CSRF-Schutz muss eine bewusste Entscheidung sein. Ich denke, dass Sie zumindest in Ihrer Anwendung darüber nachdenken möchten, und hier ist warum.

Bei CSRF handelt es sich um eine andere Website, die einen Benutzer dazu verleiten kann, versehentlich Aktionen in Ihrer Anwendung auszuführen, während er die bösartige Webseite besucht. Richtig, meistens nutzt dies die Tatsache aus, dass der Benutzer bereits angemeldet ist, aber das ist nicht unbedingt der Fall.

Für Ihre Anwendung, die beiden CSRF-bezogenen Bedrohungen, die sofort in den Sinn kommen, sind:

  • Hashing ist sehr CPU-intensiv, und auch die andere Art und Weise, Suchoperationen in einem großen Regenbogen-Tabelle kann auch sein, ressourcenintensiv. Dies stellt bereits ein Denial-of-Service-Risiko dar, aber Sie könnten dem entgegenwirken, indem Sie beispielsweise Quell-IPs mit zu vielen Anfragen ausfiltern. Wenn Ihre App jedoch für CSRF anfällig ist, kann eine Website mit hohem Datenaufkommen die Besucher solcher Vorgänge in Ihrer App ausführen, wodurch ein verteiltes DoS effektiv ausgeführt wird, gegen das es viel schwieriger ist. Wenn Sie über eine API für die App und keinen Schutz gegen CSRF verfügen (z. B. access-control-allow-origin: *), kann jede andere Website so viele Abfragen ausführen wie sie wollen, entweder Hash oder Suche, was zu entgangenem Einkommen oder verteilter Dienstverweigerung führen kann).

Vielleicht sind diese nicht anwendbar auf Ihren genauen Anwendungsfall, ich wollte nur, dass auch beachten, wenn es kein Sitzungszustand jeglicher Art ist, CSRF kann in der Tat ein Problem sein, und das Werkzeug, um systematisch solche aufzudecken potenzielle Bedrohungen nennt man Bedrohungsmodellierung.

+0

CORS bezieht sich nur auf Browser-XHR/Intrapage-Ressourcenanforderungen. Dies kann zwar eine bestimmte CSRF-Klasse mildern, indem diese Zugriffe "abgedeckt" werden, aber CSRF wird nicht gelöst. Wenn Sie sich also vorstellen, dass es eine "teure GET-Operation" gibt, wie verhindert die Aktivierung von CSRF dies? – user2864740

+0

@ user2864740 Ich wollte das nicht vorschlagen. Ich habe zwei Szenarien vorgeschlagen, in denen CSRF ein Problem in dieser Anwendung sein kann, ohne Sitzungszustand und Zustandsänderung im herkömmlichen Sinn. GET-Vorgänge sind inhärent anfällig für CSRF, sodass Sie mit GET keinen richtigen CSRF-Schutz implementieren können. –

+0

Dann ist es nicht CSRF ..:} Ich bin nicht dagegen, zusätzliche bessere Praktiken für die Härtung von Anwendungen zu verwenden (und CORS/DDoS sind sehr gültige Punkte), aber CSRF hat eine sehr enge Definition. – user2864740