Что стоит использовать для защиты PHP-кода на текущий момент?
Доброго здравия.
Был сделан обзор, и, найдены следующие решения:
- https://www.ioncube.com/
- https://www.phpshield.com/
- https://www.sourceguardian.com/
- https://phpguarder.com/
- https://www.phpdefend.com/
- https://phpbolt.com/
- https://swoolelabs.com/
- https://www.nusphere.com/products/nucoder.htm
- https://xn----7sbabnb7cmacncmoc3p.xn--p1ai/app/mai...
- www.fwd.at/fwd2/phpencoder/index.php (www.fwd.at/fwd2/phpencoder/demo_form.php)
- https://github.com/Eccenux/POBS
- https://github.com/Xeoncross/PHP-Compactor
- https://github.com/pk-fr/yakpro-po
- https://github.com/pH-7/Obfuscator-Class
- https://github.com/naneau/php-obfuscator
- https://sourceforge.net/projects/amparephpencoder/
- https://jamesrmoro.me/product/php-encoder-obfuscator/
Хотелось бы узнать мнение сообщества - кто чем пользовался, и, вкратце почитать про плюсы и минусы.
Спасибо.
Дополнительно:
Мое мнение такое, что любая обфускация кода - лишняя прослойка, затрудняющая отладку ошибок тому же самому разработчику, кто ее поставил.
У вас настолько злые заказчики, что вы не доверяете в пользование написанный вами server side?
У вас настолько злые заказчики, что вы не доверяете в пользование написанный вами server side?
Задача стоит именно в защите кода, потому что будет продаваться под лицензией, и, увы, в наше время никто не отменял недобросовестных конкурентов. А переложить всю логику в облако - мы не можем, точнее даже так, самую важную часть функционала мы не можем переложить в облако, поэтому ее нужно защищать на стороне клиента.
Например это можно сделать в виде PHP Extension. А затем пытаться защищать уже нативный код (инструментов для этого хватает)
у вас есть возможность вынести критически важные части функционала в нативный код?
Например это можно сделать в виде PHP Extension.
Думали об этом, но: могут возникнуть осложнения с поддержкой, и, обновлением, и, другой спецификой приложения. Поэтому, не совсем подходит.
А затем пытаться защищать уже нативный код (инструментов для этого хватает)
Они не входят в указанный список? Было бы интересно ознакомиться с ними, только не через goggle.com, а исходя из личного опыта.
Спасибо.
Они не входят в указанный список?
Не входят, так как это решения для нативного кода и не имеют отношения к PHP:
- https://oreans.com/
- https://vmpsoft.com/
Не входят, так как это решения для нативного кода и не имеют отношения к PHP:
- https://oreans.com/
- https://vmpsoft.com/
Спасибо за ссылки, но, увы, думаю, эти решения нам не подойдут, ибо "слишком много возни" для доставки приложения конечному потребителю. Но, рассмотрим их более детально.
Спасибо.
Код на пыхе на 90% - банален и легко повторим, если требуется. Никакое шифрование от этого не защитит.
А вот от возможности сделать на вашей базе по-своему - защитит надежно. И от возможности разобраться, где вы накосячили, без вас - стопроцентно.
И получит ваш клиент черный ящик, в котором ради любой хотелки и с любым багом нужно идти к вам на поклон.
Грамотный клиент от такого решения откажется сразу.
Код на пыхе на 90% - банален и легко повторим, если требуется.
Так никто этого не отрицает ) Только на то, чтобы это повторить - нужно затратить прилично времени = денег.
И получит ваш клиент черный ящик, в котором ради любой хотелки и с любым багом нужно идти к вам на поклон.
Он изначально знает - на что идет. Так что описываемая вами ситуация - не совсем уместна. Захочет реализовать хотелку - реализует.
Спасибо.
Захочет реализовать хотелку - реализует.
Ээээ... А вы точно понимаете, как работает шифрование кода?
Если выбора нет, то простые обфускаторы кода вам не помогут, потому что вернуть их в человекочитаемый вид проще простого (особенно в наш век GPT), и не так дорого. Поэтому, надо выбирать то, что работает в связке с сервером, типа ioncube. И если вы уже собрали список, то просто попробуйте сами все варианты и выберите что-то, что будет максимально-комфортным для вас.
Ээээ... А вы точно понимаете, как работает шифрование кода?
Да.
Виктор Кожухарь,
Как я понимаю, вы разрабатываете что-то типа платных плагинов или тем для опенсорсных CMS,
Верно мыслите, и, мы в некотором роде также привязаны к вендору, и, его правилам игры.
потому что если вы разрабатываете сервис полностью сами, то мой совет был бы вообще сменить язык программирования и распространять бинарники вместо кода в текущей модели бизнеса,
Сами, но, есть НО ...
либо сесть всем вместе и подумать, что вам изменить, чтобы не применять подобные архаичные методы.
Всем вместе - кому, простите?
Сейчас мало кто таким пользуется, и советов хороших по выбору того или иного, вы вряд ли получите.
Жаль.
Если выбора нет, то простые обфускаторы кода вам не помогут, потому что вернуть их в человекочитаемый вид проще простого (особенно в наш век GPT), и не так дорого. Поэтому, надо выбирать то, что работает в связке с сервером, типа ioncube.
На самом деле выбор уже пал на IonCube, но, в последний раз приходилось с ним работать еще с 9 версией. Сейчас, смотрю уже 13, и, что-то такое греет, что можно им польпользоваться. Просто хотел услышать толковых советов - сродни вашему. За что благодарен вам.
И если вы уже собрали список, то просто попробуйте сами все варианты и выберите что-то, что будет максимально-комфортным для вас.
Одно голова - хорошо, а две ... НУ вы поняли ) Хотелось бы услышать конструктива от коллег, старших товарищей.
Вам спасибо за хорошие мысли.
Да.
На всякий случай: чтобы реализовать хотелку, ему придется расшифровать ваш код.
На всякий случай: чтобы реализовать хотелку, ему придется расшифровать ваш код.
Возможно, вы не так поняли - изначально:
Он изначально знает - на что идет. ... Захочет реализовать хотелку - реализует.
Подразумевалось, что хотелку он сможет реализовать с нашей помощью. И получит эту хотелку - с помощью обновления.
Помнится, битриксоиды на мою жалобу о сломавшемся методе COrder->SetPaid (оплата заказа интернет-магазина) предложили подождать, пока они его исправят и выпустят обновление по этому поводу. Кстати, следующее обновление у них вышло через две недели и не содержало никаких исправлений в нужном мне месте.
Но, к счастью, у них код не зашифрован и я поправил его сам в тот же день... удачи вашим клиентам, чо.
Пиратки, как показывает опыт того же Битрикса - это просто еще один источник клиентов, и бояться их так же глупо, как и бесполезно.
Сообщество считает, что всё это бессмысленные ужимки, которые в 99% случаев используются только для того, чтобы прикрыть крайнее убожество кода. Серьёзные продукты никто не шифрует. Чем, в частности, объясняется заброшенность всех этих, на первый взгляд многочисленных, проектов, которые не выходят из стадии "мы тут с одноклассниками придумали крутую штуку". потом одноклассники либо умнеют и перестают теребить ерунду, либо находят занятие более интересное, чем пхпе.
Сам по себе код мёртв. Он устарел ещё до релиза. В работе софта важна не дискетка с исходниками, а поддержка. Вот поддержку и надо продавать. И не дрожать над каждым вором. Потому что защита от одного вора отпугивает 10 честных покупателей.
Плюс всегда есть SAAS.
- Полностью с вами согласен, но всё же у фрилансеров, особенно начинающих, до сих пор бывает так, что нет выбора, и им приходится соглашаться на требования некоторых нерадивых заказчиков. Они берут в том числе и такие заказы. Обиднее всего, когда работа была проделана очень большая, а клиент, казавшийся адекватным, вдруг отказывается платить совсем.
У меня лично лет 10 или даже больше назад был случай, когда сдавал человеку подряд несколько проектов, он прекрасно платил, и его просьба залить код на прод до оплаты вообще не вызвала никаких подозрений. И тут связь оборвалась, все доступы были отключены, меня просто игнорировали. На его голову он забыл закрыть один из FTP доступов. И я просто зашифровал одним из подобных обфускаторов весь код, который сам лично написал. Магическим образом моя работа была через неделю оплачена, а я предоставил незашифрованный код... - Пока дело не касается тиражных решений, которые стоят по условных $20 и являются законченным продуктом типа расширения для CMS. Стоит им попасть в открытый доступ - продажам конец. Да можно уносить часть кода на свой сервер и т.п. Но здесь особых вариантов кроме как шифровать и привязывать к IP - нет.
- Виктор Кожухарь, а могли бы
Статья 272 УК РФ предусматривает ответственность за неправомерный доступ к охраняемой законом компьютерной информации, если это деяние повлекло уничтожение, блокирование, модификацию либо копирование компьютерной информации. - iRedds, Да-да, есть ещё что-то об уклонении от налогов. Думаю, заказчику эта статья особенно понравится.
Ответы:
Некоторые решения, с которыми я сталкивался, использовали ioncube. Там множество настроек, и если все правильно сделать, то дешифровать, а потом еще и попытаться разобрать код - может быть очень проблематично.
Конечно, отлавливать ошибки в таком коде невозможно, все будет ссылаться на первый/нулевой символ в зашифрованном файле, но мы же говорим о защите.
Но где-то на просторах интернета я читал, что "хакеры" могут использовать модифицированное "ПО" и получить исходный код, но сам я с этим не сталкивался, ничего в открытом доступе найти не смог, но мне это и не особо требовалось, просто интерес
-
Конечно, отлавливать ошибки в таком коде невозможно, все будет ссылаться на первый/нулевой символ в зашифрованном файле, но мы же говорим о защите.
Шифровать нужно уже готовое решение, которое прошло через отдел QA.
- Valentin Borisenko, у проектов, которыми я пользовался, все еще встречались ошибки в зашифрованных файлах XD
- maksam07,
у проектов, которыми я пользовался, все еще встречались ошибки в зашифрованных файлах XD
Ну, это явно проблема разработчика, но, никак не клиента. И, такого не должно быть.
- Valentin Borisenko, так я же и не говорю о том, чьи это проблемы, просто факт. Ну а так, ионкуб вроде бы норально защищает. По крайне мере от тех, кто не особо разбирается в "it" области, должно быть замечательно
Поддержу первого комментатора - фигня это все. То, что есть проекты для этого - не означает, что они качественно справляются с задачей, а означает, что есть спрос (вот как у вас) на такого рода *невыполнимую* задачу. Но да, как небольшое препятствие - это препятствие в самом деле. Но несложное. Это примерно как защитить контент вроде фотографий, которые отдаются клиенту - принципиально невозможно, и все механизмы защиты, вроде "сгорающих фото в телеграмме" обманывают самого пользователя, который надеется, что его это защитит, но совсем не того, кому нужно это украсть.
Если речь идет про защиту от копирования - я бы просто вставил какую-то сетевую функцию в код, чтобы что-то выполнялось по сети, с вашего сервера (и этого кода не было на клиентской части). Если нужно будет отключить - просто на сервере отключаете. Это обойти будет очень сложно.
Если же про защиту от копирования, но программа должна работать без сети - вы совершили ошибку еще на этапе выбора языка программирования - он не подходит для хоть сколько-то надежной защиты.
-
я бы просто вставил какую-то сетевую функцию в код, чтобы что-то выполнялось по сети, с вашего сервера (и этого кода не было на клиентской части). Если нужно будет отключить - просто на сервере отключаете. Это обойти будет очень сложно.
Ерунда это, обходится на раз. Кроме случая, когда ваша сетевая функция обращается ко всему функционалу, который крутится не у заказчика, а на вашем сервере, ретранслируя туда все запросы и вываливая пользователям полученные ответы)
- Владимир, вроде я это и написал. "Этого кода нет на клиентской части". Скажем (чуть наивный пример) - в целом бухгалтерия на PHP у клиента, а вот какой-то налог считается на сервере.
Можно выкусить это, написать локальную функцию расчета, но даже небольшой код для чужого проекта писать уже страшновато и сложновато. А что именно делать на сервере (в идеале, что-то, что локально реализовать было бы сложно) - это уже надо по каждому проекту отдельно решать. В общем, нужно увязать готовую программу с внешним сервисом. - Ярослав, и именно это я и прокомментировал. Небольшой кусок кода чужого проекта (та же функция расчета налога) пишется максимум за час-полтора, причем минут 10-30 уйдет на перекур, чаепитие и анекдоты. Единственный вариант, когда предложенное вами сможет действительно помочь, сделать вообще все на своем сервере, а у заказчика - только сетевая функция, выполняющая обязанности примитивного прокси-сервера.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Для защиты PHP-кода на текущий момент рекомендуется использовать следующие методы:
1. Использование обновленных версий PHP: Всегда следует использовать последнюю стабильную версию PHP, так как она содержит исправления уязвимостей и обновленные меры безопасности.
2. Фильтрация ввода данных: Необходимо всегда фильтровать ввод данных от пользователей, чтобы предотвратить атаки типа SQL инъекций, XSS и другие виды атак.
3. Использование подготовленных запросов: Для работы с базой данных следует использовать подготовленные запросы, так как они предотвращают SQL инъекции.
4. Использование HTTPS: Для защиты передачи данных между клиентом и сервером рекомендуется использовать протокол HTTPS.
5. Ограничение доступа к файлам: Важно ограничивать доступ к файлам с помощью .htaccess или других средств, чтобы предотвратить несанкционированный доступ к файлам с PHP-кодом.
6. Обновление библиотек и фреймворков: Всегда следует обновлять библиотеки и фреймворки, которые используются в проекте, так как они содержат исправления уязвимостей.
7. Использование средств мониторинга безопасности: Рекомендуется использовать средства мониторинга безопасности, такие как WAF (Web Application Firewall), IDS (Intrusion Detection System) и другие инструменты для быстрого обнаружения и реагирования на атаки.
Применение этих методов поможет защитить PHP-код от различных видов атак и обеспечит безопасность вашего веб-приложения.