Судебная экспертиза исходного кода на PHP

Спорите с подрядчиком о сайте, интернет-магазине или корпоративном портале, и в основе спора — вопрос, который суд формулирует одинаково независимо от технологии: соответствует ли сделанное техническому заданию. У PHP ответ на него получают иначе, чем у других языков, — из-за устройства самого языка. Программу на PHP, за редкими исключениями, не собирают заранее в отдельный поставляемый файл: на сервере лежат те же самые тексты, которые писал разработчик. Исходный код здесь не прячется в сборке и не теряется при поставке: на сервере работает он сам. От этого зависит весь ход исследования: материал для эксперта обычно уцелел, но правку в него мог внести кто угодно и в любой момент, включая период спора. Экспертиза исходного кода на PHP — специализированное направление экспертизы процесса разработки программного обеспечения. На выходе вы получаете заключение с описанием объектов, методов и ограничений; какое доказательственное значение оно получит, оценивает суд.

Если спор уже начался, снимите копию сервера раньше всего остального. На площадке с PHP правка одного файла занимает секунды и не оставляет следа в истории изменений, если её вносили не через репозиторий, а по FTP или через панель хостинга. Раньше всего пропадают копия каталога сайта, выгрузка базы данных и резервные копии, которые ещё держит хостинг-провайдер. Что именно сохранять и в каком порядке — ниже, в разделе «Что сохранить, пока площадка не изменилась».

Предварительный разбор задачи бесплатный и начинается с разговора: достаточно назвать адрес сайта, описать спор и перечислить, что у вас есть. Собирать архив к этому моменту не требуется — как передавать материалы, договоримся потом и безопасным способом.

С какими спорами приходят

Приходят тогда, когда спор держится на проверяемом: на составе переданного, на поведении программы, на зафиксированном ходе работ. — в состояние сайта, состав переданных файлов и зафиксированный ход работ, а не только в толкование договора. До начала работы определите, о какой версии, площадке и периоде идёт речь: без этого у исследования нет предмета.

Вот с чем приходят чаще всего:

• подрядчик сдал сайт или интернет-магазин на «1С-Битрикс», WordPress, Laravel или самописном движке, а заказчик считает техническое задание невыполненным;
• стороны расходятся в объёме: подрядчик считает работой весь каталог сайта, заказчик — только то, что подрядчик написал сам, а не получил вместе с коробочной системой и модулями из каталога;
• сайт взломали, на страницах появился чужой код, и стороны спорят, чья это зона ответственности;
• после расторжения договора заказчику передали архив, который не разворачивается: не хватает файлов, настроек или выгрузки базы;
• подрядчик закрыл часть кода энкодером и после спора отказывается продлевать лицензию, а заказчик не может ни доработать сайт, ни сменить исполнителя;
• заказчик утверждает, что подрядчик выдал за свою разработку купленный шаблон или чужой модуль;
• требуется установить, когда именно появились спорные файлы или страницы, — при отсутствии репозитория и при споре о датах.

Если ваш вопрос звучит иначе — например, спор идёт о самом факте публикации на странице, а не о коде, — точнее начать с экспертизы веб-сайтов.

Почему исходный код на PHP обычно цел — и почему это не упрощает дело

Разница с компилируемыми языками принципиальная. Программу на C++ перед запуском превращают в машинный код, и восстановить из него исходный текст почти невозможно; у Java промежуточная форма читается специальными средствами и во многом восстанавливается, но это уже не тот текст, который писал разработчик. И там и там спор часто начинается с того, что заказчику передали результат сборки, а не исходники. Браузерная часть на JavaScript попадает к посетителю собранной и сжатой. В PHP этого шага нет: файл, который лежит на сервере, — это текст, написанный разработчиком, вместе с комментариями и именами переменных. Поэтому вопрос «а есть ли вообще исходный код» на площадке с PHP почти никогда не встаёт.

Обратная сторона в том, что лёгкость правки бьёт и по доказательству. Достаточно доступа по FTP или к панели управления хостингом, чтобы за минуту изменить логику расчёта, дописать строку в шаблон или удалить файл, — и если правка шла мимо репозитория, о ней не останется записи. Время изменения файла хранится в файловой системе и задаётся произвольно; его нельзя принимать за дату написания кода. Поэтому исследование начинают не с чтения кода, а с вопроса о происхождении копии: откуда она снята, кем, когда, что удостоверяет её неизменность с этого момента. Ответ на него определяет, какой вес имеют все дальнейшие выводы.

