как защитить код php

Защита PHP-скриптов от анализа и модификации

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

Защиты на уровне сервера:

NuSphere NuCoder. Новая, активно развивающаяся коммерческая защита. На уровне собственных API предоставляет взаимодействие с защищаемыми скриптами, поддерживаются операционные системы Windows и Linux. Вследствие малой распространенности не устанавливается на обычных виртуальных хостингах, но вполне может быть установлена пользователями на выделенных серверах. Публичных декодеров нет.

SourceGuardian for PHP. Коммерческая защита, практически не встречается, на вирутальных хостингах не устанавливается. Позволяет устаналивать триальный срок работы скриптов с проверкой даты по внешним серверам точного времени, делать привязку защищаемых скриптов к серверам, ip-адресу, MAC-адресу сетевой карты, причем эти данные используются для расшифровки. Поддерживаются все операционные системы. Публичных декодеров нет.

phpSHIELD. Прототип SourceGuardian for PHP. После слияния двух разработчиков перестал развиваться как самостоятельный продукт. Основной функционал тот же самый, публичных декодеров нет.

ionCube PHP Encoder. Второй по популярности коммерческий продукт для защиты скриптов. После появления публичных декодеров для Zend стал все чаще использоваться и устанавливаться на виртуальных хостингах. Позволяет шифровать не только скрипты, но и шаблоны, xml-документы, изображения, бинарные файлы. Привязывает защищенные файлы к серверам, есть мощный обфускатор, поддерживаются все операционные системы. Публичных декодеров нет, но в некоторых случаях снимается deZender’ом.

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

DWebEncoder. Экзотическая защита под Windows, предназначенная для создания скриптовых презентаций и каталогов на компакт-дисках. В установленном виде представляет собой что-то типа самостоятельного web-сервера, на котором исполняются закодированные php-скрипты. Публичных декодеров нет.

PHP Compact. Защита скорее теоретическая, чем практическая. Разрабатывалась на одном из отечественных форумов, но похоже дальше авторских релизов дело не продвинулось. Декодеров нет, впрочем как и защищенных скриптов.

PHPCoder / eAccelerator. Дополнение с открытым кодом к старинным php-акселераторам Turck MMCache и eAccelerator. Переводит скрипты в байт-код с целью повышения скорости их выполнения. Есть версии модулей под Windows и Linux. Публичных декодеров нет, но возможно открытый код проекта как-то поможет в изучении.

Защиты на уровне исходного кода:

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

PHPCipher. Защита представляет собой он-лайн сервис. На сайт загружается архив с вашими скриптами и обратно скачивается уже защищенный. Платная лицензия позволяет подписывать защищенные скрипты своими данными и использовать для коммерческих целей. Бесплатная лицензия допускает использование только для личных нужд. Сама защита представляет собой защищенный Zend’ом php-модуль, который подключается к защищенным скриптам. После deZend’а модуля защиты и получения из него всех необходимых констант снимается полностью до исходного кода. Функции обфускатора нет.

ByteRun Protector for PHP. Коммерческий продукт, в зависимости от типа лицензии позволяет защищать скрипты как на уровне сервера, так и на уровне исходного кода. Серверная защита со стандартными возможностями, ничего особенного нет. Защита на уровне скриптов снимается очень легко автоматически и вручную. Публичного декодера на серверную версию нет.

SourceCop PHP Protector. Очень популярная у отечественных разработчиков защита. Представляет собой сильно замусоренный пустым кодом модуль защиты, который подключается через include к защищенным скриптам. Алгоритм декодирования очень простой, не вызывает никаких сложностей в ручном и автоматическом снятии. Во всех случаях снимается полностью до исходного кода, функции обфускатора нет. Есть небольшие особенности для частных случаев декодирования, но здесь они описаны не будут.

