PHP-Sicherheit – Session-Hijacking

Session Hijacking

Die häufigste Angriffsmethode gegen Sitzungen ist Session Hijacking. Dabei handelt es sich um einen allgemeinen Begriff für alle Mittel, mit denen ein Angreifer Zugriff auf die Sitzungen anderer Personen erhalten kann. Der erste Schritt bei all diesen Methoden besteht darin, eine legitime Sitzungs-ID zu erhalten, um sich als legitimer Benutzer auszugeben. Daher ist es sehr wichtig sicherzustellen, dass die Sitzungs-ID nicht preisgegeben wird. Das Wissen über die Offenlegung und Fixierung von Sitzungen in den vorherigen Abschnitten kann Ihnen dabei helfen, sicherzustellen, dass die Sitzungskennung nur dem Server und legitimen Benutzern bekannt ist.

Das Prinzip der Tiefenverteidigung (siehe Kapitel 1) kann auf Sitzungen angewendet werden. Wenn die Sitzungskennung einem Angreifer leider bekannt ist, bieten einige unauffällige Sicherheitsmaßnahmen auch einen gewissen Schutz. Als Entwickler, dem Sicherheit am Herzen liegt, sollte es Ihr Ziel sein, den oben genannten Verschleierungsprozess ausgefeilter zu gestalten. Denken Sie daran, dass Ihre Bewerbung Schutz bietet, egal wie klein das Hindernis ist.

Der Schlüssel zur Komplexität des Verschleierungsprozesses liegt in der Stärkung der Überprüfung. Die Sitzungs-ID ist die primäre Authentifizierungsmethode, Sie können sie jedoch durch andere Daten ergänzen. Alle Daten, die Sie verwenden können, sind nur die Daten in jeder HTTP-Anfrage:

 GET / HTTP/1.1
  Host: example.org
  User-Agent: Firefox/1.0
  Accept: text/html, image/png, image/jpeg,
image/gif, */*
  Cookie: PHPSESSID=1234

Sie sollten sich der Konsistenz von Anfragen bewusst sein und inkonsistentes Verhalten als verdächtig einstufen. Obwohl beispielsweise der User-Agent-Header (der Browsertyp, der diese Anfrage ausgegeben hat) optional ist, ändert der Browser, der den Header ausgibt, seinen Wert normalerweise nicht. Wenn Sie einen Benutzer mit der Sitzungs-ID 1234 haben, der nach der Anmeldung Mozilla verwendet Der Firefox-Browser wechselte plötzlich zum IE, was verdächtiger ist. Sie können das Risiko beispielsweise mindern, indem Sie zu diesem Zeitpunkt ein Passwort verlangen. Gleichzeitig hat dies im Falle eines Fehlalarms auch geringere Auswirkungen auf legitime Benutzer. Sie können den folgenden Code verwenden, um die User-Agent-Konsistenz zu überprüfen:

 <?php
 
  session_start();
 
  if (isset($_SESSION[&#39;HTTP_USER_AGENT&#39;]))
  {
    if ($_SESSION[&#39;HTTP_USER_AGENT&#39;] !=
md5($_SERVER[&#39;HTTP_USER_AGENT&#39;]))
    {
      /* Prompt for password */
      exit;
    }
  }
  else
  {
    $_SESSION[&#39;HTTP_USER_AGENT&#39;] =
md5($_SERVER[&#39;HTTP_USER_AGENT&#39;]);
  }
 
  ?>

Ich habe beobachtet, dass in einigen Versionen von IE-Browsern die Accept-Header-Informationen, die gesendet werden, wenn ein Benutzer normalerweise auf eine Webseite zugreift und eine Webseite aktualisiert, unterschiedlich sind, sodass der Accept-Header nicht zur Bestimmung der Konsistenz verwendet werden kann.

Es ist zwar effektiv, sicherzustellen, dass die User-Agent-Header-Informationen konsistent sind, aber wenn die Sitzungskennung über ein Cookie weitergeleitet wird (die empfohlene Methode), liegt es auf der Hand, dass der Angreifer die Sitzungskennung auch erhalten kann, wenn er sie erhalten kann andere HTTP-Header. Da die Offenlegung von Cookies mit Browser-Schwachstellen oder Cross-Site-Scripting-Schwachstellen zusammenhängt, muss das Opfer die Website des Angreifers besuchen und alle Header-Informationen offenlegen. Der Angreifer muss lediglich den Header rekonstruieren, um eine Konsistenzprüfung der Header-Informationen zu verhindern.

Ein besserer Ansatz besteht darin, ein Tag in der URL zu übergeben, was als zweite (wenn auch schwächere) Form der Validierung betrachtet werden kann. Die Verwendung dieser Methode erfordert einige Programmierarbeit und es gibt keine entsprechende Funktion in PHP. Angenommen, das Token ist beispielsweise in $token gespeichert, müssen Sie es in alle internen Links in Ihrer App einbinden:

  <?php
 
  $url = array();
  $html = array();
 
  $url[&#39;token&#39;] = rawurlencode($token);
  $html[&#39;token&#39;] = htmlentities($url[&#39;token&#39;],
ENT_QUOTES, &#39;UTF-8&#39;);
 
  ?>
 
  <a href="index.php?token=<?php echo
$html[&#39;token&#39;]; ?>">Click Here</a>

Um die Verwaltung dieses Übermittlungsprozesses zu vereinfachen, können Sie die gesamte Anforderungszeichenfolge in eine Variable einfügen. Sie können diese Variable an alle Links anhängen, sodass Sie später problemlos Änderungen an Ihrem Code vornehmen können, auch wenn Sie diese Technik zunächst nicht verwenden.

Das Tag muss unvorhersehbaren Inhalt enthalten, auch wenn der Angreifer alle vom Browser des Opfers gesendeten HTTP-Header kennt. Eine Möglichkeit besteht darin, eine zufällige Zeichenfolge als Token zu generieren:

<?php
 
  $string = $_SERVER[&#39;HTTP_USER_AGENT&#39;];
  $string .= &#39;SHIFLETT&#39;;
 
  $token = md5($string);
  $_SESSION[&#39;token&#39;] = $token;
 
  ?>

Wenn Sie eine zufällige Zeichenfolge (z. B. SHIFLETT) verwenden, ist es unrealistisch, diese vorherzusagen. Zu diesem Zeitpunkt ist die Erfassung des Tags bequemer als die Vorhersage des Tags. Durch die Übergabe des Tags in der URL und der Sitzungs-ID im Cookie muss der Angriff beides gleichzeitig erfassen. Dies gilt nur, wenn der Angreifer die Rohinformationen aller vom Opfer an Ihre Anwendung gesendeten HTTP-Anfragen einsehen kann, da in diesem Fall alles offengelegt wird. Dieser Angriff ist sehr schwer zu implementieren (und daher selten) und seine Verhinderung erfordert den Einsatz von SSL.

有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑，而本群集中的多个代理服务器在编辑该值时可能会不一致。

如果你不希望依赖于检查User-Agent的一致性。你可以生成一个随机的标记：

  <?php
 
  $token = md5(uniqid(rand(), TRUE));
  $_SESSION[&#39;token&#39;] = $token;
 
  ?>

  这一方法的安全性虽然是弱一些，但它更可靠。上面的两个方法都对防止会话劫持提供了强有力的手段。你需要做的是在安全性和可靠性之间作出平衡。

以上就是PHP安全-会话劫持的内容，更多相关内容请关注PHP中文网（www.php.cn）！