La inseguridad basada en ejemplos ilustra la necesidad de un WAF.

Aprender en línea es muy importante. Especialmente para aquellos que se identifican como desarrolladores. Si echas un vistazo a la encuesta anual para desarrolladores de Stack Overflow (en la que obtienen decenas de miles de respuestas), encontrarás una buena parte de desarrolladores que no reciben capacitación formal:

• Entre los desarrolladores profesionales actuales a nivel mundial, el 76,5% de los encuestados afirmó tener una licenciatura o un título superior, como una maestría o equivalente.
• El 20,9% afirmó haber estudiado otros campos, como negocios, ciencias sociales, ciencias naturales, ingeniería no informática o artes.
• Del total de desarrolladores profesionales actuales, el 32% dijo que su educación formal no era muy importante o no era importante en absoluto para su éxito profesional. Esto no es del todo sorprendente dado que el 90% de los desarrolladores en general se consideran al menos algo autodidactas : un título formal es solo un aspecto de su educación y gran parte de su trabajo práctico diario depende de las decisiones individuales sobre la pila tecnológica de su empresa.

Tenga en cuenta la parte resaltada de los resultados de la encuesta. Podría escribir una tesis sobre por qué esto es cierto, pero basta con decir que cuando estudiaba para mi licenciatura, escribí en Pascal, C++ y LISP. Mi primer trabajo de desarrollo real requería C/C++, así que me fue bien allí. Pero después me pidieron que aprendiera Java. Y SQL. No volví a la escuela para hacer eso. Recurrí a libros, archivos de ayuda y cualquier otra documentación que pude conseguir. El autodidacta es la norma, independientemente de si tienes educación formal o no, porque la tecnología cambia y los profesionales no tienen tiempo para volver a la escuela solo para aprender un nuevo lenguaje o marco de trabajo.

Sospecho que esto no es nada raro para ninguno de nosotros. No volvemos a la universidad para aprender una nueva CLI o API. No nos matriculamos en una nueva carrera solo para aprender Python o Node.js. Recurrimos a libros y contenidos de Internet, a comunidades y nos apoyamos en gran medida en el “código de ejemplo”.

Todavía dependo de los blogs y la documentación, no sólo de nuestros propios ingenieros y arquitectos, sino también de otras personas. Porque inscribirme ahora en un doctorado realmente no me va a ayudar a aprender* los entresijos del framework Express o JQuery .

No es de sorprender entonces que los ingenieros y operadores de redes (quienes, al ser parte de la primera parte de la segunda ola de DevOps, de ahora en adelante serán conocidos como NetOps) probablemente también recurran a los mismos tipos de materiales para obtener las habilidades que necesitan para ser competentes en las herramientas y tecnologías requeridas. Estos son lenguajes de programación y API, para aquellos que recién se están conectando. Y ellos también, sin duda, copiarán y pegarán con todo su corazón a medida que se familiaricen con el lenguaje y los sistemas que comienzan a automatizar el proceso de producción .

Y así llegamos al motivo por el que escribo hoy. Código de ejemplo.

Hay mucho de eso. Y es buen código, no te vayas pensando que no lo aprecio o que no valoro el código de ejemplo. Es un recurso invaluable para cualquiera que intente aprender nuevos lenguajes y API. Lo que voy a criticar es que hay una desconexión entre el código de ejemplo y la seguridad que debe abordarse. Porque mientras enseñamos a codificar a gente nueva, también deberíamos inculcarles al menos una conciencia de seguridad, en lugar de ignorarla descaradamente.

Digo esto porque la seguridad de la aplicación no es (repito, NO es) opcional . Podría lanzar estadística tras estadística tras estadística, pero espero que en este punto esté predicando a los ya convencidos. La seguridad de las aplicaciones no es opcional y es importante promover esa actitud hasta que se la considere parte integral del desarrollo. No solo aplicaciones, sino también scripts y sistemas que impulsan la automatización al alcance de DevOps y NetOps.

Presento como fuente de mi angustia este ejemplo. 

El código en sí es hermoso. En realidad. Bien formateado, buen espaciado. Legible. Me encanta este código. Excepto la parte que viola completamente la Regla de Seguridad Cero .

NO DEBERÁS CONFIAR EN LA APORTACIÓN DEL USUARIO. ALGUNA VEZ.

Me desilusiona que ni siquiera haya una señal de la necesidad de desinfectar la información de entrada. Ni en los comentarios ni en el texto del artículo. El código simplemente pasa el “nombre de usuario” a otra función sin ninguna preocupación de que pueda contener contenido malicioso.

Pero Lori, obviamente este código está destinado a ilustrar la implementación de algo que no está diseñado para entrar en producción. No es un riesgo

Ese no es el punto. La cuestión es que si continuamos enseñando a la gente a codificar, al menos deberíamos intentar enseñarles a hacerlo de forma segura . Mencionarlo tan rutinariamente como uno le señala a los desarrolladores nuevos en C/C++ que si no asigna memoria a un puntero antes de acceder a él, este se bloqueará.

Podría llenar blog tras blog con ejemplos de cómo se habla mucho de seguridad y de SDLC, pero cuando se trata de lo esencial y de enseñar a la gente a codificar, de repente está solo en un rincón con un campo SEP (problema de otro) a su alrededor.

Esta es otra razón por la que los firewalls de aplicação web son un componente fundamental para cualquier estrategia de seguridad de aplicaciones. Las organizaciones necesitan un cortafuegos entre la entrada del usuario y las aplicaciones que la aceptan ciegamente como legítima para evitar convertirse en la última víctima de una larga lista de agujeros de seguridad en las aplicaciones.

Porque por mucho que nos guste hablar sobre cómo proteger el código, cuando realmente lo enseñamos a otros no lo hacemos. Debemos ser más conscientes de esta falta de atención a la seguridad, incluso en el código de ejemplo, porque ahí es donde aprenden los desarrolladores (y cada vez más, NetOps), pero hasta que comencemos a hacerlo, necesitamos soluciones de seguridad como WAF para llenar los vacíos que deja el código inseguro.
 

*O inglés, aparentemente. Oh, vamos, lo hago a propósito. Porque a veces es divertido decirlo mal.