Cómo diseñar formularios web seguros: validar, desinfectar y controlar

Si bien la ciberseguridad a menudo se considera en términos de bases de datos y arquitectura, gran parte de una postura de seguridad sólida se basa en elementos del dominio del desarrollador de front-end.

Para ciertas vulnerabilidades potencialmente devastadoras como la inyección SQL y Cross-Site Scripting (XSS), una interfaz de usuario bien considerada es la primera línea de defensa.

Aquí hay algunas áreas de enfoque para los desarrolladores front-end que desean ayudar a luchar por el buen camino.

Controlar la entrada del usuario

Pueden suceder muchas cosas locas cuando los desarrolladores crean un formulario que no controla la entrada del usuario. Para combatir vulnerabilidades como la inyección, es importante validar o desinfectar la entrada del usuario.

Puede validar la entrada restringiéndola a valores conocidos, como mediante el uso de tipos de entrada semántica o atributos relacionados con la validación en formularios. Los marcos como Django también ayudan al proporcionar tipos de campo para este propósito. La desinfección de datos se puede realizar eliminando o reemplazando caracteres contextualmente peligrosos, como mediante el uso de una lista blanca o el escape de los datos de entrada.

Si bien puede no ser intuitivo, incluso los datos que un usuario envía a su propia área en un sitio deben validarse. Uno de los virus más rápidos en proliferar fue el gusano Samy en MySpace (sí, soy viejo), gracias al código que Samy Kamkar pudo inyectar en su propia página de perfil. No devuelva directamente ninguna entrada a su sitio sin una validación o desinfección exhaustivas.

Para obtener más orientación sobre cómo combatir los ataques de inyección, consulte la Hoja de trucos para la prevención de inyecciones de OWASP.

Cuidado con los campos ocultos

Agregar type="hidden"es una forma tentadoramente conveniente de ocultar datos confidenciales en páginas y formularios, pero desafortunadamente no es eficaz.

Con herramientas como ZapProxy e incluso herramientas de inspección en navegadores web simples, los usuarios pueden hacer clic fácilmente para revelar sabrosos fragmentos de información invisible.

Ocultar casillas de verificación puede ser un truco genial para crear conmutadores solo de CSS, pero los campos ocultos contribuyen poco a la seguridad.

Considere cuidadosamente los campos de autocompletar

Cuando un usuario elige brindarle su información de identificación personal (PII), debe ser una elección consciente. Los campos de formulario de autocompletar pueden ser convenientes, tanto para usuarios como para atacantes. Los exploits que utilizan campos ocultos pueden recopilar PII previamente capturados por un campo de autocompletar.

Muchos usuarios ni siquiera saben qué información ha almacenado el autocompletado de su navegador. Utilice estos campos con moderación y desactive los formularios autocompletados para datos especialmente confidenciales.

También es importante sopesar su perfil de riesgo con sus compensaciones. Si su proyecto debe ser compatible con WCAG, deshabilitar el autocompletado puede romper su entrada para diferentes modalidades. Para obtener más información, consulte 1.3.5: Identificar el propósito de entrada en WCAG 2.1.

Mantenga los errores genéricos

Si bien puede parecer útil que los usuarios sepan si existe un dato, también es muy útil para los atacantes. Cuando se trata de cuentas, correos electrónicos y PII, es más seguro equivocarse (?) Por el lado de menos. En lugar de devolver "Su contraseña para esta cuenta es incorrecta", pruebe la respuesta más ambigua "Información de inicio de sesión incorrecta" y evite revelar si el nombre de usuario o el correo electrónico están en el sistema.

Para ser más útil, proporcione una forma destacada de contactar a un humano en caso de que surja un error. Evite revelar información que no sea necesaria. Si nada más, por el amor de Dios, no sugiera datos que coincidan con la entrada del usuario.

Ser un chico malo

Al considerar la seguridad, es útil dar un paso atrás, observar la información que se muestra y preguntarse cómo podría utilizarla un atacante malintencionado. Juega al abogado del diablo. Si un chico malo viera esta página, ¿qué información nueva obtendría? ¿La vista muestra alguna PII?

Pregúntese si todo en la página es realmente necesario para un usuario genuino. Si no es así, edítelo o elimínelo. Menos es más seguro.

La seguridad comienza en la puerta principal

En estos días, hay mucha más superposición entre la codificación en el front-end y el back-end. Para crear una aplicación completa y segura, es útil tener una comprensión general de las formas en que los atacantes pueden entrar por la puerta principal.