Поэтому хранить надо не сам архив с кодом, а архив с описанием, как он получен, и с посчитанными контрольными суммами. Как их считать, показано ниже.

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

Чем это отличается от аудита кода и от проверки сайта

Три разные работы часто называют одним словом. Разница между ними — в адресате и предмете, а не в глубине.

Аудит кода делают для владельца системы: он отвечает на вопрос «что улучшить» и опирается на выбранные аудитором представления о хорошем коде. Заключение эксперта отвечает на вопрос суда и опирается на названный в материалах критерий — пункт технического задания, требование договора, документацию используемой системы. Поэтому вывод «код написан плохо» в заключении сам по себе не работает: нужно указать, чему именно он не соответствует.

Проверка сайта как ресурса — тоже другое: там объект — то, что опубликовано по адресу, и вопрос обычно в том, что видел посетитель в конкретный момент. Эти задачи закрывает экспертиза веб-сайтов. Здесь же объект — программное обеспечение и работы по его созданию: соответствие заданию, состав, происхождение, объём. Один и тот же спор нередко требует обеих задач, и тогда их объединяют в одном исследовании, поставив вопросы раздельно.

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

Если в проекте не только PHP

Чистых проектов на одном языке почти не бывает, и по PHP это правило работает жёстче всего: серверная часть на PHP почти всегда идёт в паре с браузерной частью на JavaScript, а в крупных системах рядом оказываются и другие языки.

Для исследования это значит, что границу нужно провести до постановки вопросов, иначе эксперт получит поручение шире своей задачи. Обычно её проводят так:

• спор о серверной логике — расчёты, заказы, права доступа, обмен с внешними системами: это как раз тема страницы, которую вы читаете;
• спор о поведении интерфейса в браузере — вёрстка, динамические формы, корзина на стороне клиента: экспертиза исходного кода на JavaScript;
• рядом с сайтом работает корпоративная система или сервис на других платформах: экспертиза кода на Java, экспертиза кода на Python;
• спор касается обмена с учётной системой: он разбирается на странице экспертизы 1С.

Знать язык заранее не обязательно: его называют в техническом задании и в актах, он известен подрядчику, а по составу файлов проекта эксперт определяет его сам. Если спорная функция затрагивает обе стороны — например, сумма считается и в браузере, и на сервере, — в вопросах объектом называют обе стороны — и обе исследуются в одном заключении.

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

Битрикс, WordPress, Laravel: что пришло с системой, а что написал подрядчик

Большинство сайтов на PHP собраны не с нуля. Под ними лежит система управления содержимым — «1С-Битрикс», WordPress, Joomla, Drupal, MODX, — торговая платформа вроде OpenCart или Magento либо каркас разработки: Laravel, Symfony, Yii. Сверху ставятся готовые модули и темы, часть из которых куплена, часть скачана бесплатно. Собственный код подрядчика в такой конструкции может занимать от нескольких процентов до половины объёма, и именно этот разрыв порождает большую часть споров о деньгах.

Разделить эти слои — самостоятельная экспертная задача, и решение можно проверить. Дистрибутивы систем и модулей публикуются с указанием версий, у пакетов есть описания зависимостей, а у многих коробок — собственные средства проверки целостности. Эксперт сопоставляет каталог сайта с эталонной поставкой той же версии и получает три группы файлов: совпавшие с поставкой; файлы поставки, изменённые на площадке; файлы, которых в поставке нет вовсе. Сравнение при этом ведут не прямо по байтам: выкладка по FTP в текстовом режиме, редактор с другими настройками или перекодировка меняют невидимые части файла — переводы строк, служебную метку в начале, кодировку — не трогая ни одной строки кода. Если это не учесть, ошибка идёт в одну сторону: файлы переходят из «поставки» в «изменённые», и доля подрядчика оказывается завышенной. Поэтому перед сравнением содержимое приводят к единому виду, а расхождения только в форме записи описывают отдельно от содержательных. Первая группа — не работа подрядчика. Вторая требует разбора: изменение может быть согласованной доработкой, а может быть правкой ядра — вмешательством в файлы самой системы, которое её документация запрещает и которое ломает последующие обновления. Технически это разные вещи; согласовывались такие работы или нет, устанавливает суд по документам. Третья — кандидаты в собственный код, но и среди них встречаются чужие библиотеки, просто скопированные в проект.

