¿Debemos proteger el código fuente de la aplicación web para que no sea robado por hosts web a través de la ofuscación?

Un proveedor de alojamiento malicioso puede hacer mucho más que simplemente robar su código. Pueden modificarlo para introducir puertas traseras, pueden robar los datos de sus clientes y arruinar todo su negocio. La confianza debe existir entre usted y el anfitrión.

Sobre el código fuente. Si el atacante intenta obtener acceso a su código fuente, obtendrá acceso a su código fuente, ofuscado o no, compilado o interpretado.

Hay hay un valor para ofuscar su código, ya que probablemente hará que sea un poco más difícil de obtener por el atacante oportunista ocasional. Pero si su anfitrión está tratando de atraparlo, lo lograrán.

¿La solución? La ley. Firme un contrato con ellos y acuerde alguna forma de NDA .

Bueno, esto requiere tres comentarios:

• No puede proteger secretos con ofuscación de código. No realmente . La ofuscación de código de alguna manera funciona contra atacantes desmotivados, pero no es fuerte. Si hay un valor comercial en romperlo, entonces ocurrirá.

• Si no confía en su servicio de alojamiento, busque otro servicio de alojamiento. Si el secreto de su código es importante y vale más que unos pocos cientos de dólares, entonces debería usar su propio hardware: alquila un espacio aislado en la bahía, con cerraduras y guardas, y ejecuta su propia máquina en él.

• Su código existe como código compilado (byte) en los servidores, pero también como código fuente en sus sistemas de desarrollo y en los jefes de sus desarrolladores. No puede ser ese secreto. Como dicen, un millón de dólares siempre es suficiente para desentrañar secretos, aunque solo sea sobornando a una de las personas que han tenido acceso a él.

  (En este último caso, ese podría ser tu plan: podrías desear ver a un competidor más grande simplemente comprarte).

La protección contra la ingeniería inversa y el robo de su propiedad intelectual normalmente se garantiza a través de medios legales, no técnicos.

No, no vale la pena. Nadie quiere robar tu código. Miles y millones de productos SaaS han sido lanzados por individuos y compañías que utilizan servicios de alojamiento de terceros de alguna descripción u otra, y casi ninguno de ellos se encuentra compitiendo con ellos mismos después de que sus anfitriones les hayan robado el código de sus productos.

Entonces, ¿deberías ofuscar tu código? Claro, si te hace sentir mejor. Ningún daño hecho. ¿Está protegiendo su IP contra una amenaza válida? No en realidad no. Es el tipo de versión para desarrolladores web de un sombrero de papel de aluminio.

Hagas lo que hagas, no pierdas mucho tiempo y energía pensando en ello. Tome la decisión de ofuscar o no, y luego continúe con la preocupación por mitigar las amenazas reales.

En última instancia, usted es el único que puede hacer esa evaluación de riesgos. Si vas a dormir mejor ofuscando tu código, hazlo.

Personalmente no me molestaría. Los servicios de alojamiento web de buena reputación están en el negocio de alojamiento web, no en el negocio de robo de código fuente. Si robaran su código, aún tendrían que instalarlo, vender el servicio, encontrar clientes y luchar contra la demanda que usted presentaría contra ellos. Es demasiado esfuerzo para ellos con demasiado riesgo por muy poca recompensa.

La ofuscación no es efectiva contra un atacante determinado, solo lo hace un poco más difícil. Si tiene una razón particular para desconfiar de su proveedor de alojamiento, obtenga otra.

Si solo quiere estar seguro, obtenga un acuerdo de no divulgación y otras garantías legales que le permitan perseguir a su anfitrión si abusan de las cosas.

Si aún no confía en ellos incluso con esas garantías legales, obtenga servidores dedicados que pueda controlar y cifrar de manera que el proveedor de alojamiento no pueda acceder a los datos a menos que pirateen el servidor operativo.

Si le preocupa que alguien tenga acceso físico a sus servidores, configure su propio centro de datos o enciérrelos físicamente en un recinto en una instalación con supervisión de la propiedad física.

Sin embargo, simplemente usar un NDA debería ser suficiente con cualquier proveedor de hospedaje de buena reputación.

No me molestaría.

Dos razones:

Los lenguajes interpretados por Runtime realmente no se pueden proteger completamente de esa manera. Para ofuscarlo por completo, tendrías que hacerlo también en el tiempo de ejecución, entonces no habría forma de ejecutarlo. La ofuscación hace que la tarea sea un poco más molesta. También puede hacer que la depuración y la implementación consuman más tiempo para su propio personal.

Muy pocas aplicaciones realmente contienen el tipo de código de salsa secreto que la gente realmente tendría tantos problemas para robar. Es mucho más fácil obtener una lista de características y algunos contratistas y decir "hacer algo como esto" que copiar una función a otra con las aplicaciones más comunes.

Debes tomar precauciones para protegerte, pero no por las razones o por la amenaza que estás imaginando.

En primer lugar, si no puede confiar en su proveedor de alojamiento, obtenga un nuevo proveedor de alojamiento . No se necesita decir nada más sobre eso.

En segundo lugar, aunque crea que la propiedad intelectual de la aplicación web que ha creado es valiosa, es probable que usted sea el único. ¿Robarías el sitio web de tu competidor? Probablemente no; no valdría la pena Como regla general, las personas no están interesadas en robar su sitio. Normalmente, el costo de personalizar el sitio de otra persona para que se ajuste a sus propias necesidades se aproxima o supera el costo de crearlo usted mismo.

