Ingresaron a la base de datos de Foros del web? Como?

[Ojete]

Leyendo la Historia del foro me di cuenta de lo siguiente:

Noviembre del año 2002 fue marcado por una tragedia para nuestro foro cuando un travieso (un travieso??? un hijo de s.. .) ingresó a la base de datos y reemplazó todos los mensajes eliminando mucha información.

$travieso = "hijo de mama";

Bien mis preguntas son:

Esto lo hizo alguien que ya se savia los datos de log in de la base?? o fue un "$travieso" que de alguna manera logro entrar, o logro eliminar los datos con algún código???

La razón por la que pregunto esto es para evitar el mismo percance en un futuro (no es que tenga una gran pagina web pero creo que no esta de mas saber) así que me gustaría saber como evitar este tipo de cosas.

Cuales son los puntos mas vulnerables o en que tenemos que ser mas precavidos cuando a seguridad se refiere para evitar este y otro tipo de cosas parecidas? Gracias...

[Ronruby]

Cuales son los puntos mas vulnerables o en que tenemos que ser mas precavidos cuando a seguridad se refiere para evitar este y otro tipo de cosas parecidas? Gracias...

Todo lo demas del tema, no iria en el foro de PHP.

Pero yendonos al punto de la cita en cuestion, TODO input proveniente del usuario debe ser validado y en todo caso filtrado. Es allí donde residen todos los inconvenientes para la seguridad de una pagina. Nunca confiar en el usuario.
Ya el como validas o "limpias" esos datos, depende las necesidades.

[Ojete]

pero entonces la única manera de que puedan alterar de alguna manera nuestra web es a través de los inputs?

[pateketrueke]

Iniciado por Ojete

pero entonces la única manera de que puedan alterar de alguna manera nuestra web es a través de los inputs?

claro, un input (que significa entrada) no es únicamente a través de formularios, también puede ser a través de enlaces...

entonces la entrada -input- sería todo aquello que podemos obtener del usuario a través de la web misma, hay que recordar que el método GET no implica formularios solamente...

y que por el método POST también pueden ejecutar nuestros scripts, simulando un formulario con cURL por ejemplo, etc...

[Ronruby]

No necesariamente, pero toda la informacion que viene de un usuario debe ser validada.

Si confías en el usuario, y no validas nada, vendrá un gracioso y te hará pasar un muy mal rato inyectandote código SQL.

Tambien algunas directivas, como son register_globals, pueden comprometer la seguridad de tu sitio web.

[Hidek1]

te recomiendo leas este link

ahí encontraras muchos de los comunes errores de programación y/o seguridad

saludos.

[Heli0s]

Incluso cookies.

[Ojete]

Iniciado por pateketrueke

por el método POST también pueden ejecutar nuestros scripts, simulando un formulario con cURL por ejemplo, etc...

interesante pero como es eso? y lo de las cookies?

bueno me boy mintras a leer el link que dejo hidek1, se ve bien, Gracias....

[Heli0s]

A veces se usan las cookies, se ponen variables en ellas, el usuario busca cual es la cookie de tu pag, mira las variables que hay, y con los metodos correspondientes edita el contenido de las variables poniendo el código que tenga que poner para realizar la inyeccion, como si fuese por post o get, pero por cookie.

Un saludo

[Ronruby]

Iniciado por Ojete

interesante pero como es eso? y lo de las cookies?

bueno me boy mintras a leer el link que dejo hidek1, se ve bien, Gracias....

Lo de cURL ya un poco mas complicado (por decirlo asi), pero es posible. Por eso no basta solo validar un formulario en el cliente, con Javascript.
Ya que puedo hacer un script usando cURL que envie los datos que yo desee por POST y asi le paso por encima a la validacion en Javascript, haciendo que se guarde informacion que talvez no desees sea guardada (algo perjudicial)

[Heli0s]

El javascript no sirve de nada frente a ataques así, ni siquiera hace falta crear tu formulario y usar curl, simplemente deshabilitando javascript todas las comprobaciones con javascript son inutiles.

Un saludo

[Ojete]

Gracias, me queda claro lo de java, entonces si se quiere evitar ataques, inyecciones, la manera de hacerlo es con lenguaje php??

[Ronruby]

Iniciado por Heli0s

El javascript no sirve de nada frente a ataques así, ni siquiera hace falta crear tu formulario y usar curl, simplemente deshabilitando javascript todas las comprobaciones con javascript son inutiles.

Un saludo

Si, me acorde ahora cuando abri el mensaje.

[Heli0s]

Exacto, Javascript es simplemente para darle comunidad y aspecto dinamico a una web, pero respecto a seguridad, no sirve nada.

[Ojete]

Iniciado por Heli0s

A veces se usan las cookies, se ponen variables en ellas, el usuario busca cual es la cookie de tu pag, mira las variables que hay, y con los metodos correspondientes edita el contenido de las variables poniendo el código que tenga que poner para realizar la inyeccion, como si fuese por post o get, pero por cookie.