Эти два действия смешивать нельзя. Эталонный дистрибутив и общедоступные архивы страниц — не материалы дела: это открытые справочные источники, с которыми эксперт сверяет исследуемый объект, и в заключении он указывает, откуда и когда их получил, вместе с их контрольными суммами. А материалы дела — копию сайта, выгрузку базы, журналы — эксперт сам не собирает: их представляет назначивший орган.

Метод годится не всегда, и где он перестаёт работать, эксперт говорит прямо. Дистрибутивы коммерческих систем — а «1С-Битрикс» именно такой — распространяются по лицензии, и получить эталон нужной версии удаётся не всегда; установка, которую годами обновляли на месте, может не иметь точного соответствия ни одной опубликованной версии; каркасы разработки в этом смысле не поставка — они задают структуру, а не набор файлов; у самописного движка эталона нет вовсе. Там, где сравнить не с чем, вывод об авторстве кода строят на других признаках — на истории изменений, документах и переписке — и надёжность его ниже.

Устройство систем при этом разное, и это меняет объём работы. У «1С-Битрикс» правки принято выносить в отдельный каталог решений, не трогая ядро, поэтому наличие изменений внутри ядра — само по себе значимый факт, а часть настроек и шаблонов хранится в базе, а не в файлах. У WordPress собственный код подрядчика почти всегда лежит в каталоге тем и плагинов, ключевые настройки — в одном файле конфигурации, а остальное — в таблицах, включая содержимое страниц. У проектов на Laravel или Symfony ядра как такового нет, и сравнивают не с поставкой, а с составом библиотек: файл блокировки версий закрепляет за каждым пакетом точную запись в хранилище исходных текстов, поэтому проверка здесь получается даже строже, чем сверка с дистрибутивом коробки. Поэтому вопрос «сколько написал подрядчик» на одном сайте решается за день, а на другом требует отдельного исследования.

Особый случай — каталог зависимостей. В экосистеме PHP их устанавливает Composer, который записывает состав в описание проекта, а точные версии — в файл блокировки: он закрепляет и прямые, и косвенные зависимости с указанием источника, из которого пакет получен. Установленные пакеты складываются в отдельный каталог, и по объёму он часто превосходит весь остальной проект. Считать его работой подрядчика нельзя, но и игнорировать нельзя: подобранный состав библиотек и их обновление — это тоже труд, и он не сводится к числу строк. Если файла блокировки версий нет, восстановить состав на спорную дату сложнее, и это ограничение эксперт указывает прямо.

Версия PHP как самостоятельный предмет спора

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

Код, написанный под PHP 5.6, на PHP 7 ломается там, где раньше работал: исчезло старое расширение для работы с базой данных, изменилось поведение при ошибках, часть конструкций перестала разбираться. Переход на PHP 8 добавил свой слой: обращение к несуществующей переменной или ключу массива из малозаметного замечания стало предупреждением, а сравнение строки с числом изменило результат — выражение, которое раньше считалось истинным, теперь ложно. Последнее особенно важно для спора: такая перемена не даёт ни ошибки, ни записи в журнале, и сайт просто начинает считать иначе. Для спора это значит, что «сайт не работает» может быть следствием не дефекта кода, а смены окружения — и наоборот, подрядчик мог сдать работу на версии, которая уже не получает обновлений безопасности.

Что здесь устанавливает эксперт: под какую версию написан код (по используемым конструкциям и объявленным требованиям в описании зависимостей), на какой версии он фактически исполнялся, совместим ли он с той версией, которая указана в техническом задании, и какие именно места отказывают при переносе. Утверждение «версия устарела» без указания на конкретное требование договора или на конкретный отказ остаётся оценочным, и эксперт его не делает.

Проверяют и то, что входило в обязанности подрядчика по сопровождению: обновление платформы, коробочной системы и модулей — это работа, а не автоматический процесс, и её наличие или отсутствие в договоре меняет предмет исследования.

Что устанавливает эксперт по коду на PHP

