Форум PHP

Хотел бы мобилизовать всех знатоков, а не знатоков тоже мобилизовать... Только знатоки -- пишем скрипт по идейному соображению не знатоков... для универсальной защиты своих страничек на PHP как и с формами, так и без них, как с использованием баз так и без них и т.п. и т.д. ...... Идеи и решения все сюда!!!!!!!!!!!!!!!!!!!!!1

o_0

>>> для универсальной защиты на PHP
что я сомневаюсь что такая универсальность есть...
ну если тут все начнуть идеи и решения писать то потом можно будет книгу писать...от таково объёма..

Все равно ждем идей и решений для универсальной защиты, ну если не универсальной то хотябы наиболее полной и охватывающей все варианты взлома

Что в твоём понимании универсальная защита? Защита от XSS, SQL-иньекций или ещё что-то?

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

Мне кажется еще нужна фильтрация ненужных переменных приходящих через пост и гет, обрезка длины переменной, проверка на опасные символы, SQL инъекции и XSS атаки и.т.п. Т.е. чтобы каждый раз на сайте или в каждую страницу не вписывать всякие убиралки и резалки тегов и опасных символов а просто сделать резалку-инклюд и все она будет убирать лишнее, но желательно не тупую резалку, а понимающую параметры фильтрования и резания... особенно в формах -- ограничение на количество символов в HTML можно поставить, но кто помешает переписать скрипт или html на клиентской машине и отправить данные с более длинными параметрами.... Я плохой знаток регулярных выражений, но...

В принципе можно написать универсальный класс для валидации часто повторяющихся данных. Типа:

<?php class Validator {     public static function is_email($text) {         //проверка на корректный email     }     public static function is_url($text) {         //проверка на корректный url     } } if (Validator::is_email($_GET['email'])) {     //всё ОК! } else {     //нее... так дела не пойдут! } ?>

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

Ооо...

Я вот что по этому поводу скажу
Тут очень часто появляются сообщения о проверке адресов или безопасности
Вот действительно, сделать один класс для этого и выложить тут

Полностью согласен -- так давайте действовать!

Действуйте. А мы посмотрим.
Когда ничего не выйдет - начинайте учить php как и все остальные.

про класс, инкапсулирующий в себе методы защиты ... это просто суперская идея .. а ещё лучше несколько классов на разные темы и атаки .. тогда можно родить целую идеологию нового метода защиты ..прям как идея xml, так и этот класс может "вклиниться" в какую-то стадию парсинга :) ... умные поймут :)

И сделать предупреждение о взломе админу по sms, даже можно через эмулятор маилру агента (не все равно откого прийдет sms - главное предупредить)... Ведь при взломе идет подготовительная работа, прощупывание дырок и т.д., сделать отправку sms при первой замеченной попытке, а взломщику вывести сообщение только после второй-третьей попытке и его ip в черный список.... Вот возьмем wmshop, даже при версии 13.3. они не фильтруют лишние переменные приходящие через гет и пост, а представьте если переменная используется для инклюда или загрузки/подгрузки файла -- а переменная вначале не занулена/не очищена ... отправляешь переменну через пост и гет со ссылкой или php-скриптом на удаленном сервере, она присоединяется к существующей ... вот такой вот похожий XSS....

Прежде чем строить дворец постройте хотя бы дом

И как Вы представляете себе этот "класс", который будет обнаруживать такие дырки?
Не надо ерундой болтать... Класс, который будет проверять is_email, is_url, это - реально ... но ради двух функций ...... Есть еще идеи, что можно "проверить" этим классом? Правильность имени пользователя? Кто-то захочет, чтобы в имени были только буквы-цифры, кто-то еще чего-нибудь захочет добавить - придется копаться в коде .... Это я к тому, что если бы можно было сделать что-то универсальное, уже давно бы оно было написано.
А для какого-то конкретного случая соединить все функции в один класс - это пожалуйста.

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

=)
Я торопился, так что, может где-то и ошибся
Многие задают вопрос, как узнать, с моего ли сайта форма отправлена была.
У себя примерно такую же использую.

<? function is_referer() {  $pat = '#http:\/\/([^/]+)#is';  preg_match ($pat, $_SERVER['HTTP_REFERER'], $ref);  return ($_SERVER['SERVER_NAME'] == $ref[1]); } ?>

реферрер передается броузером, так что я вам туда что угодно нарисую.

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

Вот по этому я и писал выше, что нужна функция понимающая параметры

Не понял

В форму можно hidden полем всунуть идентификатор сесии или что-то в этом духе. А при отправке сверять есть ли у юзера сессия и совпадает ли поле с ней...

В форму можно hidden полем всунуть идентификатор сесии или что-то в этом духе. А при отправке сверять есть ли у юзера сессия и совпадает ли поле с ней...

Насчет проверки $_SERVER['HTTP_REFERER'] - это бесполезно, т.к. есть замечательные браузеры в которых почти все http-заголовки меняются.

Тогда есть идея типа брать идентификатор сессии, произвести над ним что-то типа

$code = crc32(md5(sha1(session_id())));

