Come si può eseguire il debug di un'applicazione Web PHP in modo sicuro senza esporre segreti ai concorrenti?

Di recente ho realizzato un programma. Ho dimenticato di eliminare 2 righe di codice. Quell'errore mi è costato $ 800 al giorno ogni giorno.

Stavo programmando con PHP. Se un visitatore utilizza proxy, reindirizza altrove. L'uso del debugger era impossibile perché alcuni codici contengono ioncube. Poiché il programma reindirizza semplicemente da qualche altra parte, non importa quale sia, è difficile vedere quale parte del codice viene eseguita.

Quindi ho messo un sacco di informazioni di debug ovunque. Ho pensato di eliminarli comunque.

Il modo più naturale per eseguire il debug è ovviamente quello di mettere le informazioni di debug in un file. Il problema è che uso spesso proxy. Quindi, dopo aver modificato il programma, spesso devo scaricare il file di testo con filezilla. Spesso il file di testo non mostra ciò che penso dovrebbe mostrare. Alla fine ho deciso di visualizzare l'errore sul Web.

Ho considerato di avere la modalità di debug. Tuttavia, temo che dimenticherò di eliminare le informazioni di debug.

Ho considerato di avere la modalità di debug se l'utente lo fa? Debuggingmode = 1 per esempio. Tuttavia, ero paranoico che in qualche modo il mio concorrente potesse indovinare la parola chiave segreta.

Ho eliminato la maggior parte delle informazioni di debug. Ho dimenticato di eliminarne uno e quello viene visualizzato solo se gli utenti utilizzano il proxy dal paese giusto. Si scopre che non ho proxy dal paese giusto e non me ne sono reso conto. Dopo che il programma ha funzionato per 24 ore, l'ho caricato sul mio dominio principale.

Il mio concorrente, usando il proxy, vede il codice di debug. Ha copiato l'idea ed è così che ho perso $ 800 al giorno.

In retrospettiva, ho davvero difficoltà a vedere dove ho sbagliato. Sono stato molto attento. Eppure è successo.

Come si può eseguire il debug di un'applicazione Web PHP in modo sicuro senza esporre segreti ai concorrenti?

Ho davvero difficoltà a vedere dove ho sbagliato

L'errore principale è stato che hai reinventato la ruota. Invece di utilizzare meccanismi predefiniti per la registrazione, hai inventato il tuo , che mostrava le informazioni all'interno della pagina. Un framework di registrazione preferirebbe archiviare i log nei file di log, consentendo di consultare tali log in un secondo momento tramite SSHing sul server.

Per quanto riguarda i bug, la produzione di codice privo di bug implica l'utilizzo di tecniche specifiche come la prova formale . Data la loro costosità, queste tecniche sono appropriate per applicazioni critiche per la vita come applicazioni che controllano il traffico aereo o navette spaziali, ma rappresentano un problema eccessivo per quasi tutte le applicazioni aziendali.

■ Vedi Scrivono le cose giuste sulla rivista Fast Company.
_{L'articolo descrive la metodologia utilizzata alla NASA, nonché i costi di produzione del software in questo modo.}

■ Vedi Mechanizing Proof (Mackenzie 2004).
_{Il libro riassume la storia della prova automatizzata del software, spiegando i pro ei contro di tale prova, nonché i motivi che non sono comunemente usati dalle aziende per scrivere software affidabile.}

Detto questo, ci sono un sacco di tecniche utilizzate per le applicazioni aziendali per garantire la qualità del software. Questi includono ma non sono limitati a:

• Revisioni informali del codice,
• Ispezioni formali del codice,
• test,
• Verifica personale del codice,
• eccetera.

■ Vedi Codice completo (McConnell 2004), Programmazione della produttività (Jones 1986a), Efficienza nella rimozione dei difetti del software (Jones 1996) e Cosa abbiamo appreso sulla lotta ai difetti (Shull et al. 2002).

Inoltre, non dimenticare l'integrazione continua e la consegna continua. Aiuta a ripristinare automaticamente l'app in produzione su una versione funzionante quando una rivista sembra avere un problema che è stato perso durante la revisione del codice e il test dell'unità, ma rilevato una volta che l'app è stata distribuita.

■ Vedere Il segreto per una distribuzione continua sicura (video)
_{Spiega quali tecniche sono state impostate su Google per impedire che i bug che non sono stati trovati prima della distribuzione rimangano troppo a lungo in produzione. Descrive anche pdiffe come è stato usato per catturare i bug, compresi quelli che non erano collegati al livello di presentazione.}

Non dovresti mai eseguire il debug in produzione.

Dovresti sempre avere un ambiente di test identico all'ambiente di produzione e il debug lì.

Quando è necessario modificare il codice nell'ambiente di test (come per l'aggiunta di istruzioni di debug), è necessario assicurarsi che non entrino in produzione.