Круг устанавливаемых обстоятельств задаёт вопрос суда, но по PHP он обычно укладывается в несколько типов. Ниже — то, что подтверждается материалами, а не общими соображениями.

• соответствие реализованного техническому заданию — по каждому проверяемому требованию отдельно, с указанием способа проверки;
• состав сайта: какая коробочная система и версия использованы, какие модули и темы установлены, что изменено относительно поставки, что написано сверху;
• работоспособность заявленной функции на развёрнутой копии и причина отказа, если функция не работает;
• полнота переданного комплекта: разворачивается ли сайт из того, что передали, и чего не хватает;
• наличие в коде посторонних вставок — веб-оболочек, скрытых точек входа, кода, скрытого кодированием, — и их отличие от штатных механизмов;
• совпадения между двумя проектами за вычетом коробки, библиотек и сгенерированных файлов;
• период, к которому относится спорное состояние, — по совокупности источников, а не по одной отметке времени;
• объём собственного кода в файлах, строках или функциях — с оговоркой, что это ещё не стоимость.

Эксперт не оценивает добросовестность сторон, не толкует условия договора и не определяет размер убытков: это вопросы права и, при необходимости, отдельной экономической экспертизы.

Как проверяют соответствие заданию на развёрнутой копии

Проверяют требование за требованием, а не общее впечатление. Из технического задания, приложений и переписки эксперт выбирает формулировки, допускающие проверку, и по каждой указывает способ: чтение кода, воспроизведение сценария на развёрнутой копии, сравнение с эталонной поставкой, анализ журналов. Требования, сформулированные оценочно — «удобный интерфейс», «современный дизайн», — прямой проверке не поддаются, и эксперт говорит об этом, а не подменяет критерий собственным вкусом.

Особенность PHP здесь в том, что сайт почти всегда удаётся развернуть. Имея каталог файлов и выгрузку базы, эксперт поднимает копию в изолированной среде и проверяет требования на работающей системе, не трогая площадку. Но копия должна совпасть с оригиналом по окружению: версия самого PHP, состав включённых расширений, настройки сервера и режим отображения ошибок влияют на поведение сайта не меньше кода. Проект, написанный под PHP 7.4, на PHP 8 может отказать в местах, которые к спору отношения не имеют, — и наоборот, дефект проявится только на исходной версии. Поэтому окружение фиксируют наравне с кодом и описывают в заключении.

Расхождение эксперт формулирует как факт, а не как обвинение: требование такое-то реализовано, реализовано частично или не реализовано; проверялось так-то; получен такой-то результат. Правовую оценку — существенный это недостаток или нет, исключает ли он приёмку — даёт суд. Если спор целиком укладывается в этот вопрос и язык для него значения не имеет, задачу закрывает экспертиза соответствия работ техническому заданию.

Как считают объём работ и почему объём не равен деньгам

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

Считать «строки в каталоге» бессмысленно: в них попадут ядро коробочной системы, установленные Composer'ом библиотеки, сжатые стили и скрипты, словари переводов, загруженные пользователями файлы и автоматически сгенерированный код. Поэтому эксперт сначала вычитает всё перечисленное, а уже потом измеряет остаток — и описывает, что именно вычтено и на каком основании. Эта часть заключения обычно и оспаривается, поэтому границы должны быть проверяемыми: версия дистрибутива, файл блокировки версий, признаки генерации.

Дальше — граница компетенции. Объём в строках, файлах или функциях — технический факт. Стоимость работ этим фактом не определяется: одна строка сложной интеграции и сто строк однотипной вёрстки несопоставимы по трудозатратам. Если спор о цене, вопрос о стоимости ставится отдельно и решается либо в рамках экспертизы объёма и стоимости работ, либо комплексной экспертизой с участием экономиста. Расчёт стоимости строят на этих цифрах, но делают его не здесь.

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

Если репозитория нет, а всё выкладывали по FTP

В проектах на PHP это встречается чаще, чем в любых других: сайт годами правили прямо на площадке, система контроля версий не велась, а весь след работ остался в мессенджере. Целиком историю тогда не восстановить, но и безнадёжной задача не будет — просто источники другие, и каждый из них слабее записи в репозитории.

