All-For-Kompa.RU (AFK) - Омский Развлекательный портал ^ Всё Для Компа ^ скачать софт, игры, фильмы, музыку и многое другое с торрента совершенно бесплатно и без регистрации!

Страница 1 из 1 1
Модератор форума: Vladislavik-36

Защита сайта от взлома часть 2

leonP4

Дата: Суббота, 21.03.2009, 14:09 | Сообщение # 1

.:хакер:.

Группа: Администратор

Сообщений: 664

Награды: 11

Статус: Offline

Защита сайта от взлома часть 2 В первой статье мы с Вами рассмотрели защиту Вашего Веб сайта от попытки взлома передачей данных методами GET и POST. Но предотвращение попадания вредоносных данных в приложение, это только одна сторона защиты. Сегодня мы поговорим о том, какие данные и каким образом попадают в приложение, и как вполне "добропорядочные" пользователи могут повредить Ваше приложение, сами того не желая. Не побоюсь повториться! Никогда не верьте данным, которые приходят от пользователя. И хотя эти данные могут и не нести в себе какой-либо вредоносной информации (например, JavaScript), но все равно, эти данные могут повредить Вашему приложению. Как минимум, нарушив логику его работы. Например, если пользователь в форме ввода сообщения гостевой книги вместо даты введет свой электронный адрес, или напишет дату прописью, то логика работы Вашего приложения окажется нарушена. Как минимум, при сохранении такой записи в базе данных Вы лишитесь возможности сортировать сообщения по дате их написания. Вот о защите от таких случаев мы и поговорим сегодня. Начнем с самого примитивного способа ограничения пользователей в своей фантазии.

Code

На роль настоящей защиты это, конечно претендовать не может - единственное назначение данного элемента - ограничить пользователя от случайного ввода имени длиннее 20-ти символов. Как показывает практика, для ввода имени такого ограничения вполне хватает. Вот Вы можете вспомнить имя длинной, хотя бы, в 21 символ? И у меня не получается. Следующим этапом станет пресловутая жесткая фильтрация переданных данных. Прежде всего, удалим из сообщения конечные и начальные пробелы:

Code

protected::$_post[`username`]=trim(protected::$_post[`username`]);

Так же, не будем доверять переменной maxlength в формах ввода (не так сложно сохранить страницу на диск и подправить допустимый размер), вручную порежем строку:

Code

protected::$_post[`username`] = substr(protected::$_post[`username`],0,20);

Теперь остается только проверить имя пользователя. И понять пустое это сообщение или нет, и если строка окажется пустой вывести сообщение об ошибке ввода данных.

Code

if (empty(protected::$_post[`username`])) { echo "Поле ввода имени не может быть пустым!"; exit; }

Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака "_" (подчерк), пробела и цифр:

Code

if (preg_match("/[^(w)|(x7F-xFF)|(s)]/", protected::$_post[`username`])) { echo "Поле ввода содержит недопустимые символы"; exit; }

Для поля ввода адреса e-mail добавим в список разрешенных символов знаки "@" и ".", иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:

Code

if (preg_match("/[^(w)|(@)|(.)]/",protected::$_post[`usermail`])) { echo "Электронный адрес не соответсвует допустимому"; exit; }

Должен отметить, что данное регулярное выражение не совсем подходит для проверки электронного адреса. Более правильные регулярные выражения Вы найдете в специальной литературе. Хотя можно конечно, ограничиться и тем, которое я привел. Для защиты поля ввода текста вполне достаточно использованного нами в прошлой статье способа. Все HTML теги будут преобразованы в безопасное представление. Многие скажут - "Но я хочу, что бы мои пользователи моги вводить некоторые теги!". Что же, вполне логичное желание. Текст неразбитый на абзацы, не отформатированный смотрится на сайте не очень красиво. Одно из возможных решений данного вопроса это использования PHP_BB кодов. Когда пользователь вводит, например [ul][/ul] а на сайте это преобразуется в нормальный список. Решить это можно, например следующим выражением:

Code

$content = preg_replace("#[ul](.+)[/ul]#isU",`<ul>\1</ul>`,$content);

Технически таким же способом решается ввод всех необходимых Вам тегов. Отдельно нужно сказать про вставку картинок пользователем. Браузер клиента не проверяет, какой именно файл поставлен в виде картинки. При отображении он ориентируется на заголовки которые отправляет сервер. Потому такой -

Code

<img src="http://site.ru/img.jpg" /> И такой <img src="http://site.ru/img.php" />

Коды приведут к попытке отображения картинки, если во втором случае php скрипт выдаст заголовок соответствующий изображению. Естественно, перед тем как вернуть заголовок и само изображение, скрипт может сделать очень многое. Например, сохранить логины и IP адреса пользователей, а если повезет то и пароли. Самое простое и надежное решение этой проблемы не позволять вставку файлов изображений с удаленных серверов. Закачивать изображение к себе на сайт и показывать его со своего сайта. В процессе закачки у нас будут все возможности проверить, действительно ли к нам передано изображение или это попытка взлома. Этой процедуре будет посвящена отдельная статья. Теперь давайте посмотрим на обеспечение безопасности "закрытой" части приложения. Создатели PHP рекомендуют использовать для этих целей механизм сессий реализованный в языке на уровне ядра. Например, при авторизации пользователя в сессию записываются его права, а перед генерацией закрытой страницы, мы проверяем позволяют ли права пользователя записанные в сессии просмотр этой страницы. Механизм сессий достаточно надежен, но и здесь есть несколько нюансов, которые нужно учитывать. Сессии хранятся на сервере. То есть вся информация о пользователе никому кроме нашей программы не доступна. Это хорошо, но вот идентификация пользователя происходит с помощью уникального идентификатора сессии, который передается браузеру и возвращается им при каждом запросе. А значит, возможен перехват идентификатора и подмена сессии. Давайте попробуем обезопасить сессию. Для этого сделаем две вещи. Запомним (да, в туже сессию) браузер, который использует пользователь и его ip адрес. Эти два параметра можно взять из переменных окружения сервера:

Code

$_SERVER[`HTTP_USER_AGENT`] $_SERVER[`REMOTE_ADDR`] В начале скрипта проверим их и сохраним... Делать это вполне может следующий код: if(!isset($_SESSION[`User_agent`])){ $_SESSION[`User_agent`]=$_SERVER[`HTTP_USER_AGENT`]; }else{ if($_SESSION[`User_agent`]!=$_SERVER[`HTTP_USER_AGENT`]){ $_SESSION[`user_prava`]=0; } } if(!isset($_SESSION[`User_ip`])){ $_SESSION[`User_ip`]=$_SERVER[`REMOTE_ADDR`]; }else{ if($_SESSION[`User_ip`]!=$_SERVER[`REMOTE_ADDR`]){ $_SESSION[`user_prava`]=0; } }

В первой строке мы проверяем, если у пользователя это первый заход в этой сессии, то сохраняем в сессии нужные параметры. Если же заход не первый, то проверяем с того же компьютера и под тем же браузером зашел пользователь и если нет, то обнуляем его права. После этого раз права пользователя равны нулю, мы должны потребовать его снова авторизироваться. Такой способ защиты достаточно надежен для того, что бы злоумышленнику было невозможно воспользоваться перехваченным идентификатором сессии. Мы принимаем за постулат, что пароль известен только нужному нам пользователю. Вот разговором про безопасность паролей мы и закончим эту статью. Обычно пароль выбирается по принципу - чем проще запомнить, тем лучше. Это мягко говоря, несколько не правильно! Такие пароли взламываются иногда без применения, каких-либо программ, просто достаточно посидеть и подумать. Настоящий "взломостойкий" пароль должен быть построен по принципу равномерного распределения символов, и быть не менее шести символов длинной. Для генерации «взломостойких» паролей Мы можем использовать приведенную ниже функцию:

Code

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

Админ - Первый источник флуда на форуме =)