Una configurazione professionale di solito assomiglia a questo:

Production
   ^
Staging
   ^
Development

Le istanze "Produzione", "Messa in scena" e "Sviluppo" dell'applicazione devono essere il più identiche possibile in modo tale che un bug che si verifica in "Produzione" possa essere riprodotto in "Messa in scena" e "Sviluppo", ma sia comunque completamente separato da a vicenda in modo che qualunque cosa accada in una delle istanze non influisca sulle altre.

Quando è necessario analizzare un problema, lo si fa in "Sviluppo". Gioca con le dichiarazioni di debug e sperimenta tutto ciò che desideri. Quando hai trovato una soluzione, applichi quella correzione alla base di codice invariata in "Gestione temporanea" e verifica che la correzione funzioni. Quindi promuovi la correzione su "Produzione".

Un adeguato controllo della versione e un sistema di gestione della build possono aiutarti in questo.

Questo viene fatto raramente perché lo sforzo non è utile. Anche se perdi $ 800 al giorno, lo sforzo di provare un programma corretto diventa rapidamente più grande di quello, il che implica che non ci sono ragioni per farlo.

Se essere certo è la pena più di tanto (ad esempio per il software Space Shuttle o di controllo dei missili), allora si eseguire la verifica formale, test esaustivo di tutti i possibili ingressi, ecc Certo, è anche estremamente difficile, così come lenta e costosa. Ma i progetti con budget da miliardi di dollari tendono anche ad avere persone estremamente brillanti. (O forse erano soliti fare - i titoli dei nostri giorni sembrano contraddire quella regola.)

A volte è necessario eseguire il debug di un sistema live. Sì, dovresti avere una copia di sviluppo o di gestione temporanea. Ma ci saranno sempre differenze. Ciò è particolarmente vero se il codice si sta esaurendo in modo selvaggio sull'hardware del cliente. O potenzialmente, molte diverse installazioni del cliente.

Ho usato la tecnica & debugging = 1 in passato. Sospetto che la maggior parte degli sviluppatori PHP abbia. Ciò ha attivato un interruttore nel codice che ha consentito un debug più dettagliato nell'applicazione. Quelle informazioni di solito verrebbero scaricate in un file di registro, generalmente il registro apache (usando error_log ()). Ma puoi anche produrlo. Il nostro profiler, ad esempio, raccoglieva informazioni e quindi produceva i vari parametri di riferimento nella parte inferiore della pagina. È inoltre possibile generare le informazioni di debug come commento HTML o in un elemento nascosto visibile solo se si visualizza l'origine della pagina.

Se il tuo sito ha "utenti", puoi limitare il debug solo a un determinato utente. In questo modo, se qualcuno tenta di abilitare il debug, continuerà a non funzionare a meno che non abbia effettuato l'accesso come tale utente.

Ora, hai detto che stavi usando FileZilla per connetterti al server. Uno sviluppatore dovrebbe davvero avere accesso SSH al server. Ciò renderà il debug molto più semplice per te. Ad esempio, se si dovessero generare le proprie dichiarazioni di debug nel registro degli errori di Apache, ad esempio, è possibile quindi eseguire facilmente il grep del file per l'indirizzo IP e visualizzare le informazioni di debug generate dall'ultima richiesta di pagina.

Tutti gli altri hanno già trattato il caso generale:

Convalida formale (/ Codice comprovato): non fattibile per i programmi del mondo reale, anche se esiste un sistema operativo kernal da 4000 linee, che è stato formalmente dimostrato, ci sono voluti molti molti studenti di dottorato di ricerca in CS russi molti mesi (per favore commenta se ricordi il nome di questo progetto)

