Cómo ajustar la longitud máxima de la entrada de una declaración SQL en Oracle
El número máximo de listas en la cláusula IN es 1000. Si se excede este número, se informará un error. Esto se puede solucionar con una tabla temporal. La longitud de caracteres del texto de la declaración CREATE TRIGGER no puede exceder los 32 KB (los tipos LONG y LONG RAW no se pueden usar en los activadores. Se puede hacer referencia a los valores de las columnas de tipo LOB en los activadores, pero los datos en las columnas LOB no se pueden modificar a través de: NUEVO; ) Por cierto, ahora la palabra clave PARENT en el activador solo es válida en activadores de tablas anidadas. Antes de 11G, la longitud de la entrada SQL a DBMS_SQL no podía exceder los 32 K porque los parámetros de entrada solo podían ser del tipo VARCHAR2. Después de 11G, CLOB se puede utilizar como parámetro de entrada. Luego elimine las restricciones sobre el tamaño de los paquetes, procedimientos, funciones y activadores de PL/SQL. El tamaño máximo en UNIX es 64K, mientras que en WINDOWS es 32K (no se deben permitir 32K, consulte la prueba a continuación). ¿Cuánto tiempo puede durar una declaración SQL? (Los internautas dijeron) Los documentos de Oracle dicen que es 64K. De hecho, es menor que este valor debido a algunas herramientas, pero puede ser muy largo, incluso más de 1M (he probado 170K sin ningún problema). La longitud específica, 10G, no se especifica, pero depende de muchos entornos: configuración de la base de datos, espacio en disco, memoria. . .
En PL/SQL, la longitud de la expresión/SQL en sí puede alcanzar una longitud relativamente larga (50 K), como por ejemplo: v _ str: =: new.f1 ||: ndw.f2. . ;seleccione :nuevo.f1||:nuevo.f2 .. . Al convertir de dual a v_str también se encontró que si escribe así: v_str: =' a' ||' b' |||. . . La longitud de expresión permitida se reducirá significativamente. Si la expresión/sql es demasiado larga y excede la longitud máxima del programa permitida por el paquete/procedimiento ORACLE, pls-123: se produce un error de programa demasiado grande durante la compilación. Esto se debe a las limitaciones del propio compilador pl/sql. es decir, la expresión/SQL La longitud está limitada por el tamaño máximo del paquete/procedimiento en PL/SQL = = = = = = = = =
Cuando estaba escribiendo declaraciones Sql recientemente, encontré dos problemas:
1 ) ORA-01795: el número máximo de expresiones en una lista es 1000 Causa: Escribí la siguiente declaración SQL: seleccione pallet_id, box_id, estado de SD_current_box donde pallet_id in("+pallets+" ). Entre ellos, pallets es una cadena compuesta por muchos pallet_ids.
Análisis: Obviamente, según el mensaje de error, podemos saber que el límite de entrada en in es 1000.
Solución: Reemplazar la larga cadena de bandejas con una subconsulta.
2)ORA-01704: cadena literal demasiado larga
Causa: Escribí la siguiente declaración Sql: Actualizar PDM _ Lista de miembros Establecer miembros = '
Análisis : Los campos de los miembros de diseño de la base de datos están en formato xmltype y los datos se almacenan en forma de cadena. De esta forma, cuando la cantidad de datos XML es grande, la declaración SQL es demasiado larga y ha alcanzado el límite de 2k.
Solución: Sentencia SQL parametrizada.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - Sentencia SQL de parametrización - Prevención de SQL Ataques de inyección (Parte 2)
Los principios básicos de la inyección SQL escritos en el artículo anterior fueron pensados originalmente para este artículo, pero por razones de tiempo, no se han escrito. Hoy es el feriado del Primero de Mayo, así que finalmente puedo encontrar tiempo para escribir.
Como programador, la primera línea de defensa contra la inyección SQL es lo que protegemos. Siempre que dejemos algunas lagunas en el programa, se mejorarán las funciones de seguridad del programa.
Entonces, lo que tenemos que hacer es escribir un programa seguro para evitar la inyección de SQL en el programa. No concatene cadenas SQL, sino parametrice SQL o escriba procedimientos almacenados. Hablemos primero de SQL parametrizado simple.
El ejemplo está implementado en C# y Oracle, y la implementación en Java u otras bases de datos es similar.
Usa el sistema. Datos. OracleClient//Presentación del paquete de operaciones de Oracle//Definir declaraciones DML.
string strSQL = @ " select user . name from user where user . name =:userName ";// En la oración anterior, userName es el marcador de posición para los parámetros en la declaración SQL, es decir, cuando Cuando esta declaración SQL se ejecuta en el servidor de la base de datos, este marcador de posición será reemplazado por otra cosa. ¿Con qué debería ser reemplazado? Luego mire OracleParameter[] param = {
new OracleParameter(":userName ", txt name);}// Definimos una matriz de parámetros en la que se pueden escribir múltiples parámetros SQL. Aquí solo tenemos un parámetro, por lo que escribimos un parámetro. Aquí, el marcador de posición corresponde a su reemplazo, que es el valor del parámetro. txtName es el valor de reemplazo del marcador de posición, que es el valor ingresado por el usuario en la interfaz de usuario, es decir, puede contener caracteres para ataques de inyección, por lo que el servidor de la base de datos sabe con qué reemplazar el marcador de posición.
Después de definir la instrucción SQL y los parámetros, se ejecuta. Durante la ejecución, la declaración SQL y los parámetros deben pasarse al mismo tiempo, de modo que la cadena con caracteres ilegales ingresada por el usuario se trate como un parámetro en la base de datos y no se confunda con la declaración SQL y la base de datos. mismo, evitando así ataques de inyección.
oraclecommandmd = nuevo comando de Oracle();
cmd. CommandText = strSQL // Definir el contenido de texto del comando de Oracle para (oracleParameter p in param) // Pasar los parámetros a {
cmd. Parámetros. Añadir(p);
}
cmd. ExecuteNonQuery(); //Ejecutar comando
Lo anterior es básicamente un sql parametrizado completo. Los marcadores de posición para los parámetros en sentencias SQL de diferentes servidores de bases de datos son diferentes. Oracle se usa arriba y el marcador de posición del parámetro es dos puntos (:) más el nombre. En SQLServer, el símbolo @ más un nombre se usa como marcador de posición, mientras que en MySQL, el signo de interrogación (?) agrega un nombre como marcador de posición de parámetro. Los símbolos de los parámetros en diferentes bases de datos son diferentes, por lo que debe prestar atención.
Prevención de ataques de inyección SQL (Parte 1)
La inyección SQL es un método de ataque de muy baja entrada y extremadamente destructivo. Si el sql está empalmado con cadenas, definitivamente será atacado por inyección SQL. Hace algún tiempo, hubo noticias de que un gran sitio de redes sociales extranjero había sido atacado mediante inyección SQL.
Los camaradas que vienen aquí deben tener muy claro el método de ataque de inyección SQL. Al empalmar cadenas, si ingresa comillas simples, ingrese LAF 'o 1 =' 1 '-- De esta manera, condición. Se pueden evitar las comprobaciones. Si se producen algunas condiciones como el cierre o la eliminación, la pérdida será básicamente devastadora. Durante el proceso de desarrollo de la unidad hace unos días, descubrí que casi nadie prestaba atención a la seguridad. Una persona que escribe código no presta atención a la seguridad sino sólo a la implementación. El código escrito entonces es básicamente una belleza desnuda frente al atacante.
La siguiente es mi experiencia como desarrollador, utilizada principalmente para prevenir la inyección de SQL.
1. Primero, otorgue al usuario que ejecuta SQL los permisos más bajos. Esta teoría es también la teoría del privilegio mínimo en el campo de la seguridad. Para ejecutar un programa, debe ejecutarse con privilegios mínimos, así que no le dé al usuario privilegios de DBA. Después de restringir los privilegios principales, puede evitar algunos ataques devastadores e incluso si ingresa, no cerrará ni modificará la tabla.
2. Nunca utilices la concatenación de cadenas para construir sql. Tienes que usar sql parametrizado. Los procedimientos almacenados se pueden ver como SQL parametrizado.
Construya SQL parametrizado de manera simple y directa, y escriba procedimientos almacenados para procedimientos complejos. Sin embargo, las cadenas no se pueden utilizar en procedimientos almacenados. Creo que algunas personas todavía no pueden evitar ser atacadas cuando usan cadenas en procedimientos almacenados, y es muy problemático depurarlo.
3. Controle estrictamente la entrada. Debe utilizar el sistema para la interacción. Todas las entradas del usuario deben controlarse adecuadamente. Puede utilizar varios métodos para verificar la entrada del usuario y poder configurar los caracteres confidenciales. hacer que la entrada sea legal. El usuario no puede ingresar. Aunque esto no es muy amigable, garantiza la seguridad. El contenido a verificar se puede verificar mediante expresiones o programas regulares. No importa qué método se utilice, mientras se mantenga alejada a las personas sensibles y sospechosas, no se las puede atacar. Sin embargo, la entrada restringida todavía tiene desventajas. Desde la perspectiva de la teoría de la seguridad, sólo se puede determinar que es legal pero no ilegal. Por ejemplo, si restringes la interfaz legalmente, el resto será ilegal. En este momento, todas las entradas deben ser legales. Si lo que restringes es ilegal, ¿puedes garantizar que lo que restringes sea ilegal? Si un día descubres que uno ilegal ya no está dentro de tu alcance, serás atacado.
4. Realice su propio trabajo de inspección y prueba, puede realizar ataques de inyección SQL y utilizar herramientas de prueba.
5. Asegúrese de cultivar un programador consciente de la seguridad y piense siempre en la seguridad.
Los más importantes de estos elementos son el 1 y el 2. Asegúrese de prestar atención a las restricciones de permisos; de lo contrario, morirá miserablemente. El segundo es el hábito de los programadores, que deben utilizar SQL parametrizado para interactuar con la base de datos.