Что даёт материал для реконструкции: резервные копии хостинг-провайдера — их хранят ограниченный срок, у массовых тарифов обычно от нескольких дней до месяца, и именно поэтому запрашивать их нужно немедленно; журналы FTP-сервера и панели управления, где видно, кто и когда загружал файлы; журналы веб-сервера, показывающие, с какой даты страница начала отвечать; почтовая переписка с вложениями и датами отправки; счета и акты хостинг-провайдера, привязывающие площадку к периоду; архивные копии страниц в общедоступных архивах интернета. Поодиночке ни один источник вопроса не решает, но их совпадение даёт обоснованный вывод о периоде.

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

Отметку времени файла эксперт здесь использует осторожно и всегда с оговоркой: её задают произвольно штатной командой; на Linux и macOS обычное копирование ставит дату копирования, а после переноса на другой хостинг у всего каталога нередко оказывается одна и та же дата. В Windows штатное копирование дату изменения, наоборот, сохраняет — поэтому вывод зависит от того, каким путём файл попал в исследуемую копию, и этот путь должен быть описан. Мешает и обратное: при распаковке отметка обычно восстанавливается из архива, то есть выглядит достоверной, хотя ничего не подтверждает. Есть у файловой системы и вторая отметка — времени изменения сведений о файле. Штатной командой её назад не переводят, поэтому расхождение между двумя отметками уже бывает признаком того, что дату правили. Живёт эта отметка только до копирования, поэтому и важно, чтобы копию снимали архивом и с описью. Вывод на одной дате изменения не устоит: рецензент это заметит.

Закрытый код и посторонние вставки: как их различают

В PHP есть два разных явления, которые внешне выглядят одинаково — как нечитаемый текст, — но означают противоположное, и путать их нельзя.

Первое — коммерческая защита. Подрядчик пропускает часть файлов через энкодер — средство, которое чаще других в спорах встречается ionCube PHP Encoder, — и текст программы превращается в нечитаемый вид. На сервере такие файлы работают только при установленном дополнительном расширении, а нередко и при действующей лицензии. Встречается и Zend Guard, но им закрывали код старых проектов: на PHP 7 и более поздние версии его не переносили. С точки зрения спора это существенно: заказчик получил работающий сайт, но не получил исходного кода той части, которая закрыта, и не может ни доработать её сам, ни передать другому подрядчику. Эксперт устанавливает, какие файлы закрыты, каким средством, какую долю функциональности они покрывают и что именно перестаёт работать при истечении лицензии или переносе на сервер без нужного расширения. Восстановить исходный текст из такого файла эксперт не пытается: это и технически ненадёжно, и выходит за пределы задачи.

Второе — следы постороннего вмешательства. Веб-оболочка, дающая злоумышленнику управление сайтом, — это обычно одна короткая строка, исполняющая присланный текст; её прячут в шаблоне темы или в загруженном изображении. Эксперт отличает такую вставку от штатной защиты по нескольким признакам: месту расположения, отсутствию в эталонной поставке, характеру кода, времени появления относительно журналов веб-сервера. Через какую уязвимость и когда вошли, установить можно — если сохранились журналы; при их отсутствии эксперт ограничивается фиксацией самих вставок и прямо говорит о невозможности определить момент.

В спорах о взломанном сайте это разделение обычно и есть предмет: одна сторона утверждает, что дыру оставил разработчик, другая — что сайт не обслуживали и не обновляли. Оба утверждения проверяемы, но по разным материалам, и вопросы суду стоит формулировать раздельно.

Если доступы удерживает подрядчик

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

Экспертиза иска не заменит, но часть неясностей снимет. Эксперт может зафиксировать состав того, что фактически передано, и установить, достаточно ли этого для самостоятельной работы с сайтом: разворачивается ли он из переданного, полны ли настройки, не закрыта ли часть кода энкодером, есть ли в нём привязка к площадке подрядчика — обращения к его серверам, ключи его учётных записей, механизмы удалённого отключения. Сведения о том, на кого оформлены домен и хостинг, эксперт берёт из документов, представленных сторонами или истребованных судом: в общедоступной справке по доменам зоны .RU данные владельца-физического лица не раскрываются, а самостоятельно собирать материалы эксперт не вправе.

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

Какие объекты исследуются на площадке с PHP

Перечень зависит от вопросов, но по PHP набор устойчив. Он делится на две части.

