Página ajax.php abre a pagina_ultra_secreta.php como impedir acceso directo a la 2 ?

Anarko · #1 (**permalink**) 11/10/2006, 19:18

Página ajax.php abre a pagina_ultra_secreta.php ¿Como impido que pagina_ultra_secreta.php sea abierta de forma directa ?

Cómo impido que pagina_sensible.php sea abierta por de manera directa desde un URL escrito en un browser ?

Es decir, pagina_sensible.php solo sea abierta por mi_verdadera_pagina_ajax.php Cómo puedo hacerlo ?

Gracias.

Anarko · #2 (**permalink**) 11/10/2006, 21:35

Vale la pena aclarara que ningúna de las PAG utiliza marcos.

Se trata de Páginas "al TOP", sin frames ni marcos.

Ademas COOKIES o SESSIONES no VAle, pos =, estarn almacenadas en el cliente y...

php.java.jsp · #3 (**permalink**) 11/10/2006, 22:05

no dices de que forma ajax.php abre a pagina_ultra_secreta.php

<a href="pagina_ultra_secreta.php">, un link o <form action="pagina_ultra_secreta.php">, un formulario,
o como ?

por ejemplo podrias usar includes asi muestras pagina_ultra_secreta.php pero la url en la barra de direcciones seguira siendo ajax.php

por ejemplo en ajax.php pones

<a href="ajax.php?entrar=si"> o
<form action="ajax.php"><input type="hidden" name="entrar" value="si">

y al principio de pagina ajax.php compruebas que la variable exista para mostra el include o mostrar el link

Código PHP:

  <?

 
if(!empty($entrar))

   include ("pagina_ultra_secreta.php");

else { 

?>

 
<html>

<head>

<body> ....

<a href="ajax.php?entrar=si">

<?

}

?>

Anarko · #4 (**permalink**) 12/10/2006, 08:07

Hola php.java gracias por intentar ayudar,

oye, dime la verdad:

no ves que la información siempre esta al alcance del cliente ?

Cuando se hace [<a href="ajax.php?entrar=si">], pos cualquier persona abrira el URL [ajax.php?entrar=si]...

Ahi no hay ningúna seguridad...

Aguien sabe si AJAX siémpre es asi de inseguro ?

Es que...

Analizo el problema, y a menos que se utilicen MARCOS, no veo cómo evitar que accedan directamente a información sensible...

Alguien puede orientarme plis ?

zaqpz · #5 (**permalink**) 12/10/2006, 08:28

Yo hice algo similar, aunque en mi caso la seguridad no era sumamente importante. Mi razonamiento era el siguiente:

Suponiendo que ajax.php abre a pagina_ultra_secreta.php.
-Al momento de generar ajax.php genero un código de 32 caracteres aleatorio (tipo session id).
-Almaceno ese código en mi base de datos y también se lo envío al cliente en una cookie.
-En el momento que el cliente llama a pagina_ultra_secreta.php antes de devolverle asincrónicamente su contenido leo el valor de la cookie anteriormente enviada.
-Compruebo que el valor leído de la cookie exista en mi base de datos. En caso que exista "muestro" el contenido y borro esa entrada de la base de datos. Caso que no exista no "muestro" nada.

Este procedimiento te (casi) garantiza que el cliente que quiera hacer una llamada a pagina_ultra_secreta.php debe necesariamente haber pasado por ajax.php para que se le genere un código de 32 caracteres válido.

Con algunos agregados quizá te pueda resultar útil.
Saludos.

Anarko · #6 (**permalink**) 12/10/2006, 10:15

Gracias,

Claro que debe pasar primero por AJAX pero date cuenta que tiene 0% de seguridad, si quieres pasanos el URL y te lo probamos.

Pos ni con SESSIONES ni con COOKIES (más insegursas aún), se logra.

