Enseñar a un ser querido sobre prácticas seguras de codificación

Yo diría que una excelente manera de aprender es que ella rompa las aplicaciones que ya ha escrito.

Suponiendo que esté escribiendo aplicaciones web, apúntela hacia el Top 10 de OWASP. Haga que vea si puede encontrar alguna de esas fallas en su propio código. No hay mejor manera de aprender sobre conceptos de seguridad que ver cómo sucede en su propio código.

Una vez que se haya encontrado una falla, pídale que vuelva a escribir la aplicación para corregir la falla. Hacerlo le permitirá apreciar el efecto de cosas como el saneamiento y la validación de las entradas de los usuarios y las consultas parametrizadas.

Da pasos incrementales. No me atrevería a diseñar una nueva aplicación teniendo en cuenta la seguridad antes de comprender realmente qué tipo de códigos producen fallas de seguridad.

Voy a tomar la posición que pueda llamarme ...

El problema que veo, es que la programación segura se enseña como un complemento. Las mejores prácticas deben enseñarse desde el principio (incluida la seguridad). La mentira que se enseña a la gente es que la práctica hace prefecto. La verdad es que la práctica se hace permanente. Entonces, si lo estás haciendo mal, tienes que desaprender lo que has aprendido. Ese es un enfoque de bajistas.

Yo diría que las prácticas de codificación seguras deben enseñarse desde el primer día. No hay razón para aprender cómo hacerlo, y luego aprender a hacerlo de manera segura. Es una pérdida de tiempo y dinero ...

Mis 2 bits, 1 y cero más para decir ...

Aunque en principio estoy de acuerdo con Everett, hay otro punto de vista. El objetivo de una lección es aprender un concepto, que luego se puede desarrollar. Esto disminuye la pendiente de la curva de aprendizaje. Enseñar demasiado rápido es abrumador; cuando se enfrentan a una avalancha de información, la mayoría de los cerebros "se filtran".

Es genial decir que "las prácticas de codificación seguras deben enseñarse desde el primer día", y es muy difícil demostrar cómo ese programa "Hola Mundo" de un día puede ser vulnerable, especialmente cuando "qué es un programa de computadora" es un nuevo Concepto para la clase. Un proyecto de sitio web que toque almacenes de datos compartidos (que realmente no vi hasta la mitad de la universidad) es más fácil de mostrar debilidades, pero a menudo esas debilidades son inherentes a la configuración de un entorno web de prueba de concepto básico con el " configuración por defecto. Es muy fácil probar que una aplicación tiene vulnerabilidades, cuando se conocen las vulnerabilidades. Es más difícil (realmente imposible) demostrar que no existe.

Pienso de manera similar al OP; en algún momento del desarrollo de un programador, la idea de "cómo alguien puede usar este código para hacer cosas que no quiere que hagan y cómo puede evitarlo" puede fusionarse con lo que está haciendo. Es probable que ese punto de inicio sea en algún lugar que comience a aprender acerca de la comunicación externa o la persistencia (leer / escribir datos en un disco duro o base de datos, o enviarlos a través de un canal de red), o los principios orientados a objetos (herencia, sobrecarga / anulación, etc), lo que ocurra primero. Aquí es donde un programador puede comenzar a escribir programas que tienen el poder de hacer daño en las manos equivocadas y, por lo tanto, se debe tener cuidado para asegurarse de que las manos equivocadas no puedan utilizar mal el programa.

Algunos conceptos son fáciles de entender; "Mi programa trabaja con datos que son un secreto de sus usuarios; se me confía y debo garantizar que solo aquellos que deberían ver los datos tengan permiso para hacerlo". Algunos son más difíciles; He visto personas que realmente se sorprenden al descubrir que los binarios del programa se pueden descompilar y leer para descubrir credenciales o claves codificadas (y que algunos entornos como .NET ponen metadatos suficientes en los binarios para producir casi exactamente el mismo código fuente utilizado para compilar ellos), o que su binario ensamblado puede ser superpuesto en su forma compilada por un atacante que se conecta utilizando clases o miembros públicos sin sellar, y luego tiene acceso a cualquier secreto con el que esas clases trabajen. Estos son los errores básicos que se deben ilustrar, y luego se deben ilustrar las soluciones a ellos, y cómo y por qué funcionan.

Al igual que otros aspectos de una educación real (quizás esto debería ser más en Parenting.SE ...), creo que se trata de pensamiento crítico .

Mi hija también está tomando algunos cursos universitarios de CS, y la estoy ayudando a trabajar en ellos. Sin embargo, no le doy la información con una cuchara, ella necesita trabajar para ello.
En muchos casos, le explico algo muy incorrecto y espero que me llame. (Ella usualmente lo hace). A veces, solo es sutilmente incorrecto, y luego es más difícil para ella darse cuenta. A veces, no lo nota de inmediato y comienza a construir algo basado en una suposición errónea, luego tiene que trabajar hacia atrás para encontrar el problema. (Ella también está mejorando en eso).

