Как можно безопасно отлаживать веб-приложение PHP, не раскрывая секретов конкурентам?

Недавно я сделал программу. Я забыл удалить 2 строки кодов. Эта ошибка стоила мне 800 долларов в день каждый день.

Я программировал на PHP. Если посетитель использует прокси, он перенаправляет куда-то еще. Использовать отладчик было невозможно, потому что какой-то код содержит ioncube. Поскольку программа просто перенаправляет куда-то еще, несмотря ни на что, трудно увидеть, какая часть кода выполняется.

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

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

Я рассмотрел наличие режима отладки. Тем не менее, я боюсь, что забуду удалить отладочную информацию.

Я рассмотрел наличие режима отладки, если пользователь делает? Debuggingmode = 1, например. Тем не менее, я был параноиком, что мой конкурент каким-то образом может угадать секретное ключевое слово.

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

Мой конкурент, используя прокси, видит код отладки. Он копирует идею, и вот как я теряю 800 долларов в день.

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

Как можно безопасно отлаживать веб-приложение PHP, не раскрывая секретов конкурентам?

Мне действительно трудно увидеть, где я ошибся

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

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

■ См. Они пишут правильные вещи в журнале Fast Company.
_{В статье описывается методология, используемая в НАСА, а также стоимость производства программного обеспечения таким способом.}

■ См. Механизированное доказательство (Mackenzie 2004).
_{Книга обобщает историю автоматизированного тестирования программного обеспечения, объясняет плюсы и минусы такого доказательства, а также причины, по которым компании обычно не используют его для написания надежного программного обеспечения.}

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

• Неофициальные обзоры кода,
• Формальные проверки кода,
• Тестирование,
• Персональная проверка кода,
• и т.п.

■ См. « Код завершен» (McConnell 2004), « Эффективность программирования» (Jones 1986a), « Эффективность устранения дефектов программного обеспечения» (Jones 1996) и « Что мы узнали о борьбе с дефектами» (Shull et al. 2002).

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

■ См . Секрет безопасного непрерывного развертывания (видео).
_{В нем объясняется, какие методы были настроены в Google для предотвращения ошибок, которые не могли быть обнаружены до того, как развертывание слишком долго оставалось в производстве. Он также описывает pdiffи как он использовался для выявления ошибок, в том числе тех, которые не были связаны с уровнем представления.}

Вы никогда не должны отлаживать в производстве.

У вас всегда должна быть тестовая среда, идентичная рабочей среде, и отладка в ней.

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

Профессиональная установка обычно выглядит так:

Production
   ^
Staging
   ^
Development

Экземпляры «Production», «Staging» и «Development» вашего приложения должны быть максимально идентичными, чтобы ошибка, возникающая в «Production», могла быть воспроизведена в «Staging» и «Development», но при этом полностью отделена от друг с другом, чтобы то, что происходит в одном случае, не влияло на другие.

Когда вам нужно проанализировать проблему, вы делаете это в разделе «Разработка». Возиться с отладочными утверждениями и экспериментировать все, что вы хотите. Когда вы нашли решение, вы применяете это исправление к неизмененной кодовой базе в «Staging» и проверяете, работает ли исправление. Затем вы продвигаете исправление «Производство».

В этом вам может помочь правильная система контроля версий и управления сборкой.

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

Если быть уверены , это стоит , что многое (например , для программного обеспечения Space Shuttle или управления ракетой), то выполнить формальную проверку, исчерпывающее тестирование всех возможных входов и т.д. Конечно, это также чрезвычайно трудно , так как медленно и дорого. Но проекты с бюджетами в миллиард долларов также имеют тенденцию привлекать к себе чрезвычайно ярких людей. (Или, может быть, они просто привыкли - современные заголовки противоречат этому правилу.)

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

В прошлом я использовал технику & debugging = 1 . Я подозреваю, что большинство разработчиков PHP имеют. Это щелкнуло переключателем в коде, который включил более подробную отладку в приложении. Эта информация обычно выводится в файл журнала - обычно это журнал apache (с использованием error_log ()). Но вы также можете вывести его. Наш профилировщик, например, собирал информацию и затем выводил различные тесты внизу страницы. Вы также можете вывести отладочную информацию в виде HTML-комментария или в виде скрытого элемента, который можно просматривать, только если вы просматриваете исходный код страницы.

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