Код, поставка и площадка

Основной материал — то, из чего сайт состоит и на чём работает:

• каталог сайта целиком, включая скрытые файлы и файлы настроек;
• описание зависимостей и файл блокировки версий, каталог установленных пакетов;
• дистрибутивы использованной коробочной системы, модулей и тем той же версии — для сравнения с поставкой;
• репозиторий системы контроля версий — чаще всего Git — с полной историей, если она велась: со всеми ветками, метками и записями об изменениях;
• настройки веб-сервера Apache или nginx и самого PHP: конфигурация, правила обработки адресов, список включённых расширений, версия;
• выгрузка базы данных MySQL, MariaDB или PostgreSQL: значительная часть логики сайтов на коробочных системах хранится не в файлах, а в таблицах настроек и в содержимом.

Следы работы и документы

Материал, по которому восстанавливают ход событий и требования:

• журналы веб-сервера, FTP и панели управления хостингом за спорный период;
• журналы ошибок PHP и журналы самой коробочной системы;
• резервные копии за период до спора — у хостинг-провайдера или у заказчика;
• техническое задание, приложения, акты, переписка сторон, задачи в системе учёта;
• лицензии на коробочную систему, платные модули и шаблоны с датами приобретения.

Что сохранить, пока площадка не изменилась

Главный объект здесь — работающая площадка, а не архив на диске; от этого и порядок действий. Сохранять нужно её состояние целиком и до того, как кто-либо что-то поправит.

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

Минимум такой:

• снимите каталог сайта архивом, а не простым копированием: архив сохраняет вложенность, скрытые файлы и даты изменения, а копирование их теряет — на Linux и macOS обычное копирование ставит всем файлам сегодняшнее число. Заодно выгрузите базу данных; если доступ есть только к панели управления хостингом, сделайте резервную копию сайта её штатными средствами и скачайте архив;
• сохраните опись: перечень файлов с размерами и датами изменения на момент снятия. Она нужна, чтобы позже было видно, что именно вы взяли и в каком состоянии;
• уберите архив туда же, где храните бухгалтерию: в нём лежат действующий пароль к базе, ключи платёжных систем и персональные данные клиентов. И это не для вида: выгрузка клиентской базы «на всякий случай: утечка этого архива хуже, чем спор, ради которого он снят;
• запросите у хостинг-провайдера письмом все резервные копии за прошедшие периоды — их хранят ограниченный срок, у массовых тарифов это обычно от нескольких дней до месяца, и старые затираются новыми;
• скачайте журналы веб-сервера, FTP и панели управления за весь доступный период;
• зафиксируйте окружение: версию PHP, список расширений, версию и настройки веб-сервера — снимком экрана панели управления хостингом или письмом от хостинг-провайдера. Не создавайте для этого новых файлов на спорной площадке: диагностическая страница показывает пути и переменные окружения вместе с паролями и ключами, доступна всем, кто знает адрес, и сама становится изменением в том каталоге, который вы сохраняете;
• посчитайте контрольную сумму каждого архива и запишите её отдельным документом. Контрольная сумма — это короткая строка, которую вычисляют из содержимого файла: изменится в файле хоть один знак, изменится и она, поэтому записанная сегодня сумма позволяет завтра доказать, что архив не подменяли. В Windows её считает PowerShell командой Get-FileHash архив.zip -Algorithm SHA256, в обычной командной строке — certutil -hashfile архив.zip SHA256; в Linux — sha256sum архив.zip, в macOS — shasum -a 256 архив.zip;
• составьте короткую записку: что именно скачано, с какого адреса и сервера, когда, под какой учётной записью, кто присутствовал.

Список технический — так и должно быть: выполнять его должен тот, у кого есть доступ к площадке, — ваш системный администратор, штатный разработчик или сотрудник хостинг-провайдера по вашей заявке. Если единственный такой человек — тот самый подрядчик, с которым идёт спор, поручать это ему не нужно: обращайтесь напрямую к хостинг-провайдеру, доступ к площадке принадлежит владельцу договора. Если такого человека нет, не экспериментируйте с работающим сайтом: позвоните по номеру 8 (800) 333-24-09, и мы подскажем порядок под вашу площадку. Красиво делать не нужно — нужно успеть, пока каталог не изменился.

