Escondiendo Variables (GET)!

[franco190453]

Despues de buscar por algo que ayude a evitar el problema de seguridad, que normalmente, existe con las variables que se envian desde una URL he encontrado algo y complementado con un poco.

Supongamos que alguien tiene la siguiente URL
dominio.com/Experimento/contacto.php?uno=7&dos=8&tres=9

La idea consiste en lograr exactamente lo mismo de esta forma ->
dominio.com/Experimento/contacto/7/8/9

El procedimiento es el siguiente ->
1.- El archivo contacto.php lo renombramos a contacto SIN extension
¿Es eso posible? SI lo es!.
2.- Establecemos un .htaccess archivo con lo siguiente dentro ->
ForceType application/x-httpd-php
3.- Dentro del archivo contacto (Sin la extension!!)
metemos el siguiente codigo ->
<?php
//Dividimos la URL en partes, utilizando "/" para separar!!!.
$laurl = explode("/", $REQUEST_URI);
$tres = $laurl[3];
echo "$tres<br>"; //Contiene "7", seria una variable pasada por URL
$cuatro = $laurl[4];
echo "$cuatro<br>"; //Contiene "8", seria como una variable pasada por URL
$cinco = $laurl[5];
echo "$cinco<br>"; //Contiene "9", seria como una variable pasada por URL
?>
4.- Si hacen un ->
print_r($laurl);
se podra ver un array asi ->
Array ( [0] => [1] => Experimento [2] => contacto [3] => 7 [4] => 8 [5] => 9 )
5.- Para hacerlo aun mas dificil para los que quieran hacer daño,
se puede validar cada variable.

Saludos
Y espero lo prueben a ver si a todos nos sirve.
Y mas importante sera sus comentarios sobre aspectos de seguridad en la web.
¿Verdaderamente se mejora la seguridad?
Franco

[Ronruby]

¿Esconderlas? No lo creo. Las variables aun siguen estando alli, usando contacto.php?uno=7&dos=8&tres=9 ó contacto/7/8/9 sigue siendo lo mismo (Aunque la 2da opcion es mas SEO-friendly). Eso no es esconder las variables, es solamente reescribir la URL.

Y $REQUEST_URI se usa cuando register_globals esta on, eso si es un gran riesgo de seguridad.

[PoLiZe]

Ron ruby pero las variables no se ven a eso creo qe se refiere, lo de la seguridad ronruby tiene la razón

[jenusys]

NOOOOO yo mejor seguiré enviando las variables por medio del método POST, type="hidden" y recibiendo con $_POST. A veces es más engorroso pero es más seguro.

[franco190453]

Que tal si cambiamos ->

$REQUEST_URI

Por->

$SERVER['REQUEST_URI'];

Saludos
Franco

P.S. Me da la impresion que NO es una simple re-escritura.

[Acron_0248]

Yo le doy la razón a Ronruby, no escondes nada útil realmente.

Según entiendo, en una dirección como esta:
[email protected]&nombre=alguien

Estarías escondiendo las claves de $_GET unicamente, email y nombre, sin embargo, la realidad es que lo que le interesa a alguien que busca de obtener información que tu sitio que tal vez no debería dar son los valores de $_GET que son [email protected] y alguien

Si el patrón es entendible ([email protected] indiscutiblemente hace referencia a una dirección de correo), no importa si la peticion fuera [email protected] o [email protected] o [email protected], así, el punto permanece, no está ocultando nada que realmente sea útil

[franco190453]

Fundamentado en lo siguiente ->

dominio.com/Experimento/contacto.php?uno=7&dos=8&tres=9

Y esto ->

dominio.com/Experimento/contacto/7/8/9

1.- El sistema ofrece una forma de hacer las direcciones mas cortas especialmente para poder enviar via WapPush.

2.- ¿Cualquier hacker sabe que contacto es un archivo php? No necesariamente!.

