[SOLUCIONADO] seguridad web

[webankenovi]

hola amigos de nuevo , aqui estoy dando la lata de nuevo

Queria crear una lista de todas las vulnerabilidades que puede haber en una web y ataques que se pueden realizar que ustedes conozcan desde el mas tonto que pueda haber.

por ejemplo yo conozco entre otros

xss cross site scripting
injectionsql

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar datos sensibles y base de datos

etc....

ustedes cuales conocen????

esta lista de vulnerabilidades servira de ayuda a programadores para solventar los problemas y ademas me servira de ayuda para un proyecto de seguridad web que estoy tratando la idea es intentar tener una lista lo mas completa

[Rodrhigo]

Esos 2 son los principales "vulnerabilidades que se pueden haber en una web" pero te falta otra importante y de la que derivan cientos de vulnerabilidades y es........

El escaneo de puertos abiertos. Por ejemplo uno puede hacer un nmap(para escanear puertos) a una web y darse cuenta que esa web tiene el puerto 23 (telnet) abierto y entonces se podria hacer fuerza bruta al puerto 23 para tener acceso a la consola del sistema(por dar un ejemplo)....
Tambien podria tener el puerto 3306(MySql) abierto.....osea que soporta una conexion remota a mysql.....y tambien podrias hacer fuerza bruta o probar con contraseñas por defecto para el user "root"..... pero generalmente cuando se abre el puerto 3306 se le añade la opcion para que determinada ip se conecte..... haci que puede no funcionar.

-Otra es el ataque de denegacion de servicio..... pero no hace mas que saturar la web y bajarla pero luego de unas horas de detenerse el ataque vuelve a estar arriba.

Tambien existen formas de engañar a los usuarios(pero no afecta a la web) Configurando los DNS por unos propios..... haci el usuario cuando quiere entrar a una web esta entrando a la web del atacante.

Otra forma de afectar a los usuarios es modificar el archivo host que se encuentra en :
C:\WINDOWS\system32\drivers\etc.... Lo que hace es redireccionar una direccion a la direccion que se le asigne.
Por ejemplo si yo agrego esta linea:
200.10.226.212 www.forosdelweb.com

Lo que pasara es que cada vez que intente acceder a forosdelweb en realidad estare visitando google.com(200.10.226.212)..... y haci el "atacante" podria crear una web similar a forosdelweb y pedirle el user y pass y el usuario pensara que visita la web real...... pero en realidad esta apuntado a la web del atacante.

Salu2

[webankenovi]

pues añado a la lista 'seguridad de puertos' , se puede añadir un script que rechaze la entrada por esos puertos no??

y por las demas cuestiones como no afectan a la web no las vamos a añadir

---------------------------------------------------------------------------------------------


xss cross site scripting
injectionsql

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar datos sensibles y base de datos
seguridad de puertos <---- añadido

[Doch]

muy interesante, estoy haciendo mi web y al acabarla tendré que meterme en todo este fregado de seguridad, así que ya tengo la lista hecha :D

[webankenovi]

bueno esta lista es muy pequeña , aun quedan muchas cosas haber si van añadiendo cosillas.

me alegro que te guste ya que uno de mis propositos es ayudar a esa gente que no tiene muchos o ningun conocimiento de seguridad . . .. . . saludos

---------------------------------------------------------------------------------------------


xss cross site scripting
injectionsql

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos <---- añadido
robo se sessiones<---- añadido
autenticacion de usuarios<---- añadido
autorizacion usuarios niveles<---- añadido
token formularios<---- añadido
proteger directorios .htaccess<---- añadido

[MaxDgy]

Interesante tema!!

Yo conozco un vídeo que muestra como un atacante lleva a cabo su cometido, es realmente una lección pero no sé si estará bien que lo comparta al enlace por aquí.

Saludos!

[webankenovi]

hola amigo , no interesa que la gente sepa como hacer las cosas pero si puedes decir que tipo de ataque fue el que realizo

---------------------------------------------------------------------------------------------