Пока состояние не зафиксировано, не выкладывайте исправленную версию, не переносите сайт на другой хостинг, не обновляйте коробочную систему и модули, не чистите журналы и не сокращайте срок их хранения, не удаляйте резервные копии. Смену паролей и ключей доступа планируйте так: сначала копия, сразу за ней — смена. Это правило отменяется, если доступ злоумышленника не прекращён и ущерб растёт: тогда прекращение доступа важнее чистоты копии. Порядок в этом случае обратный — снимите копию тем, что успеваете, затем смените пароли и ключи и завершите все сеансы, а закрывать сайт лучше снаружи, средствами хостинга или веб-сервера. Встроенный в систему режим обслуживания для этого не годится: он не мешает обращаться напрямую к постороннему файлу, не закрывает доступ по FTP и к панели, не отменяет заданий по расписанию — и сам по себе меняет спорное состояние. Всё, что вы сделали, и время каждого действия запишите: изменения, о которых эксперт знает, он учтёт, а о которых не знает — нет.

Это не значит, что бизнес должен встать. Если сайт уже пришлось срочно чинить или восстанавливать после взлома, требование «ничего не трогать» задним числом бессмысленно: зафиксируйте нынешнее состояние, сохраните всё, что осталось от прежней версии, и запишите, что и когда вы меняли при восстановлении. После этого сайт обслуживают штатно, включая обновления безопасности.

Копия, которую вы сняли сами, доказывает меньше, чем кажется: другая сторона вправе сказать, что архив собран уже после спора. Усиливают её посчитанные сразу контрольные суммы, независимый источник той же копии — резервная копия хостинг-провайдера, — и, при высокой цене вопроса, обеспечение доказательств: до обращения в суд — нотариальное обеспечение доказательств; в арбитражном процессе суд вправе принять меры по обеспечению доказательств и до предъявления иска, по заявлению заинтересованного лица; по возбуждённому делу подают ходатайство об обеспечении доказательств.

Как передать копию сайта и не раскрыть лишнего

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

Материалы передают в исходном виде, но по защищённому каналу и с ограниченным кругом лиц, а всё, что в копии открывает доступ, после передачи меняют: пароль к базе данных, ключи внешних сервисов и платёжных систем, а также служебные ключи подписи, которыми система заверяет сеансы пользователей, — иначе тот, у кого есть архив, сможет войти в административную часть под чужой учётной записью. Одновременно завершают все активные сеансы и принудительно меняют пароли привилегированных учётных записей: их защищённые представления лежат в выгрузке базы, а материалы, поступившие в суд, доступны сторонам. Старые значения остаются в архиве как часть объекта, но перестают что-либо открывать. Срок хранения переданных материалов, порядок их возврата или уничтожения согласуйте заранее и зафиксируйте в договоре.

Если в базе есть персональные данные клиентов, объём выгрузки согласуют до отправки и по возможности ограничивают таблицами, относящимися к спору. Основание при этом разное: по судебной экспертизе обработка нужна для осуществления правосудия и отдельного согласия клиентов не требует, а при внесудебном исследовании по договору основание придётся определять вместе со своим юристом — процессуальной обязанности там нет. Это не формальность: выгрузка клиентской базы «на всякий случай» создаёт самостоятельный риск для вас как оператора.

Эксперта соглашение о конфиденциальности связывает, стороны — нет: то, что попало в суд, они увидят. и это учитывают при выборе объёма. Куда и как передавать — защищённое хранилище, носитель с описью или доступ по согласованному каналу — предложим при первом обращении, до того как вы что-либо отправите.

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

Порядок исследования сайта на PHP

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

1. Принимаются материалы, фиксируется их состав и контрольные суммы; описывается, откуда и когда получена каждая копия.
2. Определяются коробочная система, её версия и состав модулей; подбираются эталонные дистрибутивы тех же версий.
3. Каталог сайта сопоставляется с эталонной поставкой; выделяются совпавшие, изменённые и посторонние файлы.
4. Сайт разворачивается в изолированной среде с воспроизведением исходного окружения — версии PHP, расширений, настроек сервера.
5. По каждому проверяемому требованию выполняется проверка выбранным способом; результат фиксируется вместе с условиями получения.
6. Проверяются альтернативные объяснения обнаруженного: настройки среды, действия третьих лиц, данные, внесённые пользователями.
7. Формулируются выводы в пределах поставленных вопросов; перечисляются ограничения и то, что установить не удалось.

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

