[SOLUCIONADO] seguridad web

[dashtrash]

No encripta ningún id de usuario.
Como te digo, no se usa md5 para encriptar.Se usa como hash.Los campos **clave** de un formulario, es decir: si editas un id de usuario, el id de usuario.Si editas una noticia, el id de la noticia, etc,etc, *no* se envía al html. Lo que se envía, es un hash que indica en qué variable de sesión, se han almacenado los campos clave de ese objeto.
Se usa para evitar fallos de chequeos de permisos en queries, y que sea posible editar objetos que en principio el usuario no debería.Hay miles y miles de formularios que confían en que el campo clave (que suele ser un 'hidden'), es seguro, cuando es tan manipulable como cualquier otro.

[dashtrash]

No se encripta ningún id.
Se crea un hash que identifica al formulario.Los campos *clave* del formulario, por ejemplo, el id de usuario, *no se envía al cliente*, sino que se guardan en la sesión bajo esa clave creada con un hash.Si editas al usuario con id 10, ese id no se envia al html (ni sin encriptar, ni encriptado).Evitas tanto que se manipule el id por el lado del cliente, como ciertos tipos de ataques CSRF.

[David1992]

Alguno trucos para hacer nuestro sitio web más seguro:


- Trabajar con los datos que el cliente comparte encriptados, de este modo evitaremos posibles ataques de injección.

- Nunca usar el mismo encriptado para trabajar con el servidor y para proporcionar ids a los usuarios.

- Nunca imprimir en el codigo fuente (lado del cliente) contenido vulnerable para el servidor, tales como direcciones completas o parciales con valor de directorio local, ids de conexión o permisos, etc...

- Filtrar valores no encriptables por caracteres especificos, tales como letras de la A a la Z, números, tildes, parentesis, etc... no permitiendo segun el caso el uso de comillas entre otros.

- Intentar dar el mismo servicio por un mismo puerto genérico, para un formulario de envio de emails en PHP se puede usar el puerto 80 al igual que para el enlazado a archivos del servidor, no es necesario montar un FTP para cuatro imágenes.

- Repasar las variables en la programación y en la recogida de datos no dejando interrogantes posibles que causen "fakes" en el servidor.

- Dar permisos a ficheros y directorios de nuestro servidor segun vaya a emplearlo el propio servidor, si en una carpeta solo necesitamos leer le daremos permiso de solo lectura al usuario que mantiene el S.O. servidor conectado.

:p me faltaran muchos puntos clave seguramente pero estos son los que mas me encuentro por la red, tales como puertos inecesarios, servidores FTP para las imagenes de la web y cosas asi, espero que les sea de utilidad.

[David1992]

Iniciado por dashtrash

No se encripta ningún id.
Se crea un hash que identifica al formulario.Los campos *clave* del formulario, por ejemplo, el id de usuario, *no se envía al cliente*, sino que se guardan en la sesión bajo esa clave creada con un hash.Si editas al usuario con id 10, ese id no se envia al html (ni sin encriptar, ni encriptado).Evitas tanto que se manipule el id por el lado del cliente, como ciertos tipos de ataques CSRF.

Uiss como estava en la pág 2 no lo habia leido, yo lo que hago es trabajar con encriptación unidireccional, asi aunque por lo que sea logren descargarse los ficheros del servidor no podran desencriptar la información y como las variables de sesion se pueden usar varias, en otra pongo el nombre de usuario para que el usuario lo vea y ya esta, ni siquiera yo puedo ver la info del usuario, asi me aseguro de que si hay robo de cuenta es por despieste del usuario y no por mi lvl de seguridad.

[webankenovi]

TOP 10 OWASP

1 - Injection - https://www.owasp.org/index.php/Top_10_2010-A1
2 - Cross-Site Scripting (XSS) - https://www.owasp.org/index.php/Top_10_2010-A2
3 - Broken Authentication and Session Management - https://www.owasp.org/index.php/Top_10_2010-A3
4 - Insecure Direct Object References - Insecure Direct Object References - https://www.owasp.org/index.php/Top_10_2010-A4
5 - Cross-Site Request Forgery (CSRF) - https://www.owasp.org/index.php/Top_10_2010-A5
6 - Security Misconfiguration - https://www.owasp.org/index.php/Top_10_2010-A6
7 - Insecure Cryptographic Storage - https://www.owasp.org/index.php/Top_10_2010-A7
8 - Failure to Restrict URL Access - https://www.owasp.org/index.php/Top_10_2010-A8
9 - Insufficient Transport Layer Protection - https://www.owasp.org/index.php/Top_10_2010-A9
10 - Unvalidated Redirects and Forwards - https://www.owasp.org/index.php/Top_10_2010-A10


testing

https://www.owasp.org/index.php/OWAS...le_of_Contents


De la A a la Z

A

Account lockout attack
Asymmetric resource consumption (amplification)

B

Binary planting
Blind SQL Injection
Blind XPath Injection
Brute force attack
Buffer overflow attack

C

Cache Poisoning
Cash Overflow
Code Injection
Command Injection
Comment Injection Attack
Content Security Policy
Content Spoofing
CORS OriginHeaderScrutiny
CORS RequestPreflighScrutiny
Cross Frame Scripting
Cross Site History Manipulation (XSHM)
Cross Site Tracing
Cross-Site Request Forgery (CSRF)
Cross-site Scripting (XSS)
Cross-User Defacement
Cryptanalysis