Finalmente, deberías preocuparte de que los atacantes recuperen tu código y lo usen para atacarte. Contraseñas guardadas, bases de datos de usuarios, errores de programación y vulnerabilidades: su código probablemente presenta un objetivo jugoso para los atacantes maliciosos . Esto es particularmente cierto si su código está mal escrito o su servicio es popular.

La ofuscación de su código no es una solución, y no ayudaría de todos modos. Pero las buenas prácticas de seguridad, incluyendo seguir el principio de privilegio mínimo, deberían ayudarlo. Separe su acceso, por lo que comprometer un sistema o componente no le da a su atacante la aplicación completa en un pequeño paquete. Cuanto más independientes y desconectados estén los elementos de su negocio, menos podrá un atacante engancharse de una sola vez.

Tengo muchas aplicaciones web alojadas en línea. Algún código es valioso, sí. Sin embargo, no ofusqué nada de eso, ya que incluso si lo roban, nadie más puede mantenerlo. Eventualmente se sacarán el pelo. Lo probé con alguien que quería mi software mal. No pudo instalarlo, ni entenderlo ni sacarle nada, así que ¿cómo podría encontrar clientes y venderlos como se mencionó anteriormente?

El valor está en los datos y en el soporte que da y mantiene satisfecho al cliente.

Todas mis aplicaciones de escritorio podrían ser descompiladas de una forma u otra. Creo que VB6 fue el único que no pudo ser descompilado. Nadie podría mantenerlos porque uso códigos complicados y nombres de variables difíciles.

No hay mérito de seguridad al intentar ofuscar ningún código del lado del cliente. Un atacante suficientemente determinado evitará cualquier método de ofuscación que les lances.

Si el código es realmente importante, manténgalo en el lado comercial. Considere cualquier código del lado del cliente público y disponible para todos.

Cuando no confíe en su proveedor de servicios de hosting para que no robe sus datos, debe buscar un proveedor de servicios de confianza o un anfitrión más confiable.

No solo les está confiando su código de programa, sino que también confía todos sus datos y los datos de todos sus usuarios. Cuando asume que su proveedor es lo suficientemente malintencionado como para robar su programación, también lo es para robar sus datos de usuario y venderlos al mejor postor. Los datos que probablemente prometió proteger bajo una política de privacidad.

Cuando llega a la conclusión de que no confía en ningún proveedor, pero que hospedarse a sí mismo es demasiado costoso, tiene la opción de comprar su propio servidor físico y dejar que alguien más lo aloje, pero 1. encripta completamente su sistema de archivos para que no puedo clonar los discos duros durante el mantenimiento y 2. asegurarse de que todas las comunicaciones de la red estén cifradas para que no puedan detectar el tráfico.

El mundo está al revés, el valor real generalmente no está en el código de la aplicación. Es en los datos del cliente que el código se utiliza para recopilar / modificar. En muchas aplicaciones web, el código está protegido y los datos permanecen en texto sin formato a menudo sin ninguna protección simple. Este es uno de los problemas que deben abordar PCI DSS, HIPAA y otros estándares de seguridad de datos.

Suponiendo que su proveedor de hosting es malintencionado, el acceso a los datos del cliente destruirá su empresa mucho más rápido que su código.

Además de la cuestión de la seguridad a través de la oscuridad, la ofuscación de código también puede presentar problemas de seguridad y deberá ser examinada al mismo nivel o en un nivel más alto que su base de código regular.

La ofuscación nunca oculta ni cambia su Código, solo lo modifica en algún otro formato en el que puede procesarlo,

Ej: si quieres ofuscar el nombre de tu clase MyHomePage mi cambio en M4Page De manera similar, un método de addWidgets () se nombrará en algún otro, y el nombre de la función también podría cambiarse, no la Funcionalidad Entonces, si deseo llamar al método desde su código ofuscado, puedo implementarlo fácilmente ...

No.

Claramente: está planeando invertir tiempo en el llamado seguridad a través de la oscuridad tecnología.

¡No es una buena idea!

Para proteger su idea contra la licencia de terceros, puede publicarlos bajo una licencia pública como GNU GPL , creative commons  u otros.

No puede ofuscar su código o datos lo suficiente como para hacerlos seguros. Si pudiera, su código y sus datos serían inutilizables incluso para usted.

La seguridad a través de la oscuridad solo funciona mientras el secreto de su ofuscación permanezca intacto. Los secretos nunca se mantienen en secreto. Esta es la base para la mayoría de los sistemas de derechos digitales, y hasta la fecha todos han sido crackeados.

En una nota más técnica, si está usando un lenguaje interpretado (Perl, PHP) o un lenguaje interpretado por bytecode (Java), considere usar las herramientas de compilación nativas incluidas para ellos. Muchos de estos lenguajes de alto nivel incluyen una herramienta para generar una versión C / C ++ de sus scripts o compilarlos de forma nativa para su hardware. Tener una versión compilada de forma nativa elimina la necesidad de mantener su árbol de origen en sus servidores remotos y también proporciona un aumento significativo del rendimiento.

La seguridad por oscuridad no es mala si no es solo algo en lo que se confía. El uso de la ofuscación para proteger su código no funcionará, pero el uso de la ofuscación con otras licencias no está mal.