Esteban: Hay un ataque bastante comun que consiste en incluir codigo SQL en campos de entrada, para realizar daño en la aplicacion.
En el caso que cuenta el chiste, se supone que tiene un formulario de ingreso de datos, donde pide el nombre del estudiante.
Lo habitual, es ingresar "Enrique" y con eso funciona todo bien.. La aplicacion concatena el dato ingresado con una sentencia SQL y la ejecuta en la base de datos.
Ahora, si en vez de "Enrique", se ingresa "Enrique';DROP TABLE student;--", lo que puede pasar, si la aplicacion no esta bien diseñada, es que se agrege el valor "Enrique" y luego se ejecute la sentencia que borra la tabla students y pone como comentario el resto de la linea..
Con este sencillo comando, se puede lograr borrar todos los datos de dicha tabla. Por eso hay que tener mucho cuidado y no permitir en nuestras aplicacion el ataque de "SQL Injection". Podes ver mas informacion en http://es.wikipedia.org/wiki/Inyección_SQL
En las últimas incorporaciones a KBDoctor estuve cambiando en tres áreas: modernización de Web Panels, análisis de modularización y mantenimiento de la Knowledge Base. Estas son las nuevas opciones disponibles. UI y frontend Web forms using Abstract Editor. Permite seleccionar varios Web Panels y convertir los formularios que aún usan el editor HTML al editor abstracto. Ajusta MasterPage y Style a Default, admite reemplazos de clases definidos en un archivo y muestra un reporte con los objetos modificados y los errores. Omite los objetos generados por patterns. Improve control classes. Aplica reglas de clases CSS a controles y columnas de grillas. Puede reemplazar una clase, volver a la clase por defecto o asignar clases según el tipo de control y características como la cantidad o longitud de las columnas. Las reglas se leen de un archivo y los cambios quedan registrados en un reporte. Audit Web Panels for Smooth UX. Analiza los Web Panels seleccionados y clasifica cuáles par...
Un error muy molesto que ocurre (por suerte no muy a menudo), es que no se generan correctamente los SDT. No se bien cuales son los motivos, pero los procesos sospechosos son: * Renombrar un SDT * Renombrar un objeto que es Business Component. * Alterar la estructura de un SDT y algunos otros La solución mas intuitiva es generar los fuentes de dichos SDT, pero estos objetos no son especificables y no se pueden generar directamente. La otra es hacer ver las referencias de los objetos que hacen referencia y regenerarlos. CREO que debería hacerse un Rebuild del objeto, porque si no es forzado, no se vuelve a generar el SDT. Esto hace que no sea trivial encontrar un objeto que pueda regenerarse que use dicho SDT. En modelos chicos es posible hacer un Rebuild de todo el modelo, pero en modelos grandes es muy poco practico. Estuve evaluando hacer una extensión para poder solucionar el problema, de forma de forzar la generación del codigo...
La idea de este post es comentar algunos de los problemas que he encontrado migrando desde Genexus 9.0 a GeneXus X. Tiene también algunos tips que pueden hacer mas fácil la vida (al menos la mia). Los pasos que hice fueron: 1) Copiar el directorio de la KB para guardar en caso que pase algo. Borrar de la KB el directorio de los modelos (los DATA00x). Esto es para asegurarme que no me queda ningun fuente viejo, ni ninguna dll, jar, etc de la versión anterior. 2) Entrar con GeneXus 9.0 a la KB y borrar todos los modelos que no se utilicen. Esto se hace con File/Delete Model estando en diseño. Conviene borrar el modelo de Backup (si existe) pues acelera la conversión. 3) Renombrar el domino Boolean si existiera y ponerle Boolean90. En GeneXus X Boolean es un tipo de datos nativos y si existe un domino Boolean (como el que usa el Pattern WorkWith, se arma lio). 4) Borrar todos los objetos que no se utilicen y los que sean WIN. Este paso no es indispensable, pero es muy saludable. Puede a...
no entiendo!!!
ResponderBorrarSaludos
Esteban:
ResponderBorrarHay un ataque bastante comun que consiste en incluir codigo SQL en campos de entrada, para realizar daño en la aplicacion.
En el caso que cuenta el chiste, se supone que tiene un formulario de ingreso de datos, donde pide el nombre del estudiante.
Lo habitual, es ingresar "Enrique" y con eso funciona todo bien.. La aplicacion concatena el dato ingresado con una sentencia SQL y la ejecuta en la base de datos.
Ahora, si en vez de "Enrique", se ingresa "Enrique';DROP TABLE student;--", lo que puede pasar, si la aplicacion no esta bien diseñada, es que se agrege el valor "Enrique" y luego se ejecute la sentencia que borra la tabla students y pone como comentario el resto de la linea..
Con este sencillo comando, se puede lograr borrar todos los datos de dicha tabla. Por eso hay que tener mucho cuidado y no permitir en nuestras aplicacion el ataque de "SQL Injection". Podes ver mas informacion en http://es.wikipedia.org/wiki/Inyección_SQL
Gracias por el comentario..