C cont.

CSRF
Custom Special Character Injection

D

Denial of Service
Direct Dynamic Code Evaluation ('Eval Injection')
Direct Static Code Injection
Double Encoding

E

Execution After Redirect (EAR)

F

Forced browsing
Format string attack
Full Path Disclosure

H

HTTP Request Smuggling
HTTP Response Splitting

I

Inyección SQL

L

LDAP injection

M

Man-in-the-browser attack
Man-in-the-middle attack
Mobile code: invoking untrusted mobile code
Mobile code: non-final public field
Mobile code: object hijack

O

One-Click Attack
Overflow Binary Resource File

P

Page Hijacking
Parameter Delimiter


P cont.

Path Manipulation
Path Traversal

R

Regular expression Denial of Service - ReDoS
Relative Path Traversal
Repudiation Attack
Resource Injection

S

Server-Side Includes (SSI) Injection
Session fixation
Session hijacking attack
Session Prediction
Setting Manipulation
Special Element Injection
Spyware
SQL Injection

T

Traffic flood
Trojan Horse

U

Unicode Encoding

W

Web Parameter Tampering
Windows ::DATA alternate data stream

X

XPATH Injection
XPATH Injection Java
XSRF


RECOMENDACIONES

nunca confiar en los usuarios
hasear contraseñas
autenticacion de usuarios
autorizacion usuarios niveles
Mensajes de error deben ser genéricos.no dar informacion (en ninguna pagina)
token formularios
habilitar captcha en formularios
Siempre inicializar las variables
consultas sql preparadas y saneamiento de datos
Restringir permisos a usuario de MySQL u otra base de datos
seguridad de puertos
proteger directorios .htaccess
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles
verificar codigo
realizar testing auditoria de tu codigo fuzzing

-----------------------------------
| aRmAtE dE vAlOr PaRa UnA dUrA bAtAllA |
-----------------------------------

[webankenovi]

5.5.1. Guía de seguridad general

Cualquiera que utilice MySQL en un ordenador conectado a Internet debería leer esta sección para evitar los errores de seguridad más comunes.

http://dev.mysql.com/doc/refman/5.0/...uidelines.html

[webankenovi]

Vuel vo con una nueva entrada como de costumbre , esta vez con el top ten 2013 de owasp recien salido del horno, aunque decir que no hay apenas cambios

pagina oficial owasp
https://www.owasp.org/index.php/Top_10_2013-T10

blog chema alonso donde explica un poco la lista
http://www.elladodelmal.com/2013/03/...candidate.html

Y un poco sobre administracion de sessiones
https://www.owasp.org/index.php/Sess...nt_Cheat_Sheet

saludos ::..

[webankenovi]

Para resolver muchas dudas de los usuarios respecto al uso que se debe dar a las contraseñas y su hash , aqui os dejo una faq de php que resolvera alguna de vuestras dudas y hara vuestra aplicacion algo mas segura.

la faq responde a estas preguntas

- ¿Por qué debo usar hash en las contraseñas de los usuarios de mi aplicación?
- ¿Por qué las funciones hash más comunes como md5() y sha1() no son adecuadas para las contraseñas?
- ¿Qué hash debo aplicar a mis contraseñas, si las funciones hash más comunes no son adecuadas?
- ¿Qué es el salt?

http://es.php.net/manual/es/faq.passwords.php

[loncho_rojas]

Iniciado por webankenovi

RECOMENDACIONES

nunca confiar en los usuarios

Jajaja.. esto está bueno

[webankenovi]

Hoy traigo una nueva recomendacion, de un tema que aun no hemos tocado

Archivo de Configuración

'config.txt,config.php,config.ini,config.conf'

Cuando esté trabajando con archivos de configuración para su aplicación, las mejores prácticas dictan que utilice uno de los métodos siguientes:

- Es recomendable que almacene sus archivos de configuración donde no se pueda acceder a ellos directamente por medio del sistema de archivos.

- Si no tiene otra alternativa más que almacenar sus archivos de configuración en la raíz de documentos de su aplicación, debe adjuntar la extensión.php al nombre de sus archivos. De esta manera, aun si alguien accede a ellos directamente, la información no será impresa en forma de texto a la pantalla.

- La información en los archivos de configuración debe ser protegida ya sea por medio de codificación o con los permisos de grupo/usuario pertinentes en el sistema de archivos.

extraido de http://es.phptherightway.com/ donde puedes encontrar buenas practicas programando con php.

saludos . .

[webankenovi]

Despues de comentar un poquito sobre las vulnerabilidades llego la hora de la practica donde intentare ir explicando por capitulos cada una de ellas y por supuesto espero que con vuestra colaboracion

CAPITULO 1

Proteger directorios

- Seguramente en tu aplicacion tendras directorios donde no deseas que se pueda acceder a ellos directamente desde la url , para conseguir denegar el acceso voy a explicar 2 formas diferentes pero que pueden trabajar juntas .

1 - Crear un archivo .htaccess dentro del directorio en cuestion si el directorio se llama system por ejemplo el archivo debera encontrarse dentro de system/.htaccess , si tenemos mas directorios dentro de system igualmente deberemos crear el archivo .htaccess para garantizar que no se pueda acceder a ellos .

