Как сделать $ _GET более безопасным?

Я использую метод get, чтобы выполнить некоторую операцию, например, одобрить, markasspam, delete, для системы комментариев. Я знаю, что очень небезопасно идти этим путем, но я не могу помочь. потому что причиной использования метода $ _GET является выполнение операции внутри самой страницы с помощью PHP_SELF, а FYI я использую метод post, используя флажок для выполнения операции.

теперь для того, чтобы сделать его бит безопасным, я хочу рандомизировать число или сгенерировать хэш или что-то еще, а затем сравнить его, получить идентификатор и выполнить операцию

мой текущий код несколько похож на этот.

<?php if($approve == 1 ) { ?> <a href="<?php echo $_SERVER['PHP_SELF']."?approve=".$id; ?>">Unapprove</a> <?php } else { ?> <a href="<?php echo $_SERVER['PHP_SELF']."?unapprove=".$id; ?>">Approve</a> <?php } ?> | <a href="<?php echo $_SERVER['PHP_SELF']."?spam=".$id; ?>">Spam</a> | <a class="edit-comments" href="edit-comments.php?id=<?php echo $id; ?>">Edit</a> | <a href="<?php echo $_SERVER['PHP_SELF']."?delete=".$id; ?>">Delete</a> 

и я выполняю операцию, используя этот код.

 if(isset($_GET['approve'])) { $id = intval($_GET['approve']); $query = "UPDATE comments SET approve = '0' WHERE id = '$id'"; $result = mysql_query($query); } if(isset($_GET['unapprove'])) { $id = intval($_GET['unapprove']); $query = "UPDATE comments SET approve = '1' WHERE id = '$id'"; $result = mysql_query($query); } if(isset($_GET['delete'])) { $id = intval($_GET['delete']); $query = "DELETE FROM comments WHERE id = '$id'"; $result = mysql_query($query); } if(isset($_GET['spam'])) { $id = intval($_GET['spam']); $query = "UPDATE comments SET spam = '1' WHERE id = '$id'"; $result = mysql_query($query); } 

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

как мне это сделать? Что вы думаете об этом?

EDIT: Обратите внимание только на пользователя, прошедшего проверку подлинности, то есть администратор сможет выполнить эту операцию. даже если он проходит через систему аутентификации, я хочу добавить дополнительную безопасность даже для администратора. избежать экспериментов или аварии

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

Независимо от того, используете ли вы параметры GET или POST, в этом контексте это не имеет большого значения – для чего нужен сценарий в первую очередь, это своего рода аутентификация. (После этого вы можете перейти к сведениям о безопасности, где GET чуть менее безопасен, чем POST – см. Комментарии для деталей.)

Я бы сказал, у вас есть два варианта:

  • Защита всего скрипта с помощью .htaccess – никаких изменений, необходимых для самого скрипта

  • Представляем аутентификацию стороннего пользователя PHP и выполняем операции только в том случае, если зарегистрированный пользователь делает запрос. Нуждается в фундаментальных изменениях в скрипте, но является наиболее гибким.

Повторите свое редактирование:

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

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

Повторите свое редактирование об использовании одноразовых хэшей:

Я никогда не применял одноразовые хэши в интерфейсе администратора, но у меня нет опыта с этим, но я полагаю, что очень простая реализация сохранит хэши действий в отдельной таблице с hash , record и action столбцов. Всякий раз, когда ваш инструмент перечисляет несколько записей и выходов «delete / approve / unapprove», он генерирует три записи в хеш-таблице для каждого комментария: один для удаления, один для утверждения, один для несанкционированного. Затем ссылки «delete / approve / unapprove» вместо идентификатора записи и команды получат правильный хеш как единственный параметр.

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

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

В вашем текущем коде любой может удалить что угодно в любое время и так часто, как они хотят.

Если у вас есть код обертывания, который гарантирует, что post-if-statements вы не выполняетесь, если enter good reason here указывается enter good reason here , тогда все в порядке.

Но вы должны попробовать проверить, что содержание параметров действительно целых чисел, а не просто int_val'ing их и использования их непосредственно в базе данных.

На вашем редактировании

Вы должны проверить, что ваш параметр действительно является int. intval("test") также возвращает целое число, в основном 0.

Вы можете рассмотреть регулярное выражение для этого, чтобы проверить, что строка состоит только из чисел: preg_match('/[0-9]+/', $_GET['id']);

Если это так, вы можете выполнить действие.

Вы не должны использовать GET для любых операций, которые изменяют данные на сервере. НИКОГДА. Вы используете его только для получения данных.

Если вы не можете использовать формы для кнопок управления (потому что есть другая форма вне их), вы должны рассмотреть этот дизайн:

  • Вы используете AJAX для выполнения запросов POST на ваш сервер
  • В средах с отключенным javascript вы используете ссылки GET, такие как user.php? Action = delete, который показывает вам очень простую форму на отдельной странице. Заголовок в форме спрашивает: «Вы действительно хотите удалить пользователя X?» и он имеет две кнопки: 1) «Да» – отправляет запрос POST на сценарий работы, 2) «Нет» – который отправляет пользователя обратно на страницу, где он был