Necesito para evitar ser vulnerable a inyección SQL en mi ASP.NET aplicación. Cómo puedo lograr esto?

OriginalEl autor balaweblog | 2008-11-20

16 Comentarios

  1. 22

    Aunque tu pregunta es muy genérica, algunas reglas se aplican siempre:

    • Utilizar consultas parametrizadas (SqlCommand con SqlParameter) y poner la entrada del usuario en los parámetros.
    • No construir cadenas SQL de desmarcada la entrada del usuario.
    • No asuma que usted puede construir una desinfección de rutina que se puede ver en la entrada del usuario para cada tipo de malformedness. Los casos extremos son fácilmente olvidados. Comprobación de entrada numérico puede ser lo suficientemente simple como para estar en el lado seguro, pero para la cadena de entrada solo los parámetros de uso.
    • De verificación para el segundo nivel de vulnerabilidades – no la construcción de cadenas de consulta SQL de SQL de la tabla de valores si estos valores consisten en la entrada del usuario.
    • El uso de procedimientos almacenados para encapsular las operaciones de base de datos.
    Todos ellos, excepto, tal vez, la última, están implícitas en la primera de ellas (si su entrada está correctamente escapado, siempre, por el uso de sentencias preparadas (o consultas parametrizadas)), no? O crees que hay diferencias sutiles?
    No. Pero alguien que hace este tipo de preguntas muy probablemente no tenga un claro entendimiento de las implicaciones. Haciéndolos explícitos es apoyar la comprensión. Como su experiencia y capacidad para abstraer lugar, usted no necesita la claridad, y no es probable para este tipo de preguntas más.
    Esta es una buena respuesta, pero tengo la sensación de que «el Uso de procedimientos almacenados para encapsular las operaciones de base de datos» es engañoso. Con parámetros dinámicos de SQL es tan segura como procedimientos almacenados con parámetros. Tal vez debería hacer que más implícito en su respuesta en aras de la claridad.
    Parametrice las consultas de como se usa con SqlCommand, se debe utilizar si el desarrollador no tiene mucho control o la experiencia en la base de datos de cosas técnicas. Creación de procedimientos almacenados en la base de datos no es sencillo si usted es una llanura C# developer y no DBA. El uso de los procedimientos almacenados es una buena manera de hacerlo si el DBA(s) quiere hacer en el fin de encapsular la complejidad para los desarrolladores de C#.
    Estoy de acuerdo. La respuesta podría ser mejor por dividir en 2 secciones: la Primera los puntos 2-4 como respuesta a lo que usted necesita considerar, y, a continuación, los puntos 1 y 5 como posibles soluciones sobre cómo resolver los problemas, señaló.

    OriginalEl autor Tomalak

  2. 12

    El uso de los parámetros! Realmente es muy simple 🙂

    Crear sus consultas como esta (para MS Sql server con C#):

    SqlCommand getPersons = new SqlCommand("SELECT * FROM Table WHERE Name = @Name", conn); 

    Aquí @Nombre es el parámetro donde se desea evitar la inyección sql y conn es un objeto SqlConnection.
    A continuación, agregar el valor del parámetro que hacer lo siguiente:

    getPersons.Parameters.AddWithValue("@Name", theName);

    Aquí nombre es una variable que contiene el nombre que está buscando.

    Ahora debería ser imposible hacer cualquier inyecciones sql en esa consulta.

    Ya que es así de sencillo, no hay razón de no uso de los parámetros.

    +1 para una buena respuesta y ejemplo específico.

    OriginalEl autor Rune Grimstad

  3. 11

    Nunca confíes en la entrada del usuario – Validar todos los textbox entradas utilizando los controles de validación, expresiones regulares, código, y así sucesivamente

    Nunca utilizar SQL dinámico Uso con parámetros de SQL o procedimientos almacenados

    Nunca conectarse a una base de datos con un nivel de administrador de la cuenta – el Uso de una cuenta de acceso limitado para conectarse a la base de datos

    No guarde secretos en texto sin formato – Cifrar o hash de las contraseñas y otros datos sensibles; también debe cifrar la conexión de las cadenas de

    Excepciones deben divulgar información mínima – no revelar demasiada información en los mensajes de error; uso customErrors para mostrar un mínimo de información en caso de error no controlado; conjunto de depuración a false

    Enlace útil en MSDN Detener la Inyección de SQL

    Buena respuesta, pero no estoy de acuerdo con «Nunca utilizar SQL dinámico». SQL dinámico es un término genérico y puede ser muy potente y hay muchos casos donde se debe utilizar. Su punto sólo debe ser de paso variable de datos como parámetros.
    Aye Robin, estoy de acuerdo SQL Dinámico puede ser muy útil y hay algunas buenas casos donde se debe utilizar, por mis puntos donde basada únicamente en la interacción con un usuario en el mundo exterior, para detener la inyección de SQL. Por ejemplo, las instrucciones SQL construido por la concatenación de SQL con los valores introducidos por el usuario.
    hmm me acabo de -1 voto, así como un número de puestos por debajo de mí, chocando todos nosotros hacia abajo? (todos por el mismo usuario, tal vez??)
    +1 para el uso de una cuenta limitada de la línea de

    OriginalEl autor kevchadders

  4. 4

    De inyección SQL se produce porque la consulta a la base de datos se construye en tiempo real, por ejemplo:

    SELECT * From Table1 WHERE " + UserInput

    UserInput pueden ser maliciosos y contienen otras afirmaciones que no se desea.

    Para evitar esto, usted necesita para evitar la concatenación de la consulta juntos.

    Usted puede lograr esto mediante el uso de consultas parametrizadas – echa un vistazo a la DBCommand objeto de su particular DB sabor.

    OriginalEl autor Brian Schmitt

  5. 3

    Uso parametrización de consultas y/o procedimientos almacenados y analizar sus parámetros a través de los parámetros SQL. Nunca generar código SQL mediante la concatenación de cadenas. También leer un poco acerca de la inyección de SQL y acerca de la escritura de código de seguridad, debido a que la prevención de la inyección de SQL es sólo una pequeña parte de la seguridad. Hay muchos más (como XSS Cross Site Scripting). Si un hacker quiere comprometer su sitio/aplicación que va a buscar más, a continuación, sólo la inyección de SQL.

    OriginalEl autor Gertjan

  6. 3

    Scott Guthrie publicado un poco decente artículo sobre esto hace un tiempo. En él, ofrece 5 sugerencias para protegerse a sí mismo:

    1. No construir Sentencias SQL dinámicas sin necesidad de utilizar un tipo de seguro parámetro mecanismo de codificación. […]

    2. Siempre realizar una revisión de seguridad de su aplicación antes de ponerlo en producción, y establecer una formal el proceso de seguridad para revisar todo el código en cualquier momento de efectuar actualizaciones. […]

    3. Nunca almacenar datos sensibles en texto claro dentro de una base de datos. […]

    4. Asegurarse de que usted escriba la unidad de automatización de pruebas que específicamente verificar su capa de acceso a datos y la aplicación en contra de los ataques de Inyección SQL. […]

    5. De bloqueo de la base de datos sólo se conceda la aplicación web de acceso es el conjunto mínimo de permisos que necesita para funcionar. […]

    Él hace un trabajo decente de explicar por qué estos son importantes, y enlaces a varios recursos como así…

    Importante muy bien, pero sólo la primera viñeta se aborda el OP pregunta.

    OriginalEl autor Max

  7. 2

    NUNCA confíes en la entrada del usuario, siempre validar, y el uso de los parámetros sql. Debería ser suficiente para evitar la inyección de código SQL.

    OriginalEl autor James

  8. 0

    El libro, «la Construcción de Segura ASP.NET Aplicaciones de la» guía tiene un sección sobre este tema.

    OriginalEl autor JohannesH

  9. 0

    Como otros han dicho, no concatenar la entrada del usuario para crear sentencias sql dinámicas; siempre usar SQL con parámetros cuando el uso de SQL dinámico. Sin embargo he de señalar que esta regla se aplica también a la hora de crear sql dinámico dentro de un procedimiento almacenado. Este hecho es algo que la gente suele pasar por alto. Ellos piensan que son seguros porque son «el uso de procedimientos almacenados.»

    OriginalEl autor Daniel Auger

  10. 0

    Uso de XSS Asegurado UrlEncode el uso de Microsoft.De seguridad.Aplicación.AntiXss.UrlEncode y de inyección de SQL, no funcionará. O Usted puede utilizar ASP.NET – JSON – Serialización y Deserialización

    También probar la aplicación con SiteDigger de Macfee Fre Herramienta.

    Algunos Más de aquí

    .NET Security Toolkit v1.0
    .NETMon v1.0
    Validator.NET v1.0

    OriginalEl autor Sashi

  11. 0

    Todo el mundo dice «el Uso de los parámetros». Tendríamos que decir lo menos, si no fuera tan perversamente difícil.

    Uso QueryFirst. La tentación para concatenar es eliminado, y de la manera correcta se convierte en la manera más fácil. Crear un parámetro con solo escribir @myParam en SQL, la herramienta hará el resto.

    descargo de responsabilidad: yo escribí QueryFirst

    OriginalEl autor bbsimonbb

  12. -3

    Entender qué es exactamente una Inyección de SQL y, a continuación, nunca escribir nada de lo que es vulnerable a ella.

    OriginalEl autor Robin Day

  13. -4

    Intentar utilizar Procedimientos Almacenados, y validar la entrada de datos. No utilice ningún daño directo SQL como INSERT INTO …

    Los Procedimientos almacenados no tienen nada que ver con él, usted puede ejecutar un SP en una forma insegura por no parametrización de la llamada.

    OriginalEl autor MysticSlayer

Dejar respuesta

Please enter your comment!
Please enter your name here