El compañero programador usó las peores prácticas de programación

Sé que parece extraño decirlo, ¡pero un compañero programador en el trabajo usó deliberadamente un par de malas prácticas de programación a propósito! Lo explicaré. Primero déjame decirte que es un tipo inteligente y en su mayor parte escribe código inteligible.

Se le pidió que implementara licencias en un proyecto de aplicación web escrito en Java. Dado que es Java, si uno realmente quisiera, probablemente podría hackear los frascos y leer los nombres de las clases y métodos escritos en su interior. Su solución a este problema fue, literalmente, llamar torpemente a las variables y métodos nombres menos que obvios y plantarlos dentro de clases ya congestionadas en lugar de generar nuevas clases.

Su justificación fue que si un pirata informático quisiera cambiar ciertas clases para evitar las verificaciones de licencias (y, por lo tanto, obtener una copia gratuita del producto), tendría un momento mucho más difícil si no fuera obvio qué métodos realizar estas tareas particulares. Solo después de que lo hizo, lo enfrenté al respecto, sugiriéndole que tal vez podríamos comprar algún tipo de biblioteca ofuscadora para hacerlo por nosotros, manteniendo buenas prácticas de programación. Afirma no haber tenido el tiempo o los recursos para buscar ese tipo de solución.

.. Lo que me deja en un dilema. ¿Busco una biblioteca de ofuscadores en Java y reparo su antiguo código (que podría ser un poco difícil de remodelar su código), o lo dejo así, tanto como eso me molesta sin fin?

La seguridad a través de la ofuscación nunca es buena seguridad. Debe haber mejores formas de proteger su propiedad intelectual. Y eso es lo que usted y su colega deben plantear como una preocupación conjunta con su gerente. Si la gerencia decide que no quieren gastar tiempo o dinero en mejorar la seguridad, entonces ambos tendrán que vivir con esa decisión (no es su producto, es el producto de la compañía) y mejor no gastar (¿desperdicio?) más tiempo sobre el tema.

Original: ¿Qué dice tu jefe? Averígualo, haz eso.

Me pidieron que elaborara lo anterior:

En primer lugar, creo que tienes más de un dilema:

• ¿Debería "arreglar" el código de otra persona?
• ¿Es la implementación (de aquí en adelante A) de las otras personas lo suficientemente mala como para reemplazarla por otra?
• ¿Será mejor un ofuscador (de aquí en adelante B) para esta "licencia de incrustación en nuestra aplicación"?

En primer lugar, visto desde un caso de negocios, el problema está resuelto. A está en su lugar y es, muy probablemente, una solución "suficientemente buena" para el problema. Su compañía puede estar contenta con ella, básicamente, lo suficientemente protegida como para que sea necesario un esfuerzo deliberado para romperla.

Esto significa que incluso si no te gusta (y, créeme, verás mucho peor a lo largo de tu carrera ) hace lo que se necesita. Por lo tanto, a medida que se resuelve el problema, no debe "simplemente hacerlo" sino convencer a la persona encargada de asignar su trabajo a largo plazo.El precio de esta implementación será lo suficientemente alto como para garantizar una reversión y elegir un ofuscador de acciones. Esto requerirá un poco de preparación por su parte, y también tenga en cuenta que los ofuscadores también tienen desventajas que necesita saber (otras respuestas cubren esto bien). Por ejemplo, los rastros de la pila no se pueden usar de inmediato, etc. Todo depende de lo importante que sea evitar la piratería. Tenga en cuenta que los más difíciles de romper son los que requieren dongles de hardware para ejecutarse y probablemente sean más caros de lo que les gustará a sus clientes.

Por lo tanto, esta decisión no es suya, ya que su empresa necesita utilizar recursos adicionales para llegar a B. Por lo tanto, debe comunicar sus inquietudes a la persona responsable, explicar esta y cualquier otra inquietud a largo plazo lo suficientemente bien como para que él comprenda por qué lo consideras inferior a tu sugerencia. Luego permítale tomar la decisión, e independientemente de lo que resulte ser, respetarla y comportarse en consecuencia de manera profesional. Tenga en cuenta que el autor original probablemente tendrá que mantenerlo de todos modos mientras lo escribió y si se va o no quiere más, entonces puede volver a plantear el asunto.

