Hace unas cuantas semanas Facebook decidió obligar a los desarrolladores de aplicaciones a hospedarlas en servidores que cuenten con certificados para que puedan ser acceder a través de HTTPS. Este cambio ha sido muy traumático para muchos de nosotros ya que supone la compra de un certificado. Lo peor es que se avisó con muy poco tiempo para uno poder objetar.

Gracias a Dios, hay una solución muy sencilla para resolver el problema de una manera economica más que segura: Shared SSL. Esto significa compartir el mismo certificado de SSL para todos las páginas de internet que compartan el mismo servidor. Resultado: facebook contento, pero no cuentes con ese certificado para ningún requerimiento de seguridad.

A todo esto, mi amigo y colega Juan Miguel Calcaño (asinox.net) ha decido comprarse un certificado para desarrollar sus proyectos, incluyendo los de Facebook. Aunque es bueno artillarse con todas las herramientas de seguridad posible, en mi opinión los certificados son una inversión que puede esperar a que tu negocio crezca o se presente una necesidad real.

Una de sus preguntas es “cuanto es el ahorro real con el Shared SSL y la ventaja?” y la respuesta que doy es la siguiente:


En cuál de los sentidos? lo dices para el caso de aquí (Multimedios El Caribe) o para el tuyo?

Si es el caso de aquí, innumerables…. para ir por el librito hubiésemos tenido comprar un certificado por cada cliente. El ahorro es de miles de dólares.

En tu caso el ahorro hubiese sido de algunos 100 a 200 dólares dependiendo de donde compraste tu certificado. Tal vez para ti no es mucho dinero… seguro estás forrado de dinero, pero con 100 dolares yo armo una muy buena campaña de Facebook y Google Ads que puede durar hasta 2 meses.

Que ventaja tienen los Shared SSL? Ninguna!!! Son pésimos, no ofrecen ninguna ventaja o beneficio y ni hablemos de seguridad. Las únicas dos cosas que se les pueden atribuir es que #1 son gratis y #2 funcionan con Facebook.

Pero para entender bien el despilfarro de dinero hay que entender para que se usan los certificados (seguro que lo sabes, pero repasemos). A groso modo:

  • Autenticación
  • Privacidad
  • Integridad

Autenticación: asegurarte que los dos integrantes de la conversación son realmente los que dicen ser quienes son.

Privacidad: que nadie ajeno a la conversación se entere de lo que está sucediendo.

Integridad: que nadie ajeno a la conversación pueda alterar la misma independiente de que esta persona pueda o no entender lo que se está hablando.

Entonces tu te preguntas a ti mismo: realmente necesito yo este nivel de seguridad para mis aplicaciones de Facebook? Creo que a menos que estés trabajando con datos sensibles para tus clientes no es necesario para nada tener un certificado propio.

Ahora bien, en el peor de los casos. Es extremadamente difícil que alguien pueda intervenir en una comunicación entre un cliente y un servidor. Para que esto pueda suceder tiene que suceder una de las siguientes situaciones:

  • El cliente y el atacante están en la misma red.
  • El atacante se encuentra en algún nodo entre el cliente y el servidor.
  • El Servidor y el atacante están en la misma red (Operador en el ISP?).
  • El cliente y/o el servidor tienen un virus que solo tiene acceso a ver los paquetes de red de una de las dos partes.

Estos casos son extremadamente difíciles de lograr, la seguridad siempre se rompe por donde la cuerda está más floja y eso generalmente es por la aplicación. Es en la mayoría de los casos muchísimo más fácil atacar un sistema con un SQL Injection que leyendo/modificando los paquetes de red.


 

En conclusión, los Shared SSL pueden ser una opción económica para el que quiera resolver este tipo de problemas como los de las aplicaciones de Facebook. Mi recomendación es que inviertan ese dinero en publicidad.

Ok, esta es la situación:

  • Tienes una serie de articulos en tu base de datos y quieres desplegarlos como una lista.
  • Por cada articulo que despliegues quieres traer las etiquetas relacionadas al mismo.

Pequeña observación:

  • Cuando haces dos consultas separadas (una para traer los articulos y otra para traer las etiquetas) se generan muchas consultas a la base de datos.

