¿Hay alguna forma de robar el código PHP o ASP de un servidor web a través de los protocolos HTTP (S)?

Usted tiene razón en que esto no es posible sin las vulnerabilidades de configuración o seguridad que lo permiten.

En general, los culpables más probables cuando se trata de eliminar el código de la aplicación son los códigos comentados, los archivos de copia de seguridad que tienen extensiones que les permiten ser entregados directamente a los clientes sin procesamiento, y probablemente más probable que todos los demás culpables combinados, son excesivamente mensajes de error detallados.

Por lo tanto, no solo se trata de asegurarse de que su aplicación se comporte correctamente cuando la use correctamente, sino también de que se comporte correctamente cuando se abusa de ella.

Dicho esto, el robo de código es, en general, un riesgo muy sobrevalorado. Tu código no es tan especial. Lo digo simplemente porque, en mi experiencia, hay muy poco código. Es muy poco probable que alguien realmente quiera robarlo. Es mucho más probable que se utilice el tipo de fallas que enumeré anteriormente para obtener información confidencial como las credenciales de la base de datos, o para exponer la existencia de debilidades en la lógica de la aplicación que podrían conducir a la explotación por vectores comunes como la inyección de SQL.

Si el servidor web que está utilizando está configurado correctamente, no tiene que preocuparse por la entrega de los propios archivos ASP / PHP no interpretados (a menos que, por supuesto, el atacante esté explotando una vulnerabilidad en algún lugar, como señaló) .

Si te preocupa especialmente el robo de código, probablemente sea más útil pensar en otros vectores de ataque más probables:

• Su host de control de versión (es decir, github, bitbucket, su propio host de repo privado) está en peligro. En estos días, todos los grandes proyectos de software deberían estar usando algún tipo de control de versión, y definitivamente no es extraño que los atacantes obtengan acceso al propio repositorio.
• Los servicios que está utilizando que tienen acceso de lectura a su control de versión (es decir, Travis CI) están comprometidos. Esto podría decirse que es más probable que suceda que una compañía masiva como Github o Atlassian siendo hackeada, y ha sucedido antes: enlace
• Su servidor se verá afectado por alguna otra vulnerabilidad (vulnerabilidad ssh, acceso a través de un servicio alojado en la misma caja, un proveedor de alojamiento comprometido, etc.), aunque tiene mucho más de mucho temas de los que preocuparse. en este caso.

Me inclino a estar de acuerdo con Xander en este caso: el robo de código como concepto está sobrevalorado definitivamente, a menos que esté trabajando en una IP muy compleja y única (tenga en cuenta que incluso esto es un extreme rareza).

Para mayor seguridad, mantenga el código importante fuera del directorio del servidor web. Colóquelo en otro directorio del servidor donde el servidor web no pueda acceder. En su página web, agregue una línea de inclusión para ese archivo, incluida la ruta completa desde la raíz al archivo. La página puede acceder al código, pero no hay código para mostrar si la página alguna vez descarga el código. Este es el enfoque recomendado para todas las conexiones de base de datos que tienen contraseñas en el script.