Хотя механизм cookies функционирует без нашего ведома, это вовсе не означает, что мы не можем его контролировать. Опасаясь, что какая-то информация личного характера может уйти из компьютера, можно просто отключить запись файлов cookie.

Вообще считать, что cookies угрожают утечкой информации, – большое преувеличение. Сама возможность кражи информации из файлов cookie значительно ограничена механизмом идентификации сервера с помощью параметра domain. Если даже кому-то удастся прочитать cookies, хранящиеся на диске компьютера, то эти данные невозможно использовать до тех пор, пока не удастся их связать с конкретной личностью в реальном мире, а это удается исключительно редко.

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

Если Вы пользуетесь каким–либо скриптом, доступным для свободного скачивания, то следите за bugtracker’ом и периодически обновляйтесь. В новых версиях часто исправляют серьёзные уязвимости, найденные в предыдущих версиях.

Также если на Вашем сайте указано, каким скриптом Вы пользуетесь, то удалите из этой информации номер версии. Если хакер не знает, какая у Вас версия, он может не задействовать уязвимость в той версии скрипта, которая стоит у Вас. Но, повторюсь, лишь “может”, так что всё равно обновляйтесь.

Теперь пройдёмся по ошибкам, которые могут быть в Вашем самопальном скрипте.

1. Пароль хранится в файле, который может быть скачен хакером

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

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

Исправив предыдущую ошибку, Вы заодно исправите и эту — иногда логин и пароль хранятся в файлах, которые без проблем находит Яндекс или Google! Не исправив эту ошибку, Вы рискуете тем, что хакер даже не специально взломает Ваш сайт, а просто найдёт жертву через поисковик и хакнет первого попавшегося неудачливого web–мастера! Не окажитесь им!

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

3. Пароль хранится в незашифрованном виде

Пароль нужно хранить в зашифрованном виде. Наиболее предпочтительным видом является хэширование (можно использовать алгоритмы MD5 или SHA1), так как прямым путём получить пароль из хэша невозможно. Но существуют онлайн–базы хэшей, в которых может храниться пароль и к Вашему хэшу, так что используйте неординарные пароли и пароли из случайного набора символов.

Для большей уверенности в надёжности защиты Вашего сайта, почитайте статьи по взлому, которые в свободном доступе опубликованы на хак–ресурсах, и попробуйте применить изложенные там методики, как говорится, “на себе”.

Удачной Вам защиты от взлома!

Также Вы должны знать, что использование MySQL имеет свои минусы. Сложные сайты на MySQL сильно нагружают сервера, существуют некоторые сложности с бэкапом сайта (на файлах всё несколько проще), и большая (нежели на файлах) вероятность взлома.

Связано это с тем, что кроме обычных уязвимостей, при работе в связке PHP + MySQL дополнительно существует дополнительный вид уязвимостей, который именуется MySQL-injections (MySQL-инъекции).

Суть этих уязвимостей заключается в том, что хакер может внедрить в SQL-запрос свой код. С помощью такого метода, например, можно получить пароли пользователей, можно получить пароль доступа к админке (и тогда сайт будет полностью под контролем хакера), или (так иногда поступают некоторые хакеры) получить базу e-mail адресов пользователей с целью продажи её спамерам.

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

Шаг №1. Скрываем “истинное лицо” страницы.

Для начала упрячем подальше сам скрипт обработки пользовательских запросов. Для этого мы будем использовать mod_rewrite. Вот как это будет выглядеть: вместо ссылок вида index.php?id=1, например, мы будем использовать ссылки вида 1.html. Кроме защиты это придаст также более эстетический вид ссылок, а вдобавок и более качественную индексацию сайта поисковыми системами.

Вот как это делается: создаём файл .htaccess в той директории, где хранится скрипт (если файл уже существует, то редактируем его, вписав новые строчки).

RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^.htaccess$ – [F]
RewriteRule ^([0-9]*).html index.php?id=$1

Пройдёмся по строчкам: первая строка инициализирует mod_rewrite, вторая задаёт необходимые опции, третья определяет базовую директорию для перенаправления, четвёртая не позволит скачать хакеру файл .htaccess, а пятая описывает правило перенаправления.