Posible solución:

  • Utilizar GROUP_CONCAT de MySQL para traer las etiquetas por cada registro a través de un JOIN.
  • Utilizar ARRAY_COMBINE para combinar los ids y etiquetas en un solo arreglo.

Ejemplo:

Este sería un ejemplo de la consulta:

SELECT
	art.*,
	GROUP_CONCAT(etq.id)		AS idEtiqueta,
	GROUP_CONCAT(etq.etiqueta)	AS etiquetas

FROM
	articulos AS art

LEFT JOIN
	rel_articulos_etiquetas AS rae
ON
	rae.idEtiqueta = art.id

LEFT JOIN
	etiquetas AS etq
ON
	rae.idEtiqueta = etq.id

GROUP BY
	art.id

Los registros que traerá se parecerán a algo similar a esto:

+-----------------------------------------------------------+
|TITULO   |   CUERPO   |   IDETIQUETAS   |   ETIQUETAS      |
+-----------------------------------------------------------+
|prueba   | ok.        | 5,10,15         | prueba, test, ok |
+-----------------------------------------------------------+
|Hola     | Mundo.     | 1,10,15         | hola, test, ok   |
+-----------------------------------------------------------+
|Mundo    | Hola.      | 5,10,2          | prueba, test, mundo |
+-----------------------------------------------------------+
etc.

GROUP_CONCAT simplemente lo que hace es desplegar todos los registros que no se estaban visualizando por algún GROUP BY que hagamos hecho. Por ejemplo: si hacemos una consulta SELECT GROUP_CONCAT(nombre) FROM EMPLEADOS GROUP BY departamento se agruparán los registros por departamentos y la consulta mostrará los nombres de los empleados que pertenescan a cada departamento. Si quitan el GROUP BY de la consulta el simplemente va a traer un solo registro con todos los nombres de los empleados separados por coma.

Ok, ahora vallamos a PHP. Imaginemos que tenemos los registros ya capturados en una variable $queryArticulos. Podemos hacer lo siguiente:

<?php
	while($art = mysql_fetch_object($queryArticulos)) {
		$ids		= explode(',', $art->idEtiquetas);
		$valores	= explode(',', $art->etiquetas);
		$etiquetas	= array_combine($ids, $valores);
?>
<div class="articulo">
	<h1>
		<a href="ver_articulo.php?id=<?php echo $art->id; ?>">
			<?php echo $art->titulo; ?>
		</a>
	</h1>
	
	<p><?php echo $art->cuerpo; ?></p>
	
	<ul class="etiquetas">
		<?php
			foreach($etiquetas as $id => $etq) {
		?>
		<li>
			<a href="buscar_por_etiquetas.php?id=<?php echo $id; ?>">
				<?php echo $etq; ?>
			</a>
		</li>
		<?php
			}
		?>
	</ul>
</div>
<?php
	}
?>

ARRAY_COMBINE lo que hace es tomar dos arreglos, uno de IDS y otros de VALORES, y unir ambos como si fuesen uno solo. Si tengo un arreglo “letras” con los valores (‘a’, ‘b’, ‘c’) y otro arreglo “colores” con los valores (‘rojo’, ‘verde’, ‘azul’) el resultado final será: (‘a’ => ‘rojo’, ‘b’ => ‘verde’, ‘c’ => ‘azul’)

Creo que esta forma de hacerlo es menos pesada en la base de datos ya que no hay que repetir varias veces la misma consulta. Si quieres traer 100 registros vas a tener que ejecutar 101 consultas, 1 para traer los artículos y 100 para traer las etiquetas. Ahora bien, hay que ser consientes de que el peso que le quitamos a MySQL de encima se lo estamos pasando a PHP ya que tenemos que realizar dos EXPLODEs y un ARRAY_COMBINE por cada uno de los registros. Ya dependerá del developer tomar la decisión de a quien quiere sacrificar: a MySQL o PHP.

Primero quiero aclarar que el siguiente post no es para perjudicar un partido en especifico o buscar intereses políticos. El objetivo es hablar de el mal uso de las estadisticas, cosa que puede ser peligrosa por que pueden mal informar a las personas que van dirigidas.

