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

Google Analytics (error _gat undefined)

[caption id="" align="alignright" width="188" caption="Image via CrunchBase"][/caption]

Un error al parecer bastante habitual el empezar con Google Analytics, es el de encontrarnos con el siguiente error “_gat undefined“ parece que esto se debe a no alcanzar el código Javascript que Google tiene colgado al respecto, es imporante tener en cuenta que esta línea debe encontrarse dentro de la página donde se quiera hacer funcionar Google Analytics.
<script src="http://www.google-analytics.com/ga.js" type="text/javascript">
</script>
Para evitar el error, cuando estamos hacienda pruebas en local, puede utilizarse el siguiente cambio al código Javascript, que como vemos, comprueba que se ha declarado la variable _gat para poder obtener el tracker de Analytics..
<script type="text/javascript">

function mygat(){
if (typeof(_gat) == 'undefined') {
window.setTimeout(mygat,1000);
}
else {
var pageTracker = _gat._getTracker("UA-xxxxxxx-x");
pageTracker._trackPageview();
}
}

function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
}
else {
window.onload = function() {
if(oldonload){oldonload();}
func();
}
}
}

addLoadEvent(mygat);
</script>

WhatsApp vuelve a la AppStore de Apple

[caption id="" align="alignright" width="180" caption="Image via Wikipedia"][/caption]

Segunda entrada al respecto, pero al parecer, una actualización de la popular aplicación ha hecho que la empresa de Cupertino de permiso a WhatsApp para volver a su tienda.

Desconocemos aún la razón de su retirada y vuelta a la store, pero esta claro, que parece interesante actualizar la versión de la aplicación, por si solventa algun agujero de seguridad crítico.

WhatsApp retirada de la App Store

Como suena, el titulo dice casi todo, WhatsApp ha sido retirado de la App Store de Apple, por motivos de seguridad.

Hay varios rumores de porque se ha retirado la aplicación, porque al parecer temas de seguridad varios, ha tenido esta aplicación a lo largo de su vida en la tienda de Apple. Aunque de lo más oido, es que podría tratarse de un intento por sacar adelante iMessage, aunque no parece uy logico teniendo en cuenta lo que gana Apple con cada WhatsApp.

Veremos como evoluciona este tema.

Hilos en Java (Thread) I

La programación en hilos en Java, o mejor dicho la programación concurrente en más sencilla de implementar de lo que parece, aunque primero antes de entrar en detalles de cómo hacerlo, en este post, hablaremos de que son.

-          Que es un Thread

Un thread es un proceso ligero (en el caso que vamos a ver Java) que comparte memoria con otros iguales.

-          Qué ventajas tiene

La primera ventaja radica en que es más fácil para el planificador, intercambiar entre los procesos Thread, ya que son más ligeros, que entre otros procesos.

-          Paralelo vs Concurrente

Paralelos son dos procesos que se ejecutan al mismo tiempo, porque existen varios procesadores en los que ejecutarse, o uno con varios núcleos, que resuelven un único problema en menos tiempo.

Concurrente es un proceso paralelo que nada tienen que ver entre sí, comparten un espacio de memoria, pero no hacen una tarea común.

-          Problemas habituales

El primer problema habitual en el uso de Threads, está que al ser dos tareas concurrentes, podría darse una situación conocida como la exclusión mutua (que consiste en que dos o más procesos no se dejan terminar unos a otros, porque se bloquean entre ellos). Un ejemplo de exclusión mutua, es que por ejemplo un proceso A necesite los ficheros A y B para terminar y solo tenga A, y un proceso B, necesite también los ficheros A y B, y solo tenga B, de tal forma que ninguno de los dos puede acabar nunca, porque tienen el fichero que el otro necesita para terminar bloqueado.

Otro Problema habitual es el de la visibilidad de los cambios, suele ser habitual, que no sea fácil de gestionar, como se ven los cambios, en los procesos que son paralelos, ya que, si se realiza una actualización sobre algún dato, no siempre estará disponible al instante para otros procesos.

Como se implementa en Java, esto queda para la segunda entrega de este post, que enlazaré aquí cuando esté hecho, pero hablaremos de run() y synchronized()