Test CI << Test automatizzati << Test : assicurati di utilizzare uno strumento di copertura per verificare che i tuoi casi di test abbiano una copertura del 100%.

Per il tuo caso specifico di lasciare il codice di debug in produzione, ho 2 opzioni, entrambe le quali richiedono che il codice sorgente venga ricompilato come parte della distribuzione in un nuovo ambiente (Staging / Final Testing).

1. Rimuovilo al momento della compilazione. Avvolgere il codice di debug in strutture come C # e C #ifdef DEBUGper controllare il target di compilazione, (Debug o Release) e rimuoverlo automaticamente al momento della compilazione.

2. Contrassegnalo al momento della distribuzione. Inserisci un commento vicino al codice che non deve essere eseguito nel vero ambiente. Ad esempio //TODO: Remove This Before Deployment, quando viene migrato (distribuito) su Staging, prima di compilare il codice, eseguirlo attraverso un semplice script che verifica che non ci siano commenti Flag (ad esempio //TODO:) nel codice sorgente.

Suggerisco il primo per se è a lungo termine e lo vorrai di nuovo (ad esempio modalità di registrazione dettagliata), e in seguito se si tratta di un trucco rapido mentre esegui il debug (ad esempio vari tipi di stampa sparsi nel tuo codice)

Come altri hanno già detto prima di me, molti test (unitari e funzionali), se possibile automatizzati e con una buona copertura del codice, sono la chiave per avere un software per lo più privo di bug.

Se capisco abbastanza bene la descrizione del tuo problema, le informazioni di debug sono mostrate nella pagina servita dal tuo server. In tal caso, dovresti considerare di inserire tali informazioni nei log corretti sul tuo server. In questo modo non viene mai mostrato all'utente finale, anche se si distribuisce una versione "dettagliata" alla produzione. Questo è qualcosa che è buono da fare qualunque sia il progetto a cui stai lavorando, a meno che tu non abbia ottime ragioni per fare diversamente.

Ciò che gli altri dicono del debug in produzione è giusto. Ma l'ho fatto a volte comunque. E penso che ci siano modi più sicuri per farlo rispetto ai tuoi, anche se nulla è infallibile.

Non ho bisogno di una sicurezza così elevata da solo, non voglio che gli utenti vedano un mucchio di cose incomprensibili sui loro schermi.

$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>';
}

Ora gli utenti non vedranno il tuo debug a meno che non lo vogliano davvero. Se il tuo $ 800 / giorno dipende dal mantenere segrete queste informazioni di debug, non utilizzare il codice sopra . Ma se le informazioni non sono così sensibili, quanto sopra sarà molto meglio che dipendere da una variabile GET o rivelare i tuoi segreti a un intero paese.

In alternativa, puoi creare una debugclasse o una funzione che controllerà se la stampa è consentita o meno in base ai tuoi criteri. Questo è ciò che faccio.

Qualcosa come questo:

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.

Per il mio programma che mi farà $ 800 / giorno (in fase di sviluppo), utilizzo apache mod auth per richiedere una password per accedere a qualsiasi parte del sito, oltre a limitare le informazioni di debug a determinati IP. La tua domanda mi fa pensare che dovrei cercare una migliore sicurezza.

In realtà, avrei due ulteriori convalide qui. Uno è il &debug=1parametro nella richiesta. Puoi anche utilizzare alcune variabili di sessione speciali o impostazioni di cookie che solo tu puoi attivare tramite una chiamata a una pagina "segreta" (preferibilmente con autenticazione).

La seconda convalida sarebbe quella di avere nel file di configurazione, un array con un intervallo di IP e solo le chiamate da un IP in quell'array possono attivare la funzionalità di debug. qualcosa di simile a

Nella configurazione:

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

Avere il seguente metodo da qualche parte dove è possibile accedervi a livello globale:

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'];
}

E nel tuo codice chiama qualcosa del tipo:

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

Tieni presente che il codice nel getClientIp()metodo non è sicuro poiché il valore per $_SERVER['HTTP_X_FORWARDED_FOR']è facilmente falsificato, tuttavia dovrebbe servire allo scopo di ottenere il punto per la tua domanda.