Форум PHP

Ага, это я нашёл... сегодня вечером постараюсь забросить в раздел "Статьи о PHP".

PS Можно будет потом вторую статью написать, эту переименуем в часть 1, а вторая будте часть 2.

Нашел несколько опечаток
1.

Рассмотрим код уязвимой станицы <input name="username" value="<? echo $_GET['username'] ?>"> Злоумышленнику достаточно сформировать URL следующего вида: http://www.server.com/index.php?a="><script>alert(document.cookie)</script>

1. В URL переменная "a" а выбираем "usernmae"
для одного из приведенных кодов, забыто [ code ] [ /code ] =)
После их исправления, можно добавлять статью
P.S. Жаль что далеко не все я смог рассказать. есть, например, способ обойти htmlspeshialchars, но если рассказывать ОБО ВСЕХ тонкостях, но наверное я сам потом не разберусь, что сам написал.

Если будет править не берите этот вариант пишите сюда, я вышлю документ Word, так как нашёл кучу огрехов, которые сам и внёс :))) и уже их поправил...

Да 8-[ ] похоже единственный стопроцентный способ защитить своё приложение вообще его не выкладывать...
И то не факт, из дома стырить могут, вместе с компом :)

Статью переработал, добавил, материал по SQL-инъекциям и защите форм при помощи сессий. Добавлюсь сам к вам вторым автором :))) Смотрите что ещё где исправить, как дадите команду - выкладываем.

Безопасное программирование на php
Авторы - Семенов А.Н., Симдянов И.В.

Безопасность web-приложений имеет большое значение и занимает одно из первых мест в построение надежного и качественного сайта. Рано или поздно сайт подвергнется атаке, пренебрежение безопасностью при написании Web-приложений приведёт к тому, что в лучшем случае вы увидите на главной станице сайта надпись "взломан", а в худшем потеряете важную информацию.
В этой небольшой статье я поделюсь с вами теми приемами, которыми использую сам при построении сайтов. Мы рассмотрим методы защиты, позволяющие предотвратить или, по крайней мере, снизит подверженность приложения к XSS-атакам и SQL-инъекциям.
Межсайтовый скрипинг (Cross Site Scripting - XSS) позовет злоумышленнику включать свой HTML код в вашу станицу. Наиболее уязвимы для такого вида атак гостевые книги и форумы, где происходит динамическое формирование страниц. Возможности кода, который злоумышленник может вставить в код сайта практически не ограничены, например, от вставки тега <img> со ссылкой на скрипт, который расположен на подконтрольном сайте до сбора различной информации (например, cookie). Суть атаки — выйти за пределы html тега, через специальные символы, и далее внедрять свой код. Выход из тега чаще происходит с использованием следующих символов — ' (одинарная кавычка), " (двойная кавычка), &acute; (обратная кавычка), > (знак "больше"). Защита от этого вида атак сводится к фильтрованию данных отосланных пользователем.
Рассмотрим код уязвимой станицы

<input name="username" value="<? echo $_GET['username'] ?>">

Злоумышленнику достаточно сформировать URL следующего вида:
http://www.server.com/index.php?a="><script>alert(document.cookie)</script>
и страница будет уже содержать следующий код:

<input name="username" value=""><script>alert(document.cookie)</script>">

Данный код не причиняет вреда, а лишь демонстрирует уязвимость XSS, отображая ваши cookie. Следует помнить, что код может быть другим, более опасным и будучи оставленным, например, в сообщении гостевой книги будет запускаться на машине каждого из посетителей гостевой книги.

Замечание
С синтаксисом регулярных выражений и функциями PHP, предназначенными для работы с ними можно ознакомиться в соответствующем разделе справочника PHP http://www.softtime.ru/group/id_group=3

Замечание
Синтаксис регулярных выражений является достаточно сложным и его изучение требует серьёзных усилий. Наилучшим руководством по регулярным выражением на сегодняшний день является книга Дж. Фридла "Регулярные выражения", позволяющая, по словам автора, "научиться мыслить регулярными выражениями".

Чтобы обезопасить себя от такого вида атак, следует отфильтровать значение, передаваемое через параметр username, например, при помощи регулярных выражений:

<?php    // [u]Удаляем[/u] все символы кроме букв и цифр    $a = preg_replace("/[a-z0-9]/i", "", $_GET['a']);  ?>