Как это защитит от MySQL-инъекций? Если хакер введёт http://сайт.ru/1′.html, то mod_rewrite просто не пропустит этот запрос (так как строка 1′ не удовлетворяет условию перенаправления: то, что стоит перед .html должно быть последовательностью цифр).

Это лишь первая линия защиты. Данный код не защити Вас от хакеров, разве что от самых новичков. Опытный хакер найдёт сам файл index.php и будет атаковать уже его. Для большего укрепления первой линии обороны можно дать один совет: делайте сложные, и, самое главное, необычные имена файлов. Например, файл с названием haha_diehack_3456.asp.php, хоть и выглядит нелепо, но зато вряд ли будет найден хакером. И ни в коем случае не “светите” нигде реальное название файла скрипта!

Шаг №2. Фильтруем данные, полученные от пользователя.

Любой пользователь без проблем может быть хакером, так что не советую Вам доверять данным, полученным от пользователя. Заотсрять на фильтрации конкретных типов данных я не буду, об этом написана отдельная, очень обстоятельная статья.

Добавить надо вот что: как бы не были профильтрованы данные, опасность всё-равно остаётся. Поэтому кроме “обычной” фильтрации данных, экранируем все опасные символы с помощью специальной функции: mysql_real_escape_string.

$data = mysql_real_escape_string ($data, $connect);

Где $data – переменная, хранящая какие-то данные, полученные от пользователя (данную операцию нужно проделать со ВСЕМИ переменными, используемыми в SQL-запросах!), а $connect – подключение к базе MySQL (задаваемое функцией mysql_connect). Если Вы используете MySQLi, то для него есть аналогичная функция mysqli_escape_string.

Ах да, чуть не забыл! Для того, чтобы эта защита работала, любые данные, передаваемые в SQL-запросе надо защищать одинарными кавычками:

mysql_query (“SELECT * FROM table WHERE id = ‘$id’”)

вместо

mysql_query (“SELECT * FROM table WHERE id = $id”)

Вот так в два шага можно частично обезопасить себя от взлома хакерами Вашего сайта. Также, хотелось бы дать Вам несколько рекомендаций по защите сайта от MySQL-инъекций:

• фильтруйте, фильтруйте и ещё раз фильтруйте! Фильтрация данных когда-нибудь спасёт Ваш сайт
• тщательно формируйте SQL-запросы с использованием введённых пользователем переменных. Не делайте их на скорую руку
• и также тщательно тестируйте свой сайт на SQL-инекции. Будет гораздо лучше, если ошибку обнаружите Вы, а не злостный хакер

Желаю Вам успехов!

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

Шаг №1. «Ключом по врагу», или защита от спама генерацией случайного ключа.

Допустим, у нас есть файл index.php, в котором содержится форма, направляющая данные файлу post.php, который сохраняет их на сервере. Тогда в начале php–кода index.php пишем следующий код:

// начинаем сессию
session_start ();
// генерируем случайную и достаточно длинную строку
$key = md5 (rand (10000, 99999));
// щаписываем его в сессию
$_SESSION ['key'] = $key;

Теперь в HTML–коде делаем скрытый элемент формы, в который записываем этот самый ключ.

<input type=”hidden” name=”key” value=”<? echo $key; ?>” />

Теперь приступаем к файлу post.php. Просто проверям наличие и правильность ключа. Если ключ не задан или неправилен, то не обрабатываем запрос.

// начинаем сессию
session_start ();
// проверяем наличие ключа
if (!isset ($_POST ['key']))
{
// здесь Ваш код — запрос не обработан
}
elseif ($_POST ['key'] !== $_SESSION ['key'])
{
// здесь Ваш код — запрос не обработан
}
else
{
// здесь Ваш код — запрос обработан
}

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

Шаг №2. «Стой! Кто идёт?», или проверяем, пришёл ли пользователь с нашего сайта.

Также в post.php можно проверить, а с нашего ли сайта пришёл «пользователь»? Если не с нашего, то отправляем пользователя в баню.

Вот код, реализующий предыдущую простую идею (вносим в файл post.php)

// проверяем, есть ли в адресе имя домена, на котором раположен Ваш сайт
if (substr_count (getenv (‘HTTP_REFERER’), “domen.ru”) == 0)
{
// если нет — не обрабатываем запрос (Ваш код здесь)
}
else
{
// иначе — не обрабатываем
}

