Foro - Perl en Español

Buenas, como podéis comprobar al visitar esta página, se guardan dos cookies en el navegador, una es allowvote=allowvote; con esa no hay ningún problema, pero la otra es una PHPSESID tal que así: PHPSESID=d5657d791690ce1437e64db912ecdd4e.

Y esta última no consigo que me la detecte Perl. Hice este simple programa para coger las cookies de esa página:

$res = $ua->request($req);
my $content = $res->content();
print $content;
$cookie_jar->save( $txt );
print $cookie_jar;[/syntax]

Y efectivamente guarda en mi txt la cookie de allowvote, pero no la cookie de PHPSESID, ¿alguna idea de por qué es así y alguna forma de hacerlo? Muchas gracias

Ya encontré respuesta a vuestra desazón, señor.

He aquí los pormenores de lo que hice. Os cuéntolo con todos los vericuetos que mi cabeza logró atajar, y llegar, a una simple solución, pues, es bien sabido, que las cosas simples y llanas, más del gusto son, pues es más fácil para las entendederas apreciar sus más preciados detalles.

Espero que entendáis dicha explicación y que aprovechéis sus enseñanzas, para regocijo vuestro, presente y futuro.

Al principio, delante de vuestros escritos, parecióme que debería pedir pistas de qué es lo que realmente sucede, no sea que algún maquiavélico engendro oculto hiciese sus malas obras a escondidas, y a la vez, a la vista de todos nosotros.

Por ello, agregué la línea use LWP::Debug qw(+ -conns); al principio, para, cual espía infiltrado en las líneas del ejército contrario, nos chivase todo aquello que en él sucediese.

También, sustituí la línea $cookie_jar->save( $txt ); por una entrada autosave => 1, dentro del HTTP::Cookies->new, pues es más corto, y quizás, más seguro. Estamos diciendo que queremos que nos guarden las galletas al final del proceso.

La salida del print $cookie_jar; también la cambié por print $cookie_jar->as_string; pues es la forma correcta de ver el contenido, en texto, de la jarra de galletas.

Lancé el programa y este fue su discurso:

Código: Seleccionar todo

LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking www.gamesites200.com for cookies
HTTP::Cookies::add_cookie_header: Checking .gamesites200.com for cookies
HTTP::Cookies::add_cookie_header: Checking gamesites200.com for cookies
HTTP::Cookies::add_cookie_header: Checking .com for cookies
LWP::UserAgent::send_request: GET http://www.gamesites200.com/ultimaonline/in.php?id=862
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 421 bytes
LWP::Protocol::collect: read 2479 bytes
HTTP::Cookies::extract_cookies: Set cookie PHPSESSID => c3e2ff170f45ad5718097ba4c8c991dc
LWP::UserAgent::request: Simple response: OK
Set-Cookie3: PHPSESSID=c3e2ff170f45ad5718097ba4c8c991dc; path="/"; domain=.gamesites200.com; path_spec; discard; version=0

Así que es cierto: la galleta la tenemos en nuestras manos, pero... ¿dónde está?

Código: Seleccionar todo

explorer@portatil:~/Documents/Desarrollo> cat cookie.txt
#LWP-Cookies-1.0

Toca estudiar, pues es un comportamiento extraño, dominado por fuerzas extrañas y que aún no acabamos de entender.

Entonces, recordé haber visto una nota especial en el libro sobre galletas que tenía abierto, titulado "HTTP::Cookies". En el capítulo sobre as_string, que es lo que yo usé antes, ponía una extraña advertencia: "si el conjuro se nombra con la palabra VERDAD, as_string devolverá todas las galletas salvo las que estén marcadas con el signo Discard".

Bueno, es una referencia a que no todas las galletas se devuelven. Ya tenemos una pista de que no todas las galletas son mostradas alguna vez. La nuestra, sí que tiene puesta la marca discard. ¿Qué significará?