De esta manera, la obligo a acostumbrarse a cuestionar suposiciones.
Es cierto que ella no está emocionada con mis métodos.

De la misma manera, le pido que detecte cualquier forma en que su código pueda ser mal utilizado, ya sea accidental o maliciosamente. Le expliqué que ella es propietaria de su código y es responsable de lo que hace su código , no hay lugar para la pasividad aquí. Parte de esto es el manejo adecuado de excepciones, que sus instructores esperan que hagan de todos modos, incluso sin llegar a eso hasta cursos mucho más tarde.

Ahora, por supuesto, me opongo a todas las formas de enseñar "programación de cultos de carga" - a menos que se indique explícitamente como tal , para permitir que se enseñen los conceptos básicos, con la advertencia de que es No toda la historia y volveremos a esto más tarde. (Como el manejo de excepciones anterior).

Lo que quiero decir de todo esto es que "programación segura" no es diferente de "programación" .
Sin embargo, al igual que todo el Libro de Programación no se puede enseñar en una sola sesión de una vez, pero los conceptos se introducen gradualmente, los aspectos de "seguridad" de los conceptos de programación podrían esperar, mientras que el concepto básico se enseña y se entiende, con la explicación explícita. tenga en cuenta que "no hemos terminado aquí todavía". También la expectativa de que al menos los mejores estudiantes descubrirían algunos de los aspectos inseguros.

TL; DR :

1. Un nuevo concepto de programación debe aprenderse gradualmente, algunos aspectos (incluida la seguridad) pueden enseñarse más tarde que otros;
2. Dicho concepto de programación no está completo hasta que todos los aspectos se aprenden y se comprenden, incluidos los aspectos de seguridad (y se deben tener en cuenta hasta entonces);
3. Los programadores tienen control total sobre su código, y para ser un programador, uno necesita saber cómo se puede usar mal el código;
4. Los estudiantes que practican el pensamiento crítico deben resolver esto por sí mismos desde el principio (no necesariamente todos de seguridad, sino el contexto que falta, y una buena parte del uso incorrecto del código);
5. Los estudiantes que no practican el pensamiento crítico realmente no deberían estar aprendiendo programación ...

Creo que, en última instancia, todo se reduce a tratar de averiguar en qué punto la educación de seguridad no confunde el punto de la lección. Las asignaciones de lecciones generalmente son problemas simplificados diseñados para exponer un problema en particular y mostrar cómo resolver ese problema en particular.

Creo que la forma más ideal de abordarlo es comenzar haciendo que ella haga algo como hackthissite.org para saber cuántos ataques funcionan y cuales son los peligros Tener una buena apreciación de cómo se puede subvertir el código es una excelente manera de ayudar a alguien a comprender la importancia de las prácticas de codificación seguras. Hacerlo en paralelo significa que no ocultará los temas que intentan abordar sus instructores, al tiempo que muestra cuáles son los problemas de seguridad.

Desde mi punto de vista, como analista de sistemas, hay una manera: debe enseñar a los alumnos de primer grado un concepto de estandarización, clasificación y comparación de patrones. Las siguientes preguntas son fáciles y se pueden presentar al comienzo ...

• Piense en "toda la entrada de datos posible", que el usuario puede ingresar, y cree una lista estricta de ellos.
• Aprender / enseñar expresiones regulares. Esta herramienta se puede utilizar para la comparación y el saneamiento.
• Principio de "valores predeterminados", si faltan datos de entrada o no son válidos.
• Usa archivos de registro. Si existe alguna duda o inconsistencia en la entrada, el software debe usar algún tipo de registro para "anotarlo". Los archivos de registro son una de las mejores formas de depurar y descubrir agujeros de seguridad, que alguien podría usar o ya está usando.
• Utilice mensajes de error y casos de error. Piense en los casos, cuando el sistema podría fallar y piense en el número de error apropiado y el mensaje detallado. Algunos errores podrían llevar a dos mensajes de error detallados diferentes, uno para el usuario, sencillo y otro para el propietario del sistema, con fines de depuración o seguridad.

El usuario siempre es "malo", el usuario siempre quiere romper su software; nunca le dé más información a la que pide, y si pregunta, siempre verifique si tiene el privilegio de recibir incluso una respuesta simple. "No tiene acceso": los mensajes de error pueden ayudar a un pirata informático a comprender el estado del sistema que está intentando romper.

Podría pensar en más, pero esto puede y debe ser considerado desde el principio.