Vamos a tomar como ejemplo un anuncio reciente de la campaña de Hipolito Mejía sobre el precio de los plátanos en el 2004 vs ahora en el 2011. En el mismo se muestra la cantidad de plátanos que con RD$20 pesos se podían comprar en ese entonces (diez) en comparación con ahora (dos) lo cual da a entender (por que no lo exponen implícitamente) que antes se comía más plátano que ahora por el mismo precio y todo gracias al PRD. Mi problema con el planteamiento anterior es que no está fundado en buenas bases:

  • Si entraste a gobernar a mitad de año 2004, por qué te estás atribuyendo el año completo?
  • Por qué se tomó como referencia un simple plátano y no la canasta básica completa?
  • El salario mínimo de una persona en ese tiempo es el mismo que el de ahora?
  • En que porciento subió el plátano con relación al ingreso de los consumidores?
  • De donde han sacado esta información?
  • Por qué el precio de 20 pesos? Se debió buscar una media de comparación más justa

Por ejemplo, el precio del plátano en ese entonces era de casi RD$1.83 pesos al detalle (Fuente: Secretaría de Estado de Agricultura, informe 2007, Página 56) y ahora el precio está a RD$6.95 pesos (Fuente: Visión Agropecuaria, Investigación 2011) si utilizas RD$20 pesos como media de comparación te da 10.92 plátanos en el 2004 y 2.87 para el 2011. Como no te pueden dar 0.92 ni 0.87 plátanos, el gráfico mostrado por el spot públicitario del PRD no solo asume que se están quedando con tus fracciones de plátanos, sino que también con tu devuelta…….

Tenemos que saber utilizar de manera correcta los datos estadísticos para que no nos engañen, no engañemos a los demás y no nos engañemos a nosotros mismos. Nunca se fíen de un gráfico sin buena referencia. A que viene todo esto? Hace poco estaba discutiendo con uno de mis compañeros acerca de cuál sería la mejor forma de trabajar con el nombre de usuario de un cliente para una aplicación: como un nombre de usuario común y corriente o como un email? La justificación que el me daba era que casi todo el mundo tiene un email y es más fácil de recordar que un usuario (Estoy de acuerdo con esto último) y que el 90% de sus estudiantes tienen una cuenta de correo. El problema con este dato (aunque fuese correcto) es que la muestra que estaba usando (estudiantes) no era representativa de nuestro publico final (cajeras).

Es difícil creer que en pleno siglo 21 y tras las promesas de un futuro mejor a partir del XHTML y ahora aún más con el boom de HTML5, que empresas en la República Dominicana aún estén desarrollando páginas a tablazos limpios. Por qué lo hacen así? Quienes los están asesorando? Los dueños del website están consientes de la calidad de su producto? Todo esto es un misterio.

Este tema es extremadamente viejo, pero al parecer la gente aquí adoptó XHTML/HTML5 + CSS sin considerar por que se estaban cambiando. Aquí les coloco algunas de las razones por las cuales se dejó de trabajar con tablas?

  • El código es más desorganizado y por ende más difícil de trabajar.
  • El código es menos reusable y más difícil de actualizar
  • Las tablas no son amigables con los dispositivos móviles. Una página sin tablas tratará de acomodarse a la pantalla del dispositivo.
  • En ese mismo orden, las páginas hechas con tablas tienden a pesar mucho más que las páginas hechas con otros elementos.
  • Y principalmente por que cuando no usamos las etiquetas correctas el contenido pierde su valor semántico. Esto nos afecta en:

    • Pobre optimización para técnicas de posicionamiento en buscadores (SEO).
    • Menos accesibilidad para usuarios discapacitados.

Cosas para las que NO debiesen usar tablas son: diagramar tu página, hacer menúes verticales, desplegar datos que no se mostrarán ordenados por filas y columnas (Ej. Articulos de noticias y luego arreglarlos por CSS) y para sorpresa de muchos, tampoco los formularios deben desplegarse de esta manera.

Pero antes de que empiesen a satanizar las tablas, y a hacer como vi a muchas personas con el boom de XHTML, no vallan a organizar sus informaciones tabulares en etiquetas UL (ejemplo). Las tablas tienen su lugar y momento. Son bastantes útiles para desplegar Datos Tabulares, como los que están compuestos por un campo y uno o más valores. Ejemplos serían datos estadísticos, un reporte, una factura y otros datos que se asemejen a una tabla de base de datos o una hoja de calculo de Excel.

