View
42
Download
4
Category
Preview:
DESCRIPTION
Seguridad en redes
Citation preview
Seguridad de la Informacin
Agenda 1. Seguridad de la Informacin
1.1. Introduccin
1.2. Estndares y Buenas Prcticas
1.3. Leyes y Regulaciones de Ecuador
2. Desarrollo Seguro de Software
2.1. Importancia del Software
2.2. Ambientes vs. Aplicaciones
2.3. Funcionalidad vs. Seguridad
2.4. Ciclo de Vida de Desarrollo de Sistemas
2.5. Ciclo de Vida de Desarrollo de Software
2.6. Seguridad Web
2.7. Amenazas Especficas para Ambientes Web
2.8. Principios de Seguridad para Aplicaciones Web
Agenda 3. Top Ten de Owasp
3.1. Injection
3.2. Broken Authentication and Session Management
3.3. Cross-Site Scripting (XSS)
3.4. Insecure Direct Object References
3.5. Security Misconfiguration
3.6. Sensitive Data Exposure
3.7. Missing Function Level Access Control
3.8. Cross-Site Request Forgery (CSRF)
3.9. Using Known Vulnerable Components
3.10. Unvalidated Redirects and Forwards
4. Vdeos y revisin de Casos Prcticos.
1. Qu es la Seguridad de la Informacin?
Garantiza que solo los usuarios autorizados (Confidencialidad) puedan tener acceso a la informacin precisa y completa (Integridad) cuando sea necesario (Disponibilidad)
Confidencialidad Disponibilidad - Integridad
Confidencialidad
La proteccin de la informacin privada o sensible contra la divulgacin no autorizada.
Integridad
La precisin y validez de la informacin
Disponibilidad
La informacin que se pueda acceder cuando lo requiera el proceso de negocio ahora y en el futuro
Algunos conceptos de seguridad
Vulnerabilidad
Una deficiencia en el diseo, la implementacin, la operacin o los controles internos en un proceso que podra explotarse para violar la seguridad del sistema.
Amenaza
Cualquier cosa (ej.: un objeto, una sustancia, un ser humano) que es capaz de actuar contra un activo de manera que pueda daarlo. Una causa potencial de un incidente no deseado.
Algunos conceptos de seguridad
Riesgo
La combinacin de probabilidad de un evento y sus consecuencias, el riesgo tradicionalmente se expresa como:
amenazas x vulnerabilidades = riesgo
Exposicin
La prdida potencial de un rea debido a la ocurrencia de un evento adverso
Modelo de Negocio para Seguridad de la Informacin
Organizacin
Personas
Tecnologa
Procesos
Estndares y Buenas Prcticas
Cobit for Information Security
Estndares y Buenas Prcticas
ISO 27001:2013
NTE INEN ISO/IEC 27000: DESCRIPCIN GENERAL - VOCABULARIO
NTE INEN ISO/IEC 27001: REQUISITOS
NTE INEN ISO/IEC 27002: CDIGO DE BUENAS PRCTICAS
NTE INEN ISO/IEC 27003: GUA DE IMPLANTACIN DE UN SGSI
NTE INEN ISO/IEC 27004: MEDICIN
NTE INEN ISO/IEC 27005: GESTIN DE RIESGOS
NTE INEN ISO/IEC 27006: REQUISITOS PARA ORGANIZACIONES QUE PROVEEN AUDITORIA Y CERTIFICACIN DE SISTEMAS DE GESTIN DE SEGURIDAD DE LA INFORMACION
Estndares y Buenas Prcticas
Certificacin CISSP
Estndares y Buenas Prcticas
Certificacin CISM Gobierno de Seguridad de la Informacin
Gobierno de Riesgos de la Informacin y Cumplimiento
Desarrollo y Gestin de programa de seguridad de la Informacin
Gestin de Incidentes de Seguridad de la Informacin
Leyes y Regulaciones de Ecuador
Ley de Comercio Electrnico
Leyes y Regulaciones de Ecuador
Norma JB-834-2005
Gestin del Riesgos Operativo
Disposiciones para propender a que las instituciones del sistema financiero cuenten con un sistema para la gestin del riesgo operativo que les permita identificar, medir, controlar / mitigar y monitorear los riesgos derivados de fallas o insuficiencias en los procesos, personas, tecnologas de informacin y eventos externos incluyendo el riesgo legal.
Norma JB-2148-2012
2. Desarrollo Seguro de Software
IMPORTANCIA DEL SOFTWARE EL SOFTWARE ES DESARROLLADO PRIMERO POR FUNCIONALIDAD NO POR SEGURIDAD,
PARA OBTENER LO MEJOR DE AMBOS MUNDOS TENDRAN QUE SER DISEADOS E INTEGRADOS EN FASES INDIVIDUALES DEL CICLO DE VIDA DE DESARROLLO.
LA SEGURIDAD DEBE ESTAR ENTRELAZADA EN EL NUCLEO DEL PRODCUTO Y PROVEER PROTECCIN EN LAS CAPAS NECESARIAS.
EXISTEN DIFERENTES TIPOS DE CONTROLES:
ENTRADA
ENCRIPCIN
PROCESAMIENTO LGICO
COMUNICACIN INTERPROCESOS
ACCESO
SALIDAS
INTERCONEXIN CON OTROS SISTEMAS
IMPORTANCIA DEL SOFTWARE
EL OBJETIVO ES REDUCIR LAS VULNERABILIDADES Y LA POSIBILIDAD DE TENER UN SISTEMA COMPROMETIDO
LOS CONTROLES PUEDEN SER: PREVENTIVOS
DETECTIVOS
CORRECTIVOS
IMPORTANCIA DEL SOFTWARE
POR NATURALEZA LOS CONTROLES DE SEGURIDAD SIEMPRE SE HAN IDENTIFICADO COMO ADMINISTRATIVOS O FISICOS, LOS CONTROLES USADOS DENTRO DEL SOFTWARE SON MS TECNICOS POR NATURALEZA
LOS CONTROLES ESPECIFICOS DEL SOFTWARE DEBERAN SER USADOS DEPENDIENDO:
LOS OBJETIVOS DEL SOFTWARE
LOS OBJETIVOS DE SEGURIDAD ASOCIADOS CON LAS POLITICAS DE SEGURIDAD
EL TIPO DE DATA QUE PROCESAR
LA FUNCIONALIDAD QUE EJECUTAR
EL ENTORNO DE SOFTWARE QUE SER COLOCADO
IMPORTANCIA DEL SOFTWARE
LO IMPORTANTE ES COMPRENDER LAS NECESIDADES DE SEGURIDAD DE UNA PIEZA DE SOFTWARE, IMPLEMENTAR LOS CONTROLES Y MECANISMOS CORRECTOS, SEGUIR UNA METODOLOGIA DE DESARROLLO ESTRUCTURADA.
DONDE COLOCAMOS SEGURIDAD?
FIREWALLS
IDS/IPS
FILTRADORES DE CONTENIDO
SOFTWARE ANTIVIRUS
ESCANERS DE VULNERABILIDADES
HARD AND CRUNCHY ON THE OUTSIDE SOFT AND CHEWY ON THE INSIDE
NUESTRO PERIMETRO ES SOLIDO/FORTIFICADO PERO NUESTRO ENTORNO INTERNO Y SOFTWARE SON FACILES DE EXPLOTAR UNA VEZ CONSEGUIDO EL ACCESO.
IMPORTANCIA DEL SOFTWARE
AMBIENTES VS APLICACIONES LA SEGURIDAD HA SIDO PROVISTA POR PRODUCTOS DE SEGURIDAD Y DISPOSITIVOS PERIMETRALES ANTES QUE POR CONTROLES DENTRO DE LAS APLICACIONES.
FUNCIONALIDAD VS SEGURIDAD COMPLEJIDAD
EL CODIGO POR SI MISMO
INTERACCION DE RUTINAS
VARIABLES LOCALES Y GLOBALES
ENTRADAS RECIBIDAS DE OTRA APLICACIN
SALIDAS QUE ALIMENTAN A OTRAS APLICACIONES
LOS PROGRAMADORES Y ARQUITECTOS DE APLIACIONES DEBEN SIEMPRE BUSCAR EL EQUILIBRIO ENTRE LA FUNCIONALIAD NECESARIA DEL PROGRAMA, LOS REQUERIEMINTOS DE SEGURIDAD Y LOSMECANISMOS QUE DEBERIAN SER IMPLEMENTADOS PARA PROVEER ESTA SEGURIDAD.
ESTO PUEDE PROVEER MAYOR COMPLEJIDAD A LA DE POR SI COMPLEJA TAREA DEPROGRAMACION
FUNCIONALIDAD VS SEGURIDAD
CICLO DE VIDA DE DESARROLLO DE SISTEMAS
INICIACIN:
LA NECESIDAD POR UN NUEVO SISTEMA ES DEFINIDA
ADQUISICIN/DESARROLLO:
EL NUEVO SISTEMA ES CREADO O COMPRADO
IMPLEMENTACIN:
EL NUEVO SISTEMA ES INSTALADO EN EL AMBIENTE DE PRODUCCIN
OPERACIN/MANTENIMIENTO:
EL SISTEMA SE USA Y SE LE DA MANTENIMIENTO
ELIMINACIN:
EL SISTEMA ES REMOVIDO DEL AMBIENTE DE PRODUCCIN
INICIACIN: QUE ES LO QUE NECESITAMOS Y PORQU LO NECESITAMOS?
EVALUACIN PRELIMINAR DE RIESGOS
DESCRIPCIN INICIAL DE LOS REQUERIMEINTOS DE CONFIDENCIALIDAD, INTEGRIDAD Y DISPONIBILIDAD DEBE TENER EL SISTEMA
DEBE DEFINIR EL ENTORNO EN EL CUAL OPERARA EL SISTEMA
CUALQUIER VULNERABILIDAD IDENTIFICADA
AYUDAR AL EQUIPO A COMENZAR EL PROCESO DE IDENTIFICACIN DE LOS CONTROLES DESEGURIDAD QUE EL SISTEMA NECESITAR TENER.
PUNTO DE VISTA DE SEGURIDAD: QUE NIVEL DE PROTECCIN ESTE SISTEMA NECESITA PROPORCIONAR?
ES NECESARIO PROTEGER LA DATA SENSIBLE EN EL ALMACENAMIENTO Y EN EL TRANSITO?
NECESITA PROPORCIONAR SEGUNDO FACTOR DE AUTENTICACIN?
NECESITA PROPORCIONAR CAPACIDAD DE MONITOREO CONTINUO?
ADQUISICIN/ DESARROLLO: ANLISIS DE REQUERIMIENTOS
EVALUACIN FORMAL DE RIESGOS
ANALISIS DE LOS REQUERIMIENTOS FUNCIONALES DE SEGURIDAD
ANALISIS DE LOS REQUERIMIENTOS QUE GARANTICEN LA SEGURIDAD
EVALUACIN DE TERCEROS
PLAN DE SEGURIDAD
PLAN DE EVALUACIN Y TEST DE SEGURIDAD
IMPLEMENTACIN: SOLO CONECTALO. NO TENEMOS TIEMPO PARA REALIZAR PRUEBAS. ESTOY SEGURO QUE FUNCIONAR BIEN
PROCESO DE CERTIFICACIN: ES EL TEST TECNICO DEL SISTEMA. ASEGURAR AL EFECTIVIDAD DEL SISTEMA Y LOS CONTROLES DE SEGURIDAD
PROCESO DE ACREDITACIN: ES LA AUTORIZACIN FORMAL DAD POR LA ADMINISTRACIN PARA QUE EL SISTEMA ENTRE EN OPERACIN EN JUN DETERMINADO AMBIENTE.
LA DECISIN DE ACREDITACIN ES BASADA EN EL RESULTADO DEL PROCESO DE CERTIFICACIN
LA SEGURIDAD NUNCA TERMINA
OPERACIN/MANTENIMIENTO: EL SISTEMA FUE SEGURO CUANDO LO INSTALAMOS. ESTOY SEGURO QUE NADA A CAMBIADO DESDE ENTONCES
DURANTE LA FASE DE IMPLEMENTACIN DEBE QUEDAR CLARA LA LINEA BASE DE CONFIGURACIN DE HARDWARE, SOFTWARE, FIRMWARE.
MONITOREO CONTINUO PARA GARANTIZAR QUE ESTA LINEA BASE SE MANTIENE
SE DEBE DISPONER DE UN PROCESO DE CONTROL DE CAMBIOS Y GESTIN DE LA CONFIGURACIN
SE DEBE REALIZAR EVALUACIONES DE VULNERABILIDAD Y TEST DE PENETRACIN. ESTO PERMITIRA IDENTIFICAR NUEVAS VULNERABILIDADES QUE PUEDAN PRESENTARSE Y REMEDIARLAS
ELIMINACIN: CUANDO UN SISTEMA YA NO ES EFECTIVO PARA LA FUNCIONALIDAD QUE FUE CONCEBIDO, SE DEBE PENSAR EN UN PLAN DE TRANSICIN HACIA UNA NUEVA SOLUCIN.
DETERMINAR CLARAMENTE SI LA DATA SERA MOVIDA A OTROS SISTEMAS, ALMACENADA, DESTRUIDA.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE RECOPILACION DE REQUERIMIENTOS: PORQUE EL SOFTWARE SE CREAR
QU HAR EL SOFTWARE
PARA QUIN SER CREADO EL SOFTWARE
DISEO: COMO EL SOFTWARE LOGRAR LOS OBJETIVOS IDENTIFICADOS
DESARROLLO: CODIGO DE PROGRAMACIN PARA SATISFACER LAS ESPECIFICACIONES EXPUESTAS EN LA FASE DE DISEO
TESTING/VALIDACIN: VALIDACIN DEL SOFTWARE PARA ASEGURAR QUE LOS OBJETIVOS ESTN CUMPLIDOS Y EL SOFTWARE FUNCIONA COMO FUE PLANEADO
LIBERACIN/MANTENIMIENTO: IMPLEMENTACIN DEL SOFTWARE ASEGURANDOSE QUE ESTE HASTA CONFIGURADO APROPIADAMENTE, PARCHADO Y MONITOREADO
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CICLO DE VIDA DE DESARROLLO DE SISTEMAS SE ENFOCA EN LAS OPERACIONES Y QUE EL DEPARTAMENTO DE TI SEGUIR.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE SE ENFOCA EN EL DISEO Y LA PROGRAMACIN, Y ES UN MODELO QUE LOS INGENIEROS DE DESARROLLO/PROGRAMADORES DEBERN SEGUIR.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE ADMINISTRACIN DE PROYECTOS
UNA BUENA ADMINSTRACIN DEL PROYECTO MANTIENE A ESTE MOVIENDOSE EN LA DIRECCIN CORRECTA
ASIGNA LOS RECURSOS NECESARIOS
PROPORCIONA EL LIDERAZGO NECESARIO
PLANES PARA GESTIONAR LOS PEORES ESCENARIOS (ANALISIS DE RIESGOS)
PROCESO DE ADMINSTRACIN DE PROYECTO DEBER GARANTIZAR QUE EL MISMO EJECUTE CADA UNA DE LAS FASES DEL CICLO DE DESARROLLO APROPIADAMENTE
LA ADMINTRACIN DEL PROYECTO ES UNA PIEZA CLAVE DEL DESARROLLO DE PRODUCTOS Y LA ADMINSTRACIN DE SEGURIDAD ES UNA PIEZA CLAVE DENTRO DE LA ADMINSTRACIN DEL PROYECTO.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
UN PLAN DE SEGURIDAD DEBER SER ELABORADO EN EL COMIENZO DE UN PROYECTO DE DESARROLLO E INTEGRADO EN EL PLAN FUNCIONAL PARA GARANTIZAR QUE LA SEGURIDAD NO ESTA SIENDO PASADA POR ALTO.
EL PRIMER PLAN ES AMPLIO, GENERAL Y HACE REFERENCIA A DOCUMENTACIN PARA MAYOR DETALLE. ESTA DOCUMENTACIN PUEDE INCLUIR ESTNDARES DE COMPUTACIN (RFC, MEJORES PRACTICAS, ETC), DOCUMENTACION DESARROLLADA EN ANTERIOERS PROYECTOS, POLITICAS DE SEGURIDAD, DECLARACINES DE ACREDITACIN, PLAN DE MANEJO DE INCIDENTES, LEYES/REGULACIONES NACIONALES O INTERNACIONALES QUE SE DEBEN CUMPLIR.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CUANDO EL ASEGURAMIENTO EN UN PRODUCTO DEBE SER GARANTIZADO, INDICANDO QUE LA SEGURIDAD FUE CONSIDERADA EN CADA ETAPA DEL CICLO DE VIDA, LOS PROCEDIMIENTOS, DESARROLLO, DECISIONES Y ACTIVIDADES QUE SE EJECUTARON DURANTE EL PROYECTO DEBEN SER REVISADAS. LA DOCUMENTACIN DEBE REFLEJAR COMO EL PRODUCTO FUE CONSTRUIDO Y COMO SE SUPONE QUE FIUNCIONAR UNA VEZ IMPLEMENTADO EN UN AMBIENTE ESPECFICO.
SI SE DESARROLLA UN SOFTWARE A MEDIDA, SE DEBE ELABORAR UN DOCUMENTO DE ALCANCE (STATEMENT OF WORK) EN DONDE SE DESCRIBE TODO LO REFERENTE AL PRODUCTO Y LOS REQUERIMIENTOS DEL CLIENTE. EL MAYOR DETALLE DE ESTE DOCUMENTO AYUDARA A ASEGURAR QUE LOS REQUERIMIENTOS ESTAN COMPRENDIDOS Y NO EXISTEN LOS SUPUESTOS.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
DEBE SEGUIR ESTRICTAMENTE LO QUE SE ACORDO EN EL SOW CASO CONTRARIO PUEDE CAERSE EN: UN PROYECTO SIN FIN, NO CUMPLIR LOS OBJETIVOS, SALIRSE DEL PRESUPUESTO.
SI EL CLIENTE DESEA MODIFICAR LOS REQUERIMIENTOS ES IMPORTANTE QUE EL SOW SE ACTUALICE Y SE REVISE EL PRESUPUESTO.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE RECOPILACIN DE REQUERIMIENTOS:
QUE CONSTRUIREMOS Y PORQU?
ESTA ES LA FASE CUANDO TODOS LOS INVOLUCRADOS TRATAN DE COMPRENDER EL PORQUE EL PROYECTO ES NECESARIO Y LO QUE EL ALCANCE DEL PROYECTO IMPLICA.
REQUERIMIENTO DE SOFTWARE
FUNCIONALIDAD PROPUESTA LLUVIA DE IDEAS (BRAINSTORMING SESSIONS)
RESTRICCIONES SON REVISADAS
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
UNA DEFINICION CLARA DEL PROYECTO SE DEBE GENERAR PARA QUE TODOS ESTEN ALINEADOS A LO QUE SE BUSCA.
SE EVALUA PRODUCTOS SIMILARES EXISTENTES EN EL MERCADO Y LAS NECESIDADES QUE NO ESTAN SIENDO ATENDIDAS POR ESTOS.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE DESDE EL PUNDO DE VISTA DE SEGURIDAD:
REQUERIMIENTOS DE SEGURIDAD
LOS REQUERIMIENTOS DE SEGURIDAD DEBERAN SER DEFINIDOS EN TRES CATEGORIAS: DISPONIBILIDAD, INTEGRIDAD, CONFIDENCIALIDAD.
QUE TIPO DE SEGURIDAD ES REQUERIDA POR EL SOFTWARE Y EN QUE GRADO?
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
EVALUACIN DE RIESGOS DE SEGURIDAD UNA EVALUACIN INICIAL DE RIESGOS DE SEGURIDAD DEBERA IDENTIFICAR LAS POTENCIALES
AMENAZAS Y SUS POSIBLES CONSECUENCIAS. (FINALIDAD, EL ENTORNO DONDE SE IMPLEMENTAR EL SOFTWARE, EL PERSONAL INVOLUCRADO, EL TIPO DE NEGOCIO QUE UTILIZAR EL SOFTWARE)
EVALUACIN DE RIESGOS DE PRIVACIDAD DEBER INDICARSE EL NIVEL DE SENSIBILIDAD DE LA DATA QUE SER PROCESADA O ACCEDIDA
ACEPTACIN DEL NIVEL DE RIESGO LA ACEPTABILIDAD DEL RIESGO DEPENDER DE LAS EVALUACIONES DE SEGURIDAD Y PRIVACIDAD. LA
EVALUACIN DE VULNERABILIDADES Y AMENAZAS SE EFECTUAN PARA DETERMINAR EL COSTO/BENEFICIO DE LAS DIFERENTES CONTRAMEDIDAS QUE SE PUEDAN IMPLEMENTAR.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE DISEO
EN ESTA FASE SE COMIENZA A TRASLADAR LO TEORICO A LA REALIDAD
EXISTEN TRES MODELOS:
MODELO INFORMACIONAL: INDICA EL TIPO DE INFORMACIN QUE SER PROCESADA Y COMO SER PROCESADA
MODELO FUNCIONAL: INDICA LAS TAREAS Y FUNCIONES QUE LA APLICACIN NECESITA PARA CUMPLIR SU OBJETIVO
MODELO DE COMPORTAMIENTO: EXPLICA LOS ESTADOS QUE TENDR LA APLICACIN DURANTE Y DESPUES QUE UNA TRANSACCIN ESPECIFICA SE LLEVE ACABO.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CICLO DE VIDA DE DESARROLLO DE SOFTWARE ANTIVIRUS:
MODELO INFORMACIONAL: FIRMAS DE VIRUS, ARCHIVOS DE SISTEMAS MODIFICADOS, CHECKSUMS DE LOS ARCHIVOS DEL SISTEMA, ACTIVIDAD DE VIRUS
MODELO FUNCIONAL: LA APLICACIN DEBERA SER CAPAZ DE ESCANEAR LOS DISCOS DUROS, REVISAR EL E-MAIL EN BUSCA DE FIRMAS DE VIRUS CONOCIDAS, MONITOREAR LOS ARCHIVOS CRITICOS DEL SISTEMA Y ACTUALIZARSE AUTOMTICAMENTE.
MODELO DE COMPORTAMIENTO: EL APLICATIVO INDICAR CUANDO EMPEZAR A FUNCIONAR, ESCANER LOS DISCOS DUROS Y SEGMENTOS DE MEMORIA. SI SE ENCONTRAR UN VIRUS EL ESTADO DEL COPUTADOR CAMBIAR Y SE TRATAR AL VIRUS APROPIADAMENTE. SE DEBE CONSIDERAR CADA ESTADO DEL APLICATIVO PARA GARANTIZAR QUE NO ENTRAR EN UN ESTADO INSEGURO O REACCIONAR DE UNA MANERA NO CONTEMPLADA.
CICLO DE VIDA DE DESARROLLO DE SOFTWARE DESDE EL PUNTO DE VISTA DE SEGURIDAD:
ANALISIS SUPERFICIAL DE ATAQUE
MODELAMIENTO DE AMENAZAS
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE DESARROLLO
AQU ES EL INVOLUCRAMIENTO EN PROFUNDIDAD DE LOS PROGRAMADORES PARA DESARROLLAR EL CODIGO QUE HAR CUMPLIR CON LO ACORDADO.
ESTA FASE ES LA DE MAYOR CRITICIDAD Y SI NO SE SIGUE ESTRICTAMENTE METODOS DE CODIFICACIN SEGURA SE PUEDE OBTENER RESULTADOS DEVASTADORES.
LAS 25 VULNERABILIDADES MS COMUNES DENTRO DEL DESARROLLO SON LAS SIGUIENTES:
CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE TESTING/VALIDACIN:
AQU ES IMPORTANTE HACER UN MATCH ENTRE LOS RIESGOS DE SEGURIDAD A LOS CASOS DE TESTING Y CODIGO.
SEPARACIN DE FUNCIONES
SE DEBERA TRABAJAR EN UN AMBIENTE DE PRE-PRODUCCIN QUE SIMULE EL AMBIEMTE REAL DONDE FUNCIONAR LA APLICACIN.
PENTESTING Y ATAQUES DE SEGURIDAD SON EJECUTADOS
SE EVALUA LA FUNCIONALIDAD, OPERATIVIDAD DEL SOFTWARE (PRUEBAS DE CARGA/STRESS)
CICLO DE VIDA DE DESARROLLO DE SOFTWARE TIPOS DE TESTING:
TESTING UNITARIO:
TESTING INTEGRAL
TESTING DE ACEPTACIN
RE-TESTING
CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE LIBERACIN/MANTENIMIENTO:
AQU NO FINALIZA EL ROL DEL EQUIPO DE PROGRAMACIN
CONTINUAMENTE DEBER ESTARSE VALIDANDO NUEVAS VULNERABILIDAES, DESARROLLANDO PARCHES, HOTFIXES Y LIBERANDO NUEVAS VERSIONES DEL PRODUCTO QUE MITIGEN LAS NUEVAS VULNERABILIDADES.
SEGURIDAD WEB CUANDO SE TRATA DE INTERNET Y APLICACIONES BASADAS EN WEB, HAY MUCHAS SEGURIDADES ESPECIFICAS EN ESTA AREA.
LAS EMPRESAS EXPONEN SUS PRODUCTOS Y SERVICIOS PARA LA MAYOR AUDIENCIA POSIBLE, TENIENDO UN ACCESO SIN CONTROL DESDE DIFERENTES PUNTOS A SUS SERVIDORES WEB.
TIENEN A ABRIR LOS PUERTOS 80 Y 443 EN SUS FIREWALLS PARA PERMITIR EL TRAFICO BASADO EN WEB, LO QUE LES DA UN ALTO RIESGO DE ATAQUES POR ESTA VIA.
EL RIESGO SE INCREMENTA SI NO TIENES UNA METODOLOGIA DE DESARROLLO, PROCESOS DE DESARROLLO, ASEGURAMIENTO DE LA CALIDAD, CONTROL DE CAMBIOS E IDENTIFICADOS LOS RIESGOS Y VULNERABILIDADES INTRINSECAS DE ESTE TIPO DE APLICACIONES.
AMENAZAS ESPECFICAS PARA ENTORNOS WEB
RECOLECCION DE INFORMACIN
INTERFACES ADMINISTRATIVAS (SECURE SHELL)
CONTROL DE ACCESO Y AUTENTICACIN (SECURE SOCKETS LAYER O TRANSPORT LAYER SECURITY)
VALIDACIN DE ENTRADAS (SQL INJECTION, XSS)
VALIDACIN DE PARMETROS (SESSION COKIES, WEB PROXY)
ADMINSTRACIN DE SESIN (RANDOM SESSION ID, ENCRIPCIN, TIEMPO DE INACTIVIDAD)
PRINCIPIOS DE SEGURIDAD EN APLICACIONES WEB
ANALIZAR LA ARQUITECTURA DE LA APLICACIN WEB
TODA ENTRADA DEBE CONSIDERARSE INSEGURA Y POR LO TANTO DEBE SER SANITIZADA PREVIAMENTE A SER PROCESADA
TODA SALIDA DEBE SER FILTARDA PARA VALIDAR QUE DATA SENSIBLE NO HA SIDO REVELADA
UTILIZAR ENCRIPCIN
EL WEB SITE DEBE ESTAR DISEADO PARA COMPORTARSE DE UNA MANERA PREDICTIBLE Y NO COMPROMETIDA EN CASO DE OCURRIR UN ERROR
SE DEBE CONSIDERAR EL FACTOR HUMANO
OPEN WEB APPLICATION SECURITY PROJECT
Top Ten de Owasp 2013 INJECTION
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
CROSS-SITE SCRIPTING (XSS)
INSECURE DIRECT OBJECT REFERENCES
SECURITY MISCONFIGURATION
SENSITIVE DATA EXPOSURE
MISSING FUNCTION LEVEL ACCESS CONTROL
CROSS-SITE REQUEST FORGERY (CSRF)
USING KNOW VULNERABLE COMPONENTS
UNVALIDATED REDIRECTS AND FORWARDS
INJECTION
VIDEOS SEGURIDAD EN APLICACIONES\OWASP Appsec Tutorial Series - Episode 2_ SQL Injection_(480p).mp4
INJECTION DESCRIPCIN
ESTE ATAQUE EXPLOTA UNA VULNERABILIDAD DE UNA APLICACIN QUE CONSTRUYE SENTENCIAS SQL BASADAS EN LAS ENTRADAS DEL USUARIO. EL ATACANTE TRABAJA CON LAS CADENAS DE DATOS DEL APLICATIVO QUE CONSTRUYE BAJO SENTENCIAS SQL.
EL RESULTADO DE LA SENTENCIA SQL EJECUTA OTRA ACCIN QUE LA PREVISTA POR LA APLICACIN.
SQL INJECTION RESULTA DE LA FALLA DE LA APLIACCIN PARA VALIDAR APROPIADAMENTE LAENTRADA DE DATOS. CUANDO SE TRABAJA CON ENTRADAS DE DATOS CONSISTENTES ENSENTENCIAS SQL SIN USAR UNA VALIDACIN APROPIADA COMO PARTE DE LAS CONSULTAS DESQL, ES POSIBLE OBTENER INFORMACIN DESDE LA BASE DE DATOS DE UNA MANERA NOPREVISTA EN LA ETAPA DE DISEO DE LA APLICACIN.
INJECTION
IMPACTO
UNA INYECCIN CORRECTA PUEDE OBTENER INFORMACIN, AS COMO ADICIONAR O MODIFICAR DATOS DIRECTAMENTE EN LA BASE.
IDENTIFICACIN
TODO CODIGO DEBE SER REVISADO PARA DETERMINAR SI LAS ENTRADAS SOLICITADAS ESTAN MANEJANDOSE SIN LAS VALIDACIONES CORRECTAS. ESPECIALMENTE LAS QUE LLAMAN A LA BASE DE DATOS A TRAVS DE CONCATENACIN DE CADENAS.
DURANTE LA ETAPA DE TESTING, ESTOS PROBLEMAS DEBEN SER IDENTIFICADOS EN CADA PARAMETRO QUE SE ENVIA A LA APLICACIN
INJECTION DEFENSA
VALIDACION DE DATOS DE ENTRADA
TIPOS DE VALIDACIN EXACT MATCH
WHITE LIST
BLACK LIST
VALIDACIONES ADICIONALES: TAMAO Y LONGITUD
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
VIDEOS SEGURIDAD EN APLICACIONES\OWASP Top 10 #3 - Broken Authentication and Session Management._(720p).mp4
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
AUTENTICACIN
LA AUTENTICACION ES CONFIRMAR LA IDENTIDAD DE UN USUARIO SOBRE UNA APLICACIN.DEBIDO A QUE EL PROTOCOLO HTTP NO TIENE ESTADO, LA APLIACCIN WEB DEBE PROVEER DE UN MECANISMOS DE ADMINSTRACIN DE SESIN DESPUS QUE EL USUARIO SE HAYA AUTENTICADO. MUCHAS APLICACIONES EMITEN UN SESSION ID O PARAMENTRO URL PARA MANTENER EL ESTADO ENTRE LAS SOLICITUDES. SE HAN DESARROLLA ATAQUES PARA ESTAS DOS FUNCIONES BASICAS DE UNA APLICACIN PARA ROMPER LA SEGURIDAD.
BROKEN AUTHENTICATION AND SESSION MANAGEMENT LA AUTENTICACIN PUEDE SER MANEJADA DE VARIAS MANERAS:
AUTENTICACIN BASICA
UTILIZAR TOKENS DE AUTENTICACION COMO UNA VERSION CODIFICADA DEL USUARIO Y PASSWORD
SOLICITAR AUTENTICACIN CADA VEZ QUE SE INGRESE APGINAS SENSIBLES
AUTENTICACIN NTML
PROTOCOLO DE AUTENTICACION CHALLENGE/RESPONSE
AUTENTICACIN CUSTOMIZADA
UNA SOLUCION CUSTOMIZADA PARA PROVEER AUTENTICACIN, NORMALMENTE VALIDA LAS CREDENCIALES CONTRA UNA BASE DE DATOS
BROKEN AUTHENTICATION AND SESSION MANAGEMENT ATAQUES COMUNES CONTRA LOS SISTEMAS DE AUTENTICACIN INCLUYEN:
INSUFICIENCIA EN LOS BLOQUEOS DE CUENTAS
PROCEDIMIENTO DE CUENTAS INSEGUROS
APLICACIN PERMITE CLAVES DEBILES
CAMBIO DE PASSWORD NO SOLICITA EL INGRESO DEL PASSWORD ORIGINAL
FUNCIONALIDAD OLVIDO SU CONTRASEA INSEGURA
BROKEN AUTHENTICATION AND SESSION MANAGEMENT ADMINSTRACIN DE SESIONES
ADMNISTRACIN DE SESIN ES MANEJA COMUNMENTE A TRAVS DE COOKIES. HAY DOS TIPOS DE COOKIES: PERSISTENTES Y DE SESIN.
COOKIES PERSISTENTES SON ENVIADOS AL USUARIO SIN UN TIEMPO DE EXPIRACIN FIJO. ESTAS QUEDARN EN EL DISCO DURO DESPUES DE TERMINAR LA SESIN Y CERRAR EL BROWSER. ESTAS COOKIES DAN SEGUIMIENTO A LOS SITIOS VISITADOS, PREFERENCIAS DE NAVEGACIN.
COOKIES DE SESIN NO SON ALMACENADAS EN EL DISCO DURO PERO SE MANTIENEN EN MEMORIA Y NO SE ALMACENAN DESPUES DE CERRAR EL BROWSER.
BROKEN AUTHENTICATION AND SESSION MANAGEMENT ATAQUES COMUNES CONTRA LOS SISTEMAS DE ADMINSTRACIN DE SESIONES:
IDENTIFICADOR DE SESIN DBIL (UN MISMO ID EN TODAS LAS SESIONES, LONGITUD MENOR A 128 BITS, NO RANDMICO)
CAPTURA DE SESIN NUEVO TOKEN NO ES GENERADO CUANDO UN USUARIO INTENTA IR DE UNA SESIN DESAUTORIZADA A UNA AUTORIZADA.
TIMEOUT DE SESIN INAPROPIADO
VARIOS LOGINS PERMITIDOS
FUNCIONALIDAD DE LOGOUT NO ACTIVA
SESSION ID ALMACENADO EN EL URL
LA SESION CONTINUA ACTIVA DESPUES DEL LOGOUT
BROKEN AUTHENTICATION AND SESSION MANAGEMENT IMPACTO
PARA UN ATACANTE, COMPROMETER LA COOKIE DE SESIN DE UN USARIO PUEDE SER TAN BUENO COMO OBTENER SU USUARIO Y PASSWORD. ESTAS VULNERABILIDADES PUEDEN GARANTIZAR AL ATACANTE UN ACCESO NO AUTORIZADO A LAS FUNCIONALIDADES DE UN SISTEMA O A INFORMACIN SENSITIVA.
IDENTIFICACIN
REVISAR EL CODIGO DE LA APLICACIN PARA VALIDAR LOS MECANISMOS DE AUTENTICACIN Y MANEJO DE SESIONES.
ASEGURARSE QUE LAS VULNERABILIDADES COMUNES LISTADAS ANTERIORMENTE NO ESTAN PRESENTES EN LA APLICACIN.
BROKEN AUTHENTICATION AND SESSION MANAGEMENT DEFENSA
PARA GARANTIZAR MECANISMOS DE AUTENTICACIN SEGURA, PODEMOS IMPLEMENTAR LOS SIGUIENTES CONTROLES:
FORZAR BLOQUEO DE CUENTAS PARA PREVENIR ATAQUES DE FUERZA BRUTA
DURACIN DE LA CUENTA ANTES DEL BLOQUEO
UMBRAL DE INTENTOS ANTES DEL BLOQUEO DE LA CUENTA
ASEGURAR QUE LAS CLAVES PASEN POR UN PROCESO DE VALIDACIN PREVIO ANTES DE APROBARLOS. CONTRASEA ROBUSTA
BROKEN AUTHENTICATION AND SESSION MANAGEMENT CUANDO SE CONSTRUYE UNA FUNCIONALIDAD PARA ADMINISTRACIN DE SESIN, CONSIDERAR LO SIGUIENTE:
UTILIZAR UNA SOLUCIN DE CRIPTOGRAFIA PARA REDUCIR EL RIESGO DE SECUESTRO DE SESIN ATRAVS DE IDENTIFICADOR PREDECIBLES. NO DEBERIAN SER INCREMENTALES. DEBERIAN SER MINIMO DE 128 BITS DE LONGITUD.
LAS COOKIES DE SESIN DEBEN SER NO-PERSISTANT.
SE DEBERA ENVIAR UN NUEVO IDENTIFICADOR DE SESIN UNA VEZ QUE EL USUARIO HAYA SIDO AUTENTICADO
IMPLEMENTAR MANEJO DE SESIONES A TRAVS DE COOKIES EN LUGAR DE ENVIAR EL SESSION ID EN LA CADENA DE CONSULTA
MANEJAR UN TIMEOUT PARA LAS SESIONES DE USUARIO
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
UNA COOKIE DE SESIN NO DEBERA CONTENER:
USERNAME Y PASSWORD
INFORMACIN PERSONAL
NIVEL DE ACCESO
IDENTIFICADORES DE SESIN PREDECIBLES (CONTADOR INCREMENTAL)
RECUERDEN QUE LOS VALORES DE LAS COOKIES DE SESIN DEBEN SER MANEJADOS COMO CUALQUIER OTRO VALOR DE ENTRADA
LAS COOKIES DE SESIN DEBEN SER RESETEADAS EN:
AL INCIAR LA SESIN
AL TERMINAR LA SESIN
AL EXPIRAR LA SESIN
CROSS SITE SCRIPTING
Website Hacking with XSS(Cross Site Scripting)_(360p).mp4
CROSS SITE SCRIPTING DEFINICIN:
CROSS SITE SCRIPTING (XSS) OCURRE CUANDO LOS DATOS DE ENTREDA NO SON VALIDADOS CORRECTAMENTE ANTES DE QUE EMPIEZEN A SER UTILIZADOS POR LA APLICACIN INTERNAMENTE EN FORMA DINMICA. UN ATACANTE PUEDE TOMAR VENTAJA DE ESTA VULNERABILIDAD PARA MODIFICAR LOS VALORES DE ENTRADA (HTTP GEST, POST, HEADERS, ETC) PARA INYECTAR CODIGO JAVASCRIPT EN EL LADO DEL CLIENTE. EL XSS PERMITE EJECUTAR SCRIPTS MALICIOSOS EN EL WEB SERVER, PERMITIENDO EL ACCESO A CUALQUIER PARTE DEL DOM DEL BROWSER, INCLUYENDO COOKIES, SESSION IDS, HTML.
CROSS SITE SCRIPTING HAY DOS FORMAS PRINCIPALES DE XSS:
STANDARD XSS: ESTA FORMA DE XSS REQUIERE QUE LA VICTIMA HAGA CLICK EN UN LINK MALICIOSO QUE TIENE CODIGO EMBEBIDO. ESTE TIPO DE ATAQUES SE USAN GENERALMENTE EN PHISHING O SPAM. TAMBIEN SE LO CONOCE COMO XSS REFLEJADO.
PERSISTENT XSS: ES UNA VARIANTE DE XSS QUE SE MANTIENE EN LA APLICACIN, FRECUENTEMENTE EN LA BASE DE DATOS . CUANDO UN USUARIO ACCEDE A UNA PAGINA CON UN SCRIP MALICIOSO, EL ATAQUE SE DISPARA. ESTE TIPO DE ATAQUES SE ENCUENTRAN EN FOROS ONLINE DONDE LOS USUARIOS PUEDEN ENVIAR MENSAJES REITERATIVOS.
CROSS SITE SCRIPTING IMPACTO:
ESTE TIPO DE ATAQUE PUEDE SER USUADO PARA OBTENER INFORMACIN COMO USUARIOS Y CONTRASEAS, INFORMACIN SENSIBLE, TENER CONTROL REMOTO O MONITOREAR EL BROWSER DE UN USARIO, O MANIPULAR LA PAGINA WEB PARA OBTENER INFORMACIN ESPECIFICA COMO NUMEROS DE TARJETAS DE CREDITO.
POR EJEMPLO, UN ATACANTE PODRIA USUAR ESTA VULNERABILIDAD PARA ENVIAR MAILS FALSOS A CLIENTES O EMPLEADOS, EL CUAL CONTENGA UN URL CON CODIGO MALICIOSO, EL CUAL PROBLAMENTE ESTARA DISEADO PARA QUE SE EJECUTE DESDE UN SITIO DE CONFIANZA. ES DECIR CUANDO YA EL USUARIO SE HAYA AUTENTICADO, CON LA FINALIDAD QUE EL ATACANTE ROBE UNA SESIN VALIDA.
CROSS SITE SCRIPTING IDENTIFICACIN:
REVISAR EL CODIGO FUENTE DE LA APLICACIN E IDENTIFCAR LAS PGINAS QUE ACEPTEN DATOS DE ENTRADA Y QUE ESTOS DATOS SON MOSTRADOS DE REGRESO AL USUARIO
CROSS SITE SCRIPTING DEFENSA:
EN ASP/ASP.net ESTO PODRA CUMPLIRSE A TRAVS DE LA FUNCIN server.htmlencode() .
Choose a Password:
Verify Password:
INSECURE DIRECT OBJECT REFERENCES
OWASP Top Ten 2013_ A4 - Insecure Direct Object References_(360p).mp4
INSECURE DIRECT OBJECT REFERENCES DESCRIPCIN:
ESTA VULNERABILIDAD OCURRE CUANDO UN PROGRAMADOR EXPONE UNA REFERENCIA A UN OBJETO A TRAVS DE UN PARMETRO DE URL, CAMPO OCULTO U OTRO CAMPO. ESTA REFERENCIA DE OBJETO PUEDE SER UNA LLAVE PRIMARIA DE BASE DE DATOS, U ARCHIVO, UN DIRECTORIO, U OTRO IDENTIFICAR INTERNO DE LA APLICACIN. POR EJEMPLO, VARIAS VECES UNA REFERENCIA A UN OBJETO DIRECTO ES LA LLAVE PRIMARIA DE LA BD, LO CUAL ES FACIL IMPLEMENTAR PARA LOS PROGRAMADORES PERO TAMBIEN ESTO LES PUEDE PERMITIR UN FACIL ACCESO A LOS ATACANTES EN UN BACKEND DE BD.
INSECURE DIRECT OBJECT REFERENCES IMPACTO:
MANIPULANDO UNA REFERENCIA A OBJETO, UN ATACANTE PUEDE GANAR ACCESO A RECURSOS ADICIONALES O DATA DE UN SISTEMA, TALES COMO ARCHIVOS O REGISTROS DE BD.
IDENTIFICACIN:
ESTA INSEGURA PRACTICA DE DESARROLLO PUEDE SER IDENTIFICADA A TRAVS DE UNA REVISIN DEL CDIGO FUENTE DE LA APLICACIN PARA ENCONTRAR REAS DONDE LOS OBJETOS INTERNOS SON DIRECTAMENTE REFERENCIADOS EN LA CAPA DE PRESENTACIN DE LA APLICACIN.
PARA IDENTIFICAR ESTO EN LA ETAPA DE TESTING, TODOS LOS PARMETROS DE ENTRADA DEBERAN SER MANIPULADOS EN UN INTENTO PARA GANAR ACCESO NO AUTORIZADO A LA DATA. POR EJEMPLO, SI UN URL CONTINEN UN PARMETRO ID EL CUAL REFERENCIA AUN PERFIL DE USUARIO, INTENTA CAMBIAR EL VALOR PARA GANAR ACCESO A OTRO PERFIL DE USUARIO.
INSECURE DIRECT OBJECT REFERENCES DEFENSA:
ALGUNAS RECOMENDACIONES PUEDEN SER TOMADAS PARA PREVENIR ESTE TIPO DE VULNERABILIDADES:
NO REFERENCIAR DIRECTAMENTE OBJETOS INTERNOS EN LA CAPA DE PRESENTACIN DE LA APLICACIN. EN SU LUGAR, IMPLEMENTAR UNA FORMA LGICA DE ALMACENAR UNA LISTA DE OBJETOS VLIDOS PARA ESE USUARIO DENTRO DE UN ARREGLO. Y EL ACCESO A ESTOS OBJETOS SE CONCEDE CON UN ADECUADO SISTEMA DE INDEXACIN. ESTA SOLUCIN LIMITAR A LAS OBJETOS PARA ACCESO SOLO A LOS INDICADOS DENTRO DEL ARREGLO.
AL REALIZAR BSQUEDAS DE OBJETOS SOBRE LA BASE DE UN NMERO DE REFERENCIA SE DEBE MANTENER UNA SESIN CON ESE USUARIO Y ATAR ESA SESIN A UNA LISTA DE OBJETOS PERMITIDOS EN EL BACKEND DE LA APLICACIN.
INSECURE DIRECT OBJECT REFERENCES
Cross Site Request Forgery (CRSF).
Cross Site Request Forgery Complete Video Tutorial by Offensive Security_(360p).mp4
Cross Site Request Forgery (CRSF). Un Ataque de CRSF tambin conocido como XSRF, fuerza al usuario/navegador "logueado y validado" de la victima a mandar un HTTP request forjado, a una aplicacin web vulnerable a este tipo de ataque.
Esto permite al atacante forzar al navegador de la victima para acometer daos o estafas que la aplicacin atribuye a un usuario legtimo.
Quizs esta es una de las vulnerabilidades llamada a ser la ms importante en los prximos aos. Se le conoce como el gigante dormido del OWASP top 10
Cross Site Request Forgery (CRSF). Si usted como yo o cualquier usuario actualmente, navega simultneamente en varias pginas a la vez, puede ser vctima del CSRF sin saberlo.
Y si usted es de lo que abre muchas ventanas simultneamente en cada sesin de su navegador, tampoco esta exento de ser vctima de un ataque de CSRF por culpa de una aplicacin vulnerable, sin que pueda hacer absolutamente nada al respecto.
Cross Site Request Forgery (CRSF).
Cross Site Request Forgery (CRSF). DEFENSA:
Firmando cada formulario que es entregado con un token seguro en un campo oculto. Una vez que el usuario enva el formulario el token se verifica y se borra, no se puede enviar nuevamente el formulario sin solicitarlo de nuevo para obtener un nuevo token. De esta forma el atacante no podr predecir el token aleatorio.
Esta solucin tambin es muy til para evitar que un mismos formulario sea enviado dos veces por error por parte del usuario debido quizs a una conexin problemtica o lenta.
Otras soluciones son, la solicitud de credenciales (nuevamente) al momento de la transaccin y los OTPs.
Implemente tambin funciones de salida de la aplicacin que cierren la sesin completamente y eliminen sus datos.
Reduzca el Timeout de sesin lo ms que pueda.
Top Ten de Owasp 2013 INJECTION
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
CROSS-SITE SCRIPTING (XSS)
INSECURE DIRECT OBJECT REFERENCES
SECURITY MISCONFIGURATION
SENSITIVE DATA EXPOSURE
MISSING FUNCTION LEVEL ACCESS CONTROL
CROSS-SITE REQUEST FORGERY (CSRF)
USING KNOW VULNERABLE COMPONENTS
UNVALIDATED REDIRECTS AND FORWARDS
Resumen del documento
OWASP Secure Coding Practices
Secure Coding Practice Checklist Input Validation
Realice todas las validaciones en un sistema confiable (ejemplo el servidor).
Identifique todas las fuentes de datos y clasifquelas en confiables y no confiables. Valide todos los datos de las fuentes no confiables.
Debe existir una rutina centralizada para la validacin de datos para toda la aplicacin.
Especifique el tipo correcto de caracteres para todas las fuentes de datos (ejemplo UTF-8)
Codifique todos los datos a un mismo tipo de caracteres antes de validarlos.
Todos los errores de validacin debe resultar en rechazo de las entradas.
Valide todos los datos de entrada antes de procesarlos, incluyendo todos los parmetros , URLs y nombres de cookies y sus valores.
Verifique que los valores en el header contengan solamente caracteres ASCII.
Valide todas las redirecciones.
Valide que los tipos de datos sean los esperados.
Valide el rango de los datos.
Valide la longitud de los datos.
Validate todas las entradas contra un white-list de caracteres permitidos siempre que sea posible?
Si un caracter potencialmente peligroso debe se permitido asegrese de inplementar controles adicionales como output encoding
Si su rutina de validacin no controla las siguientes entradas debe verificarla
Verifique ingreso de null bytes (%00)
Verifique ingreso de caracteres de nueva lnea (%0d, %0a, \r, \n)
Verifique el ingreso de dot-dot-slash (../ o ..\).
Secure Coding Practice Checklist Input Validation (continuacin)
Conduzca toda la codificacin de salida en un sistema confiable (ej. El servidor).
Utilice rutinas probadas para cada tipo de codificacin de salida.
Codifique la salida de todos los datos devueltos al cliente que provengan de una fuente no confiable. La codificacin HTML es un ejemplo pero no sirve para todos los casos.
Codifique todos los caracteres a menos que se conozca que son seguros para el intrprete
Desinfecte todas las salidas de datos no confiables que vayan hacia consultas para SQL, XML y LDAP.
Desinfecte todas las salidas provenientes de fuentes no confiables que vayan a comandos del sistema operativo
Secure Coding Practice Checklist Output encoding
Secure Coding Practice Checklist Authentication and Password Management
Requiera autentificacin para todas las pginas excepto para aquellas entendidas como pblicas.
Toda autentificacin debe ser realizada en un sistema confiable (ej. el servidor).
Establezca y utilice servicios probados y estndares de autentificacin siempre que sea posible.
Utilice una implementacin centralizada de todos los controles y servicios de autentificacin.
Segregue o elimine la lgica de autentificacin del recurso solicitado.
Todos los controles de autentificacin deben fallar de forma segura.
Si su aplicacin debe guardar credenciales, debe asegurar que solamente se utilicen hashes criptogrficos de un solo sentido y que la tabla o archivo donde se guarden solo sea legible por la aplicacin. (Evite la utilizacin de MD5 si es posible).
La conversin de password hashing debe ser realizada en un sistema seguro (ej. el servidor).
Las respuestas de error de autentificacin no deben aclarar cual de los datos de autentificacin es incorrecto.
Utilice autentificacin para conectarse con sistemas que envuelvan datos o funciones sensibles.
La autentificacin necesaria para conectar con sistemas externos a la aplicacin debe ser cifrada y guardada en una ubicacin protegida en un sistema seguro (ej. el servidor).
Use solamente solicitudes POST para transmitir credenciales de autentificacin.
Enve siempre los passwords no temporales por una conexin cifrada o como datos cifrados. Los passwords temporales pueden ser una excepcin.
Promueva y solicite la complejidad as como la longitud necesaria en el password para evitar ataques de fuerza bruta. Ocho caracteres son suficientes pero 16 son lo ideal.
Secure Coding Practice Checklist Authentication and Password Management
Los passwords no deben ser visibles en la pantalla del usuario.
Utilice bloqueo de cuentas despus de un nmero establecido de intentos
Las operaciones de recuperacin de password y de creacin del mismo requieren del mismo nmero de controles que los de autentificacin e ingreso.
Las preguntas de recuperacin de passwords, deben soportar un nmero suficiente de respuestas posibles.
Los passwords temporales deben tener un perodo corto de expiracin.
Obligue al cambio de las claves temporales luego del primer uso.
Obligue al cambio de password luego de un tiempo de vida, una cantidad determinada de usos o ambos.
Deshabilite la funcin de autollenado en los formularios.
Use sistemas de validacin de factores mltiples para datos de alta sensibilidad.
Secure Coding Practice Checklist Authentication and Password Management
Use los controles de sesin del entorno del servidor. La aplicacin debe reconocer solo estos identificadores como vlidos.
La creacin de identificadores de sesin debe ocurrir en un entorno confiable (ej. el servidor)
Los controles de manejo de sesin deben utilizar algoritmos que garanticen que los identificadores de sesin sean suficientemente aleatorios.
Implemente una funcin de salida que finalice completamente la sesin y destruya sus datos.
La funcin de salida debe ser accesible desde todas las pginas protegidas por autorizacin.
Establezca un Session Timeout de inactividad lo ms corto posible, basado en balancear el riesgo con los requerimientos funcionales.
Establezca un tiempo mximo de actividad para sus sesiones, y cirrelas si este tiempo es superado.
Secure Coding Practice Checklist Session Control
Genere un nuevo identificador de sesin en cada re-autentificacin.
No permita ingresos concurrentes de un mismo usuario.
No exponga los identificadores de sesin en el URL o en los mensajes de error. No los pase como parmetros GET.
Genere un nuevo identificador de sesin cada vez que se cambie de HTTP a HTTPS.
Utilice un sistema de control de sesin adicional por requerimiento, para las funciones de alta sensibilidad.
Configure los cookies utilizados en conexiones HTTPS con el atributo "secure".
Configure los cookies con el atributo HttpOnly a menos que especficamente requiera que scripts del lado cliente puedan leerlos y cambiarlos.
Secure Coding Practice Checklist Session Control
Top Ten de Owasp 2013 INJECTION
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
CROSS-SITE SCRIPTING (XSS)
INSECURE DIRECT OBJECT REFERENCES
SECURITY MISCONFIGURATION
SENSITIVE DATA EXPOSURE
MISSING FUNCTION LEVEL ACCESS CONTROL
CROSS-SITE REQUEST FORGERY (CSRF)
USING KNOW VULNERABLE COMPONENTS
UNVALIDATED REDIRECTS AND FORWARDS
Gracias
Recommended