Hay una cosa que me preocupa un poco. Tengo entendido que uno de los caminos que usan los hackers para entrar en los servidores es a través de las bases de datos. Como andamos aprendiendo su uso me parece una buena idea empezar a investigar desde ya cómo evitar estas entradas no esperadas cuando usamos aplicaciones de php y mysql.
Por el momento no tengo ni idea, me ayudais a investigar? Podemos ir colocando acá lo que aprendamos y conforme le demos forma pasarlo a los contenidos de CCTW en forma de lecciones, oki?
Por el momento lo único que se es que los hackers usan lo que llaman "inyecciones" en las páginas que poseen codigo php con instruccones "if".... voy a investigar y os cuento. Haced lo mismo y terminamos antes, vale?
lo que se yo ahora, es que los cracker (no hacker, hay diferencias entre ellos) para entrar en una base de datos, primero necesitan saber en que IP esta alojada. Para ello, usan, flecos entre web, entre ellos los errores 404. Por eso es importante, crear una web para el error 404 personalizada, para eliminar ese fleco.
voy a ser breve con este tipo de vulnerabilidades. SQLi (SQL Injection):
Ocurre cuando obtenemos datos mediante GET o POST sin restricciones a codigos especiales como comillas, cometarios ("--","#","/*"), etc. en sí todo lo que se les ocurra que pueda alterar una sentencia SQL.
Ejemplo del código vulnerable:
<?php $name=$_POST['name']; $pass=$_POST['pass']; $conexion=mysql_connect($dbhost,$dbuser,$dbpass) or die("Error."); mysql_select_db($dbname,$conexion) or die("Error."); mysql_query("select * from users where name='".$name."',$conexion) or die("Error");
El tema es que si ponemos como nombre por ejemplo ' OR 1=1-- la sentencia quedaría así: mysql_query("select * from users where name='"' OR 1=1--"',$conexion) or die("Error");
lo que retorna true porque 1=1 y con el cometario ("--") igonramos todo lo que sigue.
Codigo seguro: $name=htmlspecialchars($_POST['name']); $pass=htmlspecialchars($_POST['pass']); $conexion=mysql_connect($dbhost,$dbuser,$dbpass) or die("Error."); mysql_select_db($dbname,$conexion) or die("Error."); mysql_query("select * from users where name='".mysql_real_escape_string($name)."',$conexion) or die("Error");
htmlspecialchars= pasa todos los caracteres html a su entidad html. mysql_real_escape_string= coloca slashes delante las comillas y otros caracteres.
=FeMe= escribió:voy a ser breve con este tipo de vulnerabilidades. SQLi (SQL Injection):
Ocurre cuando obtenemos datos mediante GET o POST sin restricciones a codigos especiales como comillas, cometarios ("--","#","/*"), etc. en sí todo lo que se les ocurra que pueda alterar una sentencia SQL.
Ejemplo del código vulnerable:
<?php $name=$_POST['name']; $pass=$_POST['pass']; $conexion=mysql_connect($dbhost,$dbuser,$dbpass) or die("Error."); mysql_select_db($dbname,$conexion) or die("Error."); mysql_query("select * from users where name='".$name."',$conexion) or die("Error");
El tema es que si ponemos como nombre por ejemplo ' OR 1=1-- la sentencia quedaría así: mysql_query("select * from users where name='"' OR 1=1--"',$conexion) or die("Error");
lo que retorna true porque 1=1 y con el cometario ("--") igonramos todo lo que sigue.
Codigo seguro: $name=htmlspecialchars($_POST['name']); $pass=htmlspecialchars($_POST['pass']); $conexion=mysql_connect($dbhost,$dbuser,$dbpass) or die("Error."); mysql_select_db($dbname,$conexion) or die("Error."); mysql_query("select * from users where name='".mysql_real_escape_string($name)."',$conexion) or die("Error");
htmlspecialchars= pasa todos los caracteres html a su entidad html. mysql_real_escape_string= coloca slashes delante las comillas y otros caracteres.
Saludos.
La explicación perfecta, y la solución es válida normalmente, pero dependiendo del parámetro "magic_quotes" del PHP del servidor puede fallar esa solución.
Yo me he creado una clase para manejar las peticiones a la base de datos que ya me da los resultados en array, para no repetir lo mismo cientos de veces. Te lo dejo en mi web, que paso de copiarlo aquí con el BBCode:
hola tengo entendido que el alojamiento tiene un sistema anti hack si no esta dentro del servidor panel de control no seria posible conectar , ¿como suponen que un jacker ba entrar ahy? , tendria que ser muy devil el alojamiento.
error, men te lo dice un hacker retirado, Si se puede hacer para eso existen los exploits. Además el hackeo de base de datos es tan común que ni siquiera las grandes compañías como los dueños de WoW pudieron evitar que les hackearan las bases de datos y le copiaran su obra maestra (el juego WoW).
Además si buscas en la web paginas como face boock o youtube también les han hackeado las bases de datos, y en la web conseguirás plantillas de sus paginas con cuentas y demás.
En este mundo nada es imposible, por eso los web master siempre debemos estar pendientes de cualquier debilidad en nuestras webs (aunque sea probando su seguridad tu mismo).
edito Haber me explico mejor con los exploits.
Los exploits operan normalmente através de los errores 404 ya que esos huecos en la web son casi como unas puertas abiertas al Server, permitiéndote meter lo que te de la gana en esos huecos (mas que todo se colocan puertas de acceso secundarias, algo así como un ftp global)
Aja pero como ce hace con los php, tal y como dicen los errores de sintaxis o pequeños fallos casi invisibles, o que el Server se sature y el php sufra un error, o simplemente un código débil en lo que se refiere a su estructura; también es una entrada para los exploits, ya que através de ellos se puede entrar a la bd con una puerta de acceso secundaria. Por eso debemos cuidarnos de cualquier hueco o de códigos débiles en la estructura, y sobre todo (algo que debería decir en el curso paso a paso) que en todas las carpetas en donde alojemos imágenes o que alojemos otras carpetas debe haber una hoja html nombrada index (es muy impórtate que posea ese nombre) que no contenga nada solo es para evitar ese hueco. La ultima debilidad que les nombre es la mas grave ya que si usamos el analizado SSS mostrara eso como un error grave, los Crakers experimentados usan este error para apropiarse de tu web ya que la pagina que mostraría el servidor diría "index of..." y las carpetas o imágenes que estuvieran hay es una entrada directa a los archivos de control de la web y en esencia los accesos a todo el Server (con Server no me refiero solo a tu pagina si no a todo el servidor ficio).
Amigo los programas de protección lamentablemente no pueden hacer mucho contra estos errores ya que son excepciones para que las webs funcionen como deben.
aparte del index.html que tengo en la raíz....., debo de crear otro index.html ( sin nada de información, solo vació ese archivo ) en las carpetas que tengo en mi web y hasta en la de objetos también?
perdón, pero no me queda claro . . .,
aun no tengo bases de datos en una de web ... , pero las tendré..., aun así , ¿ sin ser dinámica mi web, siendo estática..., debo crear ese archivo en mis carpetas?
es para mayor seguridad, si te das cuenta si entras a una carpeta sin index se verian y visualizarian todos tus archivos , poniendo un index ya no se podrian visualizar asi de facil.
En otras palabras si. Sin importar si es dinámica o estática es necesario hacer esto para mayor seguridad. Aparte agrego que en si esas tres cosas que aclaramos es lo esencial para proteger las webs, lo demás depende de uno y de la estructura de tu pagina.
Hago mi aportación y experiencia en el tema (ya que me han hackeado las BBDD varias veces eliminado el contenido que había en ellas :mad:)
Si vas a recoger una variable $_POST o $_GET y la vas a guardar en otra, es recomendable usar las diferentes funciones (definidas por defecto de PHP) que han mencionado nuestros compañeros anteriormente.
Yo para recoger una variable $_POST del campo comentario de un formulario, por ejemplo, hago lo siguiente:
?
$variable = stripslashes($_POST['comentario']); // Elimino código malicioso
$variable = strip_tags($variable); // Elimino código malicioso
$variable = htmlentities($variable); // Elimino código HTML que pueda alterar el diseño de mi web.
?>
Con este sencillo código, evito que instroduzcan código malintencionado o no deseado en la BBDD.
En cuanto a la protección de los archivos e imágenes, pongo en todas las carpetas un index.html vacio :) (Al ver que PHPBB lo hacía, lo empecé a hacer yo también. Después de unas semanas me di cuenta de cual era el objetivo de los index.html en blanco xD )
Por otro lado, para evitar que los buscadores como Google indexen directorios o archivos que yo no quiero que sean rastreador por dicho buscador, uso las herramientas para webmaster que ofrece google (exactamente la herramienta que te ayuda a posicionar tu web en el buscador) y creo un archivo, robot.txt (google te crea dicho archivo) y en él, defino que archivos y directorio permito a google que explore e indexe.
En la raid tengo un index.html, que es la pagina de inicio, y sin embargo aqui se habla de pone un index.html vacio, si cambio el index.html que tengo a index.php, el usuario al entrar en la pagina se le abrira el index.html, no?
En ese index.html se le puede redireccionar a index.php, seria seguro?
En la raid tengo un index.html, que es la pagina de inicio, y sin embargo aqui se habla de pone un index.html vacio, si cambio el index.html que tengo a index.php, el usuario al entrar en la pagina se le abrira el index.html, no?
En ese index.html se le puede redireccionar a index.php, seria seguro?
Gracias
Un saludo
Supongamos que tienes una carpeta donde tienes toooodas las imágenes de tu web ¿no?. Te ha costado mucho trabajo diseñarlas etc.. y no quieres que NADIE entre a ese directorio por medio de http://www.tuweb.com/imagenes ya que por este medio vería todas y las podría descargar sin ningún problema, pues para ello crear un index.html vacío para que dicha persona cuando escriba http://www.tuweb.com/imagenes se encuentre con una página en blanco. Este mismo ejemplo es aplicable a demás carpetas y archivos.
Amigo para complementar, solo debes crear el index.html en las carpetas que partan del root(la zona principal de la web) O en otras palabras si tienes esto en tu host.
Las carpetas objetos, galerias, comentarios, y otrascosas deberían tener adentro un index.html en blanco por seguridad, y en donde esta index.php no colocar nada, ya que reconocerá como pagina de inicio el index.php.
Con poner el index.html en las carpetas, restringir las variables $_POST como se ha anunciado al principio y generando la pagina de error 404, ya seria mas o menos fiable la seguridad?
Aun que supongo que eso sera como todo, aunque valiese de momento siempre iran cabiando y avanzando las cosas tanto por los hakers como por los webmaster. no?
Lo pregnto por que yo estoy termiando una pagina que quiero subir, y la voy probando en un servidor gratuito, que no me va mal, pero he visto que si a entrado alguien(Eso si no tenia ni los index, ni restringidas las $_POST), es un registro lo que esto probando ahora y en la base de datos aun que tengo puesto en el form que los campos sean obligatorios, no los habian rellenado, solo el usuario el password y el email, pero en los tres campos ponia virus, cuando el email lo tengo que sea abligatorio y email, lo valide asi en dreanweaver. No entiendo como podia poner solo virus. sin @ ni dominio.
Ya si e puesto los index y e restringido las variables, ahora me falta generar la pagina 404 esa, a ver si doy con ello.
La verdad es que yo es lo primero que hago y hece menos de un año no tenia ni idea de nada, hice el curso paso a paso y de ahi me empezo a picar la curisidad.
Claro Jeyn, las medidas de seguridad que damos aquí son muy superficiales, siempre le puedes complicar más la vida a los Crackers y Hackers maliciosos de causarte algún problema.
Supongo que con restringir las variables $_GET y $_POST te refieres a limpiar dichas variables de código malicioso antes de ser guardadas en tu BBDD ¿no? si es así, has captado la esencia de este tema :)
Yo le he puesto como se a indicado al principio a las $_POST cuando las recojo en registro.php, de un formulario.html form action "registro.php" en el registro.php en vez de recuperar los datos directamente de $_POST he puesto $user,que lo ehe recogido en la vaiable asi: $user = htmlspecialchars($_POST['username']); No guardo la variable en la BBDD, y asi la recojo en las paginas que la necesito, eso si lo tengo qeu hacer en toas las paginas que llame a la variable, pero bueno eso ya esta. Igual soy un poco torpe, pero es como me he enterado. Ha! y si me funciona eso si que no se que nivel de seguridad puede dar. Me gustaria que me entendierais, es mi primera pagina y no se muy bien por donde ando, igual me he metido en mas de lo que debo.
he estado mirando lo del enlace que me as puesto y entonces debo de poner los tres codigos para cada variable, supongo que $variable en el caso de antes seria $user, es que como se repite tanto la $variable, por eso lo pregunto.
Cuando se trata de seguridad, alguna vez lei que hay que desconfiar de todo, y no creer que el usuario va ha seguir las intruciones al pie de la letra, si tu en un formulario pides un numero, al recoger la variable asegurate de que efectivamente sea un numero, si es un correo, asegurate que sea un correo, si es un nombre de usuario, asegurate que cumple con ciertas caracteristicas, todo eso se logra con validaciones, claro esta entre mas seguridad, mas robusta tu pagina y mas recursos consumira.
Quizas para poder ayudarte mejor, deberias postear la url de prueba de tu web, asi los mas experimentados podrian testear tu web y darte consejos en cuanto ha seguridad.
Jeyn escribió:he estado mirando lo del enlace que me as puesto y entonces debo de poner los tres codigos para cada variable, supongo que $variable en el caso de antes seria $user, es que como se repite tanto la $variable, por eso lo pregunto.
Asi pasa que no me entero bien hasta qeu no me estrello.
Gracias
Si, perfecto, lo has entendido. Lo que vos ponés ($user = htmlspecialchars($_POST['username'])) también es correcto, es más, esa sería otra "regla" a poner para eliminar cualquier intento de inyección a la BBDD. Mírate también lo que dice nuestro compañero serverdns, su aporte es muy interesante y muy bueno. Y no te lies, yo hablaba de variables a guardar en BBDD, pero como te has dado cuenta, se puede ampliar a todas las variables que pretendes que el usuario te envíe.
serverdns, me gustaría que por favor compartieras tu código con nosotros, estaría genial.
Cookies
Usamos cookies necesarias y, si lo autorizas, Google Analytics. Puedes cambiar tu elección cuando quieras.
