Тфу-ты, да, кавычки)
Хм, а тогда смысл всё прогонять через mysql_real_escape_string, когда кавычки всё равно нам ничего не дают? Может я чего-то недогоняю, но как понимаю одним из главных преобразований данной функции - как раз и является замена ' на \' .
16. bems - 27 Декабря, 2009 - 16:36:13 - перейти к сообщению
17. Hunter - 27 Декабря, 2009 - 17:34:08 - перейти к сообщению
...хм.. я вообще с числами почти не работаю (имеется ввиду получаемые данные), php позволяет почти всегда обходиться строками....
18. WebGraf - 27 Декабря, 2009 - 19:19:06 - перейти к сообщению
sql инъекция это одно, но не следует забывать о XSS. И для защиты от 1 и 2 одного mysql_real_escape_string мало
19. bems - 27 Декабря, 2009 - 20:20:26 - перейти к сообщению
А регулярные выражения тут никак помочь случайно не могут. Всмысле чтобы определить, похожи ли вводимые данные на какую-либо sql-команду, или нет. Отсеивать названия команд так понимаю не лучший способ (например вдруг что-то просто хочет употребить слово select), тогда может регулярные выражения смогут помочь?
20. Phantik - 27 Декабря, 2009 - 20:47:28 - перейти к сообщению
Если вы не проффи в криптографии, то функций
mysql_real_escape_string() и strip_tags() будет для ваших сайтов более чем достаточно.
Не изобретайте очередной говно-велосипед, поверьте, умные люди уже давно решили большую часть проблем защиты.
Большая часть уязвимостей всплывает из-за халатного отношения к простым вещам, пользователей и разработчиков. Начните с простых вещей - обрабатывайте ввод пользователя через функции, написанные выше используйте антивирус для ловли троянов и при регистрациях задавайте пароли не словарными словами длинной не менее 10 символов. И еще пароли в базе храните в хэшированом виде с засолкой либо с добавлением закрытого ключа.
mysql_real_escape_string() и strip_tags() будет для ваших сайтов более чем достаточно.
Не изобретайте очередной говно-велосипед, поверьте, умные люди уже давно решили большую часть проблем защиты.
Большая часть уязвимостей всплывает из-за халатного отношения к простым вещам, пользователей и разработчиков. Начните с простых вещей - обрабатывайте ввод пользователя через функции, написанные выше используйте антивирус для ловли троянов и при регистрациях задавайте пароли не словарными словами длинной не менее 10 символов. И еще пароли в базе храните в хэшированом виде с засолкой либо с добавлением закрытого ключа.
21. valenok - 28 Декабря, 2009 - 11:43:22 - перейти к сообщению
А если я проффи в криптографии, чем мне пользоваться?
Статью чтоли пора написать на эту тему..
(Добавление)
Ничего не понимаю. Все же написано.
Статью чтоли пора написать на эту тему..
(Добавление)
Ничего не понимаю. Все же написано.
22. Вездеход - 28 Декабря, 2009 - 11:48:02 - перейти к сообщению
valenok пишет:
А если я проффи в криптографии, чем мне пользоваться?
Статью чтоли пора написать на эту тему..
Статью чтоли пора написать на эту тему..
дадада, напиши. даже мне например будет интересно почитать =)
23. WebGraf - 28 Декабря, 2009 - 13:02:04 - перейти к сообщению
ну да, если strip_tags то другое дело.
Хотя http://phpfaq[dot]ru/safety
htmlspecialchars() всетаки лучше получается
Хотя http://phpfaq[dot]ru/safety
htmlspecialchars() всетаки лучше получается
24. Ammy - 29 Декабря, 2009 - 07:49:35 - перейти к сообщению
Контроль типов данных, ограничения прямого доступа к файлам, работающим непосредственно с базой, обрезание строковых данных соответствующими функциями, свести использование глобальных переменных к минимуму, отрезать у PHP register_globals по самые яйца, тщательно глазками анализировать последовательность выполнения программы, проворачивая подозрительные данные через мясорубку (var_dump). Ну и конечно же писать красивые запросы к базе, и обязательно установить контроль за возможными ошибками функций, работающих с базой. Много и не мало. Есть голова и руки - это зе бест!
25. Hunter - 02 Января, 2010 - 03:18:24 - перейти к сообщению
Ammy пишет:
отрезать у PHP register_globals
да ими и так никто не пользуется (почти), они вообще по умолчанию отключены.
Ammy пишет:
свести использование глобальных переменных к минимуму
в любом случае от их использования совсем не отказаться, даже если их самый минимум то они все равно у меня используются..
26. CodeGold - 02 Января, 2010 - 05:13:04 - перейти к сообщению
да ты говори сайт, мы его попробуем на вкус! )))
27. Hunter - 02 Января, 2010 - 08:53:36 - перейти к сообщению
CodeGold
все на виртуальном хосте на локалке..
все на виртуальном хосте на локалке..
28. Hunter - 09 Января, 2010 - 07:49:52 - перейти к сообщению
ну допустим я обработал строку функцией :
PHP:
скопировать код в буфер обмена
скопировать код в буфер обмена
- <?PHP
- // Функция экранирования переменных
- function quote_smart($value)
- {
- // если magic_quotes_gpc включена - используем stripslashes
- }
- // Если переменная - число, то экранировать её не нужно
- // если нет - то окружем её кавычками, и экранируем
- }
- return $value;
- }
- // Соединяемся
- // Составляем безопасный запрос
- quote_smart($_POST['username']),
- quote_smart($_POST['password']));
- ?>
внес ее в базу..
а как ее к обратному виду потом приводить?
скажем если ник был o'conor то в базу он попадает в виде 'o\'conor' ..
соответственно чтоб его использовать его надо привести к обратному виду?