Или иначе, в общем, получать каким-то шифрованием число а потом сравнивать его в скрипте.

Или еще в сессию занести параметр, и если он потом появится, то нормально, если нет, то форма не оттуда...

Впринципе можно незаморачиваться с шифрованием сессии, а записывать сразу

<input type="hidden" name="u_id" value="session_id()">

т.к. подобрать значение сессии из разряда невозможного, а session_id() это тоже 32 символьный код, неразличимый внешне от любого значения md5().

Хотя от подсовывания левых даннных такой способ гарантии не дает... Способ хорош только для защиты от автоматического заполнения каких либо досок объявлений или форума на сайте.

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

Вот именно
Можно посетить сайт, копировать идентификатор в свою форму, таким образом подсунув его в левую форму и все....
Надо или шифровать либо что-то дополнительное передавать например через сессию, не куки

Опоздали года на два. Нынешние роботы все это уже обходят.

ИМХО, если проектировать сайт с четкой древовидной структурой данных то в url достаточно передовать всего один параметр - id страницы, который проверить проблемы нет. А все остальные параметры можно получать отталкиваясь от этого ID. А если для построения сайта юзать несколько переменных razdel=x&podrazdel=y... то проверять замучаешься - ведь в таком раскладе нужно проверить все комбинации соединения razdel и podrazdel.

даже в текущем сайте можно было вместо id_forum=1&id_theme=31578 поюзать id_theme=31578, а id_forum взять из бызы т.к. завязки мезду разделами форума и темами навереяка предусмотрены. Проверяем если id_theme найден значит генерим страницу, а если такового нет, то 404...

Здесь речь не только о GET параметрах

>Идеи и решения все сюда!!!!!!!!!!!!!!!!!!!!!1
Мы сразу за вами!

=))

Если бы универсальный механизм существовал, то в РНР уже давно ввели бы встроенную функцию вроде bool protect_script(); :)

А вот мы тут пасавищаемся и введем =)

Расскажу как это реализовано у меня в CMS.

Данные, отправляемые пользователями, обычно идут в таблицу. Как их отфильтровать с минимальными телодвижениями?
Создаём служебную таблицу _properties:
id#fieldname#title#htmltype#pattern

Это основное. Там ещё есть кой-чего, но это уже другое ноу-хау.
Поля таблицы выводятся так:
title
<input type="htmltype" name="fieldname">

Получается что-то типа
Ваше имя
<input type="text" name="username">

Вот. Когда данные отправляются, значение каждого поля прогоняется на $pattern и пропускается/запрещается. Ну это всё с целью правильности формата. Типа чтоб email не был числом.
Проверки на pattern проходят ещё и в браузере. Яваскриптом.
Ну и, ясен пень, для каждого поля придётся писать свой $pattern.

От sql-inj есть один просто шикарный метод защиты. Заключатся он в использовании placeholder'ов.

$db->query('SELECT * FROM `table` WHERE `id`=?', $id);

Можете поэкспериментировать. В такую штуку вам ну никак не удастся впихнуть инжекшн.

Фильтр тегов (XSS) делается перед выводом через htmlspecialchars().
Вот.

мда-а-а. серьезные вещи... =)
я еще классы совсем не знаю . . .
давайте сделаем простую функцию.
я предлогала уже, что то такое.

и так, моя идея:

на каждой страничке:
1) создаем массив переменных, которые должны прийти.
$massiv = array('name','msg');
таким образом, скрипт будет работать только с необходимыми переменными.

2) создаем массив по типу проверки.
$proverka = array('POST','htmlspecialchars','stripslashes','nl2br');
таким образом, функция выполнит эти функции. т.е. примет методом пост, заменит \ n на <br> и т.д.

3) вызываем функцию, и отправлем 2 массива.


создаем функцию:
тут уже ставим условия от проверочного массива...
т.е. какую проверку необходимо произвести...


кто что думает об этом?

$proverka = array('POST','htmlspecialchars','stripslashes','nl2br');
Что Вы хотите проверить, изменив строку?

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

>кто что думает об этом?

Свое мнение по этому вопросу я выражать уже устал, ей-богу.
Последний раз в соседней ветви.
http://softtime.ru/forum/read.php?id_forum=1&id_theme=41343

От sql-inj есть один просто шикарный метод защиты. Заключатся он в использовании placeholder'ов.
Да это не метод защиты, а способ получения данных.

Можете поэкспериментировать.
Интересно как? :)
В такую штуку вам ну никак не удастся впихнуть инжекшн.
Откуда мы знаем что в классе, который Вы используете? Может можно.

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

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

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

Возможно вы и правы. А если оперировать параметрами UserAgent и IP. Бот разве сможет их менять. IP думаю да, а UA вряд ли. И вообще, разве есть у бота UserAgent.

IP думаю да, а UA вряд ли. И вообще, разве есть у бота UserAgent.
Всё как раз абсолютно наоборот. Практически все боты под User-Agent'ами известных браузеров.
Это всего лишь HTTP-заголовок.
IP фактически можно сменить, только используя прокси.

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

Вам очень повезло с ботами.