Вопрос по защите сайта от инъекций и xss атак

Доброй ночи!
Столкнулся с проблемой по защите сайта.
Перелопатил множество статей, но непонял что к чему. Где то пишут что достаточно использовать один метод, где то пишут опровержение этого метода.
Вобщем статьи выдаваемые гуглом ввели меня в заблуждение.
Данные переданые через form например

$pass1 = $_POST['pass1'];

я проверяю через

if (preg_match("/^(?:[-_a-zA-Z0-9]*?[A-Z])(?=[-_a-zA-Z0-9]*?[a-z])(?=[-_a-zA-Z0-9]*?[0-9])[-_a-zA-Z0-9]{6,}$/i", $pass1)){true}{false}

Но для каждого запроса геморно писать РВ (даный РВ я не писал, просто нагуглил, т.к. не совсем понимаю еще РВ).
Вот подумал может кто то сможет дать совет по защите от инъекций через урл и xss атак.
Так же как защититься от подмены этих данных (если это возможно)

if( (isset($_COOKIE['id'])) & (isset($_COOKIE['pass'])) ) {
	if (!isset($_GET['exit'])) {
		$id=$_COOKIE['id'];
		$pass=$_COOKIE['pass'];
		$sql="SELECT id, pass FROM users WHERE id='$id'";

Добавлено через 05:02 сек.
И если можно объясняйте проще, так как терминов(которые могут понять только прошареные программисты) из книг, написаных для новичков (для которых эти термины выглядят как бочка с говном) я не понимаю пока.
Может примеры какие то, по примерам смогу сориентироваться думаю.
Мне так то друг помогает с освоением, но я уже столько раз к нему обращался что как то не удобно беспокоить его по каждым непоняткам.

Прошу прощения за последний блок, не то вставил

if( (isset($_POST['id'])) & (isset($_POST['pass'])) ){
	$id = $_POST['id'];	
	$sql = "SELECT id, pass FROM users WHERE id='$id'";
	$res = mysql_query($sql);

тут кстати проверки вообще нету вот одна из проблем

Добавлено через 07:49 сек.
Если я в качестве фильтрации символов в данном примере буду использовать

$id = int($_POST['id']);

т.к. id это числовое значение, что может зделать в этом случае злоумышленник?

Если я в качестве фильтрации символов в данном примере буду использовать
$id = int($_POST['id']);
т.к. id это числовое значение, что может зделать в этом случае злоумышленник?

Да ничего он не сможет сделать, все что будет приходить в этом посте, преобразуется в число, только если не ошибаюсь нужно так писать :
$id = (int)$_POST['id'] ;

Привыкай что у каждой переменной свой тип данных, фильтруй соотвественно (регулярки достаточно редко нужны).
Регулярка для пароля дюже сложная у тебя

Добавлено через 02:28 сек.
Вообще рекомендую сделать функцию-фильтр. есть стандартная, но я предпочитаю делать свою, с своими типами, чтоб можно было централизованно модифицировать фильтр, а не в каждом файле потом править).
Ну и использовать типа...
$var1=check($_POST['var1'], 'text');
$var2=check($_POST['var2'], 'num');
$var3=check($_POST['var3'], 'mail');
и т.д.

shilo (2 Сентября 2013 / 22:53)
Регулярка для пароля дюже сложная у тебя

Ну пароли типа Qwert1 сейчас почти на всех веб сайтах используются так как это усложняет возможность подбора + каптча будет.
А вот на счет ползовательских функций я уже обдумывал, но не совсем понял как ими пользоваться (нуб)
На данный момент имею книгу Нины Савельевой (в Интернет университете информационных технологий покупал) сижу читаю про функции, но чесно сказать " смотрю в книгу, вижу фигу"))

ТС, есть много базовых принципов, на основании которых и строится защита от XSS. Они описаны много где. Я вот приведу то, чем сам пользуюсь:
1. все данные нужно приводить к определенному типу, ожидаемому скриптом
2. В зависимости от особенностей задачи, а также сложившейся ситуации, нужно использовать правила. То есть, в одних случаях полностью все запрещать, кроме некоторых исключений. В других же - все разрешать, кроме некоторых исключений. Это так называемые "черные" и "белые" листы.
3. Проверять, или же фильтровать данные. Разница в том, что, если это текстовый блок, и в нем возможна передача скрипту вредоносного кода, то данный текстовый массив можно отфильтровать на предмет всяких "лишних" данных. Если же это же логин пользователя, то нужно проверить, и сгенерировать сообщение об ошибке.
4. Для работы с БД использовать безопасные "подготовленные выражения". Они обезопасят от выполнения SQL - injection.

А вообще-то, вся защита построена на многих факторах. Тут не только XSS, а и много других опасностей.

По-моему, нужно просто получше разобраться с php, а там и понимание защиты от инъекций придет. Если сложно по одной книге - использовать другую, смотреть код скриптов.

2147483647 - максимальное значение для int. если число будет больше, оно будет приводиться к этому

Zдешний (3 Сентября 2013 / 05:15)
2147483647 - максимальное значение для int. если число будет больше, оно будет приводиться к этому

Уже сталкивался с этой проблемой. Решаема.

Добавлено через 06:17 сек.

Кевин Митник_HHTeam (3 Сентября 2013 / 01:15)
ТС, есть много базовых принципов, на основании которых и строится защита от XSS. Они описаны много где. Я вот приведу то, чем сам пользуюсь:
1. все данные нужно приводить к определенному типу, ожидаемому скриптом
2. В зависимости от особенностей задачи, а также сложившейся ситуации, нужно использовать правила. То есть, в одних случаях полностью все запрещать, кроме некоторых исключений. В других же - все разрешать, кроме некоторых исключений. Это так называемые "черные" и "белые" листы.
3. Проверять, или же фильтровать данные. Разница в том, что, если это текстовый блок, и в нем возможна передача скрипту вредоносного кода, то данный текстовый массив можно отфильтровать на предмет всяких "лишних" данных. Если же это же логин пользователя, то нужно проверить, и сгенерировать сообщение об ошибке.
4. Для работы с БД использовать безопасные "подготовленные выражения". Они обезопасят от выполнения SQL - injection.

А вообще-то, вся защита построена на многих факторах. Тут не только XSS, а и много других опасностей.

с теоритической частью я знаком.

Im-ieee

Невижу смысла в чтении того, что сложно понять. Почти все книги написаны одинаково.

9. XwiruS, решаема, да. если нужны только цифры, то регуляркой.

Добавлено через 05:52 сек.
не помню где, вроде на хвабе видел темку, там автор предлагал фильтровать всё htmlspecialchars с режимом ENT_QUOTES. а если воспользоваться strip_tags? ну при записи в бд конечно mysql_real_escape_string, mysqli_real_escape_string, sqlite_escape_string. хм...