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

37

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?

Neil
fuente
44
Si su pregunta es sobre cómo manejar la política de esta situación, muchas de las respuestas aquí apuntan en la dirección correcta, pero si, como sugiere un comentario suyo, realmente desea una mejor alternativa para proponer, es posible que desee verificar respuestas a esta pregunta: stackoverflow.com/questions/6018215/…
Mark Booth
8
Si un pirata informático con acceso a su código fuente limpio puede piratear su autenticación, entonces es pirateable, punto. Ninguna cantidad de ofuscación ayudará. Si buscas una solución que detenga a algunos piratas informáticos, entonces, además de la ofuscación, es posible que también quieras usar algunas de sus prácticas de dirección errónea (esconde cosas en clases poco probables que no se puedan reemplazar fácilmente). Las actualizaciones frecuentes que cambian por completo su práctica de autenticación también ayudan. Muchos usuarios se cansan de confiar en los piratas informáticos y simplemente lo compran.
Bill K
2
¿Estaba cambiando el nombre de los locales? Si es así, está perdiendo el tiempo: de todos modos, no existen como variables con nombre en el código compilado.
Nick Johnson el
1
Se llama "ofuscación" y, aunque se usa con más frecuencia en estos días, ¡no es a prueba de completo! ... aunque retrasará que alguien descifre el código, ¡puede descifrarlo! ... lo que me gustaría ver es un compilador ¡eso puede encriptar el código objeto y solo ejecutarse con la clave correcta, de modo que incluso alguien con un editor de discos, desensamblador o cualquier otra herramienta de craqueo nunca podrá sacar cara o cruz!
Frank R.
66
"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". y "Primero déjame decirte que es un tipo inteligente" ¡no te va bien en el mismo párrafo!
devorado elysium

Respuestas:

94

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.

wolfgangsz
fuente
31
+1 La ofuscación NO es seguridad, solo una manta de confort.
uɐɪ
77
Si puede encontrar una solución mejor que la ofuscación, entonces marcaré su respuesta como la correcta. ¿Cómo puede garantizar que alguien con acceso al archivo war no pueda modificar su funcionalidad al menos en lo que respecta a las licencias?
Neil
55
No puede garantizarlo en absoluto cuando alguien tiene acceso a los archivos. Pero la verdad es que: el mecanismo más simple evita que el 99,99% de los usuarios dañen su software. Un hacker dedicado y experto SIEMPRE encontrará una manera de eludir la seguridad de la aplicación. Sin embargo, puede cambiar a verificación remota, por lo que su programa solo se ejecutará cuando se autentique en un servicio suyo. Para que eso sea seguro, debe cifrar todo el programa y tener algún tipo de gestor de arranque. PERO: si alguien tiene una clave válida, puede volver a aplicar ingeniería inversa al software de todos modos.
Falcon
77
@Neil: Implemente la lógica empresarial central en un microcontrolador conectado como un dongle USB. No dijiste que tiene que ser barato o fácil de implementar;)
SF.
8
@SF.: Touche. Creo que debería requerir tres satélites para conectarse simultáneamente, solo por el placer de hacerlo. ;)
Neil
84

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.


fuente
8
Mi jefe no es programador y probablemente me resulte difícil explicar por qué deberíamos invertir tiempo y dinero en hacer algo que finalmente no modifique el comportamiento del programa de ninguna manera.
Neil
15
@Neil: ... ¿entonces quizás es hora de presentarle a su jefe el concepto de "costos de mantenimiento"?
SF.
21
¿Se convertirá en la respuesta predeterminada a cada pregunta sobre los compañeros de trabajo o el entorno laboral? Sé que algunas protuberancias tuvieron que ir y decirte que publiques esto como respuesta, pero vamos, no es una respuesta. Esta es en realidad una pregunta semi-decente (aunque torpemente redactada) sobre los problemas de seguridad a través de la oscuridad; Esta "respuesta" es insultante.
Aaronaught
8
@Aaronaught. Esta respuesta es fundamental cuando se trata de "la implementación A es mala, sugiero que hagamos la implementación B" porque es necesario realizar un trabajo adicional (equivalente a dinero). Si hubiera sido una elección entre implementar A o B, la respuesta habría sido diferente. Le sugiero que abra una pregunta sobre meta si desea una respuesta más detallada.
22
"¿Se convertirá en la respuesta predeterminada a cada pregunta sobre los compañeros de trabajo o el entorno laboral?" Por qué no? Si esto fue redactado como una pregunta técnica .eg "¿Qué es mejor? Ofuscación automatizada v ofuscación codificada a mano (= mala práctica)", entonces esa es una pregunta completamente diferente, y merece una discusión técnica. Todo "¿Debo arreglar esto detrás de mis compañeros de trabajo?" las preguntas finalmente se reducen a "No, tráelo a la atención del equipo / poder superior"
Binary Worrier
13

