Защита кода Php

[Rapid]

Я тут заинтересовался стороной защиты.. и хотел бы обсудить его с коллективом и окунуться в защиту кода..

Только до предела доходить не надо, когда времени/денег на защиту и тестирование тратится столько же, как и на сам код.

Надо быть всегда параноиком.

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

[Виталий Желтяков]

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

Это собственно об одном и том же. Если режим register_globals включен, то возможен взлом через адресную строку. В настройках или лучше в .htaccess добавляем строку "php_flag register_globals off" и учимся программировать без саморегистрации переменных, т.е. напрямую с глобальными массивами POST и GET.

На счет только разрешенных символов это Вы про форму??(как я помню там можно запретить какие то символы, а разве это подействует? )

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

[Johnatan]

Сообщение от Виталий Желтяков

Правила простые:
- Отключить возможность свободно задавать переменные скрипта,
- Жестко проверять вводимые данные,
- Ограничить вывод ошибок,
- Поставить защиту от атак.

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

Автор, пиши ещё!

[Виталий Желтяков]

Johnatan, Вы вообще когда-нибудь программировали для серьёзных организаций? По вашему замечанию видно, что нет.
Защита от неправильного ввода и защита от атак - это совершенно разные вещи. Нельзя ограничиваться только одной защитой.

[Shyt]

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

Виталий Желтяков да Вы правы но только с версии 5.3 стала register_globals off а раньше могла на серверах стаять и на наоборот. а в общем да.
На счет запрета определенных символов правильная идея

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

Почитал о Cookies и там сказано что им нельзя доверять и что их можно подредактировать даже в блокноте, Но вроде же они хранятся только на том компьютере с которого заходят по идее это же не опасно для юзеров, если и косяк то виноваты только они сами.. да и хотя это вроде не опасно для страницы?? или я не правильно думаю?? как и Session полностью зависит только какие олухи юзеры и на страницу не какого вреда нет


Спасибо всем за беседу

[Виталий Желтяков]

На счет запрета определенных символов правильная идея

Ещё раз - разрешаем только определённые, строим логику по белому списку, а не по черному.

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

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

Почитал о Cookies и там сказано что им нельзя доверять и что их можно подредактировать даже в блокноте, Но вроде же они хранятся только на том компьютере с которого заходят по идее это же не опасно для юзеров, если и косяк то виноваты только они сами.. да и хотя это вроде не опасно для страницы?? или я не правильно думаю?? как и Session полностью зависит только какие олухи юзеры и на страницу не какого вреда нет

Если будете аккуратно соблюдать всё вышенаписаное, то как таковой угрозы для сайта нет, только для пользователей. Хотя от этого легко защитится простейшим ip-анализом.

[Shyt]

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

а про ip это что опять сравнения если сходятся то добро пожаловать если нет иди погуляй ....

[Пепел Феникса]

Виталий Желтяков да Вы правы но только с версии 5.3 стала register_globals off а раньше могла на серверах стаять и на наоборот. а в общем да.

че?
в 4 версии тоже можно было отключить.
htaccess никто не отменял.

[Виталий Желтяков]

Вы тут можете по точнее пояснить какие логи и как можно фильтровать хотя б ссылку на пример или статью это было бы супер

Очень просто. Логи - это элементарные текстовые файлы, т.е. смотрите информацию по работе php с файлами (там всё просто). Смысл в том, что бы делать записи событий в "узких" местах, например, при авторизации, с детализацией кто, что ввел и палить ip адрес ($_SERVER['REMOTE_ADDR']). Если у нас атака (используются плохие слова), то делаем запись в отдельно отведенный лог, так удобнее.

а про ip это что опять сравнения если сходятся то добро пожаловать если нет иди погуляй

Не совсем то. В принципе ip пользователя нужен, что бы палить двойные сессии и клонов.
Двойные сессии - это когда под одним логином работают несколько клиентов. В большинстве случаев - это взломщики и спамеры. Поэтому без угрызений совести убираем эту возможность. Для этого нужно сделать таблицу он-лайн пользователей с ip и не допускать двойную авторизацию. Этот метод серьёзно ухудшает возможности разного рода хакеров и спамеров.
Клоны - это когда с одного ip работают несколько пользователей. Здесь надо тупо палить ip и логин составлять таблицу. Если произошла атака, то закрывать всех клонов с одного ip до разбирательств.

[Shyt]

Виталий Желтяков, понятно, но что с эти делать? Можно попробовать заблокировать ip (если честно без понятия как это сделать, приведи пример ) да и если заблокировать этот ip ему не составит сложности поменять и зайти с другого и рано или поздно он добьётся своего

А вот со вторым возникает проблема, т.к. я не могу запретить.