Técnicas de ataque - SQL Injection (Inyección SQL)

Aunque se trata de un tema, bastante antiguo, y que no será facil de reproducir, aunque seguro que quedan sitios, que son vulnerables a este tipo de cosas. SQL Injection es una técnica de ataque a paginas, que intentan colar codigo SQL, dentro de codigo SQL de la aplcación destino, para romper o acceder a información. Con esto se quiere decir, que por ejemplo, si suponemos que una pagina web, tiene en su pagina de login, dos campos, usuario y contraseña, muy habitual, y para buscarlo hace lo siguiente:

SELECT * FROM Users WHERE Username='usuario' AND Password='contraseña'

Si hicieramos que tanto el usuario, como la contraseña valieran 1' OR '1'='1'

La sentencia quedaría de la siguiente manera:

SELECT * FROM Users WHERE Username='1' OR '1' = '1'  AND Password='1' OR '1' = '1'

Lo que técnicamente devolvería una lista con todos los usuarios, y podría en algunos casos, concedernos acceso a la página en cuestión. Curioso cuanto menos.

Si queremos ser un poco más destructivos, y conocemos el nombre de una tabla, o podemos intuir el nombre, se puede hacer algo como esto, a través de SQL Injection.

Si por ejemplo, se le da el valor al password de: x'; DROP TABLE users; -- y al usuario, por ejemplo 1 (este valor es indiferente para este caso)

el resutaldo sería, cogiendo la SQL arriba citada, el siguiente:

SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='x'; DROP TABLE users; --'

El -- final, es importante, porque se trata de dejar en comentario, el final de la SQL, paa que no falle, la comilla, que nos habran puesto, para parametrizar la String SQL de la contraseñá, en este caso el resultado, es que si la SQL se está ejecutando con permisos de borrado, y la tabla USERS existe, no exisitirá más.

Una vez explicado, como es SQL Injection, haciendo el mal, un par de ideas, para evitarlo, sin que sean muy complicadas de implementar.

Si por ejemplo, en vez de almancenar las contraseñas de los usuarios, lo que se almancena es un HASH de las contraseñas, como pueden ser SHA1 o MD5, entonces, al comparar las contraseñas, lo que se enviará a SQL para comprar no será el texto escrito por el usuario, sino el HASH que se genera, lo que en ningún caso será una SQL Injection.

Por otro lado, otra opción de baja tecnología, para solucionar este problema, quizá mucho menos fiable, pero si mucho más sencilla, es prohibir ciertos caracteres reservados de SQL en los textos, como pueden ser, las comillas simples, el OR, el AND, lo que viene a ser una lista negra de textos prohibidos, para que no ataquen al sistema.

Curiosidad final, si pusieramos este valor a la contraseña,

1; update users set password = 'password'; select *

Esto haría que las contraseñas de todos los usuarios, pasasen a valer "password" lo que tiene gracia, al menos si no le pasa a tu aplicación.

JSP Etiquetas logic:equal y logic:iterate Struts

Para esta entrada, vamos a hablar de la etiqueta de Struts, asociada a JSPs, para gestionar variables, que tengan un valor concreto, para ello, lo primero, la estructura de la misma.

Antes de empezar a utilizar etiquetas de struts, debemos incluir la referencia al tagLib en este caso en concreto, lo haremos de la siguiente manera:

<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>

Esto nos dará acceso a todos los tags de Struts, asociados a logic, a los que podremos acceder anteponiendo la palabra logic por delante del tag que queremos usar, para el caso de esta entrada, es equal y la podemos ver de la siguiente manera:

<logic:equal name="Formulario" property="VariableACompara" value="Valor a comparar">

...Codigo HTML en caso de que la condición sea cierta.

</logic:equal>

Pasando ahora a la etiqueta iterate, para recorrer una lista y ponerlo en una tabla, si tenemos un formulario en Java, que se llama Formulario, con una variable listaArecorrer (de tipo: ArrayList), declaramos una variable interna que podemos usar (nomVariableInterna: el tipo puede ser un objeto, y acceder a sus atributos: "PropiedadVariable") dentro del iterate, para acceder a sus valores o propiedades:

 

<table>

<th>titulo</th>

<logic:iterate name="Formulario" property="listaArecorrer" id="nomVariableInterna">
<tr>
<logic:equal name="nomVariableInterna"  property="PropiedadVariable" value="Valor">
<td  width="30">Opción</td>
</logic:equal>
<logic:equal name="nomVariableInterna"  property="PropiedadVariable" value="Valor">
<td  width="30">Otra Opción</td>
</logic:equal>

</tr>

</logic:iterate>

</table>

Esta entrada es una respuesta a, donde se preguntó por un ejemplo de recorrer una lista:

Etiqueta logic en Struts

UML Casos de Uso -- Escenarios

Después del éxito de esta entrada sobre UML, siguiendo con ese tema, tenemos otro tema de UML.

Un tema que a veces da para discutir en lo que a diseño UML se refiere, los escenarios.

¿Qué es un escenario en UML?

Un escenario en UML es una circustancia o situación, en la que se puede encontrar un sistema. Es decir, si cogemos un ejemplo de sistema, por ejemplo, este blog, una escenario podría ser, escribir esta entrada. Como puede entenderse de este concepto, un escenario es ampliio, y puede tener, diferentes formas de "ejecutarse" u ocurrir.

¿Para que sirven los escenarios?

Los escenarios, como hemos dicho, definen situaciones en las que se encuentra un sistema, esto quiere decir que, el conjunto de escenarios, definien el sistema, o al menos, lo que puede hacer el sistema. De lo que deducimos, que los escenarios nos sirven para definir, que hace y que no hace un sistema.

En un sistema de reservas on-line, podemos definir escenarios como pueden ser: Dar de alta un usuario, hacer una reserva on-line, dar de baja un usuario, modificar una reserva, pero podríoamos no tener un escenario de borrar una reserva, porque el sistema no la contemple.

¿Como se definen los escenario?

Hemos visto, que los escenarios definen al sistema, pero claro, al mismo tiempo, lo que puede hacer el sustema, define a los escenarios, esto lleva a una paradoja, que solo el "alcance" del sistema puede definir. El alcance es lo que define, que si y que no hace el sistema. (Si trabajas en un sector que funcione por proyectos, preguntate el alcance del tuyo ;) )

¿Partes del escenario?

un escenario, en si mismo puede dividirse, en acciones, estas acciones, defienn que caminos puede tomar un escenario. Como hemos visto, un escenario podría ser, dar de alta un usuario (todo un clásico), este escenario, dependiendo de lo que signifique dar de alta, hará una serie de acciones, que desencadenarán en posibles resultados diferentes.Al ver que los escenarios son condicionales, eso nos hace pensar, que pueden tener diferentes salidas o resultados, dar de alta un usario, puede acabar correctaement econ el usuario dado de alta, o incorrectamente, porque falten datos para el alta (por poner un ejemplo)

La ejecución "perfecta" de un escenario, se denomina Happy Path o Camino Feliz.

Entradas relacionadas en este blog:

UML diseño de agregación vs composición

Diseño UML Clase asociativa

Ingeniería inversa con eclipse Java2UML