xss cross site scripting
injectionsql
RFI (Remote File Inclusion):<---- añadido

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos <---- añadido
robo se sessiones<---- añadido
autenticacion de usuarios<---- añadido
autorizacion usuarios niveles<---- añadido
token formularios<---- añadido
proteger directorios .htaccess<---- añadido
nunca confiar en los usuarios<---- añadido
no usar variables globales<---- añadido
consultas sql preparadas<---- añadido
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles.<---- añadido
Recuerda definir siempre las variables que vayas a usar.Siempre inicializar las variables<---- añadido
Mensajes de error en el acceso deben ser genéricos.no dar informacion<---- añadido

[webankenovi]

bueno amigos no se corten y colaboren , añado unos temas nuevos en la lista

--------------------------------------------------------------------------------------------


xss cross site scripting
injectionsql
RFI (Remote File Inclusion)
CSRF (Cross Site Request Forgery)<---- añadido
Directory Traversal<---- añadido
Upload Inyection<---- añadido

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos
robo se sessiones
autenticacion de usuarios
autorizacion usuarios niveles
token formularios
proteger directorios .htaccess
nunca confiar en los usuarios
no usar variables globales
consultas sql preparadas
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles.
Recuerda definir siempre las variables que vayas a usar.Siempre inicializar las variables
Mensajes de error en el acceso deben ser genéricos.no dar informacion
verificar codigo<---- añadido

[webankenovi]

cuentes sus experiencias si alguna vez fue atacado para conocer posibles vulnerabilidades

añado 2 nuevos temas a la lista




xss cross site scripting
injectionsql
RFI (Remote File Inclusion)
CSRF (Cross Site Request Forgery)
Directory Traversal
Upload Inyection
Hash Collision Vulnerability<---- añadido

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos
robo se sessiones
autenticacion de usuarios
autorizacion usuarios niveles
token formularios
proteger directorios .htaccess
nunca confiar en los usuarios
no usar variables globales
consultas sql preparadas
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles.
Recuerda definir siempre las variables que vayas a usar.Siempre inicializar las variables
Mensajes de error en el acceso deben ser genéricos.no dar informacion
verificar codigo
habilitar captcha en formularios <---- añadido

[webankenovi]

Hola amigos os traigo una muy buena documentacion sacada del manual de php para prevenir vulnerabilidad de fijación en aplicaciones Web, lastima que este en ingles pero no dejen de leerla por ese pequeño detalle, merece la pena .

http://www.acros.si/papers/session_fixation.pdf

[jossss]

xss cross site scripting
injectionsql
RFI (Remote File Inclusion)
CSRF (Cross Site Request Forgery)
Directory Traversal
Upload Inyection
Hash Collision Vulnerability

no hablo solo de terminos si no de consideraciones a tener en cuenta por ejemplo tambien

escapar datos y consultas
verificar siempre datos y compararlos
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos
robo se sessiones
autenticacion de usuarios
autorizacion usuarios niveles
token formularios
proteger directorios .htaccess
nunca confiar en los usuarios
no usar variables globales
consultas sql preparadas
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles.
Recuerda definir siempre las variables que vayas a usar.Siempre inicializar las variables
Mensajes de error en el acceso deben ser genéricos.no dar informacion
verificar codigo
habilitar captcha en formularios
Restringir permisos a usuario de MySQL u otra base de datos <-------añadido

[webankenovi]

Aporto una charla de para mi uno de los mejores Chema Alonso , habla sobre la seguridad en aplicaciones web , es buenisimo.

http://www.youtube.com/watch?v=JlNh1wiLsQo

[webankenovi]

Añado un nuevo video de chema alonso donde se habla de vulnerabilidades en aplicaciones web escritorio o movil .

http://www.youtube.com/watch?v=lR7KF2rVUYk

ademas os recomiendo un libro , Writing Secure Code by Michael Howard , chema alonso en el video habla de el .

[webankenovi]

xss cross site scripting
- reflected xss <-------añadido
- persistent xss <-------añadido
injectionsql
lateral sql injection <-------añadido
RFI (Remote File Inclusion)
- webshell <-------añadido
CSRF (Cross Site Request Forgery)
Directory Traversal
Upload Inyection
Hash Collision Vulnerability
Session Fixation
clickjacking <-------añadido


