ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

OWASP Top 10 Controles proactivos 2016


Enviado por   •  16 de Noviembre de 2016  •  Trabajos  •  1.997 Palabras (8 Páginas)  •  518 Visitas

Página 1 de 8

OWASP Top 10 Controles proactivos 2016

El Proyecto Open Web Application Security (OWASP) es un programa educativo sin fines de lucro 501c3 caridad dedicada a permitir a las organizaciones diseñar, desarrollar, adquirir, operar y mantener software seguro. Todas las herramientas, documentos, foros y capítulos de OWASP son gratuitos y abiertos a cualquier persona interesada en mejorar la seguridad de la aplicación. Podemos encontrar en www.owasp.org .

OWASP es un nuevo tipo de organización. Nuestra libertad frente a presiones comerciales nos permite proporcionar información imparcial, práctica y rentable sobre la seguridad de las aplicaciones. OWASP no es afiliado con cualquier compañía de tecnología. Al igual que muchos proyectos de software opensource, OWASP produce muchos tipos de materiales de una manera colaborativa y abierta. La Fundación OWASP es una entidad no lucrativa que asegura el éxito a largo plazo del proyecto.

Los diez principales controles proactivos 2016 de OWASP son una lista de conceptos de seguridad que deben ser incluido en cada proyecto de desarrollo de software. Se ordenan por orden de importancia, siendo el número 1 el más importante.

 

1. Verificar la seguridad temprano y frecuentemente

2. Parametrizar consultas

3. Codificar datos

4. Validar todas las entradas

5. Implementar controles de identidad y autenticación

6. Implementar controles de acceso apropiados

7. Proteger datos

8. Implementar el registro y la detección de intrusos

9. Aprovechar los marcos de seguridad y bibliotecas

10. Manejo de errores y excepciones

1: Verificar la seguridad temprano y frecuentemente.

 

En muchas organizaciones, las pruebas de seguridad se realizan fuera de los bucles de pruebas de desarrollo, enfoque "scanthenfix". El equipo de seguridad ejecuta una herramienta de escaneo o realiza una prueba de pluma, los resultados, y luego presenta al equipo de desarrollo una lista de vulnerabilidades que se deben corregir. Esto es a menudo referido como "la rueda del hámster del dolor". Hay una mejor manera.

 

Las pruebas de seguridad deben ser parte integral de la práctica de ingeniería de software de un desarrollador. Sólo como no se puede "probar calidad en", no se puede "probar la seguridad" haciendo pruebas de seguridad al final de un proyecto. Es necesario verificar la seguridad con anticipación ya menudo, ya sea mediante pruebas manuales o pruebas automatizadas y escaneos.

2: Parametrizar consultas.

 

SQL Injection es uno de los riesgos más peligrosos en las aplicaciones web. SQL Injection es fácil de explotar con muchas herramientas de código abierto de ataque automatizado disponibles. La inyección SQL también puede ofrecer un impacto a su aplicación que es devastador.

 

La simple inserción de código SQL malicioso en su aplicación web - y toda la base de datos podrían ser robados, borrados o modificados. La aplicación web puede incluso utilizarse para ejecutar peligrosos comandos del sistema operativo contra el sistema operativo que aloja su base de datos. La principal preocupación con la inyección de SQL es el hecho de que la consulta SQL y sus parámetros son contenidos en una cadena de consulta.

 

Con el fin de mitigar la inyección de SQL, se debe impedir que la entrada no confiable sea interpretada como parte de un comando SQL. La mejor manera de hacerlo es con la técnica de programación conocida como 'Parametrización de la consulta'. En este caso, las sentencias SQL son enviadas y analizadas por el servidor de base de datos por separado de cualquier parámetro. 

3: Codificar datos.

 

La codificación es un poderoso mecanismo para ayudar a proteger contra muchos tipos de ataques, especialmente ataques de inyección. Esencialmente, la codificación implica traducir caracteres especiales en equivalente que ya no es peligroso en el intérprete objetivo. La codificación es necesaria para detener varias formas de inyección incluyendo la inyección de comandos (codificación de comando Unix, Windows codificación de comandos), inyección LDAP (codificación LDAP) e inyección XML (codificación XML).

Otro ejemplo de codificación es la codificación de salida que es necesaria para evitar que el sitio cruzado scripting (codificación de entidad HTML, codificación hexadecimal de JavaScript, etc.). 

4: Validar todas las entradas.

 

Cualquier dato que sea ingresado directamente por, o influenciado por, usuarios debe ser tratado como no confiable. Una aplicación debe comprobar que estos datos son tanto sintáctica como semánticamente válida (en qué orden) antes de usarlo de ninguna manera (incluyendo mostrarlo de vuelta al usuario). Además, las aplicaciones seguras tratan todas las variables como no confiables y proporcionan controles de seguridad independientemente de la fuente de esos datos.

 

Validez de sintaxis significa que los datos están en la forma que se espera. Por ejemplo, una aplicación puede permitir que un usuario seleccione un "ID de cuenta" de cuatro dígitos para realizar algún tipo de operación. La aplicación debe asumir que el usuario está ingresando una carga útil de la inyección de SQL, y debe comprobar que los datos introducidos por el usuario son exactamente cuatro dígitos de longitud, y consiste sólo de números (además de utilizar la parametrización de consulta adecuada).

5: Implementar controles de identidad y autenticación.

 

La autenticación es el proceso de verificar que un individuo o una entidad es quien afirma ser. La autenticación se realiza normalmente enviando un nombre de usuario o ID y uno o más elementos de información privada que sólo un usuario dado debe saber.

 

Gestión de sesiones es un proceso por el cual un servidor mantiene el estado de una entidad que interactúa con eso. Esto es necesario para que un servidor recuerde cómo reaccionar a las solicitudes posteriores durante una transacción. Las sesiones se mantienen en el servidor mediante un identificador de sesión que puede pasar entre el cliente y el servidor al transmitir y recibir peticiones. Las sesiones deben ser únicas por usuario y computacionalmente imposibles de predecir.

...

Descargar como (para miembros actualizados)  txt (12.9 Kb)   pdf (139 Kb)   docx (15 Kb)  
Leer 7 páginas más »
Disponible sólo en Clubensayos.com