Busqué por el mismo libro y llegué, unos capítulos más arriba, a la sección clear_temporary_cookies. Allí decía que eliminaba las cookies que no tuvieran campo de expiración o que tuvieran la marca discard, y, que tal como reza en el Gran Libro, página 2965, eso ha de ocurrir siempre que se acabe el proceso lanzado. Así que las sospechas se cumplieron: la galleta es borrada por nuestro propio programa porque está marcada así desde el principio.

Es claro que el trabajo de la cookie empieza y termina a lo largo de la duración del programa, lo mismo que la sesión de un humano delante de esa página. Mientras el programa esté funcionando, la cookie existirá. No hay más preocupaciones que el de dejar que HTTP::Cookies haga su trabajo.

Pero, en el caso de que deseéis conservar dicha galleta más allá de la ejecución de este vuestro programa, esta es la solución: agregar la entrada ignore_discard => 1, al new, e impedirá que el borrado ocurra. La galleta aparecerá en su jarra de galletas.



Con gusto departiremos, si ese es vuestro deseo, el que este descubrimiento tan sin igual nos depare en cuanto a disquisiciones y futuros problemas.

Sencillamente impresionante, aparte lo que me he reído leyendo este, vuestro discurso, resulta curioso como algo que llevo intentando averiguar desde que posteé mi primer mensaje tenía una tan sencilla solución
Por ahora parece que es justo lo que hacía falta para que todo el sistema funcionase, ahora estoy intentando ponerlo más cómodo de usar con Perl/Tk, así que es muy posible que acabe preguntando alguna duda ^^ mil gracias ilustre señor.

Y aquí esta la esperada duda, al ejecutar este programa:



Todo marcha sobre ruedas con la cookie que tenía problemas (PHPSESSID), pero ahora estoy teniendo problemas con la otra (allowvote=allowvote).

Código: Seleccionar todo

LWP::UserAgent::new: ()
LWP::UserAgent::proxy: http http://203.69.39.251:80
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking www.**.com for cookies
HTTP::Cookies::add_cookie_header: Checking .**.com for cookies
HTTP::Cookies::add_cookie_header: - checking cookie path=/
HTTP::Cookies::add_cookie_header:  - checking cookie PHPSESSID=54964503a40325a2a
15fe9183e253314
HTTP::Cookies::add_cookie_header:    it's a match
HTTP::Cookies::add_cookie_header: Checking **com for cookies
HTTP::Cookies::add_cookie_header: Checking .com for cookies
LWP::UserAgent::send_request: GET http://www.**.ph
p?id=862
LWP::UserAgent::_need_proxy: Proxied to http://2*0
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 511 bytes
LWP::Protocol::collect: read 424 bytes
LWP::Protocol::collect: read 1452 bytes
LWP::Protocol::collect: read 262 bytes
LWP::UserAgent::request: Simple response: OK
Set-Cookie3: PHPSESSID=54964503a40325a2a15fe9183e253314; path="/"; domain=.games
ites200.com; path_spec; discard; version=0

¿Cómo puedo hacer para que se conecte al proxy ANTES de pedir las cookies?

El funcionamiento normal es que las cookies correspondientes a un dominio se deben transmitir en la cabecera de petición GET, para que el servidor sepa que se trata de una sesión anterior.

¿Pero lo que quieres es conectarte al web como si no tuvieras cookies?

El proxy está haciendo su papel de intermediario entre vos y el servidor final. Como es una petición a un dominio conocido, LWP::UserAgent sabe que tiene que transmitir esas cookies en la petición, al proxy.

Si el servidor no te responde con la otra cookie... sospecho que sea debido a que ya ha almacenado la IP del proxy, y por lo tanto, ya no cuenta como IP nueva.

De todas formas, si quieres que se conecte sin cookies, lo único que tienes que hacerle a tu niño glotón es, al principio... quitarle la jarra de galletas. Y probar a dárselas más tarde.

Es decir: conéctate sin la jarra de galletas que tienes. Por ejemplo, una jarra de galletas en memoria (hay un ejemplo en HTTP::Cookies). Después de conectarte, activar la jarra de galletas en fichero.

