¿Cómo se debe depurar una aplicación web PHP de forma segura sin exponer secretos a los competidores?

Recientemente hice un programa. Olvidé eliminar 2 líneas de códigos. Ese error me costó $ 800 por día todos los días.

Estaba programando con PHP. Si un visitante usa proxy, redirige a otro lugar. El uso del depurador era imposible porque algún código contiene ioncube. Debido a que el programa simplemente redirige a otro lugar sin importar qué, es difícil ver qué parte del código se ejecuta.

Así que puse un montón de información de depuración en todas partes. Pensé que los eliminaría más tarde de todos modos.

La forma más natural de depurar es, por supuesto, poner la información de depuración en un archivo. El problema es que a menudo uso proxy. Entonces, después de cambiar el programa, a menudo tengo que descargar el archivo de texto con filezilla. A menudo, el archivo de texto no muestra lo que creo que debería mostrar. Finalmente decidí mostrar un error en la web.

Pensé en tener el modo de depuración. Sin embargo, me temo que olvidaré eliminar la información de depuración.

Considere tener modo de depuración si el usuario hace? Debuggingmode = 1 por ejemplo. Sin embargo, estaba paranoico porque de alguna manera mi competidor puede adivinar la palabra clave secreta.

Eliminé la mayoría de la información de depuración. Olvidé eliminar uno y ese solo aparece si los usuarios usan el proxy del país correcto. Resulta que no tengo un representante del país correcto y no me di cuenta de eso. Después de que el programa funciona durante 24 horas, lo cargué en mi dominio principal.

Mi competidor, usando proxy, ve el código de depuración. Copió la idea y así es como perdí $ 800 por día.

En retrospectiva, realmente me cuesta ver dónde me equivoqué. He sido súper cuidadoso Sin embargo, sucedió.

¿Cómo se debe depurar una aplicación web PHP de forma segura sin exponer secretos a los competidores?

Realmente me cuesta ver dónde me equivoqué

El principal error fue que reinventaste la rueda. En lugar de utilizar mecanismos predeterminados para el registro, inventó el suyo , que mostraba la información dentro de la página. Un marco de registro preferiría almacenar registros en archivos de registro, lo que le permite consultar esos registros más tarde mediante SSHing en el servidor.

En cuanto a los errores, la producción de código libre de errores implica el uso de técnicas específicas como la prueba formal . Dada su cara, esas técnicas son apropiadas para aplicaciones críticas para la vida, como las aplicaciones que controlan el tráfico de aeronaves o los transbordadores espaciales, pero son una exageración para casi todas las aplicaciones comerciales.

■ Vea Escriben lo correcto en la revista Fast Company.
_{El artículo describe la metodología utilizada en la NASA, así como el costo de producir software de esta manera.}

■ Ver Prueba de mecanización (Mackenzie 2004).
_{El libro resume la historia de la prueba automatizada de software, explica los pros y los contras de dicha prueba, así como las razones por las que las empresas no la usan comúnmente para escribir software confiable.}

Dicho esto, hay un montón de técnicas utilizadas para aplicaciones comerciales para garantizar la calidad del software. Eso incluye pero no se limita a:

• Revisiones informales de códigos,
• Inspecciones formales de código,
• Pruebas,
• Verificación personal de código de escritorio,
• etc.

■ Ver Código completo (McConnell 2004), Productividad de programación (Jones 1986a), Eficiencia de eliminación de defectos de software (Jones 1996) y Lo que hemos aprendido sobre los defectos de lucha (Shull et al. 2002).

Además, no olvide la integración continua y la entrega continua. Ayuda a revertir automáticamente la aplicación en producción a una versión de trabajo cuando una versión revisada parece tener un problema que se perdió durante las revisiones de código y las pruebas unitarias, pero se detectó una vez que se implementó la aplicación.

■ Consulte El secreto para la implementación continua segura (video)
_{Explica qué técnicas se configuraron en Google para evitar errores que no se pudieron encontrar antes de que la implementación permanezca durante demasiado tiempo en producción. También describe pdiffy cómo se usó para detectar errores, incluidos los que no estaban relacionados con la capa de presentación.}

Nunca debe depurar en producción.

Siempre debe tener un entorno de prueba que sea idéntico al entorno de producción y depurar allí.

Cuando necesite cambiar el código en el entorno de prueba (como para agregar instrucciones de depuración), debe asegurarse de que no entren en producción.

Una configuración profesional generalmente se ve así:

Production
   ^
Staging
   ^
Development

Las instancias de "Producción", "Puesta en escena" y "Desarrollo" de su aplicación deben ser lo más idénticas posible para que un error que ocurre en "Producción" pueda reproducirse en "Puesta en escena" y "Desarrollo", pero aún así estar completamente separado de entre sí para que lo que suceda en una de las instancias no afecte a las demás.

Cuando necesita analizar un problema, lo hace en "Desarrollo". Juega con las declaraciones de depuración y experimenta todo lo que quieras. Cuando encuentra una solución, aplica esa solución a la base de código sin cambios en "Puesta en escena" y verifica que la solución funciona. Luego promueve la solución a "Producción".

Un control de versiones y un sistema de gestión de compilación adecuados pueden ayudarlo con eso.

Esto rara vez se hace porque el esfuerzo no vale la pena. Incluso si pierde $ 800 por día, el esfuerzo de probar que un programa es correcto rápidamente se vuelve más grande que eso, lo que implica que no hay ningún caso comercial para hacerlo.

Si ser cierta es la pena que gran parte (por ejemplo, para el software del transbordador espacial o el control de misiles), a continuación, realiza la verificación formal, prueba exhaustiva de todas las posibles entradas, etc. Por supuesto, también es muy difícil , así como lento y caro. Pero los proyectos con presupuestos de miles de millones de dólares también tienden a tener personas extremadamente brillantes. (O tal vez solían hacerlo, los titulares actuales parecen contradecir esa regla).