contenido .htaccess

Código Apache:

# en primer lugar prevenimos el listado de las carpetas
IndexIgnore *
 
# en segundo no mostramos ningun listado , no indexa nada
Options All -Indexes
 
# en tercera denegamos cualquier acceso a cualquier archivo
Deny from all
 

tambien se debera agregar un index.html vacio dentro de todos los directorios ademas del .htaccess, seguridad extra para evitar el listado de los directorios y archivos

2- con php se crea una verificacion en los archivos donde no se desee que se pueda acceder desde la url

una verificacion , verificando si existe la constante en los archivos a proteger, la cual la debe de contener el archivo desde el que es llamado

protegido.php

Código PHP:

<?php
if( ! defined('constante_de_seguridad'))
{
exit('acceso denegado');
}
?>
 

ahora imaginemos que tenemos un index.php desde el cual queremos incluir un archivo protegido

index.php

Código PHP:

<?php
define('constante_de_seguridad',true); // ya esta creada la constante y ya podemos acceder al fichero
 
include'protegido.php'; // si no estuviera definida la constante anterior se mostraria un mensaje de acceso denegado
 
?>
 

Recuerda siempre los nombres de tus archivos y carpetas delicados no sean muy comunes y esten en lugares no muy previsibles.

observaciones : tambien se puede usar como otra medida un sistema de permisos para los usuarios, pero eso lo contare en un proximo capitulo sobre permisos y roles.

y esto es todo sobre el capitulo 1 , si sabes mas maneras de proteger archivos y/o directorios o de mejorar alguna ya expuesta o solo mostrar tu opinion ,por favor exponlo .

saludos y de aqui a nada seguimos con el capitulo 2

[webankenovi]

CAPITULO 2

Mensajes de error

- Respecto a los mensajes de error, no es recomendable mostrar ningun tipo de fallo de la aplicacion en produccion ya que es informacion que un usuario puede usar para despues usar para ciertos ataques por ello hemos de prevenir no revelar esa informacion , por lo cual desactivaremos mostrar mensajes de error.

en todos los archivos php desactivaremos los mensajes de error

ya sea en tu archivo php.ini o a traves de en tiempo de ejecucion , debemos desactivar display_errors y display_startup_errors , si no tienes acceso al php.ini deberemos hacerlo de esta forma

ini_set('display_errors','Off');
ini_set('display_startup_errors',false);

puedes insertarlo en cada archivo al principio de el o mediante un include para que sea maz facil su aztualizacion en caso de necesitarlo

Código PHP:

include 'display.php';
 

display.php

Código PHP:

<?php
ini_set('display_errors','Off');
ini_set('display_startup_errors',false);
?>
 

otra opcion es crear un entorno de trabajo

Código PHP:

define('ENTORNO','Desarrollo',false);
     
            switch(constant('ENTORNO'))
            {
                case 'Desarrollo':
         
                ini_set('display_errors','On');
         
                ini_set('display_startup_errors',true);
         
                break;
         
                case 'Produccion':
         
                ini_set('display_errors','Off');
         
                ini_set('display_startup_errors',false);
            }
 

Recuerda no dar informacion sensible si no mas bien generica un ejemplo es el siguiente

un archivo de login que al introducir el usuario mal, me responde :

- el usuario no existe

al introducir el usuario bien y la contraseña mal, me responde:

- la contraseña no es correcta

con lo cual me deja claro que el user si existe , deberia mostrar en tal caso

- el usuario o la contraseña no son correctos

usa la logica y no confies nunca en los usuarios

Eso es todo sobre el capitulo 2 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 3

capitulos

1 - proteger directorios : link http://www.forosdelweb.com/f18/segur...ml#post4410846

[webankenovi]

CAPITULO 3

Archivo de configuracion

- Para proteger el archivo de configuracion , lo primero es testear lo siguiente introduce la url hacia tu archivo de configuracion en el navegador y no deberia verse ningun elemento , deberia aparecer blanco y sin ningun codigo fuente (y si redirige hacia fuera o bloquea el acceso mejor aun , como explicamos en el capitulo 1 ), si no es asi , vamos a protegerlo de una manera basica

- 1 lo primero es ver la extension del archivo por seguridad deberia ser .php ya que no es accesible el contenido del codigo desde el navegador ya que si fuera .txt este si sera accesible desde el navegador .

- 2 usar lo que explique en el capitulo 1 para proteger los archivos y directorios sensibles de esta manera se negara el acceso a dicho archivo

- 3 codificar la informacion contenida en el

por lo cual si el archivo de configuracion estuviera en system/configuracion.ext , este directorio deberia contener un .htacces con el contenido publicado en capitulo1 , ademas deberia de contener un index.html , ademas en archivo de configuracion.php deberia de contener la constante de seguridad publicada en el capitulo 1 y ademas codificar la informacion del archivo.

un ejemplo sencillo de codificacion prodia ser base64_encode

Código PHP:

<?php
 
if( ! defined('constante_de_seguridad'))
{
exit('acceso denegado');
}
 
$config['url'] = 'd2Vi';
 
// en vez de 
 
$config['url'] = 'web';
 
?>
 

Eso es todo sobre el capitulo 3 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 4

capitulos

1 - proteger directorios : link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140

