Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: sql инъекция [2]
Форумы портала PHP.SU » PHP » Программирование на PHP » sql инъекция

Страниц (3): « 1 [2] 3 »
 

16. bems - 27 Декабря, 2009 - 16:36:13 - перейти к сообщению
Тфу-ты, да, кавычки)
Хм, а тогда смысл всё прогонять через mysql_real_escape_string, когда кавычки всё равно нам ничего не дают? Может я чего-то недогоняю, но как понимаю одним из главных преобразований данной функции - как раз и является замена ' на \' .
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 символов. И еще пароли в базе храните в хэшированом виде с засолкой либо с добавлением закрытого ключа.
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() всетаки лучше получается
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:
скопировать код в буфер обмена
  1. <?PHP
  2. // Функция экранирования переменных
  3. function quote_smart($value)
  4. {
  5.     // если magic_quotes_gpc включена - используем stripslashes
  6.     if (get_magic_quotes_gpc()) {
  7.         $value = stripslashes($value);
  8.     }
  9.     // Если переменная - число, то экранировать её не нужно
  10.     // если нет - то окружем её кавычками, и экранируем
  11.     if (!is_numeric($value)) {
  12.         $value = "'" . mysql_real_escape_string($value) . "'";
  13.     }
  14.     return $value;
  15. }
  16.  
  17. // Соединяемся
  18. $link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
  19.     OR die(mysql_error());
  20.  
  21. // Составляем безопасный запрос
  22. $query = sprintf("SELECT * FROM users WHERE user=%s AND password=%s",
  23.             quote_smart($_POST['username']),
  24.             quote_smart($_POST['password']));
  25.  
  26. mysql_query($query);
  27. ?>

внес ее в базу..
а как ее к обратному виду потом приводить?
скажем если ник был o'conor то в базу он попадает в виде 'o\'conor' ..
соответственно чтоб его использовать его надо привести к обратному виду?
29. movEAX - 09 Января, 2010 - 10:49:12 - перейти к сообщению
Hunter пишет:
o'conor то в базу он попадает в виде 'o\'conor' ..

А что если использовать base64_encode для занесения именив базу?
30. Мелкий - 09 Января, 2010 - 11:00:38 - перейти к сообщению
Hunter пишет:
скажем если ник был o'conor то в базу он попадает в виде 'o\'conor' ..
соответственно чтоб его использовать его надо привести к обратному виду?

А если проверить? Подмигивание В базу строка записывается без экранирования.

 

Powered by ExBB FM 1.0 RC1