CodeLock. Еще одна популярная защита, отличный пример безграмотного программирования. Представляет собой приложение на php, позволяет кодировать как сами скрипты, так и результат их работы в браузере средствами javascript. Скрипты можно защищать паролем, но из-за бездарной реализации пароль легко узнать даже не снимая навесную защиту. Модуль защиты представляет собой замусоренный пустым кодом php-скрипт, который подключается к защищаемым скриптам. Алгоритм защиты очень простой, снимается полностью до исходного кода. Функции обфускации нет.

Free PHP Encoder. Бесплатный он-лайновый сервис для кодирования php-скриптов. Модуль защиты представляет собой подключаемый php-скрипт, накрытый Zend’ом, который надо скачать с сайта. После снятия Zend’а и разбора алгоритма защита легко снимается полностью до исходного кода. Алгоритм защиты неизменный, функции обфускатора нет.

gencoder. Скрипт на php, кодирование примитивное, стандартный base64. Большего внимания не заслуживает и практического интереса не представляет.

FREE Encrypted PHP. Бесплатный он-лайновый шифровщик файлов, выполняющий привязку к серверу и ограничение по времени работы скрипта. К зашифрованным скриптам подключается модуль расшифровки, накрытый ionCube. После открытия алгоритма расшифровки легко снимается.

Free Online PHP Obfuscator. Бесплатный он-лайновый шифровщик файлов, несмотря на слово «obfuscator» в названии, дополнительно сжимает и шифрует скрипты. Внешняя шифровка сложности в снятии не представляет, основная защита держится на обфускации текстовых строк и имен переменных.

Обфускаторы:

Особого интереса в плане изучения не представляют, все работают по одинаковому принципу: замена названий переменных на набор случайных символов, удаление комментариев, переносов строк и пробелов, использованных для форматирования кода. К ним относятся GridinSoft PHP Processor, Semantic Designs Obfuscator, PHP Defender, Raizlabs PHP Obfuscator, Obfusc, POBS, PHP UnReader, Code Eclipse и другие. По деобфускации различных скриптов есть полезная статья статья.
Для определения чем защищены скрипты можете воспользоваться программой PCL’s PHPiD. По всем вопросам «а где взять декодеры?» и «а как сломать?» обращайтесь к поисковым системам.

Источник

Защищаем PHP. Шаг за шагом.

Эта статья рассказывает об основных шагах в защите PHP, одном из наиболее популярных языков создания сценариев, созданном в основном для создания динамических web-страниц. Для избежания повтора информации, охваченной в предыдущей статье, мы покажем только основные различия, от процесса защиты Web сервера Apache.

В предыдущей статье «Защищаем Apache» автор описал метод защиты Web сервера Apache от несанкционированного доступа из Internet. Благодаря этому методу можно было достичь высокого уровня защиты, но в случае обслуживания только статических HTML страниц. Но как же осуществить защиту, когда необходимо взаимодействие с пользователем, а данные пользователей должны быть сохранены в локальной базе данных?

Эта статья рассказывает об основных шагах в защите PHP, одном из наиболее популярных языков создания сценариев, созданном в основном для создания динамических web-страниц. Для избежания повтора информации, охваченной в предыдущей статье, мы покажем только основные различия, от процесса защиты Web сервера Apache.

Функциональные возможности будут подобны описанным в предыдущей статье. Однако, существуют некоторые изменения:

Предложения по защите

Должно быть добавлено следующее:

Подготовка программного обеспечения

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

Перед компиляцией программы, мы должны определиться в одном из трех методов инсталляции PHP:

Для лучшей защиты и производительности, лучшим выбором, является компиляция PHP как статического модуля. Именно поэтому остальная часть статьи основана на этом методе инсталляции.

Как и в предыдущей статье, мы начнем с создания учетной записи и группы, называемых «apache». Для этого мы должны подготовить Web сервер Apache следующим образом:

cd apache_1.3.27
./configure

И откомпилировать PHP модуль:

Затем мы перемещаемся в каталог с Apache и продолжаем установку:

В команде «./configure», используются только те модули, которые являются необходимыми для выполнения функциональных возможностей и предложений по защите. Выбор модулей был детально обсужден в предыдущей статье. В следующем шаге мы должны возвратиться к каталогу PHP и скопировать файл конфигурации PHP:

Источник

Как защитить php код от воровства. Чем и как закодировать?

У меня есть скрипты собственной разработки. Так уж принято в российских интернетах удалять копирайты, а то и вообще присваивать чужое себе и даже продавать 🙁

Как можно защитить свой код от подобных изменений. Желательно закодировать так, чтобы было максимально сложно что-то с ним сделать и вырезать часть.

Подскажите возможные варианты, пожалуйста, господа эксперты.

А по хорошему — если боитесь за свою уникальную разработку… и она по истине является уникальной и такой востребованной — ее продавать надо по принципу SaaS

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

Источник

Защита PHP скриптов от копирования — это возможно?

Бывает так, что вам неохота предоставлять исходные коды проектов, которые вы разрабатывали. Для этого можно использовать программы-обфускаторы, о которых недавно шла речь.

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

Я долго искал в интернете решение для защиты от копирования. На форумах этот вопрос часто обсуждался, в основном, задавали его новички, а опытные (видимо) программисты отвечали «— Ты дурак, кому нужен твой код. Учи матчасть, да и вообще php-скрипты ничего не достойны!». Что ж, подумал я. Наверное, действительно нельзя. Но подождите, тот же Битрикс (фу) выдает лицензии на отдельные сайты, при этом вы получаете открытый исходный код после покупки лицензии. Что же мешает скопировать его на несколько своих сайтов? Я не знаю, а если вы знаете — скажите мне пожалуйста.

Решение

1. Выдача лицензии и проверка действительности лицензии скриптом

Итак, скрипт проверил правильность лицензии. То есть, подходит ли указанный ключ к указанному домену. Идем дальше.

2. Проверка домена

А точнее:
1) сохраняем случайное число на сервре (например, во временном файле)2) обращаемся по адресу наш_домен.ру/наш_скрипт.php?action=скажи_число3) проверяем, какое число нам отдают по этому адресу. Если оно соответсвует тому, что мы сохранили, значит, по адресу находимся мы :)0) нулевым пунктом надо добавить отдачу сохраненного числа, если нас вызвали с параметром action=скажи_число
Я немного упростил алгоритм, на самом деле для каждого обращения к скрипту нужно отдельно учитывать эти случайные числа.

Теперь скрипт знает, что лицензия действительна, и что он лежит на соответствующем домене. Основная задача решена!

Вы скажите — wtf, скрипт при каждом обращении будет дергать сам себя? Действительно, жестоко как-то. Поэтому:

3. Временная лицензия

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

4. Выполнение скрипта на локальном компьютере без лицензии

Было бы идеально, если бы скрипт не требовал лицензии при запуске на локальном компьютере. Зачем, спрашивается, человеку требовать с меня лицензию, если он просто хочет протестировать скрипт на своем компьютере? Он должен скачать его, и пользоваться. А вот когда он поставит скрипт на сервер, тогда и прийдет ко мне.

Я не знаю как решить эту задачу. У меня пока есть 3 варианта решения, но они мне не нравятся:
1) Если скрипт лежит на домене без точек (типа myscript) — считать, что это виртуальный домен, значит, скорее всего, это локальное тестирование. Недостаток этого метода — умельцы создадут виртуальный домен на своем сервере, а настоящий домен сделают синонимом. Так же, непонятно что делать с доменом localhost.

3) Смешно, но можно проверить операционную систему сервера. И разрешить выполнение под Windows. Только не бейте меня, это всего лишь вариант.

Выкладываю пример скрипта для тестирования.

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

Источник

Основы безопасности PHP

Данный материал для начинающих программистов.

Содержание

Демонстрация ошибок

Warning: Use of undefined constant LOCAL_SERVER — assumed ‘LOCAL_SERVER’ in /web/includes/page-definitions.php on line 13

Это одна из стандартных PHP ошибок, которая а) некрасива для пользователя; б) потенциально опасна.
Поэтому их необходимо перехватывать и упорядочивать.