[ghost_darknet]

http://php.net/manual/es/filter.filters.sanitize.php

para sanitizar las variables y de uso facil

[webankenovi]

CAPITULO 4

Permisos y roles

- esta vez vamos a proteger aun mas los archivos dandoles permisos y roles segun el usuario. un sistema basico

- 1 vamos a crear los permisos y roles

Código PHP:

<?php
 
// invitado = 0
// logueado , usuario normal = 1 
// logueado , usuario administrador = 2
 
 
// primero en la base de datos debemos guardar esos roles segun el usuario en el momento del registro o manualmente 
// a poder ser codificada o hasheada por si alguien accede a la base de datos no sepa el estatus de los usuarios , aunque podria intuirlo pero bueno . .
 
// por defecto los user tendran un rol 1 
 
INSERT INTO user (rol) VALUES (sha1('1'.'salt_rol'))
 
// ahora en el login seleccionaremos el rol y lo guardaremos en una session
 
SELECT rol FROM user
 
$_SESSION['ROL'] = $row['rol'];
 
 
?>
 

- 2 ya en el script de permisos.php , este se ha de incluir en todas las paginas

Código PHP:

<?php
 
if(isset($_SESSION['ROL']))
{
    switch($_SESSION['ROL'])
    {
        case sha1('1'.'salt_rol'):
        $user['rol'] = 'usuario';
        break;
 
        case sha1('2'.'salt_rol'):
        $user['rol'] = 'administrador';
        break;
 
        default:
        $user['rol'] = 'invitado';
    }
}
else
{
    $user['rol'] = 'invitado';
}
 
?>
 

ya tenemos los roles ahora sera cuestion de la pagina los permisos que queramos darles por ejemplo para acceder a logout.php un usuario tiene que estar logueado por lo cual un invitado no podra leer el archivo no es logico que intente acceder un invitado a dicho archivo por lo cual solo tendran acceso usuarios y administradores

logout.php

Código PHP:

<?php
 
if($user['rol'] == 'usuario' || $user['rol'] == 'administrador')
{
 
// validar login
// codigo de logout
 
 
}else{
 
// denegado el acceso para cualquiera que no sea usuario o admnistrador
 
exit('no tienes acceso para ver la pagina');
 
}
 
?>
 

no confundir los permisos con las validaciones de login , tambien hay que validar si el usuario es un usuario logueado

ahora otro ejemplo index.php

Código PHP:

<?php
 
if($user['rol'] == invitado|| $user['rol'] == 'usuario' || $user['rol'] == 'administrador')
{
 
// accesible para todos pero aqui se podria dividir contenido para usuarios o invitados
 
if($user['rol'] == 'usuario' || $user['rol'] == 'administrador')
{
 
// contenido para supuestos logueados , por que aun habria que validarlos
 
}
else
{
 
// contenido para invitados
 
}
 
}
 
?>
 

ahora si deseas dar pèrmisos de escritura deberas darselo solo a administradores

Código PHP:

<?php
 
if($user['rol'] == 'administrador')
{
 
// contenido para escritura
 
}
 
?>
 

observaciones : [U]no olvides dar los permisos en tus archivos y directorios en tu hosting [U]

Eso es todo sobre el capitulo 4 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 5

capitulos

1 - proteger directorios : link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - manejar errores : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159

[webankenovi]

CAPITULO 5

Verificacion de archivos

- Para asegurarnos que nuestros archivos no han sido modificados, vamos a realizar una comparacion de hashes para verificar que el archivo no ha sido alterado con codigo malicioso etc.....

existen varias formas pero yo me voy a centrar en 1 muy basica

1 - en el documento verificaremos que el hash proporcionado en el momento de la peticion es exactamente igual al hash que obtuvimos justo antes de la subida o al final la creacion de el lo que mas guste jejeje.

Código PHP:

<?php
 
 
// para obtener el hash realizamos sha1_file('index.php');  y lo guardamos en el archivo 
 
// ahora antes ejecutar ningun codigo verificaremos dicho hash
 
if(sha1_file(realpath(__FILE__)) == 'DJSFVD8VD9HSD8VHD8FHSV98FDHV8HV') // HASH OBTENIDO PREVIAMENTE
{
 
// contenido
 
}else{
 
exit('archivo corrupto');
 
}
 
?>
 

Eso es todo sobre el capitulo 5 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 6

capitulos

1 - proteger directorios : link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275

[andresdzphp]

Estos últimos capítulos son muy interesantes, sigue así +1

[HiToGoRoShi]

Solución a todo esto? aprender a usar un framework

[webankenovi]

Bueno lo que intento es orientar para tener unas nociones minimas , ya que cada dia veo muchisima gente que tiene mucho desconocimiento en estos temas y lo que se intenta es ayudar un poco a entenderlos , alomejor me equivoco en algunas cosas pero intento hacerlo y explicarlo lo mejor que puedo y de una forma que cualquiera lo pueda entender.

andresdzphp, intentare seguir asi si el tiempo me deja

[webankenovi]

Iniciado por webankenovi

CAPITULO 5

Verificacion de archivos

- Para asegurarnos que nuestros archivos no han sido modificados, vamos a realizar una comparacion de hashes para verificar que el archivo no ha sido alterado con codigo malicioso etc.....