Шаг №3. «Проводим математический тест», или используем один из вариантов CAPTCHA.

Под термином «CAPTCHA» некоторые пользователи понимаюь картинку с текстом, который доолжен ввести пользователь. Вообще–то, это лишь один из возможных вариантов CAPTCHA. Вообще, по определению, CAPTCHA — это автоматический тест для разделения компьютеров и людей, правда специальные программы обходят большинство CAPTCHA.

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

Для начала внесём изменения в файл index.php

Вот что мы впишем вверху, в php–коде

// запускаем сессию, если уже запущена, не добавляйте эту строчку!
session_start ();
// генерируем два случайных числа от 1 до 15 и заносим их в сессию
$num1 = rand (1, 15); $_SESSION ['num1'] = $num1;
$num2 = rand (1, 15); $_SESSION ['num2'] = $num2;

Теперь в форму заносим следующий код

Сосчитайте сумму двух чисел: <? echo $num1; ?> + <? echo $num2; ?> = <input type=”text” name=”sum” />

В файле–обработчике post.php записываем следующие инструкции:

// запускаем сессию, если не запущена
session_start ();
// проверяем наличие введённой суммы и её правильность
if (!isset ($_POST ['sum']))
{
// здесь Ваш код — запрос не обработан
}
elseif ($_POST ['sum'] !== ($_SESSION ['num1']) + $_SESSION ['num2'])
{
// здесь Ваш код — запрос не обработан
}
else
{
// здесь Ваш код — запрос обработан
}

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

• текст чисел можно «спрятать» от просмотра в HTML–коде с помощью JavaScript–хитростей
• также можно использовать более продвинутую CAPTCHA, Вы можете найти множество вариантов в Интернете
• можно сделать проверку на наличие в информации стоп–слов, нопример, можно использовать те слова, которые Вы часто видите в спам–сообщениях

Желаю Вам успехов в создании сайта, оборонённого от спам–ботов!

Для проверки полученных от пользователя данных мы будем использовать регулярные выражения. Прежде чем перейти к примерам, необходимо четко определить,
каким образом будет выполняться запрет или допуск определенных символов.
Наиболее частой ошибкой является использование регулярных выражений, запрещающих определенные символы, но разрешающих любые другие. Мы же будем действовать иначе – запрещать ВСЕ, что не разрешено.
Тоесть, наше правило не: “разрешено ВСЕ, что не запрещено “, а “разрешено ТОЛЬКО то, что разрешено”!

Чтобы понять, что именно необходимо фильтровать, нужно четко представлять, что должно передаваться в параметрах. Например, наша форма содержит поля ввода для следующих данных: фамилия, имя, e-mail, пол, дата
рождения, возраст и примечание.

Давайте рассмотрим каждое из полей и определим, какие символы можно разрешить к вводу:

Фамилия, имя – эти поля являются текстовыми и
могут содержать только и исключительно буквенные символы. Все остальные символы должны быть
запрещены. Следовательно, регулярное выражение для этих полей будет выглядеть так:

$str=ereg_replace(“[^a-zA-Z]“, “”, $str);

В данном выражении мы запрещаем все, кроме букв от А до Z в нижнем
и верхнем регистре. То есть, нет необходимости перечислять все запрещенные
символы и заботиться о том, чтобы ничего не упустить.

Email – тут немного сложнее. Давайте попробуем сформулировать задачу… Необходимо проверить, что введенная строка: содержит некоторое количество допустимых символов (допускаем буквенные символы, цифры, а так же знаки тире и подчеркивания), затем содержит символ ‘@’ (‘at’) (именуемый в народе “собакой”), затем опять некоторое количество допустимых символов, затем точку, и после точки от двух до 4 только буквенных символов… Все это реализуем регулярным выражением:

if (!preg_match(“/^(?:[a-z0-9]+(?:[-_]?[a-z0-9]+)?@[a-z0-9]+(?:\.?[a-z0-9]+)?\.[a-z]{2,4})$/i”, $email))
{
echo “Неверный email!”;
}
else echo ОК!’;

Пол — может принимать только одно из значений: ‘M’ или ‘F’. Любые другие символы беспощадно обрезаем. Регулярное выражение может выглядеть
следующим образом:

$sex=ereg_replace(“[^MF]“, “”, $sex);

В результате все символы, кроме указанных двух , будут удалены из
параметра.

Дата рождения – удалить все, кроме цифр и символа точки,
используемой в качестве разделителя числа, месяца и года:

$bdate=ereg_replace(“[^0-9.]“, “”, $bdate);

Возраст — это число, значит, параметр не должен содержать ничего, кроме
цифр.

$str=ereg_replace(“[Л0-9]“, “”, $str);

Примечание – это самая сложная переменная, так как представляет собой некий текст, который может ввести пользователь.
Как минимум,
здесь необходимо запретить любые теги:

$str=ereg_replace(“<[A-Z]{1,}>”, “”, $str);

$image = imagecreatefromjpeg(‘capch/capch_’.rand(0,9).’.jpg’);

Теперь определим цвет текста для надписи на этой капчи:

$textcolor = imagecolorallocate($image, 0, 0, 0);

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

$file=”basecapch.php”;

Теперь выбираем слово из этой базы и производим замены:

$array=file($file);
$rand=$array[rand(0,count($array)-1)];
$rand = ereg_replace(” +”, “”, $rand);
$rand = ereg_replace(”
“, “”, $rand);

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

$fp=fopen(“temp/capcha.txt”,”w+”);
fwrite($fp,$rand);
fclose($fp);

Теперь выбираем случайный шрифт для текста из файла:

imagettftext($image, 20, 1, 1, 30, $textcolor, “capch/”.rand(0,9).”.ttf”, $rand);

и выводим всё на экран:

header(‘Content-type: image/jpeg’);
imageJPEG($image);

Для правильной работы этой капчи – установите ее во фрейме, а фрейм должен отображать файл с html ссылкой на самого – себя. Пример:

<a href=”capche.html”><img src=”capcha.php”</a>

Теперь если пользователь кликнет по капчи, то она перезагрузится и отобразится новая, а на страницу действие не окажет.

Использованные функции:

ereg_replace – Заменяет регулярное выражение
Imagecolorallocate — Распределяет цвет для изображения
fopen — Открывает файл или URL

Ip юзера::причина бана.

И сохраним его – files/ban.login

Теперь начнем писать систему бана.

Открываем разными способами этот файд:

<?
if (file_exists(“files/ban.login”)){ $file = file(“files/ban.login”); }
else{$file = file(“./files/ban.login”);}

Теперь считаем кол-во банов:

for($i=0;$i<count($file);$i++)

Всё ок, теперь разбиваем все строки:

{
$q = explode(“::”, $file[$i]);
$banlogin = $q[0];
}

Проверяем, не забанин ли пользователь:

if (ereg(“^$banlogin$”,$login) || ereg(“^$banlogin$”,$login2) and $userr){
echo(“Вам закрыт доступ на сайт. Причина: “.$q[1]);

}
else{
$file=implode(”,file(‘files/ban.ip’));
$ip=$_SERVER['REMOTE_ADDR'];
if (ereg($ip,$file)){
echo(“Вам закрыт доступ на сайт.”);

}
else{?>

И контент:

Основной контент
<?
}
?>

Вот и всё, система бана по ip готова.

Использовались функции:

• count — Посчитать количество элементов массива или количество свойств объекта
• ereg — ищет со строгим регистром
• explode – Разбивает строку на подстроки
• implode — Объединяет элементы массива в строку
• file_exists — Проверить наличие указанного файла или каталога

Рассмотрим основные примеры использования .htaccess:

1) Установка пароля на директорию:

AuthName “Admin page”
AuthType Basic
AuthUserFile /pub/home/server/.pass
require valid-user

2) Запретить доступа к файлам с определенными расширениями:

<Files ~ “\.(xls|doc|txt)$”>
deny from all
</Files>

Запрещен доступ к файлам с расширениями .xls, .doc, .txt. Для запрета только для одного типа расширение эта функция применяется так:

<Files “*.txt”>

3) Глобальное перенаправление трафика:

Redirect / http://www.newsite.ru

4) Перенаправление трафика только при запросе определенных страниц:

redirect /files http://webteach.ru/nofiles
redirect /images http://webteach.ru/noimages

При запросе страниц из каталогов files и images будет произведено перенаправление на новые адреса.

5) Перенаправление трафика по IP:

SetEnvIf REMOTE_ADDR 192.168.0.1 REDIR=”redir”
RewriteCond %{REDIR} redir
RewriteRule ^/$ /ban_users.html

6) Обработка ошибок Apache:

ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html

7) Запрет доступа ко всем файлам и каталогам в текущей директории:

deny from all

8 ) Запретить доступ к определенному файлу:

<Files config.php>
deny from all
</Files>

9) Разрешить доступ только с определенного IP-адреса:

order deny,allow
deny from all
allow from 192.198.0.1

10) Запрет на отображение содержимого каталога при отсутствии индексного файла:

Options –Indexes

Это десятка основных и наиболее часто используемых настроек для файла .htaccess. Пользуйтесь и экспериментируйте

<?php
$login=”Admin”;
$pass=”password”;
?>

Теперь приступим к написанию основного кода. Для начало открываем наш файл с конфигам для последующей работы с переменными:

include(“config.php”);

После – проверяем условия. Если параметр post совпадает с переменными из фала, то создает cookies и открывает файл админки:

if($_POST['user']==$login and $_POST['passw']==$pass):
setcookie(“userr”,$_POST['user']);
setcookie(“passs”,$_POST['passw']);
include(“admincp.php”);

Если cookie существует, и совпадает с переменными из файла, то входит в защитную зону:

elseif($userr==$login and $passs==$pass):
include(“admincp.php”);

$userr и $passs передают cookie и содержат данные, которые мы туда записали.
Теперь заканчиваем наши условия и выводим форму для входа:

else:
?>
<form method=POST>
Login: <input type=text name=user maxlength=80 size=30>
<br>Pssword: <input type=password name=passw maxlength=80 size=30>
<input type=”submit” value=”Вход”>
</form>
<?
endif;
?>

Форма для входа написана, теперь пишем код, который будет удалять наши cookie:

<?
setcookie(“userr”);
setcookie(“passs”);
print ‘<meta http-equiv=”refresh” content=”0; url=index.php”>’;
?>

Содержимое print просто перенесет нас на главную страницу после удаления cookie. Поместив этот код в файл exit.php.

В админ панели ставим ссылку на этот файл. Теперь защищаем файл админки от просмотра, это мы осуществим так… В файле админки (admincp.php) в самом начале пишем код:

<?
if(!defined(“INDEX”)) die(“Доступ к файлу закрыт!”);
?>

Это значит, что если передать параметру defined(“INDEX”) – yse, страница будет грузится дальше, а если нет, то выведет “ Доступ к файлу закрыт ”. Теперь правим открытие этого файла – в скрипте… Дописываем перед include(“admincp.php”); код:

define(“INDEX”, “yes”);

Теперь этот файл откроется.

Всё, файл защищен, можно туда вложить защищаемую информацию.
Ниже приведены листинги готовых файлов…

Листинг файла index.php:

<?php
include(“config.php”);
if($_POST['user']==$login and $_POST['passw']==$pass):
setcookie(“userr”,$_POST['user']);
setcookie(“passs”,$_POST['passw']);
define(“INDEX”, “yes”);
include(“admincp.php”);
elseif($userr==$login and $passs==$pass):
define(“INDEX”, “yes”);
include(“admincp.php”);
else:
?>
<form method=POST>
Login: <input type=text name=user maxlength=80 size=30>
<br>Pssword: <input type=password name=passw maxlength=80 size=30>
<input type=”submit” value=”Вход”>
</form>
<?
endif;
?>

Листинг файла admincp.php:

<?
if(!defined(“INDEX”)) die(“Доступ к файлу закрыт!”);
?>
<a href=”exit.php” mce_href=”exit.php”>Выход</a>
<br><br><h1>Защищаемая инфармация!</h1>

Листинг файла exit.php:
<?php
$login=”Admin”;
$pass=”pass”;
?>

В ходе этого урока мы подробнее разобрали условия if, else и т.д., научились создавать и удалять cookies, и научились грамотно защищать файл.

Новые функции, которые мы изучили в этом уроке:

• die - Эквивалентен exit(), выведит сообщение, и закончит текущий сценарий.
• defined - Проверяет, существует ли данная названная константа.
• include - включает и выполняет указанный файл.
• setcookie - передает данные cookies.