¿Qué es mejor, un marco establecido o una solución casera?

Ciertamente quieres que tu código sea escrito por el desarrollador más capacitado posible, pero eso no es suficiente. Incluso los desarrolladores más competentes cometen errores (aunque los menos competentes obviamente tienden a cometer más errores).

Para obtener algoritmos y código relativamente libres de errores, debes comenzar con el código más limpio posible, pero eso es solo la mitad del proceso. La mejor manera de eliminar fallas es tener tantos desarrolladores capacitados como sea posible peinar el código buscándolos. Esto se aplica tanto al código como a los algoritmos. Su solución debe ser ampliamente examinada por las personas más experimentadas posibles.

Donde empiezas, el nivel de habilidad del desarrollador original, es solo el punto de partida. Después de una revisión suficiente, realmente no importa la habilidad del desarrollador original.

Así que aquí está la clave: el valor de seguridad en cualquier código está en la forma en que está bien revisado . Ya sea que lo haya escrito usted, un criptógrafo de renombre, una gran corporación o nadie en particular, lo único que importa es cuántos ojos expertos han analizado el código.

Esta regla tiende a favorecer a los marcos establecidos sobre las soluciones caseras. Pero establecido no es necesariamente lo mismo que vetted , que es parte de por qué muchos expertos en seguridad tienden a preferir las soluciones de código abierto: es difícil para un abierto El proyecto fuente se hará popular sin que sea sujeto a una cierta cantidad de escrutinio.

Para un marco homebrew, un programador competente no es suficiente. Necesita un programador competente que tenga tiempo para dedicarse tanto a la implementación como al mantenimiento posterior, y que aún lo hará dentro de diez años. Esto se puede hacer, pero no realmente en un contexto universitario donde los estudiantes van y vienen.

Si se adhiere a un marco establecido, entonces se beneficiará de las actualizaciones de seguridad y del trabajo general del equipo de mantenimiento del marco, lo que facilitará su tarea.

El único punto a recordar es que un framework homebrew no , por sí solo, proporciona seguridad; solo da un sentimiento de seguridad. El razonamiento por lo general sigue las líneas de: "dado que tenemos un marco homebrew, no sufrimos los errores y debilidades conocidos de un marco establecido, y el atacante nunca adivinará dónde están nuestros propios errores". Este razonamiento es defectuoso: el atacante ya conoce su código, posiblemente mejor que usted. Especialmente en una universidad, que, por definición, alberga a muchas personas con conocimientos tecnológicos, con una mentalidad aventurera, una moral flexible y, como regla, mucho más tiempo libre y capacidad de cálculo disponible de lo que puede considerarse saludable. >

Por lo tanto, debes usar un marco establecido.

Tienes dos preocupaciones:

1. Los piratas informáticos que eliminan sus datos detienen el funcionamiento de su servidor web explotando miles de sitios web a la vez.
2. "Destinatarios de piratas informáticos" que desean acceder a su servidor web específicamente para "mayores ganancias", sea lo que sea.

Lo primero no es un problema siempre que tenga implementados planes de recuperación, actualización y respaldo sólidos. Superará el costo de escribir un marco a menos que sea hackeado cada dos días.

El segundo no importará incluso si NO usas un marco. Porque si el incentivo es lo suficientemente alto, todo vale, incluyendo piratería social, compra de exploits de día cero en el mercado negro, etc. Lo que debe hacer es reducir el incentivo. Aislar datos valiosos del servidor web y las debilidades de su marco ya no son importantes.

El problema más grande con un marco homebrew: muy pocos expertos en el código base.

Escribir el propio marco es divertido (bueno, es para el tipo de codificador que disfruta de ese tipo de cosas), pero a menos que la propiedad del código se comparta ampliamente, es un camino peligroso a seguir.

He trabajado en varios lugares donde habían escrito sus propias bibliotecas de marcos. Normalmente, el marco en sí ha sido escrito casi en su totalidad por uno o dos desarrolladores. Los jefes están convencidos de que el código del marco era un activo valioso, y los desarrolladores principales que conocen el código al revés son virtualmente irremplazables.

El problema es que en todos los casos que he visto, el código está lleno de errores, agujeros de seguridad y malas prácticas. Cuando el desarrollador principal finalmente se va, sus sucesores se quedan para recoger las piezas. A veces simplemente luchan con el código existente; a veces emprenden un proyecto de reingeniería a gran escala; a veces cambian a un marco de terceros.

El otro problema que suele ocurrir es que la tecnología y los requisitos del usuario continúan. Si ha escrito su propio marco, debe seguir trabajando en él constantemente para mantenerlo actualizado. Esto está bien si el marco es su proyecto principal, pero si es solo su código de back-end, consumirá su tiempo que sería mejor gastar trabajando en su proyecto real.

Finalmente, seguridad. Este es el grande, de verdad. Muchos, muchos desarrolladores competentes han escrito código que es inseguro. De hecho, si somos honestos, todos lo tenemos. Java no fue escrito por incompetentes y, sin embargo, Oracle tuvo que emitir un parche para cincuenta agujeros de seguridad esta semana. Cada otra pieza de software que podría nombrar tiene agujeros también, y probablemente todavía tenga agujeros. Al escribir su propio marco, categóricamente no va a escribir algo más seguro que cualquiera de los conocidos marcos de terceros. De hecho, es probable que sea significativamente peor, y no tendrá los recursos para buscar errores de seguridad. Tendrá "seguridad por oscuridad" porque nadie habrá visto su código, pero solo necesita buscar esa frase en google para ver qué piensa el mundo de la seguridad al respecto.

En resumen, diría que no; un marco de fabricación casera no es una buena idea.

Siga adelante y escriba uno de todos modos, es un gran ejercicio de aprendizaje, pero no espere que sea tan bueno como los marcos ya existentes. Si fuera tan fácil, no habría ninguna necesidad de las bibliotecas existentes.

Como esbozado por otros, el marco respaldado, examinado y mantenido será casi siempre mejor que una solución 'homebrew'. Esto es especialmente cierto en el contexto de la Universidad, donde el trabajo a menudo se realiza inicialmente como un proyecto y luego persiste con fondos y apoyo insuficientes para los años posteriores. Siempre que se apliquen los paquetes de seguridad al trabajo, al menos puede mantener cierto nivel de confianza. Lo mismo no puede decirse de un sistema homebrew. Dado que la seguridad es una fiesta en evolución y en movimiento, necesita esto.

La única advertencia que tendría con respecto a los marcos establecidos es garantizar que elija el marco adecuado para la tarea. Algunos marcos son enormes, extremadamente complejos y requieren conocimientos especializados y experiencia para usarlos correctamente. Un marco seguro y bien diseñado no será beneficioso si es implementado o utilizado por desarrolladores inexpertos. Además de considerar los aspectos de seguridad de su marco, también considere los conjuntos de habilidades de sus desarrolladores y busque un marco que proporcione solo la funcionalidad que desea y no muchas características adicionales que no necesita y que probablemente no se configurará correctamente .