existen varias formas pero yo me voy a centrar en 1 muy basica

1 - en el documento verificaremos que el hash proporcionado en el momento de la peticion es exactamente igual al hash que obtuvimos justo antes de la subida o al final la creacion de el lo que mas guste jejeje.

Código PHP:

<?php
 
 
// para obtener el hash realizamos sha1_file('index.php');  y lo guardamos en el archivo 
 
// ahora antes ejecutar ningun codigo verificaremos dicho hash
 
if(sha1_file(realpath(__FILE__)) == 'DJSFVD8VD9HSD8VHD8FHSV98FDHV8HV') // HASH OBTENIDO PREVIAMENTE
{
 
// contenido
 
}else{
 
exit('archivo corrupto');
 
}
 
?>
 

Eso es todo sobre el capitulo 5 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 6

capitulos

1 - proteger directorios : link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275

RE-EDIT CAPITULO 5

Me equivoque en el script ya que el hash obtenido previamente nunca sera igual al has resultante al añadir el hash en el script despues de obtenerlo modificara el hash resultante y nunca coincidiran, por lo tanto hay que hacerlo desde fuera del archivo.

arreglo

Código PHP:

<?php
 
// hashes.php contendra los hash de los archivos 
// ejemplo 
// $hash_login = 'FG67uRFVCrtki875tr'; 
// para obtenerlo y tenerlo codificado base64_encode(sha1_file('login.php'))
 
include 'hashes.php ';
 
if(sha1_file('login.php') == base64_decode($hash_login))
{
include 'login.php'; 
}else{
 
exit('archivo corrupto');
 
}
 
?>
 

[webankenovi]

CAPITULO 6

CONFIGURACION DE SESSIONES

- Ahora que ya tenemos mas o menos protegidos nuestros archivos y asignado un rol al usuario , vamos a configurar las sessiones

1 - configuremos las directivas de session

si no se tiene acceso al archivo php.ini deberemos modificarlo en tiempo de ejecucion

algunas directivas muy pocas no se comentan, no afectan .

Código PHP:

<?php
 
// ruta donde guardaremos los archivos creados.
ini_set('session.save_path','ruta');
 
// nombre de la session que se usa como nombre de la cookie
ini_set('session.name','por defecto PHPSESSID');
 
// inicia una session automaticamente
ini_set('session.auto_start',false);
 
// contiene la subcadena para comprobar cada HTTP Referer. Si la Referencia fue enviada por el cliente y la subcadena no se encontró, 
// el id de sesión embebido será marcado como no válido
ini_set('session.referer_check','');
 
// almacenar el id de session en una cookie en la parte del cliente
ini_set('session.use_cookies',true);
 
// usar cookies para almacenar el id de sesión en la parte del cliente, 
// este ajuste previene ataques que impican pasar el id de sesión en la URL
ini_set('session.use_only_cookie',true);
 
// tiempo de vida en segundos de la cookie que es enviada al navegador.
ini_set('session.cookie_lifetime',0); // 0 por defecto hasta que se cierre el navegador
 
// especifica la ruta a establecer en la cookie de sesión. Por defecto es /.
ini_set('session.cookie_path','ruta');
 
// especifica el dominio a establecer en la cookie de sesión
ini_set('session.cookie_domain','dominio');
 
// especifica si las cookies deberían enviarse sólo sobre conexiones seguras, esto dependera de cada dominio 
ini_set('session.cookie_secure ',0);
 
// Marca la cookie como accesible sólo a través del protocolo HTTP. Esto siginifica que la cookie no será accesible por lenguajes de script, tales como JavaScript. 
// Este ajuste puede ayudar de manera efectiva a reducir robos de indentidad a través de ataques 
ini_set('session.cookie_httponly',1);
 
// especifica el método de control de caché usado por páginas de sesión
ini_set('session.cache_limiter','nocache');
 
// especifica el tiempo de vida en minutos para las páginas de sesión examinada
ini_set('session.cache_expire',valor deseado);
 
// si está habilitado sid transparente o no
ini_set('session.use_trans_sid',0); 
 
// directivas eliminadas en 5.4 en versiones inferiores desactivar
 
ini_set('session.bug_compat_warn',0); 
ini_set('session.bug_compat_42',0); 
 
// algoritmo hash utilizado para generar los ID de sesión.
ini_set('session.hash_function','algoritmo soportado'); // se puede obtener algoritmos soportados con la funcion hash_algo() , por defecto '0' md5 ,'1' sha-1
 
// especifica qué etiquetas HTML son reescritas para incluir el id de sesión si el soporte para sid transparente está habilitado, 
// desabilitandolo no incluiremos el id de session en las etiquetas a=href,area=href,frame=src,input=src,form=fakeentry,fieldset=
ini_set('url_rewriter.tags',null);
 
?>
 

Eso es todo sobre el capitulo 6 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 7

capitulos

1 - proteger directorios :link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275
5 - verificacion de archivos : link http://www.forosdelweb.com/f18/segur...ml#post4412596

[webankenovi]

CAPITULO 7

SESSION HIJACKING

- es tan solo un ejemplo sencillo que usted puede mejorar.

- login

// una vez verificado el usuario procedemos a crear una cadena para su verificacion en el caso de que le secuestren una session intentar proteger la cuenta del usuario en la medida de lo posible .