Una tabla bien utilizada puede ayudarte a:

  • Organizar información adecuadamente
  • Mediante el uso de THEAD, TBODY y TFOOT puedes lograr que cuando tu tabla se imprima y se extienda durante varias páginas la cabecera y el pie de página se repitan automaticamente en cada hoja para que tus usuarios no pierdan el hilo de la información que están leyendo.
  • Muchos pluggines de Javascript con solo tener una tabla bien organizada puedes lograr crear gráficos de barras y pasteles automáticamente, así como también lograr que los campos se organicen ascendente o descendentemente.

Ok, ya sé que muchos de ustedes se saben todo esto, pero parece que hay otros que aún están ciegos a las nuevas tendencias. Personas que deberían ser pioneros en el área y predicarnos con el ejemplo. Aquí les tengo uno de los tantos casos que hablo y créanme que no es el único:

Print-Screen de la página Visanet Dominicana demostrando su pobre utilización de tablas.

No solamente diagramaron su página completa usando tablas, sino que también su formulario se rompe cuando se abre en Chrome. Una hazaña nunca antes realizada y que se mantendrá en los anales de la historia

Para aquellas personas que todavía piensan que no pueden lograr desarrollar un formulario sin utilizar tablas, aquí les dejo el siguiente código. Para ver el ejemplo funcionando vallan a: http://jsfiddle.net/rene_olivo/yv9EM/

<form class="form" action="enviar.php" method="post">
    <div class="input text">
        <label for="nombre">Nombre:</label><br />
        <input type="text" id="nombre" name="nombre" />
    </div>
    
    <div class="input text">
        <label for="email">Email:</label><br />
        <input type="text" id="email" name="email" />
    </div>
    
    <div class="input radio">
        <label>Sexo:</label>
        
        <ul>
            <li>
                <input type="radio" id="sexo_m" name="sexo" value="M" />
                <label for="sexo_m">Masculino</label>
            </li>
            <li>
                <input type="radio" id="sexo_f" name="sexo" value="F" />
                <label for="sexo_f">Femenino</label>
            </li>
        </ul>
    </div>
    
    <div class="input checkbox">
        <label>Cómo escuchó acerca de nosotros?</label>
        
        <ul>
            <li>
                <input type="checkbox" id="contacto_web" name="contacto_web" />
                <label for="contacto_web">Web</label>
            </li>
            <li>
                <input type="checkbox" id="contacto_radio" name="contacto_radio" />
                <label for="contacto_radio">Radio</label>
            </li>
            <li>
                <input type="checkbox" id="contacto_periodico" name="contacto_periodico" />
                <label for="contacto_periodico">Periódico</label>
            </li>
        </ul>
    </div>
    
    <div class="input textarea">
        <label for="mensaje">Escribanos un mensaje:</label><br />
        <textarea id="mensaje" name="mensaje" cols="35" rows="6"></textarea>
    </div>
    
    <div class="input submit">
        <input type="submit" value="Enviar" />
        <input type="reset" value="Limpiar" />
    </div>
</form>

Algunos de ustedes saben que estoy trabajando para constituir mi empresa y uno de los tantos retos a superar es el manejo de los impuestos. En la poca experiencia que he tenido y a pesar de mi gran ignorancia en la mayoría de los procesos, solo tengo que reconocer que las normas de la DGII no se pensaron para el chiripero independiente. El asunto es tan complicado y tan poco user-friendly que muchas veces he deseado nunca haberme metido en este lio… pero como los burros, hay que seguir adelante sin mirar atrás. Para entender el asunto, hagamosle un review a algunas de las normas de la DGII:

  • Si no estás registrado en la DGII, o sea, no posees tu Registro Nacional del Contribuyente (RNC, para el trabajador independiente es la cedula), ni tus Números de Comprobantes Fiscales (NCF, un número de indentificación único por cada factura), no estás bajo las normas del DGII, lo que significa que:
    • No tienes protección legal contra la empresa a la que le provees servicios (A menos que halla un contrato pre-establecido).
    • La empresa está obligada a retener un 16% de ITBS del total de la factura, más un 10% de retención, para un total de un 26% por que ellos asumen que no vas a reportar ITBS.
  • El trabajador independiente, luego de entrar al sistema de la DGII, no sale… NUNCA!!! Ni siquiera cuando dejas de trabajar independientemente y consigues trabajo fijo. “Solo muerto se sale del sistema” en palabras de ellos.
  • Religiosamente debes reportar tus impuestos todos los meses, aunque nunca hallas hecho nada en ese mes. Tienen la facilidad de que puedes hacerlo por la oficina virtual…. el sistema “más amigable” del mundo.
  • Cuando la empresa a la que le estás trabajando es un Agente de Retención, ellos están en la obligación de quedarse con el 16% de ITBS y reportarlo ellos, aunque tu estés registrado en la DGII.
  • Por otro lado, tú como trabajador independiente tienes gastos, gastos que pagan ITBS. Si eres bien organizado, puedes pedir facturas con comprobantes en todos los establecimientos que vallas (gasolina, pago decuotas de un prestamo, compra de algún equipo inmuebles, etc.) y a través de la oficina virtual puedes subir un Excel con todos esos números y el total de ITBS que pagaste en todas esas facturas se te descontará en el total de ITBS que debes pagar de lo que retubiste en las facturas que tú generaste. El descuento solo es valido para el mes en que se generó esa factura.

