ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Защита при передаче данных по GET.
23 сообщений из 23, страница 1 из 1
Защита при передаче данных по GET.
    #39534789
pash358
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pash358
Гость
Здравствуйте.

Я на страницах своего сайта делаю передачу нескольких переменных по GET, то есть в URL...?aa=3&bb=4&cd=100
Значение переменных определяется или программой или действиями пользователя, но пользователь ничего нигде не вводит, только выбирает ссылку-картинку (при этом меняется значение переменных). Переменные только числовые и их размер от 0 до 100, т.е. не более 3-х символов.

ВОПРОС1 : как мне нормально защититься от всяких-там SQL-инъекций и др. ?

Я порылся в интернете и пока решил сделать так:
1) Все переменные приходящие по GET берутся через mysql_real_escape_string();
2) Потом переменные проходят через htmlspecialchars();
3) Потом переменные проходят через htmlentities();
4) Потом переменные я проверяю на длину strlen(). Проверка: если больше 3-х символов, то переменная равна NULL.
5) Может быть сделать еще и проверку на размер URL. Если слишком большой, значит пользователь что-то ввел самостоятельно и все переменные приравнять NULL.

ВОПРОС2 : нормальная ли эта защита?
ДОПОЛНИТЕЛЬНО : У меня пользователи ничего не вводят, только кликают на разные картинки-ссылки, в результате образуются значения переменных. Но в строку URL кто-нибудь может что-то внести дополнительно. На страницах моего сайта в коде PHP есть запросы к базе MYSQL типа: $zapros=mysql_query("SELECT * FROM aaa WHERE bb='cc'); или UPDATE.
...
Рейтинг: 0 / 0
11.10.2017, 15:38
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534846
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
pash358как мне нормально защититься
Используй PDO и параметрические запросы.

pash358нормальная ли эта защита?Нет.
...
Рейтинг: 0 / 0
11.10.2017, 16:49
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534872
machetero
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
machetero
Гость
В базу надо писать POST-запросами

автор2) Потом переменные проходят через htmlspecialchars();
3) Потом переменные проходят через htmlentities();

Через эти функции не надо пропускать переменные, перед записью в базу. Через обе функции переменную тоже никогда не пропускают(посмотрите в мануал что они делают).

автор4) Потом переменные я проверяю на длину strlen(). Проверка: если больше 3-х символов, то переменная равна NULL.

Круто вы проверяете строковой функцией то, что по идее ожидаете как число.

авторНо в строку URL кто-нибудь может что-то внести дополнительно.
Чтоб такого не было в базу пишут POST-запросами
...
Рейтинг: 0 / 0
11.10.2017, 17:11
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534892
qtech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qtech
Гость
POST запрос тоже не панацея, ведь есть тот же curl
Как уже правильно сказали используйте prepared statements с параметрами, перед этим валидируйте сами данные.

Если у вас PHP, то правильно валидировать integer с помощью следующего кода
Код: php
1.
filter_var($value, FILTER_VALIDATE_INT) !== false;
...
Рейтинг: 0 / 0
11.10.2017, 17:33
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534894
pash358
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pash358
Гость
POST запросы решил не делать, т.к. поисковики скорее всего по ним не переходят.
...
Рейтинг: 0 / 0
11.10.2017, 17:34
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534910
pash358
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pash358
Гость
На счет использования strlen() для числовых переменных:

Попробовал так:
<?php
$asdfq1=1;
$asdfq2=23;
$asdfq3=100;
$asdfq11=strlen($asdfq1);
$asdfq22=strlen($asdfq2);
$asdfq33=strlen($asdfq3);
echo $asdfq11;
echo $asdfq22;
echo $asdfq33;
?>
Итог: 123

Получается, что strlen() прекрасно работает и с числовыми переменными.
Можно ли взломать базу через URL, если я сделаю проверку длины всех переменных и также сделаю проверку длины URL, чтобы длина была в пределах моего лимита длины ?
...
Рейтинг: 0 / 0
11.10.2017, 17:46
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534933
machetero
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
machetero
Гость
авторPOST запрос тоже не панацея, ведь есть тот же curl
О капчах слышали ?
авторPOST запросы решил не делать, т.к. поисковики скорее всего по ним не переходят.
Поисковикам вообще пох*й на POST-запросы, они индексируют страницы.
...
Рейтинг: 0 / 0
11.10.2017, 18:00
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534943
pash358
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pash358
Гость
Капча - я в своем вопросе написал, что у меня пользователи ничего не вводят, только выбирают ссылку-картинку, от этого меняются переменные.
Риск в том, что сломать базу могут через URL, т.к. в нем я передаю переменные и собираю их через GET:
if (isset($_GET['aaa'])){$aaa=$_GET['aaa'];} else {$aaa=NULL;}