Во первых, функция error_reporting позволяет нам решить, какие ошибки мы хотим видеть.
В принципе, достаточно просто выключить показ всех ошибок (error_reporting(0)), но нам нужно не это, потому что об ошибках мы хотим знать.
Константа всех ошибок — E_ALL.
В пятой версии появилась константа E_STRICT, показывающая строгие замечания по поводу кода.
Разумеется, их желательно видеть, но они не входят в E_ALL, потому будем использовать числовое значение error_reporting(8191), которое вбирает всё, вплоть до новых ошибок шестой версии.

Примечание для любознательных: error_reporting(E_ALL | E_STRICT) не подходит, ибо тогда PHP 4 будет ругаться, не зная, что такое E_STRICT. С численным значением никаких проблем не будет.

Добавляем проверку на DEBUG — константу, выставленной в конфиге, и, с помощью set_error_handler, будем отлавливать ошибки в уже запущеном сервисе. Кстати, свой репортер ошибок должен возвращать true, иначе PHP выбросит стандартную ошибку.

Результат:
(Насчёт сравнения переменной с пятью параметрами я не уверен в выборе метода: in_array красивее, и гораздо медленее, а switch case case быстрее, но совсем некрасиво. Красота — субъективное дело. )

register_globals

Другая проблема с register_globals:

SQL injection и magic_quotes

Так популярна среди начинающих конструкция

опасна. Если пользователь введёт вместо пароля ‘ OR `username` = ‘admin, то система впустит его как админа.

Приведённый пример, разумеется, элементарен.
Но если не решить проблему глобально, всегда можно пропустить какой-нибудь запрос, подверженный SQL injection.
Для борьбы с этим разработчики PHP решили сделать так, чтобы вся информация, поступающая от пользователя, подвергалась обработке и все кавычки escapeились (перед ними ставится слэш, что делает команда addslashes).
Что случилось? Вся информация от пользователя приходит со слэшами. Даже та, что вроде слэши получить не должна. Например, комментарии к статье.
Мало того, это не 100-процентный способ защиты от SQL injection.

Решение. а) со всей входящей информации снимаеи слэши, если они есть. б) Всю информацию, поступающую в SQL запрос фильтруем специально для этого созданной функцией mysql_real_escape_string (или аналогом для другой базы данных).

Создаём функцию для фильтрации (mysql_real_escape_string — длинно, да и привязанно к формату проверки. А если понадобиться поменять фильтр?)

И используем её везде. Как только какие-то динамические данных отсылаются SQLу, сразу используем quote:

Проверка данных

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

Старайтесь не фильтровать, старайтесь валидировать.
Другими словами, не создавайте чёрного списка, создавайте белый.
Вместо

Так вы будете уверены, что информация чиста и никаких неожиданностей не будет.
Если вы составляете список запрещённых символов, всегда можете просмотреть какой-нибудь нехороший %00 и подобные, о которых, скорее всего, не догадываетесь.

Разумеется, есть ситуации, когда нужна фильтрация, например, когда пользователь пишет комментарий.
Тогда надо отсекать плохие символы.
Но в принципе стараться надо валидировать.

Есть несколько команд, с которыми надо обращаться очень осторожно.
Это include, require, readfile, eval, «, system, exec, create_function, dir, fopen и подобные.
Всегда посмотрите трижды, когда используете их, если в них используются данные, которые могут прийти от пользователя, будьте уверены — кто-то обязательно этим воспользуется.

Этот кусок опасен. Если злоумышленник введёт ‘../../../../../etc/passwd%00’, будет рад, а вы — вряд-ли.

Аутентификация

Не забывайте, что cookies редактируются ни чуть не сложнее, чем то, что видно в адресной строке.
Поэтому всё, что приходит как печенье, потенциально — атака.
Так что не надо хранить в cookies уровень доступа пользователя или его ID.
Лучше всего дать PHP самому разбираться с этим, используя сессии.

Кстати, в cookies вообще хранить что-либо надо очень скромно и три раза подумать, а надо ли?

Источник