Todas estás reglas hacen que el chiripear, tanto temporal/expontaneo o como modo de vida, se haga casi imposible. Lo primero es que a las empresas que están bien constituidas y que llevan su contabilidad por el librito les enctanta pagar impuestos!!! Así como lo oyen, dejenme explicarles el truco y como las empresas se benefician de esto con la siguiente historia:

Arriba, en la cadena alimenticia de empresas, hay una super-empresa que inevitablemente debe pagar impuestos (a esta empresa le llamaremos PALOMA de ahora en adelante), ya sea por que trae cosas por aduana, trabaja con el gobierno, es gubernamental, etc. Cuando otra empresa X (de ahora en adelante TIGUERES) adquiere productos y/o servicios de la empresa PALOMA esta tiene que pagar los ITBS correspondientes. Se crea un efecto ping-pong entre varias empresas TIGUERES vendiondo y comprandose productos y servicios unas a las otras. Ahí es donde entramos nosotros (LOS MáS PENDEJOS), los que estamos al final de la cadena.

Cuando nosotros LOS MáS PENDEJOS le ofrecemos un servicio a los TIGUERES van a tratar de retener de nosotros la mayor cantidad de impuestos posible. Cuando les enviamos una factura sin comprobante y sin ninguna especificación de ITBS, ahí es que ellas se están riendo con la muela de atrás, a la hora de pagar van a tratar de tumbarte el 26% (16% de ITBS + 10% de retención). El truco está en adquirir los productos bases de la empresa PALOMA, procesarlos o re-venderlos y adquirir servicios de LOS MáS PENDEJOS.

Ejemplo, si le haces un servicio y lo cotizas a $25,000.00, ellos le tumban $6,500.00 y tú solo cobras $18,500.00 . Esos $6,500.00 es un ahorro que ellos dejarán de pagar por los impuestos que los PALOMOS les retubieron. $6,500.00 que no caen nada mal……

Cadena Alimenticia de los Impuestos

Este diagrama puede explicar mejor la situación.

Esto explica como las empresas se benefician de nosotros, pero también hay que destapar que el sistema de la DGII simplemente no funciona para nosotros. Hay razones muy importantes como las siguientes:

  • Si yo no vivo de chiripear y simplemente hago uno que otro trabajo, ese 26% sube demasiado el costo del trabajo de uno. Si no especificas ITBS, te quieren mochar y si lo haces es un arma de doble filo….
  • Si haces trabajos muy exporadicamente, llevar el control de todo lo que hay que hacer para ir por el librito es demasiado tedioso. Llevar un control de todas las facturas que te generan y las que tú generas y procesar eso religiosamente todos los meses a través de la DGII (que no es el portal más amigable del mundo) hace que uno lo piense hasta tres veces.
  • Si te dedicas tiempo completo al trabajo independiente y llevas las facturas que te generan a ti, estas solo son validas para el mes en que se generaron. El problema aquí está en que por ejemplo tú armas tu oficina y pagas los impuestos de los inmuebles que adquiriste, pero duras un mes sin facturar, pues perdiste ese dinero. Otro caso: cotizas un trabajo y cobras el 50% alante, es bastante dinero y el proyecto es largo… pero duras varios meses sin cobrar. Todas las facturas que te generen en ese transcurso de tiempo no van a servir de nada…
  • Otro punto: Si te metiste de lleno a ese mundo de pagar impuestos, estás preso. No puedes salirte del sistema nisiquiera si te conviertes en un empleado fijo y tu empresa reporte tus ingresos, etc. Personalmente tuve un problema en el que dejé de reportar por un año (por ignorancia) y me pusieron una multa de $5,000.00 pesos sin yo haber hecho ningún trabajo por fuera, a lo que viene mi siguiente punto:
  • No existe un manual consiso de como pagar impuestos… el proceso es tan complejo… tengo años en esto y aún no comprendo todo. Como trabajador independiente no puedo pagar a un contador…. con lo poco que genero, me quitan el 26% y también tengo que pagarle a un contador???? El colmo!

