Algunas dudas con respecto a Codeigniter y la Entrada de las capacidades de manejo. Algunos pueden ser un poco raros, pero son dudas ninguno-el-menos.

  1. Si puedo usar el Active Record funciones de Clase en CodeIgniter, es mi entrada prevenirse contra inyección SQL?
  2. He leído en algún lugar que no, pero yo no lo entiendo, ¿cómo? o ¿por qué?
  3. También hace xssclean lidiar con la inyección de SQL en cualquier forma?
La palabra active record puede ser mal entendido y CI docs tiene que cambiar para query builder codeigniter.com/user_guide/database/query_builder.html

OriginalEl autor OrangeRind | 2010-09-26

3 Comentarios

  1. 16

    es mi entrada prevenirse contra inyección SQL?

    No exactamente ‘automáticamente’, pero provee de parametrizar las consultas. CodeIgniter o no, usted debe utilizar parametrizar las consultas en la preferencia de la cadena de consulta de la piratería siempre que sea posible.

    $bof= "a'b";
    $zot= 'a\b';
    
    // Insecure! Don't do this!
    //
    $this->db->query("SELECT foo FROM bar WHERE bof='$bof' AND zot='$zot'"); 
    
    //Secure but annoying to write
    //
    $this->db->query("SELECT foo FROM bar WHERE bof='".$this->db->escape($bof)."' AND zot='".$this->db->escape($zot)."'"); 
    
    //This is what you want
    //
    $this->db->query('SELECT foo FROM bar WHERE bof=? AND zot=?', array($bof, $zot)); 

    Nota esto no tiene nada que ver con la ‘entrada’: cuando se realiza una consulta SQL a partir de cadenas de debe uso de parametrización o escape para que quepan, independientemente de si son de entrada de usuario o no. Esta es una cuestión de simple corrección; la seguridad no es un efecto secundario de esa corrección.

    De manera similar al texto de salida en HTML, usted necesita para HTML-codificar <, & y " caracteres luego. Es absolutamente ningún uso tratando de jugar con la entrada de escapar o quitar caracteres que pueden ser problemáticos en el futuro si usted usa sin escapar en SQL o HTML. Vas a destrozar su salida por tener inesperado SQL-escape en HTML (que es la razón por la que la auto-multiplicación de barras en mal escrito apps) y no deseados HTML de escapar en SQL. Y debe usted tomar el texto en que la directa entrada de usuario (es decir, material que ya están en la base de datos) no están protegidas en todo.

    También hace xssclean lidiar con la inyección de SQL en cualquier forma?

    No. Está dirigido a las de inyección de código HTML. Pero es peor que inútil. Nunca lo uso.

    «Filtrado XSS» es completamente falso (de nuevo, CodeIgniter o cualquier otro). XSS debe impedirse correctamente el HTML, escapa de salida, no destrozando la entrada. Vulnerabilidad XSS en el filtrado de las no proteger adecuadamente si su aplicación no está seguro; en el mejor de los ofuscará sus deficiencias y dar lugar a un falso sentido de seguridad. También va a destrozar una gran cantidad de entrada válido que CI piensa que se parece a las etiquetas.

    Muy interesante! Especialmente el último punto. Creo que su forma es realmente mejor.
    Cuidado de explicar por qué el CI xssclean no sirve para nada? Estoy seriamente curioso! Es la mitad de la razón por la que el uso de CI. Me gustaría saber si me estoy engañando a mí mismo y no segura!
    Si estás recordando a HTML-escapar de todas las cadenas de salida en sus páginas HTML, usted está seguro de si usas o no xss_clean, y todo lo que va a hacer por usted es el silencio destrozando sus cadenas de entrada, en terriblemente extrañas formas. En serio, echa un vistazo a function xss_clean en Input.php y reír, ya que sustituye las cosas con % en la dirección URL decodifica, reemplaza las cosas con % de nuevo, rompe los vínculos codificados, destroza palabras con el signo entre ellos, escapa de algunos a menos que los signos a &lt;, y le impide hablar acerca de innerHTML o el uso de la palabra alert… y más…
    Básicamente, es la carga de culto de programación. Los autores no entiendo nada acerca de cómo HTML codificación y codificación URL trabajo, por lo que tirar todo lo que tienes en al azar en la esperanza de que algo se pegue. Sería hilarante si no fuera tan triste. Y no puede trabajar nunca. Incluso si lo hizo el trabajo para las cadenas en sus el propios, todos iban a ser un grande de manejo de cadenas en la secuencia de comandos después de decir, dividir y unir con otro supuestamente «seguro» de cadena a hacer peligroso de nuevo.
    Parece que hemos tenido este filtro de allí y de vez en cuando alguien viene con un exploit que se pone alrededor de él, momento en el que se tire más espurios de basura en el objetivo de que uno de explotar, sin abordar el problema real. El bloqueo de alert es sintomático, ya que es una función JS que normalmente se utilizan para mostrar que una vulnerabilidad de XSS existe; no los exploit de la vulnerabilidad de la que nunca iba a reventar un cuadro de alerta! Y las múltiples maneras, todos diferentes, que intenta analizar HTML buscando «malo» etiquetas… por dios.

    OriginalEl autor bobince

  2. 1

    1. si lo haces correctamente

    2. Usted probablemente ha notado que todas las llamadas a funciones son en manera que el usuario se pasan los datos en una variable de cada uno. De modo que ni siquiera tienen la posibilidad de pasar de SQL de control de código y de datos de usuario en una variable. Hablando en corto, se encapsulan los datos en una variable de cada uno. Por lo tanto puede ser codificados de forma segura, sin romper su código SQL.
    La excepción es, sin embargo, si usted pasa yóur toda la consulta. Entonces no es posible.
    Si usted

    $db->query("select * from table where password = 'hello ' or '1=1");

    no hay manera de decirle lo que debe ser escapado y lo que no, pero si usted cita es en como esta

    $db->query("select * from table where password = ?",array('param1'));

    la variable de usuario consigue encapsulado en una variable y se escapó.

    3. Sí lo hace, pero su primpary objetivo no es evitar la inyección sql,
    prefiero confiar en http://codeigniter.com/user_guide/libraries/input.html

    Creo que no hay comillas simples alrededor de la ? parámetro.
    hmm… no se puede decir realmente. creo que es correcta esa manera. por supuesto, usted no lo necesita cuando usted tiene los números enteros, pero no importa… así que probablemente es mejor escribir de él?
    Bien, no he probado esto con CodeIgniter en concreto, pero por lejos la forma más común de hacer parametrizar las consultas es el uso de un desnudo de ? como un reemplazo punto, y tratar '?' en una cadena como un verdadero signo de interrogación. Esta parece ser la sintaxis de codeigniter.com/user_guide/database/queries.html, de todos modos.
    estás totalmente en lo cierto en esta 🙂 +1

    OriginalEl autor The Surrican

  3. 1

    Whenver utilizar Generado por el Usuario, de Entrada, a continuación, pasar a través de la entrada de la biblioteca, donde se filtra para xss y de las inyecciones de sql.

    $this->input->post() 

    http://codeigniter.com/user_guide/libraries/input.html

    Hacer de verificación para obtener más información sobre el filtrado de seguridad.

    Dentro de la CI marco compruebe el archivo

    Codeigniter->System-libraries->input.php

    archivo donde usted puede encontrar internamente las funciones utilizadas por el CI para la desinfección de los datos.

    XSS limpio, básicamente, significa que el filtrado no deseados de XHTML/HTML Etiquetas

    De acuerdo a su propio vínculo $this->input->post() no hace nada para evitar la inyección de código SQL.

    OriginalEl autor Sandy

Dejar respuesta

Please enter your comment!
Please enter your name here