По результатам проверки можно либо продолжить работу скрипта, либо вывести в окно браузера страницу "предупреждения".

<?php    // [u]Проверяем[/u] все символы на буквы и цифры    if( !( preg_match("/([a-z0-9])*/i", $_GET['a']) ) )    {       header("plz_die.php");    }  ?>

Что предпринять — выбор за вами. Лучше написать о разрешенных символах где-нибудь рядом с соответствующим полем HTML-формы, иначе посетитель может вести свое имя и обнаружить что оно отображается не так, как нужно (например Elvi$ как Elvi) и ему придется проходить процедуру регистрации повторно. Кроме того, посетитель может случайно вести неверный символ и устрашающий вид страницы plz_die.php, может его отпугнуть.

Замечание
Следует проверять ВСЕ переменные получаемые от пользователя — GET, POST, COOKIE. Во все из них без труда можно встроить зловредный код. Особое внимание следует уделять паролям, так как в них не принято вводить ограничения на символы.

PHP обладает несколькими функциями, позволяющими значительно облегчить задачу защиты Web-приложений. Одной из таких функций является htmlspecialchars() которая гарантирует, что любой введенный пользователем код (php, javascript и т.д.) будет отображен, но выполняться не будет. Функция имеет следующий синтаксис:

string htmlspecialchars (string str [, int quote_style [, string charset]])

Через первый обязательный параметр str, функции передается обрабатываемый текст, который возвращается после преобразования как результат работы.
Второй необязательный параметр quote_style задаёт режим обработки одинарных и двойных кавычек. По умолчанию, данный параметр соответствует константе ENT_COMPAT, в данном режиме двойные кавычки заменяются символом "&quot;", при этом одиночные остаются без изменений. Кроме этого параметр может принимать два других значения: ENT_QUOTES и ENT_NOQUOTES. В первом случае, помимо двойных, кавычек преобразованию подвергаются так же одинарные кавычки, которые заменяются символом "&#039;". Значение параметра ENT_NOQUOTES задаёт режим, в котором не один из видов кавычек не подвергается преобразованию.
Последний параметр charset определяет кодировку, например "cp1251" или "KOI8-R".
Данная функция предназначена для отображения кода и HTML-разметки на Web-странице, но вводимые пользователем данные не мешает пропускать через неё, во избежание неприятностей.
Другой полезной функцией является stripslashes(), которая предназначена для удаления обратных слешей и имеет следующий синтаксис:
string stripslashes (string str)
Функция принимает единственный параметр str, с обрабатываемой строкой. Результатом работы функции является строка str в которой удаляются экранирующие бэкслэши (\' преобразуется в ', двойные бэкслэши (\\) преобразуется в одиночные(\) и т.д.).

SQL-инъекции — абсолютно другой вид атаки и он наиболее опасен. В Web-приложения, где есть данного вида уязвимость, злоумышленник может внедрить свой SQL код, что может провести к потери информации, краже или полному уничтожению базы данных.

Пусть имеется база данных пользователей users, содержащая три поля: первичный ключ (id_user), имя пользователя (name) и его пароль (pass). SQL-оператор CREATE, создающий данную таблицу приведён ниже.

CREATE TABLE users (   id_user int(11) NOT NULL auto_increment,   name tinytext,   pass tinytext,   PRIMARY KEY (id_user) ) TYPE=MyISAM; INSERT INTO users VALUES (1, 'user1', 'pass1'); INSERT INTO users VALUES (2, 'user2', 'pass2'); INSERT INTO users VALUES (3, 'user3', 'pass3');

Авторизация пользователей производится через HTML-форму.

<form action=handler.php method=post>  Имя посетителя : <input type=text name=name ><br>  Пароль : <input type=password name=pass ><br>  <input type=submit value=Отправить>  </form>

Обработчик handler.php проверяет соответствие введённого имени паролю

<?php   // Устанавливаем соединение с базой данных   include "config.php";   // Осуществляем соответствия имени паролю   $query = "SELECT * FROM users             WHERE name = '$_POST[name]' AND                   pass = '$_POST[pass]'";   $usr = mysql_query($query);   if(!$usr) exit("Ошибка в SQL-запросе");   if(mysql_num_rows($usr)>0)   {     // Вход в защищённую область сайта   } ?>[code] Данный метод авторизации обходиться указанием следующего значения в для ввода пароля pass: [code]123' AND 1=1