Graciasentonces, como podemos evitar esto? de que manera y con que lenguage? php?

[mariomon17]

Si, PHP o cualquier lenguaje de servidor, osea que se ejecute alli. El usuario no podra ver el codigo original.

[Heli0s]

En mi anterior mensaje dije "comunidad", iba a editar pero no me dio tiempo, queria decir comodidad.

Para evitarlo simplemente tienes que tratar las variables que cojas de las cookies como "sospechosas", al igual que las que recibes por GET y POST, por lo tanto hay que realizar las comprobaciones que sean necesarias para evitar ataques.

[Ojete]

Iniciado por Heli0s

tienes que tratar las variables que cojas de las cookies como "sospechosas", al igual que las que recibes por GET y POST, por lo tanto hay que realizar las comprobaciones que sean necesarias para evitar ataques.

perdon pero no entiendo, cuando dices tratarlas como sospechosas a que terefieres? podrias explicar esto un poco mejor? Gracias...

[mariomon17]

Debes filtrar los datos para que no puedan ejecutar codigo JavaScript o SQL.
Funciones como:
htmlentities()
addslashes()
etc....

[Heli0s]

Yo en mis aplicaciones, paso todas las variables externas por -> htmlentities(addslashes(stripslashes(striptags($va r))));
striptags para evitar ataques XSS, stripslashes y addslashes, puede parecer contradictorio porque una las quita y otra las añade, pero lo hago asi por si el string ya viene con slash, las quito, y las pongo, así se con seguridad que no tendre slash repetidos, y despues htmlentities para codificar los caracteres como < > en su código ascii, ya que si se pone como código ascii no pueden realizar función alguna en cuanto a código.

Esas comprobaciones para mi son básicas en cualquier variable externa, y después están las especificas, si pasas un ID por url asegurarte que solo recojas números, básicamente asegurarte que cada variable tiene lo que debe de tener, y no caracteres raros.

Un saludo

[Ronruby]

Iniciado por Ojete

perdon pero no entiendo, cuando dices tratarlas como sospechosas a que terefieres? podrias explicar esto un poco mejor? Gracias...

Suponer que TODOS los usuarios son malignos y que podrian hacerle daño a tu sitio web, aun cuando muy pocos, desean hacerlo en realidad.

Tengo un libro en cuanto al tema, llamado Pro PHP Security de Chris Snyder & Michael Southwell. Si tienes facilidad de conseguirlo, te recomiendo leerlo (en ingles claro)

[Ronruby]

Iniciado por Heli0s

Yo en mis aplicaciones, paso todas las variables externas por -> htmlentities(addslashes(stripslashes(striptags($va r))));
striptags para evitar ataques XSS, stripslashes y addslashes, puede parecer contradictorio porque una las quita y otra las añade, pero lo hago asi por si el string ya viene con slash, las quito, y las pongo, así se con seguridad que no tendre slash repetidos, y despues htmlentities para codificar los caracteres como < > en su código ascii, ya que si se pone como código ascii no pueden realizar función alguna en cuanto a código.

Esas comprobaciones para mi son básicas en cualquier variable externa, y después están las especificas, si pasas un ID por url asegurarte que solo recojas números, básicamente asegurarte que cada variable tiene lo que debe de tener, y no caracteres raros.

Un saludo

Tampoco olvides el siempre importante mysql_real_escape_string() (que reemplaza a addslashes()) para insertar datos a tu BBDD MySQL.

[Heli0s]

Cierto, pero yo estaba hablando de comprobaciones genéricas, que se deben hacer con cualquier dato, y mysql_real_escape_string() se debe usar si los datos van a ir a una base de datos mysql, y no siempre se da esa situación.

Un saludo

[Ojete]

Bueno me han servido bastante sus comentarios gracias por la recomendación Ronruby, y gracias a los demás: Heli0s, mariomon17, Hidek1, pateketrueke...

[Heli0s]

Te dejo un link en el cual participe hace algún tiempo, donde se hablan de la mayoría de temas sobre seguridad en PHP.

Toma

[mariomon17]

Iniciado por Heli0s

Cierto, pero yo estaba hablando de comprobaciones genéricas, que se deben hacer con cualquier dato, y mysql_real_escape_string() se debe usar si los datos van a ir a una base de datos mysql, y no siempre se da esa situación.

Un saludo

Pero aunque los datos vayan a una BD, se puede utilizar addsalashes(), no?
¿Que tiene de diferencia con mysql_real_escape_string()?

[Ojete]

Iniciado por Heli0s

Te dejo un link en el cual participe hace algún tiempo, donde se hablan de la mayoría de temas sobre seguridad en PHP.

Toma

Muchas gracias Heli0s...

[Heli0s]

Siempre se puede usar addslashes, y la diferencia es que mysql_real_escape_string tiene algunos algoritmos mas de seguridad para mysql aparte de añadir slashes al string.

Aqui tienes la documentacion de la funcion.