Вопрос по input, php – Как злоумышленники могут использовать ключи ввода?

23

вCodeIgniter PHP Framework, есть функция, которая автоматически запускается при каждом запросе, которая, помимо прочего,фильтрует ключи массива GET / POST / COOKIEи убивает приложение, если оно встречает символы, которые оно считает небезопасными.

To prevent malicious users from trying to exploit keys we make sure that keys are only named with alpha-numeric text and a few other items.

Что-то вроде:

// foreach GET/POST/COOKIE keys as $str...
if ( ! preg_match("/^[a-z0-9:_\/-]+$/i", $str))
{
    exit('Disallowed Key Characters.');
}

Например, это сработает, если вы случайно разместите что-то вроде<input name="TE$T"> или иметь строку запроса, такую как?name|first=1.

Я вижу, что это хороший способ обеспечить соблюдение имен ключей здравого смысла или выявить ошибки при разработке приложения, но я не понимаю: как злоумышленник может «использовать ключи»? в$_POST данные например? Тем более, что (я бы предположил) входvalues так же пригодны для использования, что это на самом деле мешает?

12 голосов за 17 минут. Вы, кажется, ударил аккорд :) AlienWebguy
Это странно, что они позволяют/ проходить. Alix Axel
Возможно, это не защита от прямой атаки, а то, что значительно усложнит использование любых других уязвимостей, таких как, например, инъекции XSS или SQL. Просто мысль... d_inevitable
fyi - шаблон preg, который они используют, неверно проверяется для "буквенно-цифровых" символов. Это позволит завершить символ новой строки LOL. Это ОЧЕНЬ распространенная ошибка в коде php.proof, Они должны использоватьD modifier goat
Еще одна странная вещь заключается в том, что они не позволяют[] пройти ... это просто глупо. Alix Axel

Ваш Ответ

5   ответов
9

what именно вы защищены от. Но есть некоторые популярные пункты, к которым это может быть обращено:

magic quotes things that could eventually lead to SQL injection strings that could be executed by way of shell commands things that could conflict with your URL things that could conflict with HTML things that resemble a directory traversal attack cross site scripting (XSS) attacks

Но кроме них, я действительно не могу думать о том, почему вы всегда, почему вы хотите вообще защищаться черезpreg_match("/^[a-z0-9:_\/-]+$/i", $str).

У меня есть ощущение, что ониoverprotecting просто потому, что CodeIgniter настолько широко используется, что им нужно защищаться от вещей, о которых они сами еще не думали ради своих пользователей, которые могут быть даже менее осведомлены о таких атаках, чем разработчики CodeIgniter.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Wesley Murch
Error: User Rate Limit ExceededkeysError: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Wesley Murch
Error: User Rate Limit ExceededunsetError: User Rate Limit ExceededassumeError: User Rate Limit Exceeded Wesley Murch
18

Вы часто видите этот мусор в коде noob:

$_SESSION = $_POST;

Редко известный секрет в том, что$_SESSION is "special" and can't handle the pipe character, |, как ключ массива верхнего уровня. php не может сохранить переменные сеанса во время shutdown / session_write_close, вместо этого стирая весь массив.

session_start();

if (!isset($_SESSION['cnt'])) {
    $_SESSION['cnt'] = 0;
}

$_SESSION['cnt']++;

/* prior to php 5.4, it will never increment, because it never successfuly saves
unless you comment line below
*/
$_SESSION['a|b'] = 1;

print_r($_SESSION);

Я не говорю, что именно поэтому CodeIgniter чистит ключи, но это один из многих способов использования клавиш ввода.

Возможно, более вероятная причина в том, что люди, конечно, делают такие вещи:

if ($formPostDidntValidate) {
    echo "Please fix the form submission errors and try again\n";
    foreach ($_POST as $key => $value) {
        echo "<p>$key<br>
              <input name='$key' value='$value'></p>";
    }
}

Вывод переменных запроса без выполнения надлежащего контекстно-зависимого экранирования, такого как экранирование для контекстов HTML, атрибутов HTML или даже контекстов SQL:

$sql = "select * from myTable where 1=1";
foreach ($_POST as $key => $value) {
    $sql .= " and $key = '$value'";
}

Я видел, как многие люди избегают значения, но не ключ при создании sql и / или html.

Если вы не избежите всего, вас легко взломать. Очистка значений не так хороша, как экранирование, но это намного лучше, чем ничего, и, учитывая, сколько разработчиков еще недостаточно изощренно, чтобы понять, когда и как выйти, я вижу привлекательность добавления автоматической очистки переменных запроса.

Error: User Rate Limit Exceededphp.net/manual/en/language.variables.external.php#81080Error: User Rate Limit Exceeded"The full list of field-name characters that PHP converts to _ (underscore) is the following (not just dot): chr(32) ( ) (space) chr(46) (.) (dot) chr(91) ([) (open square bracket) chr(128) - chr(159) (various). PHP irreversibly modifies field names containing these characters in an attempt to main,tain compatibility with the deprecated register_globals feature." Wesley Murch
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Wesley Murch
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
3

туп только к тем ключам, которые ожидаете - и если по какой-то причине вы перебираете все элементы, вы, скорее всего, избежите их должным образом для всего, что вы собираетесь с ними делать.

Однако, глядя на навыки обычного программиста PHP-новичка (хотя представители этого вида, скорее всего, вообще не используют фреймворк), есть некоторый смысл, вы никогда не узнаете, какие неприятности он собирается делать с код, который может даже убить его кошку без такой проверки.

То же самое относится и к отклонению сообщений, содержащих, например, & quot; удалить из & quot; как мера против SQL-инъекций. Это может легко вызвать ложные срабатывания, и если вы, например, используйте параметризованные запросы, вы в любом случае в безопасности.

Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededhackersError: User Rate Limit Exceeded
Error: User Rate Limit ExceededbeforeError: User Rate Limit Exceeded
Error: User Rate Limit ExceededprobablyError: User Rate Limit Exceeded Wesley Murch
Error: User Rate Limit Exceededall data must be sanitizedError: User Rate Limit Exceeded
2

эта атака.

Атака работает, используя знание того, как PHP строит свои структуры хеширования для создания ключей в$_POST которые занимают произвольно много времени для обработки.

Я подозреваю, что он, вероятно, просто пытается предотвратить более приземленные атаки с использованием SQL-инъекций.

Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededanyError: User Rate Limit Exceeded Wesley Murch
4

name="email" вname="email\"); DROP TABLE users;

Это вряд ли будет успешной атакой XSS, но я вижу, что нечто подобное наносит ущерб плохо закодированному PHP. CI, вероятно, просто пытается охватить все их базы, чтобы они могли претендовать на максимальную XSS-защиту.

Error: User Rate Limit Exceeded Wesley Murch
Error: User Rate Limit Exceeded

Похожие вопросы