Защитим свои скрипты
Предлогаю Вашему вниманию некоторые простые но эффективные способы защиты от sql-инъекций, xss, php-inj при написании php скриптов, а также как дополнительно обезопасить готовые движки. Следуя этим примерам, Вы сможете избежать распространенных ошибок.
Как известно, простейшая уязвимость начинаетcя с такого URL:
site.com/index.php?id='5
Появляется ошибка и пошло поехало… xss начинается с этого:
site.com/index.php?id=5"><script>alert(xss)</script>
Если не проверять входные данные Ваши скрипты станут совсем беспомощными.
В идеальном случае каждый текстовый входной параметр должен проверяться следующим образом:
$text = trim($text); $text = htmlspecialchars($text, ENT_QUOTES); $text = addslashes($text);
Сначала строка тримуется (удаляются пробелы в начале и конце), затем идет преобразование специальных html символов для защиты от xss, ENT_QUOTES позволяет также заменить одинарные кавычки, ну и напоследок, для страховки, еще и выполняется экранирование спец. символов (addslashes).
Именно в таком виде лучше всего хранить данные в БД. При извлечении нужно выполнить обратное преобразование экранированию:
$text = stripslashes($text);
И затем можно подавать пользователю данные.
Что же касается строго числовых данных (только целых), то тут рекомендуется сразу обрабатывать их так и только так:
$val = intval($val);
Благодаря этой грубой силе в переменной будет либо целое число, либо пустая строка. Одним махом и от sql-inj и от xss.
Если у Вас есть готовый движок (та же джумба), но Вы в нем сомневаетесь (нормальное явление), то для защиты от sql-inj (только от нее) есть такая вещь как magic_quotes_gpc. Для того чтобы ее включить надо в php.ini прописать
magic_quotes_gpc on
И перезапустить сервер. Если Ваш сайт на хостинге можно попросить хостера перенести сайт на сервер где эта magic_quotes_gpc включена, если у хостера специально есть такой сервер где держатся сайты где эта штуковина включена, Ваш сайт может быть перенесен.
Итак. Что делает эту штуковина? Автоматечески экранирует ВСЕ входные параметры, тобеж перед каждой кавычкой добавляет слэш («). Это и защищает ваши скрипты от sql-inj, но надо быть осторожным, если в движке не предусмотрена обработка этой директивы, то параметр может экранироваться дважны («), что не есть хорошо. Надеюсь, в Вашем движке это предусмотрено, иначе нужно самостоятельно прописать ее обоработку в скриптах.
Делается это так:
if(!get_magic_quotes_gpc())
{
$_POST[text] = mysql_escape_string($_POST[text]);
}
Проверяется, если get_magic_quotes_gpc включена, то строка дополнительно не экранируется.
Вывод: использовать get_magic_quotes_gpc стоит, если ее обработка предусмотрена в Ваших скриптах, либо в Ваших скриптах вообще нет никакой обработки -)
Теперь пару слов о php-inj. Несмотря на кучу красивых запросов в гугл для поиска сайтов с этой уязвимостью, которые можно найти на форумах, и красивые приемы заливки шелла через php-inj, защита от этого элементарна — Не применять в инклудах динамически подставляемые переменные. Просто НЕ применять. Придумайте что-то другое, пусть пострадает супер-функциональность Вашего скрипта, но не нужно подставлять в файлы которые инклудятся названия которые вы получаеете как входные данные.
Пример нормального инклуда:
require_once($_SERVER['DOCUMENT_ROOT'] . '/includes/file.php');
Вот и вся защита. Теперь никто не зальет шелл на Ваш сайт.
Теперь пару слов о фильтрах. Я не рекомендую их применять вообще, лучше применять только обработку, которая описана выше. Фильтры обрабатывают входные данные, заменяя или удаляя лишь определенные символы, комбинации, слова, например «sctipt», но вы не знаете наверняка можно ли обойти Ваш фильтр. Фильтры часто обходятся тем или иным способом, и в большинстве случаев лучше их избегать, особенно в тех случаях когда можно обойтись без них.
Статья с сайта: hacker-pro.net (см. hacker-pro.net)
Оставляйте комменты, буду рад всем….
PS: всевозможные варианты аренды жилья — где, как и за сколько можно снять/сдать комнату в Москве (см. antirr.ru).
Твитнуть
Статейка довольно неплохая, но как защитить DLE от sql-injection? Если знаете, ответьте пожалуйста. Спасибо!
Если Вы внимательно читали статью, то в третьем примере кода находиться, так называемый, синтаксический анализатор, проверяет корректность sql запроса, и в случае несоответствия приводится к нужному виду и выдается пользователю — это в общих чертах. А как книжка пишет, то причиной возможности SQL инъекций является использование в приложениях динамического SQL запроса. Теперь вернемся к DLE, не сталкивался, но пишут что там:
— Мощная система безопасности
— Минимальная нагрузка на базу данных (от 0 до 5 запросов).
Если не предусмотрено разработчиком, надо ковыряться в коде движка, что не очень удобно. Совет (если поможет), ищите плагин, или конкретный форум по DLE.
WordPress, если я не ошибаюсь, уже позаботился о безопасности
По крайней мере в Template’ах, всё как Вы описываете
А сила все равно в аккуратных самописных cms
Если специалист, то самописная cms однозначно круче, но зачем, если велосипед уже давно выдумали до Вас и нас… можно усовершенствовать или следить за новыми патчами
Не сложно, но эффективно.
Господа, я не давно в этом деле, а объясните плиз, что это за злобная штука — xss! sql-инъекция я так понял это когда в бд добавляют свои данные?
все сделал как тут и написано, все равно у меня каждый раз пропадают и появляются на других сайтах самописные утилиты(
Хм, а вы уверены что если вначале свернуть строки, записать их в БД а потом развернуть и отобразить пользователю то от xss убережешься?
Допустим я хоть бейз64 запаковал строку и записал в мускул. Да мускуль не пострадает. Теперь я в админке открываю коментарии посмотреть поправить и мне выводится уже развернутое сообщение с яваскриптом который выполняясь шлет мои куки куда ненадо. И где же защита?
По поводу intval совершенно согласен. А вот теги лучше вырезать.
Давно не заглядывал на ваш сайт. А тут и почитать и посмотреть есть чего. сча в рсс добавлю. Так удобнее 😉 И всем советую.
Дискутировать по этому поводуможно бесконечно, поэтому просто поблагодарю автора. Спасибо!