Если вы знакомы с SMF, вот как вы обычно используете его на стороне сервера:
//foo.php at http://example/foo.php
<?php
require('./SSI.php'); //assuming we're at SMF's root
//...
?>
Но это скрыто неподготовленным глазом, который http://example/foo.php?ssi_function=something
вызовет ssi_something
быть вызванным изнутри SSI.php
, эффективно обходя foo.php
нормальное поведение
Я мог бы подготовить это раньше require
, но я мог избежать перенаправления:
if(isset($_GET['ssi_function']))
{
unset($_GET['ssi_function']);
return header('Location: ?' . http_build_query($_GET));
}
Я уже открыла вопрос на GitHub, но какие еще варианты у меня есть, чтобы противостоять этой неприятности?
Как вы упоминали, это поведение, зависящее от реализации в SMF. Вам не нужно делать перенаправление в этом случае, так как $_GET
суперглобальный изменчив, просто удаляя ssi_function
параметра должно быть достаточно.
Эта ошибка была исправлена в # 4038.
@@ -177,6 +177,9 @@
// Have the ability to easily add functions to SSI.
call_integration_hook('integrate_SSI');
+// Ignore a call to ssi_* functions if we are not using SSI.php
+if (empty($modSettings['allow_ssi_functions_anywhere']) && isset($_GET['ssi_function']) && basename($_SERVER['PHP_SELF']) !== 'SSI.php')
+ unset($_GET['ssi_function']);
// Call a function passed by GET.
if (isset($_GET['ssi_function']) && function_exists('ssi_' . $_GET['ssi_function']) && (!empty($modSettings['allow_guestAccess']) || !$user_info['is_guest']))
{