Или даже еще проще, например вводом следующего значения в качестве имени users:

admin'/*

Все что следует за "/*" считается комментарием. В любом из этих случаев будет получен допуск в защищенную область сайта. Как вы уже, наверное, успели заметить, атака основывается через указание кавычки, позволяющей выйти за рамки, отведенных программистом.
Методом защиты служит, как и предыдущем случае, фильтрацией данных.
Вот несколько вариантов. Приведено только для переменной user, лишь для экономия места.

<?php   // добавляем слешы перед кавычками, чтобы они стали виде escape-последовательности,   // например ' замениться на \', " замениться на \"    $user = addslashes( $user );    // заменяем все специальные символы эквивалентом    $user = htmlspecialchars ( $user );    // отрезаем все ненужные симовлы    $user = preg_replace("/[a-z0-9]/i", "", $_GET['a']  ?>

Может быть использован любой из них или их комбинации.

В некоторых случаях для в формирования SQL используется не строчка, а цифра. Это наиболее опасно, потому что злоумышленнику даже не надо добавлять кавычку, а сразу добавлять код после пробела.

<?php
$id = $_POST['id'];
$pass = $_POST['passw'];
$sql = "SELECT info FROM users WHERE user_id = $id AND pass = '$pass'"
// если запрос не вернул результат, то пользователь не найден
if( !( mysql_num_rows( mysql_query( $sql ) ) ) )
{
echo 'Нет такого пользователя';
}
?>