Последний мой вопрос: можно ли взломать базу через URL, если я сделаю проверку длины всех переменных (мои переменные числовые и не более 3-х знаков), а также сделаю проверку длины URL, чтобы длина была в пределах моего лимита длины ?
...
Рейтинг: 0 / 0
11.10.2017, 18:10
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534980
machetero
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
machetero
Гость
GET-запросы не предусмотрены для записи в базу. Они поэтому и называются GET. Я изначально пытался намекнуть вам на то, что вы не правильно делаете сайт. В котором при переходе по ссылке-картинке, что-то пишется в базу. Надо исключить возможность на сайте пользователю писать в базу без капчи. А все что он отправил c капчей, уже писать можно, НО только проэкранировав это всё вашим mysql_real_escape_string(); или pdo, смотря что используете.
...
Рейтинг: 0 / 0
11.10.2017, 18:54
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39534984
pash358
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pash358
Гость
Чего-то я не понял. Капча - это проверка что пользователь не бот - вроде так.
ВАШ ТЕКСТ - " Надо исключить возможность на сайте пользователю писать в базу без капчи."
В моем сайте ничего пользователь не может писать, только если ХАКЕР напишет что-то в URL. Я не разбираюсь как они это делают, но вроде так - что они в URL в переменную вместо автоматически сгенерированной цифры укажут какой-то хакерский код. Вот я и хочу узнать, если я просто все переменные полученные по GET проверю на длину (не более 3-х символов) и проверю длину URL - примерно на мой предел, чтобы не было возможности хакеру написать большой взламывающий код, то будет ли моя база защищена ?
...
Рейтинг: 0 / 0
11.10.2017, 19:06
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535029
vkle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkle
Участник
GET или POST не имеет никакого значения.
Одной только проверки длины в ряде случаев недостаточно для самой бизнес-логики. Например, сообразно использованию, переменная $_GET['action'] должна принимать значения из списка "add", "remove", "edit", а остальные варианты, которые пользователь решит немытыми руками напечатать в адресной строке браузера, должны вызывать переход на сообщение об ошибке. Как можно заменить эту проверку на проверку длины? Длину же длины текстовых данных в самом плохом (только в самом плохом!) варианте исполнения можно и вовсе не делать - СУБД выдаст сообщение об ошибке при попытке записать больше данных, чем позволяет поле (попробуйте записать сотню символов в поле VARCHAR(10), например).

pash358Получается, что strlen() прекрасно работает и с числовыми переменными.В общем да, работает. Только сперва, перед проверкой, число из Вашего примера будет преобразовано в строку. Почитайте про неявные преобразования.
А в общем то, из GET всё строкой приходит, так что, в ситуации strlen($_GET['number']) преобразования не потребуется. Можете проверить при помощи var_dump().
Кстати, как будете strlen'ом проверять числа на соответствие диапазону от -999 до 999 включая дробные значения, например? ;-)
В общем, не мудрите в этом месте. Числа гораздо проще и экономичнее сравнивать математическими методами - больше, меньше, равно и т.д.
...
Рейтинг: 0 / 0
11.10.2017, 20:56
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535034
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
macheteroВ базу надо писать POST-запросамиНе имеет никакого значения. Это вообще к работе с БД отношения не имеет. И к защите от SQL-инъекций тоже.


По сабжу - либо экранирование, либо параметризованные Prepared Statement (либо оба).

Вот только mysql_real_escape_string относится к устаревшему расширению mysql и удалено в современных версиях PHP.
Подробности см. тут - http://php.net/manual/ru/function.mysql-real-escape-string.php
...
Рейтинг: 0 / 0
11.10.2017, 21:06
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535038
vkle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkle
Участник
pash358В моем сайте ничего пользователь не может писатьНе может ничего писать в базу? Гхм, как простой, хотя и немного левый способ - оставить mysql-пользователю, через которого работает сайт, только минимально необходимые привилегии, а все остальные, которые касаются записи/обновления/удаления - отобрать. Даже, бывает, сайты годами работают при таком раскладе (был неописуемый случай, когда заказчик напрочь отказался обновлять насквозь дырявую джумлу-полторашку).
...
Рейтинг: 0 / 0
11.10.2017, 21:11
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535041
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
vkleСУБД выдаст сообщение об ошибке при попытке записать больше данных, чем позволяет поле (попробуйте записать сотню символов в поле VARCHAR(10), например).Обрежется и будет Warning.
Хотя, конечно, и Warning-и проверять надо.
...
Рейтинг: 0 / 0
11.10.2017, 21:18
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535046
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
miksoftvkleСУБД выдаст сообщение об ошибке при попытке записать больше данных, чем позволяет поле (попробуйте записать сотню символов в поле VARCHAR(10), например).Обрежется и будет Warning.
В зависимости от sql_mode . С включенными STRICT_TRANS_TABLES и/или STRICT_ALL_TABLES - будет нормальная ошибка.
...
Рейтинг: 0 / 0
11.10.2017, 21:30
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535050
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Melkijmiksoftпропущено...
Обрежется и будет Warning.
В зависимости от sql_mode . С включенными STRICT_TRANS_TABLES и/или STRICT_ALL_TABLES - будет нормальная ошибка.я вот тоже так думал и читал эту страницу, но бегло именно про длину строковых полей не нашел.
А в доке про INSERT про это "обрезание" написано без отсылки к SQL Mode.
...
Рейтинг: 0 / 0
11.10.2017, 21:34
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535053
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
miksoft,

