Як слід безпечно налагоджувати веб-додаток PHP, не розкриваючи секретів конкурентам?

Нещодавно я зробив програму. Я забув видалити 2 рядки кодів. Ця помилка коштувала мені 800 доларів на день щодня.

Я програмував за допомогою PHP. Якщо відвідувач використовує проксі, він перенаправляє кудись інше. Використовувати відладчик було неможливо, оскільки деякий код містить ioncube. Оскільки програма просто переспрямовується кудись інше незалежно від того, важко зрозуміти, яка частина коду виконується.

Тому я всюди розміщував інформацію про налагодження. Я думав, що все-таки видаляю їх останніми.

Найбільш природний спосіб налагодження - це, звичайно, помістити інформацію про налагодження у файл. Проблема в тому, що я часто використовую проксі. Тому після зміни програми мені часто доводиться завантажувати текстовий файл з filezilla. Часто в текстовому файлі не відображається те, що, на мою думку, повинно відображатися. Нарешті я вирішив просто відобразити помилку в Інтернеті.

Я розглядав режим налагодження. Однак я боюся, що забуду видалити інформацію про налагодження.

Я вважав, що в режимі налагодження, наприклад, користувач? Debuggingmode = 1. Однак я був параноїком, що якось мій конкурент може відгадати секретне ключове слово.

Я видалив більшість інформації про налагодження. Я забуваю видалити один і той, який з’являється, лише якщо користувачі використовують проксі з потрібної країни. Виявляється, я не маю проксі від правильної країни і цього не усвідомлював. Після того, як програма працює протягом 24 годин, я завантажив це в основний домен.

Мій конкурент, використовуючи проксі, бачить код налагодження. Він копіює ідею, і ось так я втрачав 800 доларів на день.

З ретроспективою мені справді важко бачити, куди я пішов не так. Я був дуже обережним. І все-таки це сталося.

Як слід безпечно налагоджувати веб-додаток PHP, не розкриваючи секретів конкурентам?

Мені справді важко бачити, де я помилився

Основна помилка полягала в тому, що ви винаходили колесо. Замість того, щоб використовувати меканізми за замовчуванням для ведення журналу, ви вигадали свій власний , який відображав інформацію на сторінці. Рамка ведення журналів швидше зберігатиме журнали у файлах журналів, дозволяючи вам згодом звертатися до цих журналів SSHing на сервер.

Що стосується помилок, створення коду без помилок передбачає використання конкретних методик, таких як формальне підтвердження . Враховуючи їхню дорогоцінність, ці методи підходять для життєво важливих застосувань, таких як додатки, які контролюють рух літаків або космічні човники, але є надмірним для майже кожного бізнес-додатку.

■ Див. Вони пишуть потрібні речі в журналі Fast Company.
_{У статті описано методологію, що використовується в NASA, а також вартість виготовлення програмного забезпечення таким чином.}

■ Див. Механізуючі докази (Mackenzie 2004).
_{У книзі підсумована історія автоматизованого доказування програмного забезпечення, пояснюються плюси і мінуси такого доказування, а також причини, які підприємства зазвичай не використовують для написання надійного програмного забезпечення.}

Це, як кажуть, існує маса методик, що використовуються для бізнес-додатків для забезпечення якості програмного забезпечення. До них належать, але не обмежуються ними:

• Неофіційні огляди коду,
• Офіційні перевірки коду,
• Тестування,
• Особистий стіл-перевірка коду,
• тощо.

■ Див. Кодекс повний (McConnell 2004), Продуктивність програмування (Jones 1986a), Ефективність видалення програмних дефектів (Jones 1996) та Що ми дізналися про боротьбу з дефектами (Shull et al. 2002).

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