De todas formas... todo este jaleo, ¿para qué? ¿por qué es importante esa página? ¿qué pretendes conseguir?

Cuando termine este programa, si lo termino... será enviado como proof of concept a Games0, para demostrarles un agujero de seguridad...

Pues si el sistema de voto depende de la IP del origen, poco se puede hacer. El sistema recordará la IP del votante, da igual que sea del proxy o la real. Un efecto perverso de este sistema de votación es que hay redes enteras que quedarían fuera del sistema de voto con tal de que vote uno de ellos. Por ejemplo, las empresas de cable suelen ofrecer IP locales a sus abonados, y todos ellos salen al exterior por unas pocas IP públicas. Bueno, pues basta que uno de ellos vote en un sistema como estos para que los otros 10.000 abonados ya no puedan hacer ni votar, ya que el sistema de voto siempre ve la misma IP (la del proxy).

De todas formas, sí que es posible averiguar la IP real del que hace la petición a través del proxy (va en la cabecera HTTP). En los sistemas tipo navegación anónima, sí que está oculta.

Puedo estar equivocado, naturalmente, pero para que el programa funcionara debería de utilizar todos -o una buena parte- de los proxy existentes, para que cada uno contase como un votante.

Esa sería una posible solución, pero realmente los proxies tienen una vida muy corta y aparecen nuevos proxies cada pocos segundos y es imposible detectarlos todos. Los que en realidad son transparentes o Gateways se puede saber fácilmente la IP real, pero los anónimos 100% sería un proceso detectarlos. Yo lo único que quiero demostrarles (y ya falta poco, una duda que se me ocurrió bebiendo una Mahou y ésta y ya tengo el programa) es que son muy vulnerables a un proxy voter muy simple como el que yo puedo hacer con tu ayuda y con tan solo gastar 10 minutos y poner un captcha, o mejorar el detector de referers o poner una buena cookie encriptada podría detener las falsas votaciones... ahora creo que me voy a la cama que estoy hecho polvo mañana a primera hora pruebo a ver si funciona el tema de la cookie_jar, voy al concierto de Motorhead, vuelvo y te comento el resultado ¡Buenas noches!

Tienes un par de dificultades más... en el formulario de la página de voto, hay un par de campos ocultos. Uno se llama 'hi' y el otro es uno de tipo submit que no tiene valor, pero está oculto. La otra dificultad es que el botón de submit que aparece en pantalla tiene un nombre aleatorio (jam, hiya, food, sendin, etc.) cada vez que solicitas el formulario).

Algo extraño me pasa, que no consigo hacerme con la cookie allowvote desde una máquina que no ha votado. Seguiré mirando, pero a lo mejor es tan tonto como crear esa cookie desde cero. De todas formas, si en el momento de sumar un voto se da cuenta de que es la misma IP, no lo tomará en cuenta. Ahí es donde entran en juego los proxies.

Por ahora el tema del submit vacio y los campos ocultos sencillamente utilicé un programa llamado GreaseMonkey comúnmente utilizado para localizas XSS's, el query sería algo así:


Y las palabras aleatorias ya me había fijado, por ahora solo varían entre jam, food y sendin creo, ahí tal vez podría hacer que el programa leyera el código, y
Y asi sucesivamente, el mayor problema que yo creo tenemos, es que si te fijas al acceder a la página de voto con una IP nueva y todo correcto, no solo te asigna la PHPSESSID para verificar que efectivamente es un voto legal, sino que en el formulario, además de los campos mencionados antes, aparece un campo tal que PHPSESSID=j3434j3jho3jh4i134, y haría falta pedirle al programa que lo introdujera leyéndolo del mismo formulario; en Mechanize vi algo parecido a esto:


Pero a decir verdad no conseguí encontrar una explicación al por que del phpsessid entre corchetes. ¿Quizás es para hacer justo lo que necesitamos para el campo de phpsessid en el formulario?