Параметр id злоумышленника тогда будит иметь такой вид:
1/*
ВСЕ!

Проблема числовых параметров, встала еще более остро, начиная с MYSQL 4, где появился SQL-оператор UNION, объединяет результаты запросов. Пусть страницу с информацией о пользователе формирует скрипт user.php, который принимает в качестве параметра первичный ключ id_user из таблицы users.

<?php   // Устанавливаем соединение с базой данных   include "config.php";   // Осуществляем запрос к базе данных,    // извлекая запись из таблицы user   if(isset($_GET['id_user']))   {     // Формируем SQL-запрос     $query = "SELECT * FROM users WHERE id_user = ".$_GET['id_user'];     // Выполняем SQL-запрос     $usr = mysql_query($query);     if($usr) exit("Ошибка при обращении к таблице пользователей");     $user = mysql_fetch_array($usr);     // Выводим имя пользователя     echo $user['name'];   } ?>

Результатом работы скрипта при обращении к странице по адресу users.php?id_user=1 является вывод имени посетителя: user1
Теперь помещая в адресную строку следующий адрес

http://localhost/user.php?id_user=-1 %20UNION%20SELECT%201,pass,name%20FROM%20users%20WHERE%20id_user=1

можно получить пароль пользователя с первичным ключом id_user = 1: pass1.

Проверить содержимое числового параметра можно при помощи следующего регулярного выражения:

<?php   if(!preg_match("|^[\d]*$|", $_GET['id_theme'])) exit(); ?>

Или при помощи функции is_numeric

<?php   // Проверяем значение на число    if( !is_numeric($id) )    {          die("Неверное значение в строке запроса!");    }    // Или же так преобразуем значение    $id = intval($id);  ?>

Третий вид атаки, который может быть произведён на сайт — это флуд, часто в автоматической форме.

Замечание
Размещение однотипных сообщений на форуме или гостевой книге на жаргоне Web-разработчиков называется флудом (от англ. flood — поток, избыток).

Злоумышленник может загрузить страницу с формой добавления сообщения к себе на локальный компьютер и добавить несколько сотен сообщений в гостевую книгу или форум. Для предотвращения такого вида атак существует два метода борьбы

Замечание
Элемент суперглобального массива $_SERVER['REFERRER'] содержит адрес страницы с которой посетитель пришёл на данную страницу.

Проверка элемента суперглобального массива $_SERVER['REFERRER'] на предмет содержания в нём адреса исходного сайта, позволяет устранить данный вид атаки

<?    // $site_addres можете поменять на свое    // но лучше определить его в "общем" файле    if ($_SERVER['REFERRER'] =! $site_address) die;  ?>

Не стоит сильно надеяться на эту защиту, ведь REFERER формируется браузером, а значит, может быть подделан. Поэтому когда необходима более надёжная защита необходимо прошить HTML-форму сессией.

<?php   // Инициируем сессию   session_start(); ?> <form action=handler.php method=post> Имя : <input type=text name=name><br> Пароль : <iput type=password name=pass><br> <input type=submit name=send value=Отправить> <input type=hidden name=session_id value=<?php echo echo session_id();?>>  </form>

Как видно HTML-форма содержит дополнительное поле с именем session_id. После того как пользователь нажимает на кнопку "Отправить" данные отправляются обработчику:

<?php   // Инициируем сессию   session_start();   // Сравниваем переданный идентификатор из формы с   // текущим идентификатором сессии   if($_POST['session_id'] != session_id())   {     exit("Попытка передачи данных с другого хоста. Скрипт остановлен.");   }   // Дальнейшая обработка данных... ?>

В котором значение поля session_id проверяется с текущим идентификатором сессии.

Теперь несколько рекомендаций по защите сайта.

1. Не используйте проверку на возращение строки (mysql_num_rows()), а применяйте следующий подход:

<?php    $user = $_POST['user'];    $pass = $_POST['pass'];    $sql = "SELECT user, pass FROM users WHERE user = '$user'";    list($m_user, $m_pass) = mysql_fetch_row( mysql_query($sql) );    if ( $pass != $m_pass or  // даст TRUE, если пароли не равны       $user != $m_user // данная проверка даст TRUE, если была sql инъекция    )    {          die("die");    }  ?>

2. Не используйте на прямую foreach() для массивов переменных переданных от пользователя

<?php  foreach ($user as $k => $v)  {          $sql = "UPDATE users SET $k = $v WHERE user ='$user['name']'";          mysql_query($sql);  }  ?>

Злоумышленник может подправить код и добавить еще один параметр к массиву.
Как альтернативу можно предложить следующий код:

<?php   $users_vars = array('Date' => 'Date', 'City' => 'City', 'ZIP' => 'ZIP');   foreach ($user as $k => $v)   {      if( isset($_POST[$users_vars[$k]]) )     {         $sql = "UPDATE users SET $k = $v WHERE user ='$user['name']'";         mysql_query($sql);     }   } ?>

3) Там где не требуется ввод большого объёма данных ограничивайте число вводимых в HTML-форму символов, за это несёт ответственность параметр maxlength тега input. Например, в следующем текстовом поле ввести можно не более 32 символов:

<input name="user" maxlength="32" value="">

Можно организовать проверку и непосредственно в скрипте

<?    // Не будим доверять пользователю, ведь подправить значение maxlength    // можно и на локальной машине    substr($_POST['user'], 0, 32);  ?>

И напоследок несколько блиц-советов:
- лучше использовать "белый" список чем "черный" (Лучше разрешать только нужное, чем запрещать ненужное)
- помните, что картинка может на самом деле оказать скриптом!
- когда дело доходит до взлома, злоумышленник проявляет всю изобретательность, заложенную в него природой, в тоже время, когда дело доходит защиты, программист же демонстрирует верх скудоумия и однообразности, так как ему чисто психологически не хочется ломать собственное творение. Для тестирования своего сайта приглашайте сторонних людей.
- если код Web-приложения неизвестен злоумышленнику, его гораздо сложнее ломать. Не ленитесь – напишите собственное Web-приложение, на своём уникальном движке – не используйте готовые широкоизвестные Web-приложения. В тоже время постарайтесь не выводить полный отчёт при возникновении ошибки по которому легко восстановить логику Web-приложения.

Вот теперь, пожалуй, и все.

Подробно про XSS:
http://www.bugtraq.ru/library/www/xssanatomy.html
http://www.bugtraq.ru/library/www/advancedxss.html


PS Жалко статья уже очень здоровая и не получается добавить защиту от подделки ников и загрузки зловередных PHP и Perl скриптов на сайт.

Да нет вообще реальной защиты от таких дыр. Чтобы гарантировать что вошедшие данные безопасны, нужно всегда сканить их на предмет наличия спецсимволов, их последовательностей и прочее... прочее..., а это такой гемор!

Классно... забираю на редактирование, добавлю материал из 9 главы третьей книги посвящённой безопасности...

Здравствуйте. Давно меня не было, потому что сессия была, поэтому заходил на форум чтобы лишь почитать.
Хочу на ваш суд представить мою новую статью.
Безопасность при программировании на php.
Прочтите и дайте значить, если я где-то допустил ляпы...
Вот статья:
______________

Безопасное программирование на php

Безопасность web-приложений имеет очень огромное значение и занимает одно из первых мест в построение надежного и качественного сайта. Если пренебрегать безопасностью при написании web-приложений, рано или поздно сайт подвергнуться атаке и в лучшем случае вы увидите на главной станице сайта надпись "взломан", а в худшем потеряете важную информацию.
В этой небольшой статье я поделюсь с вами теми приемами, которыми сам пользуюсь. Мы рассмотрим методы защиты, позволяющие предотвратить или по крайней мере снизит подверженность приложения к XSS - атакам, SQL инъекциям.
Меж сайтовый скрипинг (Cross Site Scripting - XSS) позовет злоумышленнику включать свой html код в вашу станицу. Это наиболее опасно при использовании гостевых книгах и на досках объявлений, где станицы динамически формируются и изменяются. Возможности кода, который может вставить злоумышленник очень велики, например, вставка тега <img> со ссылкой на скрипт на подконтрольном ему сайте и собрать различную информацию (например, cookie). Но для этого, злоумышленнику надо, чтобы жертва зашла на "взломанную" станицу. Суть атаки - выйти за пределы html тега, через специальные символы, и далее внедрять свой код. Выход из тега чаще происходит по следующим символам - ' (кавычка), " (двойная кавычка), ' (обратная кавычка), > (знак "больше"). Защита от этого вида атак сводится к фильтрованию данных отосланных пользователем.
код Уязвимой станицы
<input name="username" value="<? echo $_GET['$a'] ?>">
Злоумышленнику достаточно сформировать следующий url:
www.server.com/index.php?a="><script>alert(document.cookie)</script>
и страница будит уже выглядеть так
<input name="username" value=""><script>alert(document.cookie)</script>">
Данный код не причинят вреда, а лишь показывает уязвимость XSS, отображая ваши cookie, но код может быть другим, более опасным и оставлен, например, в сообщение гостевой книги, и каждый кто зайдет на данную станицу, запустит данный код.
Чтобы обезопасить себя, следует отфильтровать значения переменной "a":

<?php // [u]Удаляем[/u] все символы кроме букв и цифр $a = preg_replace("/[a-z0-9]/i", "", $_GET['a']); ?>

В данном случае можно лишь делать проверку на символы, и показывать страницу "предупреждения" злоумышленнику.
Вот так

<?php // [u]Проверяем[/u] все символы на буквы и цифры if( !( preg_match("/([a-z0-9])*/i", $_GET['a']) ) ) {         header("plz_die.php"); } ?>