Примеры вопросов эксперту по коду на PHP

Годный вопрос называет две вещи: объект и проверяемый критерий. Объект по PHP — это адрес площадки и дата снятия копии либо конкретный архив с контрольной суммой; критерий — пункт технического задания или иной документ. При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу: эксперт отвечает в пределах специальных знаний и представленных материалов и при неясности вопроса сообщает об этом назначившему органу, а помощь с формулировками возможна до назначения.

Ниже — примеры формулировок; подробные перечни под конкретные задачи собраны на страницах экспертизы качества исходного кода и экспертизы плагиата исходного кода.

1. Соответствует ли программное обеспечение, содержащееся в архиве с контрольной суммой SHA-256 …, требованиям пунктов … технического задания (приложение № … к договору от …)?
2. Какая система управления содержимым и какой версии использована; какие файлы каталога сайта совпадают с эталонной поставкой этой версии, какие изменены и какие в поставке отсутствуют?
3. Какой объём программного кода в архиве … создан вне состава коробочной поставки и подключённых через Composer библиотек?
4. Содержится ли в файлах сайта программный код, не относящийся к штатной работе системы управления содержимым и обеспечивающий выполнение произвольных команд?
5. Имеются ли в файлах архива … и архива … совпадения программного кода, не объясняемые использованием одной коробочной системы, общих библиотек и типовых конструкций языка?
6. Позволяет ли комплект, переданный по акту от …, развернуть работоспособную копию сайта; если нет — каких компонентов недостаточно?

Форматы работы: суд, досудебная стадия, рецензия

Форматов несколько, и выбирают их по стадии спора:

• судебная экспертиза по определению суда или постановлению органа расследования — с предупреждением эксперта об уголовной ответственности за заведомо ложное заключение;
• внесудебное исследование по договору со стороной — до подачи иска или параллельно с ним;
• письменная консультация по материалам, когда нужно понять перспективу и правильно поставить вопросы;
• участие специалиста в судебном заседании для пояснений по проведённому исследованию;
• рецензирование чужого заключения — подробнее на странице рецензии на заключение о процессе разработки.

После назначения судебной экспертизы правила общения меняются, и по спорам о сайтах это чувствуется особенно: у стороны обычно остаётся доступ к площадке, и возникает соблазн дослать эксперту свежую выгрузку или журнал напрямую. Так делать нельзя. Назначенный эксперт не принимает материалы от одной стороны и не даёт ей частных оценок по существу поручения: доступ, вопросы и всё новое идут через суд или орган расследования. Если специалист раньше работал для одной из сторон, это раскрывают при рассмотрении его кандидатуры; решение о назначении и об отводе принимает назначивший орган.

От чего зависят стоимость и срок по проекту на PHP

Решают три обстоятельства, и первые два специфичны именно для PHP. Первое — сколько слоёв придётся разделять: сайт на коробочной системе с двумя десятками модулей требует сопоставления с эталонными поставками каждого из них, и это самостоятельная работа, которой нет у проекта, написанного с нуля. Второе — уцелело ли окружение: если известны версия PHP, состав расширений и настройки сервера, копия поднимается за часы; если сайт уже перенесён, а прежняя площадка недоступна, восстанавливать среду придётся отдельно, и получится не всегда. Третье — есть ли история изменений: репозиторий с ветками и метками отвечает на вопрос о датах сразу, а его отсутствие означает реконструкцию по журналам, резервным копиям и переписке. Дальше как везде: объём спорной части, число проверяемых требований, количество вопросов и необходимость смежных специалистов. Ориентир для судебной экспертизы — от 100 000 ₽, ориентировочный срок — 10 рабочих дней; точные условия определяются после просмотра материалов.

Начинать с архивов не нужно. Назовите программу, опишите спор и перечислите, что у вас есть: договор, задание, переписка, доступы к репозиторию. — договор, задание, переписка, доступы. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку: мы скажем, относится ли задача к нашей компетенции, какое направление её закрывает, что стоит сохранить прямо сегодня и каких данных не хватает для расчёта стоимости.