PHP-Sicherheit – Replay-Angriff

Wiederholungsangriff

Bei einem Replay-Angriff, manchmal auch Demonstrationsangriff genannt, spielt ein Angreifer Daten ab, die zuvor von einem legitimen Benutzer an den Server gesendet wurden, um Zugriff oder andere diesem Benutzer zugewiesene Rechte zu erhalten.

Wie beim Passwort-Sniffing müssen Sie sich auch bei der Verhinderung von Replay-Angriffen der Offenlegung von Daten bewusst sein. Um Replay-Angriffe zu verhindern, müssen Sie es einem Angreifer erschweren, an Daten zu gelangen, die für den Zugriff auf eingeschränkte Ressourcen erforderlich sind. Dies erfordert vor allem die Vermeidung der folgenden Praktiken:

Festlegen der Verwendung von Daten mit dauerhaften Zugriffsrechten auf geschützte Ressourcen

Festlegen der geschützten Offenlegung von Daten das den Zugriff auf Ressourcen ermöglicht (auch auf Daten, die nur vorübergehenden Zugriff ermöglichen);

Auf diese Weise sollten Sie nur Daten verwenden, die einen vorübergehenden Zugriff auf geschützte Ressourcen ermöglichen, und Sie sollten auch versuchen, Lecks dieser Daten zu vermeiden. Hierbei handelt es sich lediglich um allgemeine Richtlinien, die jedoch als Orientierung für Ihre Vorgehensweise dienen können.

Der erste Grundsatz wird, soweit ich weiß, mit erschreckender Häufigkeit verletzt. Viele Entwickler konzentrieren sich nur auf den Schutz sensibler Daten vor Offenlegung und ignorieren die Risiken, die entstehen, wenn die Daten zum Festlegen des dauerhaften Zugriffs auf geschützte Ressourcen verwendet werden.

Stellen Sie sich beispielsweise ein lokales Skript vor, das einen Hash eines Kennworts für ein Formular zur Formularvalidierung berechnet. Auf diese Weise wird der Klartext des Passworts nicht offengelegt, sondern nur sein Hashwert. Dadurch wird das ursprüngliche Passwort des Benutzers geschützt. Das Hauptproblem bei diesem Prozess besteht darin, dass die Replay-Schwachstelle gleich bleibt – ein Angreifer kann einfach den legitimen Authentifizierungsprozess einmal wiederholen und die Authentifizierung bestehen, und solange das Passwort des Benutzers konsistent ist, wird der Authentifizierungsprozess erfolgreich sein.

Weitere sichere Betriebslösungen, MD5-JavaScript-Quelldateien und andere Algorithmen finden Sie unter http://www.php.cn / .

Ein ähnlicher Verstoß gegen den ersten Grundsatz ist die Angabe eines Cookies, um dauerhaften Zugriff auf eine Ressource zu ermöglichen. Betrachten Sie beispielsweise den folgenden Versuch, einen dauerhaften Zugriffsmechanismus durch Setzen eines Cookies auszuführen:

CODE:
 
  <?php
  $auth = $username . md5($password);
  setcookie(&#39;auth&#39;, $cookie);
  ?>

if An Ein nicht authentifizierter Benutzer stellt ein Authentifizierungscookie bereit und das Programm prüft, ob der Hash des Passworts im Cookie mit dem Hash des in der Datenbank gespeicherten Passworts übereinstimmt. Wenn sie übereinstimmen, ist der Benutzer authentifiziert.

Das Problem bei diesem Prozess besteht darin, dass die Offenlegung des Authentifizierungscookies ein sehr großes Risiko darstellt. Wird es erbeutet, erhält der Angreifer dauerhaften Zugriff. Während das Cookie eines legitimen Benutzers möglicherweise abläuft, kann ein Angreifer das Cookie jedes Mal zur Authentifizierung bereitstellen. Eine Darstellung dieser Situation finden Sie in Abbildung 7-2.

Eine bessere dauerhafte Login-Lösung besteht darin, die Daten nur zum Festlegen temporärer Zugriffsrechte zu verwenden, was auch das Thema des nächsten Abschnitts ist.

Das Obige ist der Inhalt des PHP-Sicherheitswiedergabeangriffs. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php .cn)!