DWORD
02.01.2008, 14:01
Ответ в соседнюю, почему-то снова закрытую тему.
Для защиты от xss вполне хватит функции htmlspecialchars() либо htmlentities()
Нет, это демагогия. В общем случае, для защиты от XSS как минимум придется довольно долго искать особенности HTML/JS парсеров конкретных браузеров, потому что все остальное - это не защита от XSS, а отказ от предоставления услуг пользователю, ввиду не знания того, как от него защититься. И Точка.
Проверка на кириллицу вот - $str=preg_replace('/[^а-я]/i','',$str);
Самое полезное регулярное выражение, с которым я когда либо сталкивался. Надо записать на бумажку.
Если нужна проверка на инклуд.
Во первых, инклудить лучше файлы с префиксом, например
include('./inc/inc_'.$_GET['page']);
Во вторых, лучше приписывать расширение к файлу и желательно, чтобы это расширение не было '.php' .
include('./inc/inc_'.$_GET['page'].'.inc');
В третьих, существование файла надо проверять и фильтровать точки :).
$_GET['page']=str_replace('.','',$_GET['page']);
file_exists('./inc/inc_'.$_GET['page'].'.inc')?include('./inc/inc_'.$_GET['page'].'.inc'):echo('неверный файл');
На все вопросы автора ответили уже :)
Это все не так. Технику защиты от PHP-инъекций вы тут грамотно не раскрыли. Хотя ответы действительно на все уже даны, только вот не в этой теме.
как я понял, прочитав http://forum.antichat.ru/thread30641.html
при вводе (+заключаем в кавычки).
1. если число, intval();
2. если строка, mysql_escape_string();
+заключаем в кавычки.
3. при выводе htmlspecialchars();
все?
Самый главный вывод, который следует из той статьи звучит так:
Любое веб приложение можно защитить от любой атаки, отличной от атаки грубой силой, если писать его, зная язык программирования, на котором ты его пишешь и протоколы, по которым общается твое приложение с сервером и клиентом.
Все. Это необходимое и достаточное условие. Видите ли, "SQL-инъекции", "PHP-инъекции", "XSS" не есть область информационной безопасности. Все эти проблемы исчезают ровно тогда, когда человек перестает быть студентом/самоучкой и становится программистом. У него уже рука просто-напросто не повернется написать код с широко известными вам всем дырами, потому что это элементарные вещи, вы все здесь играете в детский сад. Но вас так много, что вам кажется, что это нормально. Это ненормально. Все уязвимости, которые вы рассматриваете, в строгом смысле уязвимостями называть нельзя. Просто код с такими уязвимостями написан человеком, который не владеет стандартами, которыми пытается оперировать, а значит программистом считаться и не может.
Для защиты от xss вполне хватит функции htmlspecialchars() либо htmlentities()
Нет, это демагогия. В общем случае, для защиты от XSS как минимум придется довольно долго искать особенности HTML/JS парсеров конкретных браузеров, потому что все остальное - это не защита от XSS, а отказ от предоставления услуг пользователю, ввиду не знания того, как от него защититься. И Точка.
Проверка на кириллицу вот - $str=preg_replace('/[^а-я]/i','',$str);
Самое полезное регулярное выражение, с которым я когда либо сталкивался. Надо записать на бумажку.
Если нужна проверка на инклуд.
Во первых, инклудить лучше файлы с префиксом, например
include('./inc/inc_'.$_GET['page']);
Во вторых, лучше приписывать расширение к файлу и желательно, чтобы это расширение не было '.php' .
include('./inc/inc_'.$_GET['page'].'.inc');
В третьих, существование файла надо проверять и фильтровать точки :).
$_GET['page']=str_replace('.','',$_GET['page']);
file_exists('./inc/inc_'.$_GET['page'].'.inc')?include('./inc/inc_'.$_GET['page'].'.inc'):echo('неверный файл');
На все вопросы автора ответили уже :)
Это все не так. Технику защиты от PHP-инъекций вы тут грамотно не раскрыли. Хотя ответы действительно на все уже даны, только вот не в этой теме.
как я понял, прочитав http://forum.antichat.ru/thread30641.html
при вводе (+заключаем в кавычки).
1. если число, intval();
2. если строка, mysql_escape_string();
+заключаем в кавычки.
3. при выводе htmlspecialchars();
все?
Самый главный вывод, который следует из той статьи звучит так:
Любое веб приложение можно защитить от любой атаки, отличной от атаки грубой силой, если писать его, зная язык программирования, на котором ты его пишешь и протоколы, по которым общается твое приложение с сервером и клиентом.
Все. Это необходимое и достаточное условие. Видите ли, "SQL-инъекции", "PHP-инъекции", "XSS" не есть область информационной безопасности. Все эти проблемы исчезают ровно тогда, когда человек перестает быть студентом/самоучкой и становится программистом. У него уже рука просто-напросто не повернется написать код с широко известными вам всем дырами, потому что это элементарные вещи, вы все здесь играете в детский сад. Но вас так много, что вам кажется, что это нормально. Это ненормально. Все уязвимости, которые вы рассматриваете, в строгом смысле уязвимостями называть нельзя. Просто код с такими уязвимостями написан человеком, который не владеет стандартами, которыми пытается оперировать, а значит программистом считаться и не может.