явным образом не написано (вероятно подразумевается помимо прочего в "or it might be out of range"), я просто проверил поведение
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
mysql> set @@sql_mode='strict_all_tables';
Query OK, 0 rows affected (0.00 sec)

mysql> create table foo (p varchar(10));
Query OK, 0 rows affected (0.07 sec)

mysql> insert into foo values ('111oooooooooo1');
ERROR 1406 (22001): Data too long for column 'p' at row 1
mysql> select * from foo;
Empty set (0.00 sec)
...
Рейтинг: 0 / 0
11.10.2017, 21:40
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535058
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Melkijявным образом не написаноНу, значит, огрехи документации.
Спасибо, что проверили.
...
Рейтинг: 0 / 0
11.10.2017, 21:53
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535202
pash358
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pash358
Гость
Большое всем спасибо за столь многочисленные ответы, НО все-таки я не получил полного ответа на мой вопрос:

Итак, я передаю числовые переменные (2 - 5 шт) через URL (URL: "... .com/catalog1/page_2.php?aaa=1&bb=100") с одной страницы на другую. На принимающей странице беру данные: if (isset($_GET['aaa'])){$aaa=$_GET['aaa'];} else {$aaa=NULL;}
Все переменные числовые и не более 3-х знаков (от 0 до 100).
Я на принимающей странице вначале PHP кода ставлю проверку длины каждой переменной при помощи - strlen() (с числами она работает), то есть в условии будет - если менее 3-х символов и значение равно от 0 до 100, то присваиваю значение переменной $aaa=$_GET['aaa']; , иначе делаю редирект на главную страницу, т.е. все , что хакер понапишет в URL - будет уничтожено. Также при помощи strlen() сделаю проверку длины URL ($_SERVER['REQUEST_URI'];), если слишком большой, то тоже самое - редирект на главную страницу.
ВОПРОС: эти действия защитят от SQL инъекций и т.п. или нет? Ведь проверка будет в самом верху кода PHP, в результате при хакерской записи в URL вроде бы не возможно выполнения хакерского запроса с SQL-иньекцией типа $request=mysql_query("SELECT aaa FROM bbb WHERE ccc='bb'"); и др.
...
Рейтинг: 0 / 0
12.10.2017, 10:18
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535222
vkle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkle
Участник
В данном конкретном случае (ограничение на длину значения любого параметра в три символа) вполне рабочий вариант. Концептуально - подход весьма странный.
...
Рейтинг: 0 / 0
12.10.2017, 10:34
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535273
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
pash358НО все-таки я не получил полного ответа на мой вопрос
Вам уже трижды написали полный ответ: prepared statements.
Никогда не конкатенируйте текст запроса с данными. Всё. Это всё что требуется для исключения SQL-инъекций.
Некоторое сочинение про проверку данных в php я писал вот тут , не хочу пересказывать всё то же самое

pash358иначе делаю редирект на главную страницу
Там где должен быть 404 или редирект на каноничный адрес страницы, если есть.
...
Рейтинг: 0 / 0
12.10.2017, 11:43
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535549
machetero
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
machetero
Гость
pash358 Итак, я передаю числовые переменные (2 - 5 шт) через URL (URL: "... .com/catalog1/page_2.php?aaa=1&bb=100") с одной страницы на другую. На принимающей странице беру данные: if (isset($_GET['aaa'])){$aaa=$_GET['aaa'];} else {$aaa=NULL;}
Все переменные числовые и не более 3-х знаков (от 0 до 100).
если хочешь запилить кастыль - проверяй переменные так - if(is_number($aaa = $_GET['aaa']) && $aaa >= 0 && $aaa =< 100){...}
И это решит твои проблемы.

miksoft Не имеет никакого значения. Это вообще к работе с БД отношения не имеет. И к защите от SQL-инъекций тоже.
К работе с бд это действительно отношения не имеет. Но в веб-разработке GET-запросы не используют, когда надо что-то в базу записать - это философия веба.
...
Рейтинг: 0 / 0
12.10.2017, 17:17
| Ответить | Цитировать | Написать  
Защита при передаче данных по GET.
    #39535994
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
macheteroэто философия веба.
Это не философия, а всего лишь техническое ограничение на объём передаваемых данных. У GET оно мизерное.
...
Рейтинг: 0 / 0
13.10.2017, 13:44
| Ответить | Цитировать | Написать  
23 сообщений из 23, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Защита при передаче данных по GET.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]