3.- Si contacto es un directorio y 7 es otro directorio y el codigo esta en
el 8 como va a saber un intruso en que punto se encuentra el codigo; y logicamente tendria que hacer multiples pruebas para poder saber donde se encuentra el codigo y poder asi determinar cuales son las variables.
En otras palabras puedo hacer lo siguiente :
dominio.com/Experimento/2/3/7/8/9.
Nadie absolutamente nadie puede saber cuantas son las variables que intento trasladar, a menos que se hagan multiples pruebas ya que en este caso 2 y 3 son directorios y 7, 8 y 9 son las variables.

4.- Logicamente si se manda una variable como direccion de corrreo se puede identificar pero las numericas o de letras es sumanente dificil identificarlas.

Saludos
Y espero nos ayude
Franco

[oso96_2000]

Nah, bastaria con probar la url como:

dominio.com/Experimento/contacto/7'/">/9

Y ver que sucede =P

No creo que esta sea una manera real de evitar el posible problema, lo mejor siempre ha sido y seguirá siendo el validar y limpiar todo valor que un usuario envie.

Lo de enviar variables por POST como dijeron arriba es lo mismo.. nada me impide cambiarle el valor a una de esas variables.

Y de hecho, lo que es peor, es lo que pones de el .htaccess con el handler de php.. si no lo cuidas estarias diciendo que practicamente cualquier archivo en el directorio debe ser interpretado como un archivo php, y eso es malisimo tratandose de seguridad.

En resumen: valida, limpia.

Código PHP:

  $variable_a_usar_en_sql = isset($_GET['variable']) ? mysql_real_escape_string($_GET['variable']) : null ; 
$variable_a_mostrar_en_sitio = isset($_GET['var']) ? htmlspecialchars($_GET['var']) ? '' ;  
   

Son validaciones por demas simples, pero que ejemplifican un poco como debe hacerse.

[Acron_0248]

Bueno, había hecho una respuesta referente al tema pero seguramente se perdió con el reciente problema del foro.

@franco190453:

Entiendo tus puntos, realmente lo hago, pero relacionado a la seguridad, es un método muy frágil.

Lo que estás mostrando es aceptable como una dirección amigable a lo sumo, pero como forma de mejorar la seguridad no es aceptable, es el típico ejemplo de seguridad por oscuridad el cual en cantidad de oportunidades ha dejado claro que no es, ni será, una solución real para los diferentes problemas que pueden comprometer el estado de los datos.

Este método para esconder variables es como lo que hacen muchos al definir el handler de php como el encargado de procesar archivos .html con la esperanza de que un posible atacante no sepa el tipo de código usado por el sitio.

Tomando en cuenta la cantidad de aplicaciones capaces de hacer peticiones de forma automatizada a un sitio web, el método no es capaz de ofrecer una mejora importante a nivel de seguridad.

Si, alguien que "vea" la URL no sabrá de primera mano qué partes de la URL se refieren a variables y qué partes no, pero como dijo oso96_2000, nada cuesta probar enviando diferentes valores en cada parte de la URL, y si utilizas una herramienta que haga el trabajo por tí, cuánto se puede tardar en saber qué es variable y qué no? menos de un minuto? puede que dos?

Debido al poco tiempo que se llevaría reconocer lo que esa URL "esconde", es que digo que el método es frágil para ser ofrecido como una mejora en la seguridad, esto claro, es mi opinión, nada más :)

@oso96_2000:

Es preferible usar htmlentities a utilizar htmlspecialchars debido a que el rango de caracteres modificables por la última, es menor y debido a la cantidad de payloads que existen y se pueden probar, es posible vulnerar las modificaciones que pueda hacer htmlspecialchars.

[lcervantes]

Hola.

Tal cual como comentan:

contacto.php?uno=7&dos=8&tres=9 ó contacto/7/8/9

Es lo mismo. Esto se le llama SEO-friendly o bien URL AMIGABLES. Si descubren cual es cada uno de los parametros que pasan ya tienes el valor... es más si en tu URL el 7 lo cambian por 45 si tienes ese registro seguro que podrán acceder a ese registro.

Lo que alguna vez he utilizado pero solo en backoffice cuando no me interesa que se vean los parámetros, es en base a una función encriptación y desencriptación que me he creado, le digo que parámetros quiero encriptar y me devuelve un valor de caracteres.
Entoneces a mi nuevo link podré