Что предпринять - выбор за вами. В первом случае лучше написать о разрешенных символах где-нибудь рядом, иначе пользователь может вести свое имя и обнаружить что оно отображается не так, как нужно (например Elvi$ как Elvi) и ему придется регистрироваться вновь. Во втором варианте пользователь может случайно вести неверный символ и увидит страницу plz_die.php, что может отпугнуть посетителя.
Замечание
Следует проверять ВСЕ переменные получаемые от пользователя - GET, POST, COOKIE. Во все из них может быть встроен код злоумышленника. Особое внимание уделите паролям, ведь их не нужно никак ограничивать.

SQL инъекции - абсолютно другой вид атаки и он наиболее опасен. В web-приложения, где есть данного вида уязвимость, злоумышленник может внедрить свой SQL код, что может провести к потери информации, краже или полному уничтожению базы данных.
Рассмотрим код, подверженный SQL инъекции

<?php $user = $_POST['user']; $pass = $_POST['pass']; $sql = "SELECT * FROM users WHERE user = '$user' AND password = '$pass'"; // если  запрос не вернул результат, пароль пользователя не соответствует тому, что в базе данных if( !( mysql_num_rows( mysql_query( $sql ) ) ) ) {         echo 'Неверный пароль'; } ?>

Данный метод авторизации обходиться указанием следующего значения в параметре pass:
123' AND 1=1
Или даже еще проще, следующим значением параметра users:
admin'/*
Все что следует за "/*" считается комментарием и добавлено, чтобы не вызвать ошибки SQL
В любом из этих случаях будит получен допуск в защищенную часть сайта.
Как вы уже, наверное, успели заметить, атака основывается через указание кавычки, позволяющей выйти за рамки, отведенных программистом.
Методом защиты служит, как и предыдущем случае, фильтрацией данных.
Вот несколько вариантов. Приведено только для переменной user, лишь для экономия места.