Código PHP:

$rand = rand();
$token = hash('whirpool',session_id().$rand);
$credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);
 

// guardamos en la bd del usuario sus credenciales
// y guardamos en la cookie el rand

Código PHP:

setcookie("dmz_", base64_encode($rand));
 

comprobacion en todas las peticiones (paginas)

// antes deberemos verificar que el usuario esta logueado con la variable de session que usted haya creado para validar al usuario como logueado inmediatamente despues realizamos la 2 verificacion comprobara sus credenciales

Código PHP:

if(isset($_COOKIE['dmz_']))
    {
        $rand         = base64_decode($_COOKIE['dmz_']);
        $token        = hash('whirpool',session_id().$rand);
        $credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);
         
        // realizamos una consulta en la bd y extraemos los credenciales guardados en el login y comparamos
     
        if($row['credenciales'] == $credenciales)
        {
            // si es correcto generamos un nuevo session id y un nuevo rand y volvemos a guardar los credenciales
     
            session_regenerate_id();
            unset($_COOKIE['dmz_']);
     
            $rand            = rand();
            $token          = hash('whirpool',session_id().$rand);
            $credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);
     
            // guardamos en la bd del usuario sus credenciales
            // y guardamos en la cookie el rand
     
            setcookie("dmz_", base64_encode($rand));
        }
        else
        {
            exit('session hijacking');
        }
    }
 

Eso es todo sobre el capitulo 7 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 8

capitulos

1 - proteger directorios :link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275
5 - verificacion de archivos : link http://www.forosdelweb.com/f18/segur...ml#post4412596
6 - configuracion de sessiones : link http://www.forosdelweb.com/f18/segur...ml#post4416219

[webankenovi]

CAPITULO 8

HASH DE CONTRASEÑA

- Vamos a procedeer a registrar la contraseña hasheada en la bd en el momento del registro y despues en el login su posterior autentificacion

- que vamos a usar , pues vamos a usar crypt con el algoritmo blowfish

- El algoritmo Blowfish no puede ser aplicado en todos los sistemas. puedes revisar tu sistema con el siguiente codigo

Código PHP:

<?php
 
if (CRYPT_BLOWFISH == 1) {
    echo "Yes";
} else {
    echo "No";
}
?>
 

A partir de PHP 5.3.0 crypt , PHP contiene su propia implementación y la utilizará si el sistema carece de soporte para uno o varios de los algoritmos.


1 - registro, solo vamos a centrarnos en la pass los demas datos deberas tambien registrarlos en el mismo script pero eso no entra en este capitulo

Código PHP:

<?php
 
// validar datos del formulario, previamente
 
if(isset($_POST['password']))
{
 
// como ejercicio se debera verificar que la contraseña tiene mas de 8 caracteres por lo menos una mayuscula y una minuscula algun numero y algunos signos que se permitan .
 
// tambien se debera exponer en el formulario de registro la re-pass es decir pass y re-pass ambas deben de coincidir 
 
if($_POST['password'] != $_POST['re-password'] )
{
// las contraseñas no coinciden
}
 
 
$password = $_POST['password']; // password
$algoritmo = '$2y$'; // blowfish
$coste = '10'; // coste 
$salt= '$aquidebesponerelsalt$'; // el algoritmo coste y salt deberan ser el mismo en la pagina de validacion del login
$hash = crypt($password,$algoritmo.$coste.$salt);
 
// guardamos la pass  $hash en la bd del usuario
 
 
}
?>
 

2 - login

Código PHP:

<?php
 
// validar los datos , previamente 
 
// extraer la pass del usuario de la bd y comparamos
 
 
$password = $_POST['password']; // password
$algoritmo = '$2y$'; // blowfish
$coste = '10'; // coste 
$salt= '$aquidebesponerelsalt$'; // el algoritmo coste y salt deberan ser el mismo en la pagina de validacion del login
$hash = crypt($password,$algoritmo.$coste.$salt);
 
 
if ($hash == $database['password']) 
{
    // acceso concedido
} 
else
{
    // acceso denegado
}
 
?>
 

Eso es todo sobre el capitulo 8 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo .


Saludos nos vemos nuevamente con el capitulo 9

capitulos

1 - proteger directorios :link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275
5 - verificacion de archivos : link http://www.forosdelweb.com/f18/segur...ml#post4412596
6 - configuracion de sessiones : link http://www.forosdelweb.com/f18/segur...ml#post4416219
7 - session hijacking : link http://www.forosdelweb.com/f18/segur...ml#post4419281

[andresdzphp]

+1 Muy bueno el capítulo 8, también se puede almacenar el salt aparte y hacer algo así cierto?

Código PHP:

if (crypt($password, $data['salt']) == $data['password']) {
 

[webankenovi]

gracias, se hace lo que se puede

Si claro si ves en el ejemplo

crypt($password,$algoritmo.$coste.$salt);

lo marcado en rojo esta almacenado fuera de la funcion, lo puse simple por hacerlo mas sencillo pero el salt deberia estar bastante protegido y fuera del alcance publico , aunque el salt lo guardes fuera no hay que olvidarse del algoritmo y el coste de lo contrario puede dar resultados inesperados

[SamyCanales]

Hola a todos, hace unos días yo en Taringa! hallé un post dónde exponían un pequeño código que al introducirlo lograbas vulnerar algunos sistemas de autentificación, ¡Y en efecto, funciona!

Desgraciadamente borraron el post pero el código se parecía a esto:

OR"='

(no es el original, el original tenia signos que yo no puedo sacar con mi teclado)

¿Alguien me puede explicar como funciona?

[webankenovi]

tiene pinta de ser sql injection , de hecho si en la aplicacion en el momento del login no validan ningun dato o mal validados , proveniente del formulario estos se inyectan en la consulta y se puede tener acceso en el momento del login , ademas de muchas otras cosas informacion de la bd , contraseñas etc....

ese es un tema que se resuelve validando correctamente los datos de entrada escapando y usando sentencias preparadas y procedimientos almacenados.

en este post ay mucha informacion sobre sql injection y proximamente hare un capitulo sobre ello

[webankenovi]

CAPITULO 9

EVITAR INYECCION SQL MEDIANTE PDO

En este capitulo trataremos de evitar la inyeccion en nuestra base de datos, es tan solo un ejemplo basico (se deberia de mejorar) que espero sirva como guia.

!!! RECUERDEN !!!

mysql esta deprecado no deberia usarse en nuevos proyectos en su lugar PDO o mysqli, en proyectos que ya usaban mysql deberian de migrar.

Aqui dejo links de ayuda

PDO
http://es1.php.net/manual/es/book.pdo.php

CONEXION
http://es1.php.net/manual/es/pdo.connections.php

TRANSACIONES Y AUTO-COMMIT (no se habla en este capitulo de este tema)
http://es1.php.net/manual/es/pdo.transactions.php

SENTENCIAS PREPARADAS Y PROCEDIMIENTOS ALMACENADOS
http://es1.php.net/manual/es/pdo.pre...statements.php

ERRORES
http://es1.php.net/manual/es/pdo.error-handling.php


1 - Conexion

- La conexion se establece creando instancias de la clase PDO, no importa el controlador que se utilice, siempre se usara el nombre de la clase PDO.

- Si la aplicación no captura la excepción lanzada por el constructor de PDO, la acción predeterminada que toma el motor zend es la de finalizar el script y mostrar información de rastreo.
Esta información probablemente revelará todos los detalles de la conexión a la base de datos, incluyendo el nombre de usuario y la contraseña.
Es sumamente importante capturar esta excepción, ya sea explícitamente (con una sentencia catch) o implícitamente por medio de set_exception_handler().

Código PHP:

$dsn = 'mysql:dbname=testdb;host=127.0.0.1';
$usuario = 'usuario';
$contraseña = 'contraseña';
 
try {
 
    $gbd = new PDO($dsn, $usuario, $contraseña);
 
} catch (PDOException $e) {
 
    print "¡Error!: " . $e->getMessage() . "<br/>";
    die();
}
 

2 - Sentencias preparadas y procedimientos almacenados

- Inserciones

Código PHP:

$sentencia = $gbd->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
 
$sentencia->bindParam(':name', $nombre);
$sentencia->bindParam(':value', $valor);
 
$nombre = 'uno';
$valor = 1;
$sentencia->execute();
 

- Obtencion de datos

Código PHP:

$sentencia = $gbd->prepare("SELECT * FROM REGISTRY where name = ?");
 
if ($sentencia->execute(array($_GET['name']))) 
{
  while ($fila = $sentencia->fetch()) 
  {
    print_r($fila);
  }
}
 

Tambien podemos crear un filtro antes de ejecutar una sentencia

Código PHP:

function filter($data,$filter)
{
    switch($filter)
    {
        case 'alpha';
 
        if( ! ctype_alpha($data)) // validar caracteres alfabeticos solamente  [A-Za-z]
        {
            exit('el valor contiene caracteres ilegales');
        }
 
        return true;
 
        break;
 
        case 'alnum';
 
        if( ! ctype_alnum($data)) // validar caracteres alfanumericos solamente  [A-Za-z0-9]
        {
            exit('el valor contiene caracteres ilegales');
        }
 
        return true;
 
        break;
 
        case 'digit';
 
        if( ! ctype_digit($data)) // validar caracteres numericos solamente  [0-9]
        {
            exit('el valor contiene caracteres ilegales');
        }
 
        return true;
 
        break;
 
        // asi podriamos crear muchos mas filtros, para correos etc..........
        // los mensajes de error se pueden personalizar o hacer cualquier otra cosa como mandarle a otra pagina funcion etc... tan solo es un ejemplo
 
    }
 
}
 

// unimos todo lo mencionado y obtenemos lo siguiente

Código PHP:

$dsn = 'mysql:dbname=testdb;host=127.0.0.1';
$usuario = 'usuario';
$contraseña = 'contraseña';
 
try {
 
    $gbd = new PDO($dsn, $usuario, $contraseña);
 
} catch (PDOException $e) {
 
    print "¡Error!: " . $e->getMessage() . "<br/>";
    die();
}
 
    // insercion
 
    $sentencia = $gbd->prepare(" INSERT INTO REGISTRY (nombre, edad) VALUES (:nombre, :edad)");
 
    $sentencia->bindParam(':nombre', $nombre);
 
    $sentencia->bindParam(':edad', $edad);
 
        $nombre = 'uno';
        $edad = 1;
 
        $sentencia->execute(); // ejecutamos la sentencia
 
 
        // obtencion de datos
 
        $sentencia = $gbd->prepare(" SELECT * FROM REGISTRY where nombre = ? ");
 
        $name = filter($_GET['nombre'],'alpha'); // verificacion del filtro
 
        if ($sentencia->execute($name)))
        {
            while($fila = $sentencia->fetch()) 
            {
                print_r($fila);
            }
        }
 
    $gbd = null; // cerramos la conexion
 