Cuando abres pagina.AJAX la COOKIE va al cliente.
Luego Cliente ABRE una NUEVA VENTANA y accede a "pagina que no deberia mostrar info si el REQUEST/REFERER no es pagina.AJAX

Con lo que sugieres tienes 0 de seguridad.

zaqpz · #7 (**permalink**) 12/10/2006, 11:37

Cero de seguridad dependiendo lo que estés tratando de hacer...

Si lo que deseas es que un .php se ejecute si y solo si es llamado desde tu objeto XMLHttpRequest no creo que encuentres muchas alternativas. La única forma que tiene tu .php de saber si es llamado desde un método OPEN, es que dentro de los valores que envías haya alguno que le haga saber que es llamado por ese medio; y lógicamente, todo lo que escribas en tu JavaScript puede ser visualizado por un usuario (aunque ofusques, ocultes o codifiques), por lo que una alternativa así no resultaría eficaz durante mucho tiempo.
Con AJAX se pueden realizar aplicaciones muy seguras; todo depende de cómo estés diseñando tu aplicación. Si quieres puedes comentar lo que pretendes lograr y seguramente vayan surgiendo alternativas viables para construir tu aplicación.

Saludos.

Anarko · #8 (**permalink**) 12/10/2006, 12:08

Gracias zaqpz,

lo que pretendo es justo lo que dices:

info.php solo muestra datos si es solicitado desde crack.ajax

De lo contrario mostrar otra info.

Repito la "nota": SIN FRAMES NI MARCOS

MaBoRaK · #9 (**permalink**) 12/10/2006, 14:55

Cita:

Iniciado por Anarko

Gracias,

Claro que debe pasar primero por AJAX pero date cuenta que tiene 0% de seguridad, si quieres pasanos el URL y te lo probamos.

Pos ni con SESSIONES ni con COOKIES (más insegursas aún), se logra.

Cuando abres pagina.AJAX la COOKIE va al cliente.
Luego Cliente ABRE una NUEVA VENTANA y accede a "pagina que no deberia mostrar info si el REQUEST/REFERER no es pagina.AJAX

Con lo que sugieres tienes 0 de seguridad.

Con todo el respeto que te mereces, no digas estupideces Ajax es seguro segun el modelo de sistema que se tenga, el modelo de aplicacion que uno realice, la seguridad no viene por AÑADIDURA en ningun lenguaje de programacion.

Una aplicacion se hace vulnerable cuando se programa con las patas.

connection closed.

Anarko · #10 (**permalink**) 12/10/2006, 15:04

Tio aprende a leer.

Hablo de la solución propuesta por zaqpz, que mdiocre tu actitud.

Estoy preguntando cómo aplicar seguridad a un script y sales a hacer una ALARACA inecesaria...

Te recuerdo: APRENDE A LEER!!!

MaBoRaK · #11 (**permalink**) 12/10/2006, 15:20

loading..........

"mediocre, actitud, aprender, leer,,,,,,,,,,,,,, vaya palabreria barata "que ardido. Amor y Paz

Pero la solucion es tan simple como loq ue dice zaqpz poner un include en tu response Server y usar el metodo POST y no GET (.php?bla=bla).

Y ya con tu metodo post puedes añadir variables que identifiquen si realmente esta autorizado para ver esa página, no te fies de los http_referer

connection closed.

Anarko · #12 (**permalink**) 12/10/2006, 15:38

Hola,

te sugiero que leas un poco sobre los REQUEST; el POST es tan vulnerable como el GET...

Con tu amplisima experiencia, me extraña que no lo sepas.

MaBoRaK · #13 (**permalink**) 12/10/2006, 15:44

loading................

Entonces tu pregunta no se entiende, en si Todas las paginas pueden abrirse pero no todas pueden mostrar su contenido eso ya depende de como sea tu estructura de seguridad.

te dije lo del post para dividir en 7 los peligros de tu gruesa aplicacion con includes jeje x).

Y para que uses un echo "Si" , echo "No" tu si que sabes mucho de seguridad.