<? // добавляем слешы перед кавычками, чтобы они стали виде escape-последовательности, например ‘ замениться на \', “ замениться на \" $user = addslashes( $user ); // заменяем все специальные символы эквивалентом $user = htmlspecialchars ( $user ); // отрезаем все ненужные симовлы $user = preg_replace("/[a-z0-9]/i", "", $_GET['a'] ?>

Может быть использован любой из них или их комбинации.
Еще один важный момент. В некоторых случаях для в формирования SQL используется не строчка, а цифра. Это наиболее опасно, потому что злоумышленнику даже не надо добавлять кавычку, а сразу добавлять код после пробела.

<?php $id = $_POST['id']; $pass = $_POST['passw']; $sql = "SELECT info FROM users WHERE user_id = $id AND passwod = '$pass'" // если  запрос не вернул результат, то пользователь не найден if( !( mysql_num_rows( mysql_query( $sql ) ) ) ) {         echo 'Нет такого пользователя'; } ?>

Параметр id злоумышленника тогда будит иметь такой вид:
1/*
ВСЕ!
Это стало еще более серьезной проблемой, начиная с MYSQL 4, где есть union - объединяет результаты запросов.
Наилучшей проверкой в данном случае воспользоваться функцией is_numeric, которая проверяет значение на число или же применить преобразование в целое значение функцией intval

<? // Проверяем значение на число if( !is_numeric($id) ) {         die("Неверное значение в строке запроса!"); } // Или же так преобразуем значение $id = intval($id); ?>

Теперь я бы хотел дать несколько рекомендаций, при написании SQL запросов.
1. Рекомендую, не используйте проверку на возращение строки (mysql_num_rows), а применяйте другой подход:

<?php $user = $_POST['user']; $pass = $_POST['pass']; $sql = "SELECT user, password FROM users WHERE user = '$user'"; list($m_user, $m_pass) = mysql_fetch_row( mysql_query($sql) ); if ( $pass != $m_pass or  // даст TRUE, если пароли не равны      $user != $m_user // данная проверка даст TRUE, если была sql инъекция ) {         die("die"); } ?>

2. Рекомендую, не используйте на прямую foreach для массивов переменных переданных от пользователя

<?php foreach ($user as $k => $v) {         $sql = "UPDATE users SET $k = $v WHERE user ='$user['name']'";         mysql_query($sql); } ?>

Злоумышленник может подправить код и добавить еще один параметр к массиву.
Как альтернативу могу предложить следующий код:
<?php
$users_vars = array('Date' => 'Date', 'City' => 'City', 'ZIP' => 'ZIP');
foreach ($user as $k => $v)
{
if( isset($_POST[$users_vars[$k]]) )
{
$sql = "UPDATE users SET $k = $v WHERE user ='$user['name']'";
mysql_query($sql);
}
}
?>
[/code]

Теперь стоит рассмотреть общие принципы организации защиты на сайте.
Для начала это несложные манипуляции добавление значения maxlength для тега input
<input name="user" maxlength="32" value="">
и непосредственно в скрипте

<? // Не будим доверять пользователю, ведь подправить значение maxlength // можно и на локальной машине substr($_POST['user'], 0, 32); ?>

Проверим REFERRE'A на наш адрес, что у пользователя не было желания скачать страницу себе на локальный компьютер. Данную проверку для станиц обрабатывающих POST значения.

<? // $site_addres можете поменять на свое // но лучше определить его в "общем" файле if ($_SERVER['REFERRER'] =! $site_address) die; ?>

Но не стоит сильно надеяться на эту защиту, ведь REFERER формируется браузером, а значит может быть изменен.

И напоследок несколько заповедей программиста:
- лучше использовать "белый" список чем "черный" (Лучше разрешать только нужное, чем запрещать ненужное)
- помните, что картинка может на самом деле оказать скриптом!

Вот теперь, пожалуй, и все.

Подробно про XSS:
http://www.bugtraq.ru/library/www/xssanatomy.html
http://www.bugtraq.ru/library/www/advancedxss.html
__________________________________________
И так, у кого какие вопросы?

P.S
Подробно про SQL injection ничего путного не нашел. Как только увижу - скину ссылки сюда.