единичка должна в таблице files в столбике zhaloba поменяться на ноль, но этого не происходит Код (Text): if(isset($_GET['otkl'])){ mysql_query("UPDATE `files` SET `zhaloba` = 0 WHERE `id` = '".$_GET['otm']."'"); header('Location: ?zhaloba'); } <div class="commup-edit"><a href="?otkl&otm='.$post['id'].'">Отклонить жалобу12345</a></div>
По порядку: 1. Действия должны передаваться только лишь post-запросами (тут призывается @Fell-x27 с рассказом про картинку на форуме) 2. post-запрос должен сопровождаться csrf-токеном 3. Вот так вот взять и просто вставить любой ID по желанию? 4. mysql_* уже выпилен. 5. Почему не меняется - я как-то даже хз )
у тебя уязвимость пиши абсолютные пути проверял что в гете присылается и существует ли ид в бд ? примеры абсолютных путей: /var/www/site/forum/index.php /img/frame.gif с:\windows\command.com
Защита от чего? От любого валидного числового ID, какой я захочу прописать, подпихнув его в адрес картиночки на форуме, где бывает админ ресурса, которй откроет картиночку и пошлет кросс-браузерный запрос со своими привелегиями, сделав то, что хочу я, а не он? Кроме SQL-инъекций есть еще и другие уязвимости
Я все время цифровые посты и геты интом обрабатываю, ну, если нужно иногда субстром обрезаю, подскажи как лучше сделать, а то вдруг я что-то упускаю?
А ты так и не понял, почему просто прогонять через инт недостаточно? Я же выше описал пример моей любимой уязвимости.
Нет, не понял, как в случае с ТС обработать $_GET['otm'] ?, по мне, так int в данному случае в самый раз, если есть какие-то иные варианты, расскажи, может что-то упускаю.
Для начала - не пересылать команды серверу через GET. Это уже закроет тебя от простейших CSRF-атак. От хитровыбоенных, через JS-инъекцию на стороннем ресурсе, оно тебя не закроет, JS хитрый, он умеет слать POST в фоне. Для таких случаев была придумана техника CSRF-токенов. Попутно она помогает отсеивать консоле ботов. Если кратенько, то у каждой формы или в каждом запросе (вкелючая ajax, да), пересылающим серверу запрос, по важности чуть выше, чем "покажи-ка мне главную страницу", должен быть в наличии некий уникальный идентификатор, созданный специально для этой формы. Это гарантирует, что конкретный запрос был послан именно со страницы нашего же сайта, и его можно не игнорировать. Но доверять ему все равно нельзя - обязательно нужно проводить проверки доступа и тд на уровне сервера. Алгоритм следующий: 1) Генерируя страничку с формой, пихаем в нее скрытое поле с идентификатором, сгенерированным на лету. 2) Идентификатор, параллельно, кладем в сессию. 3) Пользователь заполнил форму и отправил ее на сервер. 4) Первым делом проверяем наличие нашего волшебного скрытого поля среди полученных параметров. 5) Сравниваем его значение с тем, что лежит в сессии. 6) Совпало? Ок. Эту форму можно обработать. 7) Не совпало или в форме вообще отсутствует наш токен? Отклоняем запрос, он был послан не нашим клиентом. Это самый простенький алгоритм, собсна, не без проблем, но работающий. Дальше уж сам под себя напильником его доработай и все будет ок. При этом некоторые разрабы таки гоняют команды серверу и запросы на изменение данных через GET, да. Например, разрабы движка phpBB. Но, при этом, каждый запрос у них сдобрен длинным токеном. Это, в общем-то, тоже безопасно, но, как по мне, не красиво.