Eso es todo sobre el capitulo 9 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo.


Saludos nos vemos nuevamente con el capitulo 10.

1 - proteger directorios :link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275
5 - verificacion de archivos : link http://www.forosdelweb.com/f18/segur...ml#post4412596
6 - configuracion de sessiones : link http://www.forosdelweb.com/f18/segur...ml#post4416219
7 - session hijacking : link http://www.forosdelweb.com/f18/segur...ml#post4419281
8 - hash de contraseñas : link http://www.forosdelweb.com/f18/segur...ml#post4421471

[webankenovi]

Si alguien desea que toque algun tema en especial referente a seguridad solo tiene que decirlo y/o repasar alguna duda sobre los temas expuestos.

Si cres que existe algun error/sugerencia sobre algun tema igualmente te invito a que me lo cuentes para poder corregirlo y/o agregarlo (los ejemplos son basicos para que sirvan de orientacion).

Moderadores si existe algun problema en que haga doble post solo tienen que decirmelo, pero creo post diferentes para cada tema para que quede mas claro.

[webankenovi]

CAPITULO 10

CROSS SITE REQUEST FORGERY

CSRF , digamos que es la capacidad para engañar a un usuario a que realice una accion sin su consentimiento, puede haber acciones de nivel bajo , cambiar idioma , cerrar la session etc... y mas serios como cambiar la contraseña , retirar fondos , cambio de direccion postal , compras etc........

Estos ataques suelen ser enviados a la victima mediante emails, redes sociales ,privados etc....

Para evitar este ataque y prevenir a los usuarios de falsas peticiones , vamos a generar un token de session generado en todas las peticiones.

A la practica pues....

1 mostrare un ejemplo vulnerable y despues veremos la implementacion del token

perfil.php

Código PHP:

<?php
session_start();
 
if(isset($_SESSION['USUARIO']))
{
    // contenido del perfil 
        echo 'Bienvenido "'.$_SESSION['USUARIO'].'"';
    echo '<a href="logout.php">salir</a>';
}
else
{
     echo 'no tienes suficientes permisos para ver esta pagina';
}
?>
 

logout.php (vulnerable)

Código PHP:

<?php
session_start();
session_destroy();
echo 'Has cerrado la session';
?>
 

ejemplo de ataque

Código PHP:

<html>
 <body>
  <p>una imagen muy chula amigo!!</p> 
  <img src="logout.php" style="display: none;">
 </body>
</html>
 

directamente cerrariamos la session ya que la imagen envia una peticion al servidor para acceder a logout.php y en logout no hay ninguna validacion de que el usuario halla pedido cerrar session.

soluciones

perfil.php

Código PHP:

<?php
session_start();
 
if(isset($_SESSION['USUARIO']))
{
    $_SESSION['TOKEN'] = sha1(uniqid(mt_rand().session_id(), true));
 
    // contenido del perfil 
    echo 'Bienvenido "'.$_SESSION['USUARIO'].'"';
    echo '<a href="logout.php?token='.$_SESSION['TOKEN'].'">salir</a>';
}
else
{
    echo 'no tienes suficientes permisos para ver esta pagina';
}
?>
 

logout.php

Código PHP:

<?php
session_start();
 
if(isset($_SESSION['USUARIO']) and isset($_SESSION['TOKEN']) and isset($_GET['token']) and $_GET['token'] == $_SESSION['TOKEN'])
{
    session_destroy();
    echo 'Has cerrado la session';
}
else
{
    exit('CSRF');
}
 
?>
 

Una vez implementado el token el ejemplo de ataque no tendria ningun resultado ya no se cerraria la session evitando asi CSRF.

Bueno eso es todo espero que sriva de inspiracion para crear buenas defensas CSRF.

Eso es todo sobre el capitulo 10 , si sabes otras maneras o mejorar lo expuesto o solo deseas mostrar tu opinion por favor exponlo.


Saludos nos vemos nuevamente con el capitulo 11.

1 - proteger directorios :link http://www.forosdelweb.com/f18/segur...ml#post4410846
2 - mensajes de error : link http://www.forosdelweb.com/f18/segur...ml#post4412140
3 - archivo de configuracion : link http://www.forosdelweb.com/f18/segur...ml#post4412159
4 - permisos y roles : link http://www.forosdelweb.com/f18/segur...ml#post4412275
5 - verificacion de archivos : link http://www.forosdelweb.com/f18/segur...ml#post4412596
6 - configuracion de sessiones : link http://www.forosdelweb.com/f18/segur...ml#post4416219
7 - session hijacking : link http://www.forosdelweb.com/f18/segur...ml#post4419281
8 - hash de contraseñas : link http://www.forosdelweb.com/f18/segur...ml#post4421471
9 - inyeccion sql : link http://www.forosdelweb.com/f18/segur...ml#post4451398