En otras palabras: ¿qué dice tu jefe? Averígualo, haz eso.

Tenga en cuenta también que esto habría sido diferente si hubiera planteado el problema anteriormente, de modo que el dinero perdido por el tiempo dedicado a la implementación de A fuera menor. En otras palabras, cuando la elección entre A y B debía hacerse.

Finalmente, me gustaría comentar su pregunta sobre "solo arreglar el código de otras personas". Esta no es una pequeña solución para el código existente (lo cual me parece bien y alentado, especialmente con las pruebas en su lugar). Es una reversión y reimplementación disruptiva, e incluso en equipos con propiedad de código común, esto no sería algo aceptable, al menos para mí, sin aprobación previa.

Esperemos que esto aclare mi punto de vista.

¿Busco una biblioteca de ofuscadores en Java y reparo su antiguo código (que podría ser un poco difícil de remodelar su código), o lo dejo así, tanto como eso me molesta sin fin?

No , retroceder detrás de alguien y alterar el código del que es responsable sería una ofensa peor que escribir el código cuestionable para empezar.

Lo mencionó con el programador, su próximo paso es mantener la nariz fuera de él o mencionarlo con la administración y luego mantener la nariz fuera de él.

¿Hubo algún tipo de revisión oficial del código, o fue la confrontación que tuvo una "revisión del código" no oficial? Diría que, dado que este es un tema delicado e importante, como la seguridad y las licencias, es necesario elevarlo en la cadena. Has hecho la primera parte: confrontar al programador. Sin embargo, ahora que no está escuchando, puedes / debes retomarlo. Si no lo hace, puede ser parte del problema.

Le diría que lo vas a hacer, esto PUEDE cambiar de opinión. Si no es así, escriba un correo electrónico muy políticamente correcto, pero preciso y conciso sobre la situación a su jefe, y CC al programador. En el correo electrónico, solicite una reunión entre los tres y / o cualquier otra parte participante.

Siempre enfréntate a estas cosas de frente, pero de una manera política y amigable.

Si puede encontrar un ofuscador que pueda ofuscar la firma de clases (nombres de métodos, etc.), proponga comprarlo y usarlo.

Hasta entonces, es posible que tengas que vivir con eso. Admito que hice algo similar en un proyecto reciente de Grails: las verificaciones de licencia están integradas deliberadamente en el método de inicio de sesión ya grande, por lo que sería bastante difícil reemplazar el método para evitar la verificación.

¿Puede demostrar que tal truco es factible, o es solo un escenario hipotético que le preocupa un poco? ¿Puede dar una demostración en vivo de este trabajo? Debería intentarlo. Seriamente. Si funciona, debe presentarse a la gerencia y luego sugerir obtener un ofuscador.

Si un ofuscador no es lo suficientemente seguro, ¿ha buscado otras formas de proteger el JAR, tal vez algo como cifrarlo o compilarlo en código nativo?

RE: reelaborando su código: ¿Es solo una cuestión de renombrar? Muchos IDE tienen herramientas de refactorización que pueden hacer esto con bastante facilidad.

Independientemente de cuán valiosa sea su IP, lo inteligente no es destrozar su código con la esperanza de confundir a los piratas informáticos. Además del hecho de que será una pesadilla seguir adelante, en realidad no resuelve ningún problema. Simplemente lo hace más difícil pero no imposible. Por lo tanto, no es realmente una solución y los efectos secundarios son malos. Es como tomar medicamentos que no funcionan y que tienen efectos secundarios negativos.

Su problema es cómo asegurar su IP. Encuentre una solución para eso: ofuscadores, servidor de licencias, etc.