¿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.

DKnight
fuente
Luego, cuando pesque en estas clases en el futuro, supongo que me taparé la nariz.
Neil
3
Cuando tienes una responsabilidad directa por ese código, entonces está bien alterarlo a tu gusto, pero si hay una responsabilidad conjunta, necesitarás a alguien para arbitrar. Es fácil dañar las relaciones laborales y perder el tiempo en situaciones como esta, mejor no hacer un problema si es posible. Si es necesario resolver un problema, elimínelo lo antes posible.
DKnight
6

¿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.

Catchops
fuente
Sin duda un enfoque encomiable. Noté la modificación del código yo mismo, actualizando mi código desde SVN. Aunque es probable que, si no está de acuerdo, convencer a mi jefe de que tome estas precauciones de seguridad probablemente no genere ningún cambio, ya que el programador podría argumentar que ya "funciona".
Neil
2

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.

usuario281377
fuente
1
No puedo decirte cuánto me molesta, aunque probablemente tengas razón en que tendré que vivir con eso.
Neil
2

¿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.

FrustratedWithFormsDesigner
fuente
Me parece un poco paranoico, aunque puedo ver por qué. Si el producto fuera pirateado, probablemente significaría su trabajo. No diré que es posible, pero sé lo suficiente como para saber cómo puede buscar nombres de métodos y si hubiera un método obvio llamado "isLicenseValid", sería cuestión de escribir una clase que tenga este método y siempre regrese fiel a 'hackearlo. Creo que este programa es bastante complicado sin complicarlo aún más, aunque parece querer estar seguro de ello. Creo que podría arreglar su código fácilmente renombrándolo, sí.
Neil
El hecho de que tenga un método llamado "isLicenseValid" no significa que pueda ser pirateado simplemente escribiendo una clase con el mismo método. Si marca su clase como "sellada" (esa es la sintaxis de C #), los terceros no pueden eludir sus controles de seguridad escribiendo subclases y anulando su método. En cualquier caso, a menos que este tipo sea el oficial de seguridad de la compañía, ¿por qué significaría su trabajo si el producto es pirateado?
Tundey
2
@Tundey, no se trata de subclases (¿cómo se cargarían?): Se trata de escribir la misma clase y poner la versión pirateada antes en la lista de búsqueda de classpath.
Peter Taylor
1
ja. Recuerdo las alegrías de la carga de clases en Java. Todavía tiene que haber una mejor manera de mitigar eso. En realidad, si su cargador de clases no se ve comprometido, ¿cómo puede alguien escribir una clase que sea igual a su clase? ¿Especialmente si su JAR está firmado? ¿Firmar sus JAR y sellar sus clases no resolvería el problema de que alguien escriba una clase con el mismo nombre que el suyo?
Tundey
1
@Tundey the Sun JVM es (principalmente) de código abierto, puede modificarlo.
Spudd86
2

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.

Tundey
fuente
Estoy de acuerdo contigo 110%. En lo que respecta a la seguridad de la IP, es una protección para nuestro cliente, ya que es su máquina la que ejecuta la aplicación web, no la nuestra, aunque usted hace un punto válido. Estaba más preocupado por el cliente que tiene acceso directo a nuestro producto en su máquina y puede distinguirlo. Un servidor de licencias es tan bueno como la seguridad del cliente. Si puede evitar el acceso al servidor de licencias, ningún truco en el libro le impedirá usar el programa sin licencia.
Neil
1

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.

Christopher Bibbs
fuente
Bueno, por supuesto, siempre podemos cambiarlo más tarde, aunque creo que el cambio debe estar en la cabeza más que el código.
Neil
1
@Neil Entonces te sugiero que seas tú quien necesita el cambio en la cabeza. Si el código funciona, tiene pruebas adecuadas y está bien comentado, ir en esa ruta en lugar de usar y ofuscador no es la mejor opción, pero tampoco es el fin del mundo. Solucionelo más tarde si es un problema y simplemente continúe de lo contrario.
Christopher Bibbs
@Christopher_Bibbs: tranquiliza tu mente. Es casi seguro que puedo asegurarle que, de hecho, eventualmente presentará un problema.
Neil
1

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.

Steph
fuente
0

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.)

jhocking
fuente
0

"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!


fuente
0

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.

usuario66734
fuente