Решил сам сделать защиту для страницы с материалом, можете пожалуйста посмотреть и сказать правильно или нет, и если нет указать на ошибки, строго не судите это первые шаги многое непонятно! PHP: if (isset($_GET["id"])){ $page2 = (int)$_GET["id"]; if($page2) { if($page2 < 1){ $a1 = $_GET["id"] = 1; header ("Location: view.php?id=$a3"); exit(); } elseif($page2 > $num_posts){ $a2 = $_GET["id"] = $num_posts; header ("Location: view.php?id=$a2"); exit(); } } else { $a3 = $_GET["id"] = 1; header ("Location: view.php?id=$a3"); exit(); } }
каким местом этот бред чего-то защищает? почему бы не использовать стандартные и понятные способы? от http Basic autentification до системы авторизации с лог/пассом?
Много вы знали когда делали свой первый сайт на php, mysql? Мне абсолютно непонятно то что вы написали, форум то для новичков вы и обьясняйте на просто языке, я не профи. Я читал что нужно проверять информацию отправляемую get, вот и напаял разных условий. На практике работает если вводить теги, и прочую лабуду, скрипт переходит на нужные страницы и передает нужные параметры. Мне интересно вообще как реализуеться подобная защита, на входящие данные?
старайся что не понятно первым делом искать в google или yandex, это сэкономит тебе время и даст больше знаний
Ну это же неправильно если кто угодно может в адресной строке изменить запрос get на свой! Я читал где то что любые входящие данные нужно проверять на действительность, если get отправляет число значит нужно его проверить получил он число или что то другое. Ну вот к примеру жму я на новость мне открылась php.ru/news.php?id=1 по идее первая новость, если не трогать все как бы хорошо. Ну а если изменить ?id=-100 выдаст ошибку, или если передать какой то скрипт или sql запрос.
Нутак это не данные ты защитить хочешь, а базу, получается от SQL инъекций. Просто проверяй все данные на валидность, вот и всё. Можно ещё на всякий случай mysqli_real_escape_string, или её аналог в PDO, я хз какой он там. Но если есть возможность проверить валидность, и там всё ок с кавычками - можно даже не использовать последнюю ф-цию. --- Добавлено --- Я обычно, если есть ситуация, как в твоём примере, когда данные не могут быть такими как их прислал клиент тупо заменяю на 1, 0, или вывожу ошибку что такой фигни быть не может. Обратитесь к администратору.
@Unga, лучше скажи, какая у тебя там структура, как логически у тебя всё работает. Так тебе подскажут правильный путь. А то у тебя, честно говоря, я вообще не понимаю, что происходит)
Ну так впринцепи понял, да это точно я про sql иньекции читал. Вот и пишу что надо проверку делать на пагинаторе, и на новостях. --- Добавлено --- Завтро выложу, там сайт по сути на 3ех файлах, index.php, view.php, и search.php На главной выводяться последние 100 торрент файлов, пагинация, и форма поиска. На новость жмешь переходишь на view.php вот и вся структура, многое из пабла брал поэтому нужно немного до ума довести.
Если ты о том, что люблй желающий сможет изменить id новости - пусть себе меняют. get запрос ты от этого не защитишь. Защитить можно переменную переж использованием в БД. Для этого используй подготовленные запросы, или экранирование кавычек, или же, как я писал выше - делай проверку на валидность. То есть для id новости достаточно будет PHP: if (is_numeric ($new_id)) { if ($new_id > 0) { } else die ('ID новости должна быть числом'); } else die ('ID новости не может быть отрицательным'); Но можно ещё сделать проверку на существование новости: PHP: if ($query) { if (mysqli_num_rows($query)) { } else die ('Новость не найдена'); } else die ('Ошика выполнения запроса'); Или что-то подобное. Можно использовать ф-ции filter_input(), или filter_var().
Ну это хорошо когда материал так усваиваеться, а я вот базовые знания по урокам php на youtube получил, так же самые базовые по myql. А теперь мучаюсь, учусь методом тыка, что незнаю по ходу дело вычитываю
Кто для изучения программирования вместо книжного магазина идёт на youtube, тот, уж извини, заранее сам себя считает идиотом. Поскольку не идиот в состоянии прочесть книжку. Докажи, что я не прав, купи и прочитай: https://www.ozon.ru/context/detail/id/137538198/
@miketomlin, а зачем? Я просто использую плейсхолдеры или преобразую к числу. Если ты мне вместо id поста передашь в get хрень какую-нибудь, база не найдёт пост, сайт выдаст 404-ю, база нисколько не пострадает.
Та же фигня, только вид сбоку. Более того, далеко не везде можно точно контролировать значение, например в mysqli_stmt для идентификатора типа i имеем: /article/1 - OK /article/01 - OK /article/1pig - OK
Огосподи. И тут регулярка. Инженеры в Zend сидят, придумывают всякую херню, нет бы просто сказать "ребят, юзайте регулярки". Уже давно все украдено придумано за вас. PHP вообще плавно движется давно в сторону "языка-фреймворка", наращивая высокоуровневую функциональность. До C# ему далеко еще, но он уверенно шагает. В таком случае очень важно соблюдать правило, чтобы нулевые идентификаторы нигде не ипользовались. Потому что может оставаться вероятность, что кто-то исхитрится, да заюзает приведение строки к нулю себе на пользу. Или что ты где-то забудешь экранирование сделать. Я вот везде на всякий случай делаю фильтрацию и экранирование. Даже если понимаю, что ломаться в конкретном случае особо нечему. Но это, скорее как полезная привычка, на вроде расставления фигурных скобок даже там, где они и не особо нужны по логике, типа однострочных циклов и ифов. Но хуже не становится, и, покуда это происходит чуть ли не на автомате, я относительно спокоен за остальной код.
Кстати, для числовых идентификаторов сущностей регулярку по формату значения можно и не использовать. Заглянул в пару наших каркасов. Прежде всего используется проверка на наличие только допустимых символов, к которым апостроф и проч. естественно не относятся, хотя также может быть проверка и по формату, например путь[?строка_параметров]. А в запросах есть вот такое: WHERE CAST(`id` AS CHAR)= с пояснением, что тип поля может быть и числовым, и символьным. Может, не оч. эффективно, но всякую хрень писать в качестве числовых идентификаторов в адресах писать не дает, результат пустой и как следствие 404-ая.
Костыль поверх логики. Просто надо правильно, грамотно экранировать. Если у меня есть статья "Садоводство", то, если злоумышленник пропишет " Садоводство' ", такая статья просто не будет найдена в БД. Таким образом, " Садоводство' " на уровне логики приложения не отличается от "Shdkadjfajfhks". Ваш поиск на недопустимые символы, увы, дырявое решето. Если вы вырезаете недопустимые символы, то, у вас получается троичная логика: допустимо, недопустимо, сойдет. Это некрасиво и неправильно. Если же вы просто заворачиваете запрос с ними, то это обходится на раз два. В mysqli_, в экранировании не просто так добавили возможность явного указания кодировки, и не просто так рекомендуют ее указывать всегда. Потому что текстовые данные это весело. Можно собрать запрос так, что ваш фильтр не найдет там ни одного запрещенного символа. И отдаст в его в базу. А вот уже на уровне базы окажется, что для самой базы там был спрятан целый букет подарков. С экранированием от mysqli_ такой фокус не прокатит. Так что в лучшем случае ваша система защиты просто бесполезный велосипед, увы. В худшем же - потенциальная брешь, которую нужно латать. --- Добавлено --- Разумеется, и это прекрасно. Сам очень люблю ссылаться на нулевой идентификатор, когда таблица является, к примеру, связным списком, чтобы, таким образом, указывать, где он кончается и откуда начинается. Но айдишник не всегда может быть следствием автоинкремента. Не все могут понимать тонкости этих моментов. Плюс, не всегда выборка идет именно по айдишнику. Случай может быть всякий. Моя логика в данном случае проста - "чем сложнее система, тем выше вероятность ошибки". Если система работы с параметрами, передаваемыми базе на вход, простая как топор (фильтруй/проверяй тип+экранируй), независимо от смысла передаваемых данных, то вероятность того, что где-то что-то упустишь, не сейчас, так потом, при рефакторинге или расширении, минимальна. Если же в эту схему вводятся исключения, это усложняет систему и повышает вероятность ошибки, так как подготовка данных из абстрактной задачи превращается в контекстно-зависимую. И, как по мне, тут разом и KISS, и Бритва Оккама клином сходятся в одной точке.