2012-04-14 16 views
6

Estoy intentando mejorar la seguridad de mi aplicación. Cada vez que recibo datos del usuario (ya sea a través de POST o GET) que se supone que es un número entero, lo valido apropiadamente. Pero a menudo los datos son VARCHAR, y algunas veces pueden contener HTML.Protección contra inyección de SQL en ColdFusion

¿Cómo protejo mi DB de la inyección SQL en ese caso?

¿Protege <cfqueryparam value="#form.textInput#" cfsqltype="cf_sql_varchar"> la consulta de enviar una declaración SQL maliciosa dentro de un valor VARCHAR?

Respuesta

5

La respuesta breve a su pregunta es 'sí'.

Bloqueo de intentos de pirateo con tres métodos.

  1. Utilizo cfqueryparam en todas mis consultas a bases de datos. Usaré cfparam en la parte superior de los archivos de plantilla/cfm para las variables de ámbito url.

  2. He usado Portcullis o variantes de la misma. Puede obtenerlo llamando al http://portcullis.riaforge.org/. Portcullis también defenderá contra algunos ataques de scripts cruzados.

  3. Uso Windows IIS 7.5 (Windows Server 2008 R2). Uso la función Reescribir URL para bloquear la mayor parte de los ataques basados ​​en URL. Puede hacer cosas similares con Apache y la reescritura que admite. Aquí están mis reglas de reescritura de URL de IIS: se añaden

    <?xml version="1.0" encoding="UTF-8"?> 
    <appcmd> 
        <CONFIG CONFIG.SECTION="system.webServer/rewrite/globalRules" path="MACHINE/WEBROOT/APPHOST" overrideMode="Inherit" locked="false"> 
         <system.webServer-rewrite-globalRules> 
          <rule name="SQL Injection - EXEC - SCRIPT_NAME" stopProcessing="true"> 
           <match url="^.*EXEC\s*[\(|%28].*$" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - EXEC - QS" stopProcessing="true"> 
           <match url=".*" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
            <add input="{QUERY_STRING}" pattern="^.*EXEC\s*[\(|%28].*$" /> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - CAST - SCRIPT_NAME" stopProcessing="true"> 
           <match url="^.*CAST\s*[\(|%28].*$" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - CAST - QS" stopProcessing="true"> 
           <match url=".*" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
            <add input="{QUERY_STRING}" pattern="^.*CAST\s*[\(|%28].*$" /> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - DECLARE - SCRIPT_NAME" stopProcessing="true"> 
           <match url="^.*DECLARE.*$" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - DECLARE - QS" stopProcessing="true"> 
           <match url=".*" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
            <add input="{QUERY_STRING}" pattern="^.*DECLARE.*$" /> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - NVARCHAR - SCRIPT_NAME" stopProcessing="true"> 
           <match url="^.*CHAR\s*[\(|%28].*$" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - NVARCHAR - QS" stopProcessing="true"> 
           <match url=".*" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
            <add input="{QUERY_STRING}" pattern="^.*CHAR\s*[\(|%28].*$" /> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - sp_password - SCRIPT_NAME" stopProcessing="true"> 
           <match url="^.*sp_password.*$" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - sp_password - QS" stopProcessing="true"> 
           <match url=".*" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
            <add input="{QUERY_STRING}" pattern="^.*sp_password.*$" /> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - xp - SCRIPT_NAME" stopProcessing="true"> 
           <match url="^.*%20xp_.*$" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
          <rule name="SQL Injection - xp - QS" stopProcessing="true"> 
           <match url=".*" /> 
           <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
            <add input="{QUERY_STRING}" pattern="^.*%20xp_.*$" /> 
           </conditions> 
           <serverVariables> 
           </serverVariables> 
           <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> 
          </rule> 
         </system.webServer-rewrite-globalRules> 
        </CONFIG> 
    </appcmd> 
    

Estas reglas al directorio C: \ Windows \ System32 \ inetsrv \ config \ applicationHost.config archivo para IIS. Sin embargo, yo NO ****, recomiendo que edite este archivo directamente. Un error e IIS no se cargará. En su lugar copie & pegue las reglas anteriores y guárdelas como "iis-global-rewrite.xml". A continuación, ejecute el siguiente archivo por lotes para agregar las reglas para el servidor IIS: reglas de reescritura

C:\Windows\System32\inetsrv\appcmd.exe set config -in < iis-global-rewrite.xml 

El IIS deben trabajar con IIS 7.0 (Windows Server 2008), pero no he probado.

Estas reglas también se pueden aplicar a un único sitio utilizando el archivo web.config si no tiene acceso al servidor.

¿Por qué utilizo tres métodos diferentes de protección? Porque ninguno de ellos cubre todas las bases. Las reglas de reescritura de IIS solo protegen contra los ataques basados ​​en URL. Los hackers también pueden usar ataques de envío de formularios que hacen lo mismo. Prefiero las reglas de IIS como primera línea de protección porque funcionará con todos los sitios del servidor, incluidos PHP, ASP, etc. Portcullis es una buena segunda línea de defensa para ColdFusion, ya que detectará ataques basados ​​en formularios y algunas secuencias de comandos cruzadas. ataques. La última línea de defensa es el código cfqueryparam/cfparam que protege contra ataques de inyección SQL basados ​​en URL/formularios.

Si se utilizan los tres métodos, el servidor/sitio debe ser muy seguro. Todavía recomendaría revisar los registros del servidor de vez en cuando ya que los ataques evolucionan y mejoran.

+1

Guau, eso es simplemente perfecto. En realidad estoy ejecutando CF en IIS, así que definitivamente voy a buscar asegurar mi aplicación web con algunas reglas de reescritura más avanzadas. ¡Gracias! – Eleeist

+0

IIS URL Rewrite y Apache mod_rewrite son herramientas muy útiles para defensa y SEO. http://blogs.iis.net/ruslany/archive/2009/04/08/10-url-rewriting-tips-and-tricks.aspx tiene algunos ejemplos útiles para la reescritura de URL de IIS. –

6

La respuesta corta es sí.

cfqueryparam detendrá algunos ataques de inyección sql.

Existen otras variables de ataque que se pueden utilizar, así que tenga cuidado, pero un coldfusion bien escrito puede ser muy seguro.

Tenga cuidado con los ataques de Cross site scripting si está almacenando y luego muestra input html, tenga especial cuidado con las etiquetas javascript.

+0

Gracias! Eso fue realmente útil. – Eleeist

+3

La única vez que cfqueryparam * no * detendrá un ataque de inyección SQL no tendrá nada que ver con la naturaleza del ataque, sino con la naturaleza del código en la base de datos. Por ejemplo, si tuviera que llamar a algún procedimiento de base de datos que tomara un argumento varchar y lo ejecutara dinámicamente como SQL, ninguna cantidad de consultas parametrizadas lo ayudará. CfQueryParam * siempre * previene ataques de inyección de SQL cuando usa SQL simple (no llamadas de procedimiento de base de datos, etc.). –

+1

No se olvide de usar 'maxlength' también en campos de texto de longitud variable cuando corresponda. Si sabe que un campo de texto solo tendrá cadenas de hasta 16 caracteres, por ejemplo, no es necesario permitir cadenas más largas, ya que deberían marcarse como un error. –

Cuestiones relacionadas