tratamiento de datos de entrada escapar y verificacion
tratamiento de datos del servidor , verificar siempre (http_referer , user_agent , etc....) <-------añadido
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
Mensajes de error deben ser genéricos.no dar informacion (en ninguna pagina)
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos
autenticacion de usuarios
autorizacion usuarios niveles
token formularios
proteger directorios .htaccess
nunca confiar en los usuarios
no usar variables globales
consultas sql preparadas y saneamiento de datos
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles.
Recuerda definir siempre las variables que vayas a usar.
Siempre inicializar las variables
verificar codigo
habilitar captcha en formularios
Restringir permisos a usuario de MySQL u otra base de datos
realizar testing auditoria de tu codigo fuzzing <-------añadido
validar archivos, imagenes , etc... que se suben mediante una subida de archivos <-------añadido

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

[webankenovi]

xss cross site scripting
reflected xss
persistent xss
injectionsql
lateral sql injection
RFI (Remote File Inclusion)
JPG file inclusion <-----------añadido
local file inclusion <-----------añadido
webshell
CSRF (Cross Site Request Forgery)
Directory Traversal
Upload Inyection
Hash Collision Vulnerability
Session Fixation
clickjacking


tratamiento de datos de entrada escapar y verificacion
tratamiento de datos del servidor , verificar siempre (http_referer , user_agent , etc....)
desactivar magic_quotes , register_globals y todo lo que tenga que ver con errores display_errors
no mostrar nunca errores a los usuarios
Mensajes de error deben ser genéricos.no dar informacion (en ninguna pagina)
encriptar contraseñas
codificar y proteger datos sensibles y base de datos
seguridad de puertos
autenticacion de usuarios
autorizacion usuarios niveles
token formularios
proteger directorios .htaccess
nunca confiar en los usuarios
no usar variables globales
consultas sql preparadas y saneamiento de datos
nombres de tus archivos y carpetas delicados esten en lugares no muy previsibles.
Recuerda definir siempre las variables que vayas a usar.
Siempre inicializar las variables
verificar codigo
habilitar captcha en formularios
Restringir permisos a usuario de MySQL u otra base de datos
realizar testing auditoria de tu codigo fuzzing
validar archivos, imagenes , etc... que se suben mediante una subida de archivos

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

[dashtrash]

Aporto un par de cosas para ayudar en la seguridad..
- Dejar sólo accesible 1 solo punto de entrada, index.php.Todo el resto de código php no debe ser accesible por http.
- Definir los parámetros que recibe una página.Todas las páginas que puedan accederse en la web, deben tener una configuración que,entre otras cosas, debe definir qué parametros recibe esa página, cuáles son opcionales, cuáles requeridos, y de qué tipo son cada uno.
Por ejemplo, para una página llamada "listado.php", que acepta , por ejemplo, un campo de ordenacion "sortby", y el número de página, sería algo como

Código PHP:

$páginas=array(
       /* ... */
      "listado"=>array(
            "source"=>"pages/listado.php", /* fichero que genera la pagina */ 
             "params"=>array(
                       "sortby"=>array("TYPE"=>"String","REQUIRED"=>false),
                        "page"=>array("TYPE"=>"Integer", "REQUIRED"=>false)
                                     )
                                  )
 

Esto no sólo sirve para el escapeado / binding, etc, sino también como documentación de la página.
Es parecido a ver tu web como una clase, siendo las páginas los métodos públicos.

Estos parámetros, recibidas por $_GET (aunque yo hago cosas parecidas para $_POST), se asignan a un objeto Request, y se hace unset($_GET), antes de incluir pages/listado.php.Todo acceso a los parámetros se hace a través de Request.

Seguridad extra por $_GET se obtiene haciendo hashing de los parámetros de las urls.
Otras medidas son no incluir los campos clave de los formularios (los que usualmente son campos hidden).En vez de esos campos, se incluye un hash, que apunta a una variable de sesion que contiene los índices para ese formulario.
Otra opción es hacer hash de los campos índice, e incluir ese campo hash como otro campo "hidden".
Obviamente, cuando digo "hash", me refiero a hash de valores + cadena secreta.

[webankenovi]

Iniciado por dashtrash

- Dejar sólo accesible 1 solo punto de entrada, index.php.Todo el resto de código php no debe ser accesible por http.

En este punto concuerdo contigo totalmente ya que es la estructura que yo sigo y animo a que apuesten por esta estructura , tiene muchas ventajas.

Iniciado por dashtrash

Otras medidas son no incluir los campos clave de los formularios (los que usualmente son campos hidden).En vez de esos campos, se incluye un hash, que apunta a una variable de sesion que contiene los índices para ese formulario.

podria explicarlo con un ejemplo aunque sea muy basico , para que todo el mundo pueda entenderlo?

muchas gracias por tu aportacion , muy interesante.

De grano en grano llena la gallina el buche.

[dashtrash]

El ejemplo:
Vamos a editar un usuario, con campo clave "id".
En vez de incluir en el formulario:

Código HTML:

<input type="hidden" name="id" value="35" />
 

Lo que se hace en PHP es:

Código PHP:

<?php
   /* Se ha obtenido en $row los datos del usuario.
       MY_SECRET_HASH está definido en la sesion, y es inicializado a una cadena aleatoria.
       $formName es un nombre que le demos al formulario.
   */
   $hash=md5($_SESSION["MY_SECRET_HASH"].$formName.$row["id"]);
   $_SESSION["FORMS"][$hash]=array("id"=>$row["id"]);
?>
<input type="hidden" name="hash" value="<?php echo $hash;?>" />
 

Al recibir el POST, se obtiene el valor de hash, se recupera el id de la sesion, se une con el resto de los $_POST, antes de procesar el formulario.

El objetivo es impedir que, manipulando las variables POST, se acceda a objetos que, por descuido en el lado del servidor, el usuario no puede tener acceso.

[webankenovi]

Ya que estamos aporto una conferencia

Spring I/O 2012 - Seguridad web mediante Spring MVC y HDIV - Roberto Velasco

http://www.youtube.com/watch?v=w-8DQEPubBM

[Triby]

Pues, ya que estamos, agrego una lista de problemas y posibles soluciones: http://www.forosdelweb.com/f18/aport...a-php-1011808/

[webankenovi]

Voy a agregar un aporte , se basa en sanear los datos que entrega el cliente al servidor digamos como una capa intermedia , he de explicar que el script solamente esta basado en datos $_GET pero su uso lo aconsejo en todas las variables $GLOBALS globales y sanear segun la necesidad , este script es automatico y sanea todos los datos que provienen de $_GET antes de llamarlo en la aplicacion para su uso , lo que se trata es entregarselo a la aplicacion ya saneado para su uso , la verificacion sen este caso en los $_GET lo he basado solamente en alfanumericos solo dejaremos pasar datos originales que sean alfanumericos de lo contrario retiraremos cualquier caracter invalido , revaluarla como NULL o destruirla totalmente , antes de el saneamiento guardaremos en memoria en una variable de session el dato original , la intencion es verificar los datos que sean alfanumericos de esta manera estamos fortificando el sistema y eliminado varias vulnerabilidades web.

ami me gusta aplicarlo en vez de solo a $_GET en $GLOBALS y segun el array ya sea $_POST , $_FILES , $_REQUEST aplicar el saneamiento correspondiente , asegurandonos de que no entra nada que no tuviera que llegar.

si deseas que no solo deje pasar la puerta a alfanumericos tan solo cambia la funcion ctype_alnum() , este ejemplo es muy basico y espero que sirva como orientacion

el script viene configurado con un ataque simple , despues de ver el ataque descomenta las lineas DE PRUEBA

de una en una , son ejemplos sencillos de que hacer en caso de que la variable no fuera en este caso alfanumerico , retirar caracteres , convertirlos o simplemente dar un valor null al dato , para que no pudiera actuar.

para hacer pruebas viene en el script un get javascript de prueba pero puedes pasar datos via url y automaticamente los escapara , prueba el resultado

una manera muy simple de evitar algunas vulnerabilidades web ya que solo dejando pasar alfanumericos evita muchos posibles ataques

Código PHP:

<?php
     
    // creamos la session
    session_start();
     
    // un ejemplo de un get javascript
    $_GET['QUERY']= "<script language='javascript' type='text/javascript'>alert('TU WEB ES VULNERABLE PODRIA HACER MUCHAS COSAS MALAS.');</script>";
     
    // volcado de datos get , dato original.
    var_dump($_GET);
     
    // comprobacion de get
    if( ! isset($_GET) || empty($_GET))
    {
        // mensaje de salida si es false
        print('No existe ninguna variable get');
    }
    else
    {
        // verificacion de datos
        foreach($_GET as $value=>$val)
        {
            // creamos la session con el dato original , guardamos en memoria el dato original antes de actuar
            $_SESSION['GET'][$value] = $val;
     
            // comprobamos si el valor es alfanumérico
            if( ! ctype_alnum($_GET[$value]))
            {
                // en este caso imaginemos que no existe ningun saneamiento, para ver que podria pasar.
               
                // PRIMERO PROBAREMOS SIN NINGUN ESCAPADO , DESPUES DESCOMENTAR LOS EJEMPLOS
     
                // vamos a sanear ahora los datos (convertir caracteres htmlspecialchars)o (retirarlos strip_tags())
     
                // ejemplo de funciones
     
                //$_GET[$value] = strip_tags($_GET[$value]);
     
                // $_GET[$value] = htmlspecialchars($_GET[$value]);
 
                // $_GET[$value] = NULL;
 
                // unset($_GET[$value]);
 
 
              /*  tambien podemos añadir verificaciones para otros tipos de datos como por ejemplo un email
 
              if(! preg_match("/^([a-zA-Z0-9])+([a-zA-Z0-9\._-])*@([a-zA-Z0-9_-])+([a-zA-Z0-9\._-]+)+$/", $_GET[$value])) 
              {
 
                $_GET[$value] = NULL;
 
              }
 
              */
 
                     
                    
     
               
           
     
            }
            // ejecutar variable para la prueba
            echo $_GET[$value];
        }
    }
     
    // volcado de datos get , saneados.
    var_dump($_GET);
     
?>
 

espero haberme explicado lo mejor posible , no soy muy tecnico sorry!!

[webankenovi]

aporto funciones para encriptar/desencriptar codificar/decodificar , protegiendo asi la informacion

mcrypt_encrypt
http://www.php.net/manual/es/functio...pt-encrypt.php

mcrypt_decrypt
http://www.php.net/manual/es/functio...pt-decrypt.php


convert_uuencode
http://www.php.net/manual/es/functio...t-uuencode.php

convert_uudecode
http://www.php.net/manual/es/functio...t-uudecode.php

mcrypt_generic
http://www.php.net/manual/es/functio...pt-generic.php

mdecrypt_generic
http://www.php.net/manual/es/functio...pt-generic.php

y a continuacion funciones hash de un solo sentido para proteger passwords por ejemplo , olvidense de md5 , sha1 etc...

crypt
http://es.php.net/manual/es/function.crypt.php

password_hash
http://es.php.net/manual/es/function.password-hash.php

password_verify
http://es.php.net/manual/es/function...ord-verify.php


si sabeis mas funciones ,postearlas.thanks

[David1992]

Se le olvido

base64_encode()
http://php.net/manual/es/function.base64-encode.php

y base64_decode()
http://php.net/manual/es/function.base64-decode.php


Nota: para encriptar de manera 100% segura de cara a lo que pueda ver el cliente de cara a la información, en lugar de:

<?php
/* Se ha obtenido en $row los datos del usuario.
MY_SECRET_HASH está definido en la sesion, y es inicializado a una cadena aleatoria.
$formName es un nombre que le demos al formulario.
*/
$hash=md5($_SESSION["MY_SECRET_HASH"].$formName.$row["id"]);
$_SESSION["FORMS"][$hash]=array("id"=>$row["id"]);
?>
<input type="hidden" name="hash" value="<?php echo $hash;?>" />

Yo haria:

<input type="hidden" name="hash" value="<?php echo $id ?>" />

Y despues en la recogida de datos, encripto ese valor y lo comparo con el de la db, de este modo el usuario no se puede ni imaginar que se cuece a lvl servidor.

[webankenovi]

Iniciado por David1992

Se le olvido

base64_encode()
http://php.net/manual/es/function.base64-encode.php

y base64_decode()
http://php.net/manual/es/function.base64-decode.php

en verdad no se me ha olvidado e incluso me he dado cuenta de un error , base64_encode no es seguro que digamos ya que no usa ninguna clave es decir yo me encuentro con algo asi

VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==

y usando simplemente base64_decode puedo obtener el valor real

This is an encoded string

el error que he comentado es con convert_uuencode ya que tampoco usa ninguna clave. claro que hay metodos donde podemos generar nosotros mismo un salt o concatenar claves añadirlas a la codificacion etc , pero yo hablo de la funcion en si tal cual .

gracias por añadir la funcion y muy bueno lo del input tambien

[David1992]

Iniciado por webankenovi

en verdad no se me ha olvidado e incluso me he dado cuenta de un error , base64_encode no es seguro que digamos ya que no usa ninguna clave es decir yo me encuentro con algo asi

VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==

y usando simplemente base64_decode puedo obtener el valor real

This is an encoded string

el error que he comentado es con convert_uuencode ya que tampoco usa ninguna clave. claro que hay metodos donde podemos generar nosotros mismo un salt o concatenar claves añadirlas a la codificacion etc , pero yo hablo de la funcion en si tal cual .

gracias por añadir la funcion y muy bueno lo del input tambien

mira lo que hay furrulando por internet... esto yo creo que es seguro, ademas lo mejoro un poco para complicarlo:

function encrypt($string, $key) {
$result = '';
for($i=0; $i<strlen($string); $i++) {
$char = substr($string, $i, 1);
$keychar = substr($key, ($i % strlen($key))-1, 1);
$char = chr(ord($char)+ord($keychar));
$result.=$char;
}
return base64_encode(base64_encode(base64_encode(base64_e ncode($result))));
}

$cadena_encriptada = encrypt("LA CADENA A ENCRIPTAR","LA CLAVE");



function decrypt($string, $key) {
$result = '';
$string = base64_decode(base64_decode(base64_decode(base64_d ecode($string))));
for($i=0; $i<strlen($string); $i++) {
$char = substr($string, $i, 1);
$keychar = substr($key, ($i % strlen($key))-1, 1);
$char = chr(ord($char)-ord($keychar));
$result.=$char;
}
return $result;

$cadena_desencriptada = decrypt("LA CADENA ENCRIPTADA","LA CLAVE QUE SE USÓ PARA ENCRIPTARLA");

Asi te deja meter una clave y tal :) seguro que tambien es aplicable al que tu dices, no lo e mirado mucho

[webankenovi]

yo te hablo de la funcion tal cual sin crear una funcion personalizada , esta claro que aplicandole una key es mas seguro y se le puede aplicar muchas cosas mas , pero repito hablo de la funcion en si .

gracias por el aporte .

[dashtrash]

Yo haria:

Cita:

Código PHP:

<input type="hidden" name="hash" value="<?php echo $id ?>" />
 

Y despues en la recogida de datos, encripto ese valor y lo comparo con el de la db, de este modo el usuario no se puede ni imaginar que se cuece a lvl servidor.

Qué es ese "$id"? Creo que no sabes para qué sirve el código que estabas mirando...Repásalo...

[David1992]

Iniciado por dashtrash

Qué es ese "$id"? Creo que no sabes para qué sirve el código que estabas mirando...Repásalo...

Para encriptar el valor del input que tiene el cliente, pero eso no es necesario, ese $id es su nombre de usuario o la fecha sin encriptar ni nada, despues en las comprobaciones a lvl servidor ya lo encriptas, cuando lo recojes, y lo cotejas con la DB asi el usuario no se quedara extrañado si ve un valor encriptado por hay furrulando... aunque sea hidden.

[dashtrash]

Y eso que tiene que ver con el código con el que lo comparas?...Mira el código..repásalo..
Es un sistema de ocultación de las keys de un formulario..No tiene nada que ver con usar sistemas de encriptación y desencriptación.

[David1992]

Iniciado por dashtrash

Y eso que tiene que ver con el código con el que lo comparas?...Mira el código..repásalo..
Es un sistema de ocultación de las keys de un formulario..No tiene nada que ver con usar sistemas de encriptación y desencriptación.

Ya me fige, estas encriptando un id de usuario para despues usarlo para cotejar los accesos y permisos O.o, lo que yo te digo es que hay puedes meter el id sin encriptar, pero tienes razon es mas inseguro mi modo lo tuyo tiene su lógica, ahora viene la critica:

¿no sera mas lógico ya que el id esta en una sesion, que el PHP lo recoja por defecto en lugar de andar recogiendolo en los formularios?

es decir, usas un include, con la sesión y los datos del usuario y lo añades donde vas a precisar ese dato, asi el usuario no anda rulando su id encriptado en cada solicitud...

Almenos eso es lo que yo entendi, pero quien mejor que el autor para explicar su verdadera utilidad :)