A veces es necesario depurar un sistema en vivo. Sí, debe tener una copia de desarrollo o de ensayo. Pero siempre habrá diferencias. Esto es especialmente cierto si el código se está agotando en el hardware del cliente. O potencialmente, muchas instalaciones de clientes diferentes.

He usado la técnica & debugging = 1 en el pasado. Sospecho que la mayoría de los desarrolladores de PHP tienen. Eso activó un cambio en el código que permitió una depuración más detallada en la aplicación. Esa información generalmente se volcaría en un archivo de registro, generalmente el registro de apache (usando error_log ()). Pero también puedes generarlo. Nuestro generador de perfiles, por ejemplo, reuniría información y luego generaría los diversos puntos de referencia en la parte inferior de la página. También puede generar la información de depuración como un comentario HTML o en un elemento oculto que solo se puede ver si ve el origen de la página.

Si su sitio tiene 'usuarios', puede limitar la depuración solo a un usuario en particular. De esta manera, si alguien intenta habilitar la depuración, aún no funcionará a menos que haya iniciado sesión como ese usuario.

Ahora, mencionó que estaba usando FileZilla para conectarse al servidor. Un desarrollador realmente debería tener acceso SSH al servidor. Eso hará que la depuración sea mucho más fácil para usted. Por ejemplo, si tuviera que enviar sus declaraciones de depuración al registro de errores de Apache, por ejemplo, podría fácilmente seleccionar ese archivo para su dirección IP y ver la información de depuración generada por su última solicitud de página.

Todos los demás ya han cubierto el caso general:

Validación formal (/ Código comprobado): No es factible para programas del mundo real, aunque hay un kernel de sistema operativo de 4000 líneas, que se comprobó formalmente, le tomó muchos meses a muchos estudiantes de doctorado ruso de CS muchos meses (comente si recuerda el nombre de este proyecto)

Pruebas de CI << Pruebas automatizadas << Pruebas : asegúrese de utilizar una herramienta de cobertura para verificar que sus casos de prueba tengan una cobertura del 100%.

Para su caso específico de dejar el código de depuración en producción, tengo 2 opciones, las cuales requieren que el código fuente se vuelva a aplicar como parte de la implementación en un nuevo entorno (Prueba provisional / final).

1. Eliminarlo en tiempo de compilación. Envuelva el código de depuración en estructuras como C # y C #ifdef DEBUGpara verificar el destino de la compilación (depurar o liberar) y eliminarlos automáticamente en el momento de la compilación.

2. Marcarlo en el momento de implementación. Ponga un comentario cerca del código que no debe ejecutarse en el entorno real. Por ejemplo //TODO: Remove This Before Deployment, luego, cuando se migra (implementa) a Staging, antes de compilar el código, ejecútelo a través de un script simple que verifica para asegurarse de que no queden comentarios de Flag (por ejemplo //TODO:) en el código fuente.

Sugiero el primero para si es a largo plazo y lo querrá nuevamente (por ejemplo, modo de registro detallado), y el segundo si es un truco rápido mientras estaba depurando (por ejemplo, varias impresiones dispersas a través de su código)

Como otros han dicho antes, muchas pruebas (unitarias y funcionales), si es posible automatizadas y con una buena cobertura de código, son la clave para tener un software en su mayoría libre de errores.

Si entiendo bastante bien la descripción de su problema, la información de depuración se muestra en la página servida por su servidor. Si ese es el caso, debe considerar poner esa información en los registros adecuados en su servidor. De esta forma, nunca se muestra al usuario final, incluso si implementa una versión 'detallada' en producción. Esto es algo bueno para hacer cualquier proyecto en el que esté trabajando, a menos que tenga muy buenas razones para hacerlo de otra manera.

Lo que otros dicen sobre la depuración en la producción es correcto. Pero lo he hecho a veces de todos modos. Y creo que hay formas más seguras de hacerlo que la suya, aunque nada es infalible.

No necesito una seguridad tan alta, simplemente no quiero que los usuarios vean un montón de galimatías en sus pantallas.

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

Ahora los usuarios no verán su depuración a menos que realmente quieran. Si sus $ 800 / día dependen de mantener en secreto esta información de depuración, no use el código anterior . Pero si la información no es tan delicada, lo anterior será mucho mejor que depender de una variable GET o revelar sus secretos a un país entero.

Alternativamente, puede crear una debugclase o función que verifique si la impresión está permitida o no según sus criterios. Eso es lo que hago.

Algo como esto:

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.

Para mi programa que me hará $ 800 / día (en desarrollo), uso apache mod auth para requerir una contraseña para acceder a cualquier parte del sitio, así como restringir la información de depuración a ciertas IP. Sin embargo, su pregunta me hace pensar que debería buscar una mejor seguridad.

En realidad, tendría dos validaciones adicionales aquí. Uno es el &debug=1parámetro en la solicitud. También puede usar alguna variable de sesión especial o configuración de cookies que solo usted puede activar mediante una llamada a una página "secreta" (preferiblemente con autenticación).

La segunda validación sería tener en el archivo de configuración, una matriz con un rango de IP y solo las llamadas de una IP en esa matriz pueden activar la funcionalidad de depuración. algo como

En la configuración:

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

Tenga el siguiente método en algún lugar donde se pueda acceder globalmente:

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

Y en su código llame algo como:

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

Tenga en cuenta que el código en el getClientIp()método no es seguro, ya que el valor $_SERVER['HTTP_X_FORWARDED_FOR']se puede suplantar fácilmente, sin embargo, debe servir para comunicar su pregunta.