Creo que los programadores debemos cuidar un poco más nuestro código, puesto que todo el mundo sabe lo que SQL Injection, pero pocos son los que toman medidas oportunas para evitarlo.
Para introducir un poco, decir que hay dos tipos de ataques a una pagina, por software y por hardware.
En cuanto a los ataques por Hardware, se recomienda tener actualizado el sistema operativo, servidor web y servidor de base de datos. Tener siempre los ultimos parches instalados para evitar, en mayor medida, el ataque por la via del servidor.
Si nuestra pagina está alojada en un hosting .. es problema del ISP el mantener estos programas actualizados. En caso de tener un servidor propio o un servidor dedicado .. tenemos que tomar nosotros estas medidas. Los ataques con estas técnicas no suelen ser un tanto por ciento muy elevado.
El ataque por «descuidos» en nuestro software es bastante mas común. A continuación detallo algunos pasos para evitar, en mayor medida, los ataques por SQL Injection:
1.- El usuario de acceso a base de datos debe ser un usuario con privelegios unicamente para hacer INSERT, UPDATE, DELETE y SELECT.
El otro dia solucionamos un problema a un cliente pq le ejecutaban un procedimiento …
pagina.asp?id=909;DECLARE%20@S%20VARCHAR(4000);
SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C40432056
4152434841522832353529204445434C415245205461626C655F437572736F722043555253
4F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736
F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E69
6420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220
F7220%20AS%20VARCHAR(4000));EXEC(@S);–
Esto no lo podemos permitir.
2.- Proteger toda entrada de parametros a traves de una función que deseche posibles palabras «peligrosas».
En java no tenemos problema ejecutando todas las consultas con PreparedStatement.
En asp podriamos tener una función de la siguiente forma:
<%
function validar_entrada( input )
palabras = array( «script», «select», «insert», «update», «delete»,»drop»,»DECLARE»,»declare»,»EXEC»,»exec» ,»VARCHAR»,»varchar» , «–«, «‘» )
validar_entrada = True
if ( instr( 1, input, palabras(i), vbtextcompare ) <> 0 ) Then
validar_entrada = false
exit function
end if
Next
end function
%>
En php, podemos utilizar la funcion addslashes para evitar esto, o incluso, utilizar la funcion descrita en asp .. pero transformada para php
<?
function prepararValorSql($cadena) {
return preg_replace(«/(-)+/», «-«, !get_magic_quotes_gpc() ? addslashes(trim($cadena)) : trim($cadena));
}
?>
Espero que con estas pequeñas pautas, elimineis el 90% de ataques contra vuestras paginas.
No sería más facil y menos costoso validar los datos de entrada, por ejemplo si sabemso que es un número, poner
ASP:
Si es una cadena
Esto lo llevo haciendo años, y nunca me han jodido una web.
Eso es cierto tal y como comento en otro post
Proteger formularios contra robots, se deben realizar comprobaciones tanto en el lado cliente como en el lado servidor.
Si es cierto, que si permites una cadena, pueden ejecutar una sentencia sql …. pero es más dificil que esto ocurra.