Me encontré con un problema similar cuando otro desarrollador nombró nuestras rutinas de cifrado / descifrado str__copyy str__delete(observe el segundo guión bajo). Era lamentable y podría haberse hecho mejor, así que esperamos hasta que hubo una historia en la que era necesario actualizar la licencia. La gerencia no tuvo problemas con el puñado extra de horas porque lo describimos como "limpiar, así que la próxima vez que entremos en la licencia, tomará menos tiempo y será más seguro". Problema resuelto, sin sentimientos heridos.

Mi primer pensamiento fue el mantenimiento de ese código. Si el código ya está ofuscado y se ha mudado, buena suerte tratando de manejar ese código. Entonces serás el hacker tratando de descifrar el código.

En cambio, recomendaría limpiar el código y usar un ofuscador para hacer todo el trabajo duro. A largo plazo, tendrá un código manejable y dejará toda la complejidad loca a quien quiera hackear su licencia.

Recuerde que ningún obfuscater es perfecto, y un hacker muy decidido puede realizar ingeniería inversa en cualquier cosa, pero al menos solo será él. Además, los ofuscadores añaden mucha más complejidad de la que ese tipo probablemente pueda.

Estoy totalmente de acuerdo con las respuestas de que debe preguntarle a su jefe sobre el tema y hacer lo que él dice.

Sin embargo, una adición muy importante a estas respuestas es que debe documentar sus inquietudes sobre la seguridad y el mantenimiento. Ya sea que cambie o no el código, es importante que las personas sepan qué le preocupa y por qué. Esto es importante tanto de manera proactiva (su jefe no puede tomar una decisión que ni siquiera sabe que debe tomarse) como a la defensiva (si un pirata informático abre agujeros en el sistema de licencias mal asegurado, no puede culparlo por sus Error.)

"No seas el profesional más superior para saber de un problema".

En otras palabras, dile a tu jefe y ve desde allí. Si te quedas callado y eres la parte superior del tótem en ese secreto, cuando te empujen, serás responsable. Dile a tu jefe de pasada y deja que decida una forma de abordarlo. De esa manera, se libera de la carga de la elección.

No se lo diga simplemente a su jefe, porque muchos gerentes tal vez no sean tan técnicos, sino que haga lo que siempre hacemos: dar el problema y las posibles soluciones con las ventajas / desventajas de cada una de esas soluciones. Luego déjelos decidir y haga que eso pase. ¡Es por eso que a los gerentes / líderes se les paga mucho dinero!

La verdad es que, dado el tiempo y los recursos suficientes, todo se puede descifrar. Es una función simple de cuán popular es su aplicación. Cuanto más popular es, los hackers más hábiles atrae y se dedica más tiempo a romperlo. La ofuscación de código proporciona precisamente eso: un medio para aumentar el tiempo requerido para romperlo, de manera similar a la criptografía. Entonces, si su código está ofuscado, requiere que el atacante sea hábil y le dedique tiempo, de lo contrario se desesperará y se dará por vencido. Debe preguntarse si su aplicación vale la pena en ambos extremos.

Es realmente sorprendente lo difícil que puede ser descifrar el código ofuscado. Puede convertir fácilmente un programa simple de 10 líneas C en un ensamblaje de 100 líneas mediante la ofuscación. Si intenta depurarlo, saltará sin sentido en el código y puede ser realmente frustrante recorrerlo. Eventualmente se romperá, pero se vuelve realmente difícil y dado que nada es realmente imposible, ese es el punto. La ofuscación del código reduce la cantidad de personas que pueden descifrarlo.

Claro que hay mejores formas, como tratar de confundir al depurador, no al cracker, pero esta es barata y eficiente. Sin embargo, nombrar cosas torpemente no es suficiente. Debe cambiar las funciones de llamada de flujo de control que realmente no hacen nada por su código general, pero aumentan el tamaño y la complejidad del mismo: llame a funciones ficticias cuyo valor de retorno no se usa en ninguna parte, desde funciones internas que realmente hacen algo. Ya puedes ver cómo esto puede ser realmente confuso.

Tienes algo que el atacante no tiene. El código fuente original. Encuentre una manera de organizarlo mejor para usted.