Вы упомянули, что используете FileZilla для подключения к серверу. У разработчика действительно должен быть SSH-доступ к серверу. Это сделает отладку намного проще для вас. Например, если вы хотите вывести свои отладочные операторы, например, в журнал ошибок Apache, вы можете легко найти этот файл для своего IP-адреса и просмотреть информацию об отладке, сгенерированную вашим последним запросом страницы.

Все остальные уже рассмотрели общий случай:

Формальная валидация (/ проверенный код): не подходит для реальных программ, хотя существует ядро ​​с 4000 строчками ОС, которое было формально доказано, многим российским аспирантам CS потребовалось много месяцев (пожалуйста, прокомментируйте, если помните название этого проекта)

CI Testing << Автоматическое тестирование << Testing : убедитесь, что вы используете инструмент покрытия, чтобы проверить, что ваши тесты имеют 100% покрытие.

Для вашего конкретного случая оставить отладочный код в рабочем состоянии, у меня есть 2 варианта, оба из которых требуют, чтобы исходный код был перекомпилирован как часть развертывания в новой среде (Staging / Final Testing).

1. Удалите его во время компиляции. Оберните код отладки в такие структуры, как C # и C, #ifdef DEBUGчтобы проверить цель сборки (либо отладка, либо выпуск) и автоматически удалить их во время компиляции.

2. Отметьте это во время Развертывания. Поместите комментарий рядом с кодом, который нельзя запускать в реальной среде. Например //TODO: Remove This Before Deployment, затем, когда он переносится (развертывается) в Staging, перед компиляцией кода запустите его с помощью простого скрипта, который проверяет, не осталось ли комментариев к файлу (например, комментариев //TODO:) в исходном коде.

Я предлагаю первый вариант, если он долгосрочен, и вы захотите его снова (например, режим подробного ведения журнала), и позже, если это быстрый взлом во время отладки (например, различные printfs разбросаны по вашему коду).

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

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

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

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

$debug = true;
$allowed_ips = array('192.168.0.220','173.46.89.255'); // limit to your own ip's. If your competitor knows them, though, he can spoof it! But if your stuff is not top secret, it's ok. 

if(!in_array($_SERVER['REMOTE_ADDR'],$allowed_ips) ) {
  $debug = false;
}

if($debug) {
  echo '<pre>' . print_r($some_variable) . '</pre>';
}

Теперь пользователи не увидят вашу отладку, если они этого не хотят. Если ваши $ 800 / день зависят от того, чтобы сохранить эту отладочную информацию в секрете, не используйте приведенный выше код . Но если информация не настолько конфиденциальна, вышеприведенное будет намного лучше, чем зависеть от переменной GET или раскрывать ваши секреты всей стране.

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

Что-то вроде этого:

class debug {
  public $on = false;
  public static function print($variable) {
    if($on) {
      echo '<pre>' . print_r($some_variable) . '</pre>';
    }
  }
}

debug::print($some_variable); // class checks if printing is allowed. If not, no printing occurs.

Для моей программы, которая будет приносить мне 800 долларов в день (в разработке), я использую apache mod auth, чтобы требовать пароль для доступа к любой части сайта, а также ограничив отладочную информацию для определенных IP-адресов. Ваш вопрос заставляет меня думать, что я должен смотреть на лучшую безопасность все же.

На самом деле, у меня было бы две дополнительные проверки здесь. Одним из них является &debug=1параметр в запросе. Вы также можете использовать некоторую специальную переменную сеанса или настройку cookie, которую только вы можете активировать с помощью вызова «секретной» страницы (желательно с аутентификацией).

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

В конфиге:

$debugAllowedIPs = array('127.0.0.1', '192.168.0.1', /* add more IPs here */);

Где-нибудь, где есть глобальный доступ к следующему методу:

function getClientIp() {
    if (!empty($_SERVER['HTTP_CLIENT_IP']))  return $_SERVER['HTTP_CLIENT_IP'];
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) return $_SERVER['HTTP_X_FORWARDED_FOR'];
    return $_SERVER['REMOTE_ADDR'];
}

И в вашем коде вызовите что-то вроде:

if (in_array(getClientIp(), $debugAllowedIPs)) { /* show debug info here */ }

Помните, что код в getClientIp()методе небезопасен, так как значение for $_SERVER['HTTP_X_FORWARDED_FOR']легко подделывается, однако оно должно служить цели для разъяснения вашего вопроса.