contacto.php?param=dkjhasd809312kljalsdkjadsa09803 132klkjsxdasdasd

Aqui lo unico que verás es "param" o el nombre de la variable que pasas por URL el resto de variables estan encriptadas dentro de param.
Evidente que luego tendrás que desencriptar param para saber que es lo que le pasas.

Es la unica manera que he encontrado, ten en cuenta que esto te obliga a cada link encriptar y luego en cada pagina que carges desencriptar.
Obligas a que el servidor trabaje un poco más
Si cambias algun valor de la URL te enia a una pagina que no existe.

Espero que te sirva de ayuda.
Saludos

[ciberwap]

para mi seria lo mejor para no mostrar la variable no los valores en la barra de dir del navegador es por el metodo header de php donde lo redirecionas si se ha loguedo correcto usando el metodo base_decode(64) asi se reemplaza to2

[lcervantes]

Hola Ciberwap
Podrías ponernos un ejemplo. No lo he acado de entender...
Saludos,

[Triby]

Iniciado por Ronruby

$REQUEST_URI se usa cuando register_globals esta on, eso si es un gran riesgo de seguridad.

Exacto, de hecho, el principal riesgo de recibir parametros (GET o POST) es tener register_globals activado. Entonces, ademas de deshabilitar register_globals, la mejor forma de garantizar la seguridad es evaluar y validar cada variable recibida, porque se puede "ofuscar", encriptar y tratar de ocultar las variables por cualquier metodo, pero si no hay una buena validacion es casi como cerrar tu auto, poner alarma y colocar las llaves debajo de la llanta, esperando que nadie las encuentre.

Es decir, si esperas una cadena, verifica que el dato recibido sea una cadena, con la longitud deseada y reemplazando caracteres especiales por sus respectivos codigos html; si esperas un dato numerico, asegurate de que realmente sea asi, con doubleval(), intval() o simplemente multiplicando por 1.

Otras practicas de seguridad:

Nunca uses directamente $_GET['variable'] o $_POST['variable'] ni $_REQUEST['variable'] en consultas a base de datos.

Asegurate de inicializar cada variable esperada (por GET o POST):

Código php:

// Por asignacion ternaria:
$variable = (isset($_GET['variable'])) ? html_entities(trim($_GET['variable'])) : '';
 
// Con if - then - else convencional
if(isset($_GET['variable']))
    $variable = html_entities(trim($_GET['variable']));
else
    $variable = '';
 
// Despues validas lo recibido
// Cadenas con strlen() y numeros con mayor que, menor que o igual a
 

[Acron_0248]

Y se podría agregar a esas prácticas colocadas por Triby el evitar $_REQUEST['']; cuando sea posible usar las variables $_GET, $_POST y $_COOKIE.

El problema de $_REQUEST es su incapcidad de decirle a otras porciones de código de dónde realmente llegaron los valores almacenados, allí se guardan tanto valores get, como post y como cookie dependiendo entonces de la configuración variables_order en el php.ini para que el script procese la solicitud.

La configuración común es EGPCS, si $_REQUEST se usara para verificar los datos de una cookie, sería muy fácil engañar a la cookie con tan solo enviar lo que la cookie espera mediante get o post.

Esto rompe por ejemplo la necesidad de aceptar cookies de un sistema de autentificación hecho para trabajar con cookies.

[enriqueplace]

Iniciado por Acron_0248

El problema de $_REQUEST es su incapcidad de decirle a otras porciones de código de dónde realmente llegaron los valores almacenados, allí se guardan tanto valores get, como post y como cookie dependiendo entonces de la configuración variables_order en el php.ini para que el script procese la solicitud.

La sugerencia es correcta, no así la explicación de $_REQUEST. En sí no es "su incapacidad", es la funcionalidad para la cual fue pensada, es decir, obtener todas las peticiones sin distinguir por ningún origen, de lo contrario, deberás usar los arrays de sistema específicos para ello.

¿Cual usar? Dependiendo de lo que quieras hacer. Pero NUNCA porque te quede "más cómodo" $_REQUEST y así no preguntas si vino por GET o POST

Solo una pequeña aclaración