■ Див. «Секрет безпечного безперервного розгортання» (відео) У
_{ньому роз'яснено, які методи були створені в Google, щоб запобігти помилкам, які не вдалося знайти до розгортання, залишатись занадто довго у виробництві. Він також описує pdiffі як він використовувався для лову помилок, у тому числі тих, які не стосувалися шару презентації.}

Ніколи не слід налагоджувати виробництво.

У вас завжди повинно бути тестове середовище, яке є ідентичним виробничому середовищу і там налагоджено.

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

Професійні установки зазвичай виглядають так:

Production
   ^
Staging
   ^
Development

Екземпляри вашої програми "Виробництво", "Постановка" та "Розробка" повинні бути максимально ідентичними, щоб помилка, яка виникає у "Виробництві", могла бути відтворена в "Постановці" та "Розвитку", але все-таки повністю відірвана від один одного, так що все, що станеться в одному з екземплярів, не впливає на інші.

Коли вам потрібно проаналізувати проблему, ви робите це в «Розвитку». Поплутайтеся з заявами про налагодження і експериментуйте все, що вам потрібно. Коли ви знайшли рішення, застосуйте це виправлення до незмінної бази коду в "Постановці" і переконайтеся, що виправлення працює. Потім ви просуваєте виправлення до "Виробництво".

Правильна система управління версіями та складання системи може допомогти вам у цьому.

Це рідко робиться, тому що докладати зусиль не варто. Навіть якщо ви втрачаєте 800 доларів на день, зусилля довести програму правильною швидко зростають, ніж це, що означає, що для цього немає ділового випадку.

Якщо бути впевнені , це варто , що багато (наприклад , для програмного забезпечення Space Shuttle або управління ракетою), то виконати формальну перевірку, вичерпне тестування всіх можливих входів і т.д. Звичайно, це також надзвичайно важко , так як повільно і дорого. Але проекти, що мають мільярдні бюджети, також, як правило, мають надзвичайно яскравих людей. (А може, вони просто звикли - сучасні заголовки, здається, суперечать цьому правилу.)

Іноді вам потрібно налагодити живу систему. Так, у вас повинна бути копія розробки або постановки. Але завжди будуть розбіжності. Це особливо актуально, якщо код нестандартно закінчується на апаратному забезпеченні клієнта. Або, можливо, багато різних клієнтських установок.

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

Якщо на вашому веб-сайті є "користувачі", ви можете обмежити налагодження лише певним користувачем. Таким чином, якщо хтось намагається ввімкнути налагодження, він все одно не буде функціонувати, якщо вони не ввійшли як цей користувач.

Тепер ви згадали, що використовуєте FileZilla для підключення до сервера. Розробник дійсно повинен мати доступ SSH до сервера. Це зробить налагодження набагато простішим для вас. Наприклад, якщо ви, наприклад, виводили ваші заяви про налагодження до журналу помилок Apache, ви могли б легко зв'язати цей файл за вашою IP-адресою та побачити інформацію про налагодження, створену вашим останнім запитом на сторінку.

Усі інші вже висвітлювали загальну справу:

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

CI Тестування << Автоматизоване тестування << Тестування : переконайтеся, що ви використовуєте інструмент покриття, щоб перевірити, чи мають ваші тестові випадки 100% покриття.

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

1. Видаліть його під час компіляції. Вставте код налагодження в такі структури, як C # і C, #ifdef DEBUGщоб перевірити ціль збірки (або налагодження чи випуск) та автоматично видалити їх під час компіляції.

2. Позначити його під час розгортання. Помістіть коментар біля коду, який не повинен бути запущений у реальній обстановці. Наприклад //TODO: Remove This Before Deployment, тоді, коли він переміщений (розгорнуто) до Постановки, перед тим як скласти код, запустіть його за допомогою простого сценарію, який перевіряє, чи не залишилося коментарів із прапорцем (наприклад //TODO:) у вихідному коді.

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

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

Якщо я досить добре розумію опис вашої проблеми, інформація про налагодження відображається на сторінці, яку обслуговує ваш сервер. Якщо це так, вам слід розглянути можливість розміщення цієї інформації у правильних журналах на вашому сервері. Таким чином, він ніколи не відображається кінцевому користувачеві, навіть якщо ви розгортаєте «багатослівну» версію для виробництва. Це те, що добре робити будь-який проект, над яким ви працюєте, якщо у вас немає дуже вагомих причин зробити інше.

Те, що інші кажуть про налагодження у виробництві, правильно. Але я це роблю іноді все одно. І я думаю, що є безпечніші способи зробити це, ніж ваш, хоча нічого не є надійним.

Мені не потрібна така висока безпека, я просто не хочу, щоб користувачі бачили купу своїх потвор на своїх екранах.

$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()методі не є безпечним, оскільки значення для $_SERVER['HTTP_X_FORWARDED_FOR']нього легко підробляється, однак він повинен слугувати меті отримати точку для вашого запитання.