Mejor pon un detalle de lo que haces y vemos soluciones.

connection closed.

Anarko · #14 (**permalink**) 12/10/2006, 20:08

Hola??

Alguien sabe cómo puede evitarse ?

O definitivamente no es posible ?

ikhuerta · #15 (**permalink**) 13/10/2006, 06:02

Hey

Crea un coockie de sesion que en su calculo tenga en cuenta el tiempo, el usuario, su contraseña y un numero aleatorio generado por javascript y que solo se cree al cargar una pagina determinada.

Al cargar tu pagina genera un numero aleatorio y Lannza primero una llamada a esa pagina que solo cree la cookie. (no se recibirá nada).

No envies por ajax esa cockie solo por php de forma que no aparezca en el codigo del usuario.

Luego haz la llamada a la pagina secreta también con el numero aleatorio generado. En tu superpagina php ultrasecreta. comprueba esa cookie antes de mostrar los datos.

Y sobretodo no hagas un solo calculo en javascript sobre esa cookie, todo en php. En javascript solo debe verse un random.

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

De esta forma la seguridad solo dependerá de la formula que tu inventes para generar esa cookie (que repito debería tener en cuenta, el tiempo, el usuario, la contraseña y el numero aleatorio).

Como esa formula solo la ves tu porque eres el unico que tiene acceso a PHP y no pueden hacerse pruebas con numeros ya que cada minuto una contraseña que era valida pasara a no serlo y lo que es valido para un usurio no lo es para otro. ---> pues en definitiva tu pagina tendrá muy muy pocas probabilidades de ser mostrada si no se sigue exactamente ese proceso.

Anarko · #16 (**permalink**) 13/10/2006, 15:16

Hola gracias,

pillen que la pagina no tiene conraseña ni clave de acceso...

Si fuera asi, os no habria rollo...

Todo el planeta puede acceder, pero la idea es que la info solo se muestre si se accede desde el AJAX.

foo · #17 (**permalink**) 13/10/2006, 16:48

Cita:

Iniciado por Anarko

Todo el planeta puede acceder, pero la idea es que la info solo se muestre si se accede desde el AJAX.

eso no es posible, te sugiero que no pierdas tiempo en intentos inútiles de proteger esa pagina "ultra secreta" de otras formas de acceso.

Anarko · #18 (**permalink**) 13/10/2006, 16:56

Si me dices que no se puede pos...

Te creo, por que lo más que he visto es "ofuscación" del código:

Código:

um.s2=(um.s&&typeof XMLHttpRequest!=um.un)

Sospecho que lo más a hacerse es eso, "encriptar" el JS

En CODE que coloc, tomado de una empresa muy fregada... xD cómo diantres saber el destino de ese AJAX ?

Ok, alguna idea de "desinformar" el destino del AJAX ?

foo · #19 (**permalink**) 13/10/2006, 17:52

alguna vez has oido de programas que permiten ver el trafico que fluye entre cliente y servidor? si no es asi, aqui hay un articulo basico (que salio hace pocos dias)

http://www.securityfocus.com/infocus/1879/1

Cita:

Ok, alguna idea de "desinformar" el destino del AJAX ?

si te refieres a ocultar que paginas invoca, eso como ya te dije, no es posible.

Anarko · #20 (**permalink**) 13/10/2006, 18:59

Gracias,

dije "desin.." con COMILLAS pos por que eso "no se puede", a lo sumo ofuscar el código.

Pos (insisto), mira el truquillo hecho por estos tios:

Código PHP:

  um.ovi=um.pi(um.u.split(/opera[/ ][7-9]./)[1].match(/^[0-9]/)[0]);um.o75=(um.ova>=8||um.ovi>=5);um.o73=(um.ova>=8||um.ovi>=3);um.o71=(um.ova==7&&um.ovi<=1);}um.s=(navigator.vendor=='Apple Computer, Inc.');um.s2=(um.s&&typeof XMLHttpRequest!=um.un);um.wie=(um.d&&typeof um.m.all!=um.un&&typeof window.opera==um.un&&!um.k);um.mie=(um.wie&&um.u.indexOf('mac')>0);um.mx=(um.u.indexOf('tasman 0.9')>0);if(um.mx){um.mie=1;}um.omie=0;if(um.mie){um.wie=0;um.iev=um.u;um.iev=um.iev.split('msie ');um.iev[1]=um.iev[1].split(';');

No se trata tanto de ocultar URL sino de hacer que URL se comporte diferente en acuerdo a si recibe o no ciertos datos.

Cuales, como ? Eso es lo que nos tiene aqui, pero mira esaforma en que invocan a XMLHttpRequest... Uf!!, es un ofuscadero

ikhuerta · #21 (**permalink**) 14/10/2006, 08:20

Ok...

La verdad es que me parece un poco chapuza pero bueno.

que tal si metes parte del nombre de la pagina en una cookie un par de paginas antes de llegar a la que contiene el ajax y luego solo la rescatas... Se podría mirar claro, pero ya habría que entender las funciones de cookies de javascript y luego ir a buscar la cookie que tu habilmente habrías borrado justo después de cargar tu pagina mega-importante.

Otra cosa...

Que no hay usuarios ni claves no implica que no pueda haber usuarios virtuales a los que asignes claves virtuales... si tan chungo quieres ponerlo puedes, solo se trata de pensar como liarla.

Anarko · #22 (**permalink**) 14/10/2006, 17:39

Gracias a todos,

FOOTe agradezco mucho la liga,

tocan un tema similar al que yo planteo aquí, ellos hablan de que ahi esta definido el URL, y que si alguien lo adultera...

Ya pensamos que hacer ?

Sinembargo yo no hablo de URL adulterado sino "cargado al TOP".

Justo como plantean alli, noticias.aspx?id=chiva_de_la_semana, luego...

Lamers.com pueden agregar un iframe que cargue noticias.aspx?id=chiva_de_la_semana...

Algo asi es lo que yo digo, cómo parar esa situación, las COOK pueden ayudar, y las SESS también, pero no dan seguridad real, mucho menos un POST como sugeria el aficionado MaBoRaK.

Una que se me ocurre es generar una YAVE aleatoria dependiendo del día, o mas extrictos, de la HORA y del día.

Luego los JAVAS y las PAG.IMPORTANTES trabajarian en base a esa YAVE, luego, no habra quien se pase cada hora/día cuadrando su aplicaion para tomar tus datos...

Y si lo hace, pos hasta se lo merece...

Definitivamente parece que lo más confiable es OFUSCAR + COOK + algo como la YAVE.

Es decir un conjunto de normas medias que sumen un dolor de cabeza desarmarlas, y que frenen una friega media, luego, si se trata de info altamente delicada, pos ahi si se omite el AJAX explicito y nos hiriamos a unas SESS o registros, etc...

Alguien puede sugerirnos algo + confiable ?

efra · #23 (**permalink**) 18/10/2006, 10:54

Vaya, cuanta complicación siendo la cosa más básica del mundo.

Si no deseas que nadie pueda llegar directamente a tu página "ultrasecreta"(aunque sepan el nombre de esta)

Lo que se debe hacer es agregar esto en el index

Código PHP:

  <?php
define("In_SITE", true);
?>

Despues poner el siguiente código en la página ultrasecreta:

Código PHP:

  <?php
if (!defined("ON_OUR_SITE"))
{
   die ("Esta página esta prohibida para tus ojos");
}
?>

Otra alternativa es esta:

Si alguien intenta llegar directamente a nuestra pagina ultrascreta.php

Código PHP:

  if(substr_count($_SERVER['SCRIPT_NAME'], "ultrascreta.php") >= 1){        
    header("location:../404.php");
}

¿Y donde esta el truco? Bueno, si ultrasecreta.php esta incluida en otra página podrá recibir parámetros y seguir funcionando normalmente siempre y cuando el get o post no la llame directamente.

Es tan simple que no veo por que el usuario que pidio amablemente la solución no se esforzo por leer un poco de documentación oficial.

Creo que sería mejor estudiar un poco más lo básico y luego seguir con lo demás.

Salud.

B** · #24 (**permalink**) 20/10/2006, 07:24

Cita:

Iniciado por efra

Vaya, cuanta complicación siendo la cosa más básica del mundo.

Si no deseas que nadie pueda llegar directamente a tu página "ultrasecreta"(aunque sepan el nombre de esta)

Lo que se debe hacer es agregar esto en el index

Código PHP:

  <?php
define("In_SITE", true);
?>

Despues poner el siguiente código en la página ultrasecreta:

Código PHP:

  <?php
if (!defined("ON_OUR_SITE"))
{
   die ("Esta página esta prohibida para tus ojos");
}
?>

Seguro que esa alternativa funciona? en la ultrasecreta.php verificas si se definio una variable en el index.php? Si ese es el funcionamiento no creo que funcione(Te digo por que ya lo probe)... por que igual pudieron estar en el index.php y querer ir a la ultrasecreta.php, sin estar autentificados..
Pasando a la duda original, creo que para tener seguro el acceso a la susodicha... hace falta programacion de lado del servidor... ya sea que lo hagas por sessiones... o si va ahaber envio de variables, por POST O GET... si tu caso es el numero 2... pues solo verificas si se creo una variable de envio:

Código PHP:

  if(isset($_POST[variable])){
        ...
}

Saludos.

Anarko · #25 (**permalink**) 20/10/2006, 17:43

Cita:

Iniciado por efra

Vaya, cuanta complicación siendo la cosa más básica del mundo.

Cita:

Iniciado por efra

Es tan simple que no veo por que el usuario que pidio amablemente la solución no se esforzo por leer un poco de documentación oficial.

Cita:

Iniciado por MaBoRaK

Pero la solucion es tan simple como loq ue dice zaqpz poner un include en tu response Server y usar el metodo POST y no GET (.php?bla=bla).

Carambas, si se unieran efra y MaBoRaK, seguro harian el matrimonio perfecto en honor a la inseguridad y a los deseos de escribir pavadas...

Que parejita!...

MaBoRaK · #26 (**permalink**) 21/10/2006, 08:56

loading..............

vaya anarko al parecer el que no entiende nada de seguridad eres vos, cuando nos referimos en usar GET o POST no nos referimos simplemente a ponerlo tal cual, eso depende de tus validaciones de variables, definiciones y estructuras de control.

Lee un poco al respecto pero esas son ideas básicas, tu trabajo es desarrollar tu sistema de seguridad en base a eso.

connection closed.

MaBoRaK · #27 (**permalink**) 21/10/2006, 09:04

loading..........

acá mas detalles para ayudar a tus conocimientos baratos.

http://leimnud.info/index.php?&artic...ang=en&cat=PHP

y

http://leimnud.info/index.php?&artic...ang=en&cat=PHP

connection closed.

MaBoRaK · #28 (**permalink**) 21/10/2006, 09:07

loading.........

dame tu mail, te mando un buen libro sobre SEGURIDAD EN PHP

connection closed.

lbauerle · #29 (**permalink**) 28/09/2008, 11:26

Anarko... hace algo mas seguro. mete el archivo en pendrive.. y anda a dejarlo personalemente.... no veo otra forma mas segura...

creo que te han pueso formas buenas y confiables de hacerlo... o si no usa la opcion mia...(cualquier cosa en el camino pide refuerzos al gope)...

caricatos · #30 (**permalink**) 28/09/2008, 15:01

Hola:

El tema es muy viejo... por favor, no revivan temas antiguos.

Saludos