En mi opinión, el trabajador independiente es una especie en peligro de extinsión. No tenemos voz ni voto y muchumenos un 4%. Quisiera saber si alguno de ustedes está pasando por la misma situación, si tienen algunas palabras de aliento o si ya le encontraron el truco a este sistema. Dejen sus comentarios con sus opiniones y espero que les halla gustado el artículo 🙂

Estoy pensando en utilizar Facebook como plataforma para publicar artículos sobre desarrollo web. A modo de prueba voy a colocar esta respuesta que hice a una pregunta en el grupo de Desarrolladores Dominicanos sobre cuál es la manera más segura de guardar passwords en una base de datos.

Aquí va:

———————————————–

MD5 es bastante seguro!!! el problema viene de las malas practicas de los desarrolladores. Independientemente del algoritmo de encriptación la forma más segura debe incluir un SALT.

http://en.wikipedia.org/wiki/Salt_(cryptography)

La siguiente implementación es bastante segura:

md5( $salt . $pasword);

Si deseas utilizar otro algoritmo que no sea MD5 puedes utilizar la función HASH de PHP, pero nunca te olvides de usar un SALT

http://php.net/manual/en/function.hash.php

Cuál es la seguridad en este caso? Si alguien entra a tu servidor y se roba tu base de datos o te hace un SQL Injection y busca la forma de ver la información de acceso de tus usuarios ya tu sistema está comprometido (jodio!), con esto se busca que no se comprometa información personal del usuario porque seguramente esa clave es la misma para otros sistemas. Ej. tu clave de facebook fácilmente es la misma que usas para tu internet banking.

Por qué MD5 y demás algoritmos no son seguros por si solos? porque aunque sean algoritmos de encriptación one-way hay gente que de ante mano hace un listado de claves y las van convirtiendo una a una a los equivalentes de todos estos algoritmos. Por ejemplo

abcdefg = 7ac66c0f148de9519b8bd264312c4d64

123456 = e10adc3949ba59abbe56e057f20f883e

fulano = 3342949e2e99fc2f304de6fdd626a188

Si en tu base de datos aparece un password e10adc3949ba59abbe56e057f20f883e (123456) ellos solo tienen que hacer un query a su tabla de conversión y les va a decir el valor de ese hash. Mira esta página por ejemplo:

http://www.md5decrypter.co.uk/

Ahora bien, como protege el SALT esa información del usuario? Los algoritmos de encriptación siempre van a devolver una cantidad de caracteres definidia sin importar la cantidad de texto que entres. Ej. una letra y un documento de word van a dar 32 caracteres en MD5. Si concatenamos a la clave un texto aleatorio y que sea secreto entonces se altera el hash que resulta de la encriptación. Si tengo un SALT que diga “DEVELOPERSDOMINICANOS@FACEBOOK” y trato de encriptar la clave “fulano” con MD5 obtengo:

93f88ff318f19a1521eb3b9f0f832f34 (Con salt)

VS

3342949e2e99fc2f304de6fdd626a188 (Sin salt)

trata de buscar los dos en la página anterior 😉

Puntos finales:

  • la seguridad nunca es absoluta (por más cliché que suene), uno solo trata de alargar lo inevitable.
  • Si alguien se roba tu tabla de usuarios o tu SALT, preparate a pedirle a tus usuarios que cambien de clave y tú debes cambiar tu SALT.
  • La última de mis preocupaciones sería que un “hacker” vea las claves de la base de datos, cuando ellos llegan a ese punto es porque ya han volado todos los niveles de seguridad de la aplicación. Estudia bien SQL Injection…. para empezar.