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. Debe existir confianza entre usted y el anfitrión.

Acerca del código fuente. Si el atacante está tratando de obtener acceso a su código fuente, obtendrá acceso a su código fuente, ofuscado o no, compilado o interpretado.

Allí está un valor en la ofuscación de su código, en el sentido de que probablemente hará que sea un poco más difícil de obtener por el atacante oportunista ocasional. Pero si tu anfitrión quiere atraparte, ellos te atraparán.

¿La solución? La ley. Firme un contrato con ellos y acuerde algún tipo de NDA.

Bueno, esto requiere tres comentarios:

• No se pueden proteger secretos con la 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 sucederá.

• 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 debe usar su propio hardware: alquila un espacio de bahía aislado, con cerraduras y protecciones, 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 la cabeza 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 mediante el soborno de una de las personas a las que se les ha informado.

  (En este último caso, ese podría ser su plan: usted es posible que desee ver a un competidor más grande simplemente comprarlo.)

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 merece la pena. Nadie quiere robar tu código. Mil millones de productos SaaS han sido lanzados por individuos y empresas que utilizan alojamiento de terceros de una descripción u otra, y casi ninguno de ellos se ha encontrado a sí mismo compitiendo contra sí mismo después de que sus hosts les robaran el código de sus productos.

Entonces, ¿debería ofuscar su código? Claro, si te hace sentir mejor. Ningún daño hecho. ¿Está protegiendo su propiedad intelectual contra una amenaza válida? No en realidad no. Es una especie de versión del desarrollador 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 pase a preocuparse por mitigar las amenazas reales.

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

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

La ofuscación es ineficaz 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 abusa 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 piratee 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 gabinete en una instalación compartida con monitoreo de la propiedad física.

Sin embargo, el simple hecho de usar un NDA debería ser suficiente con cualquier proveedor de alojamiento de confianza.

No me molestaría.

Dos razones:

Los lenguajes interpretados en tiempo de ejecución realmente no pueden protegerse completamente de esa manera. Para ofuscarlo completamente, también tendría que ofuscarlo del tiempo de ejecución, entonces no habría forma de ejecutarlo. La ofuscación solo 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 contienen realmente el tipo de código secreto que la gente realmente se tomaría tantas molestias para robar. Es mucho más fácil obtener una lista de funciones y algunos contratistas y decir "hacer algo como esto" que copiar función por función con la mayoría de las aplicaciones comunes.

Debe tomar precauciones para protegerse, pero no por las razones o de la amenaza que está imaginando.

En primer lugar, si no puede confiar en su proveedor de alojamiento, obtenga un nuevo proveedor de alojamiento . No es necesario decir 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 solo uno. ¿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 excede el costo de construirlo usted mismo.

Finalmente, debería preocuparse de que los atacantes recuperen su código y lo usen para atacarlo. 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.

Ofuscar su código no es una solución y no ayudaría de todos modos. Pero las buenas prácticas de seguridad, incluido el cumplimiento del principio de privilegio mínimo, deberían ayudarlo. Separe su acceso para que comprometer un sistema o componente no le dé a su atacante toda la aplicación en un pequeño paquete ordenado. Cuanto más independientes y desconectados sean los elementos de su negocio, menos se puede enganchar un atacante de una sola vez.

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

El valor está en los datos y en el apoyo que brindas y mantener contento al cliente.

Todas mis aplicaciones de escritorio podrían descompilarse de una forma u otra. Creo que VB6 fue el único que no se pudo descompilar. Nadie podía mantenerlos porque yo uso codificación complicada y nombres de variables complicados.

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

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ía en que su proveedor de servicios de alojamiento no robe sus datos, debe buscar un proveedor de alojamiento más confiable o un servidor usted mismo.

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

Cuando llega a la conclusión de que no confía en ningún proveedor de alojamiento, pero que su alojamiento es demasiado caro, tiene la opción de comprar su propio servidor físico y deje que otra persona lo aloje, pero 1. cifre completamente su sistema de archivos para que no puedan clonar los discos duros durante el mantenimiento y 2. asegúrese de que toda la comunicación de la red esté cifrada para que no puedan olfatear el tráfico.

El mundo está patas arriba, el valor real no suele estar 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 se encuentran en texto plano, a menudo sin ninguna protección simple. Este es uno de los problemas que PCI DSS, HIPAA y otros estándares de seguridad de datos deben abordar.

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

Además del problema de seguridad a través de la oscuridad, la ofuscación del código también puede introducir problemas de seguridad y deberá ser examinado al mismo nivel o a un nivel superior que su base de código habitual.

No.

Claramente: planea invertir tiempo en una tecnología llamada seguridad a través de la oscuridad .

¡No es una buena idea!

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

La ofuscación nunca oculta ni cambia su código, simplemente lo modifica a algún otro formato en el que pueda procesarlo,

Ejemplo: si desea ofuscar el nombre de su clase, MyHomePage puede cambiarlo a 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 puede ofuscar su código o sus datos lo suficiente como para protegerlos. 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 quedan en secreto. Ésta es la base de la mayoría de los sistemas de derechos digitales y, hasta la fecha, todos han sido descifrados.

En una nota más técnica, si está utilizando un lenguaje interpretado (Perl, PHP) o un código de bytes interpretado lenguaje (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 compilar de forma nativa para su hardware. Tener una versión compilada de forma nativa elimina la necesidad de mantener su árbol de fuentes en sus servidores remotos y también proporciona un aumento significativo del rendimiento.

La seguridad por oscuridad no es mala si no es lo único en lo que confía. Usar la ofuscación para proteger su código no funcionará, pero usar la ofuscación con otras licencias no está mal.