 Autor
|
Tema: prevenir injeccion sql usando hash y cifrado/compresión[php] (Leído 4,291 veces)
|
|
flacc
|
Hola, no se mucho de injección sql, pero por lo que he visto es que colocan comandos de sql en los campos input en los formularios y en la barra de direcciones para envió de información.
Lo que haría básicamente sería usar una tabla sql para autentificar usuarios, pero la información en la tabla estaría pasada por sha-1, eso para campos irreversibles como las contraseñas, para campos que necesitas revertir como el nombre de usuario, correo y demás usaría aes, ahora, se bien que el cambio y el peso de la información sería mas en relación a tener los datos en texto plano.
Quiero tener otras opiniones al respecto, no se si será el método mas óptimo tomando en cuenta el coste sobre todo teniendo en cuenta que si tienes 1000 registros deberías decencriptar o descomprimir los 1000 registros, pero según lo que he visto, me parece una alternativa fácil para mi de protegerme de injección de sql, obviando que la otra vía sería aprender mas y aplicar las técnicas necesarias.
¿Que opinan ustedes?
Saludos y gracias
|
|
|
|
|
En línea
|
|
|
|
|
Ari Slash
|
En un formulario POST no deberias codificar nada, si te refieres al envio del formulario, usaria HTTPS (certificado) que evite la lectura de esos datos a traves de la red, eso se aplica en el Servidor Web, no a traves de sql ni programacion.
Utilizando variables GET, no creo que seria correcto pasar un email o contraseña a traves de esto, aunque este bajo codificacion de un solo sentido.
Para evitar SQLI, utilizaria GET lo menos posible que se pueda y con variables de tipo numerico ojala, y una vez recibidas volver a convertirlas. Me ayudaria con variables de tipo SESSION, que despues liberaria. Tambien convertir todo tipo de datos del formulario en su tipo correspondiente.
En php, utilizar funciones como SPRINTF(). En .NET string.format() y convert. Filtrar las comillas simples y dobles, o agregar un Backslash (replace). En .net Web.config contiene unas instrucciones de seguridad.
Y por supuesto para autentificar un usuario, primero que nada una buena arquitectura de software, me refiero a una clase y el objeto instanciado en una variable de session. Y mas bien, con una buena arquitectura y diseño de software estas asegurando tu sistema.
Saludos
|
|
|
|
|
En línea
|
|
|
|
|
flacc
|
muchas gracias, me queda un poco mas claro, saludos
|
|
|
|
|
En línea
|
|
|
|
|
MinusFour
|
Trata de usar Sentencias Preparadas (parametrizadas) y evita concatenar variables enviadas por el usuario en tus enunciados SQL. Por ejemplo: $sql = "SELECT * FROM tabla WHERE numero =" . $numero;
Puede facilmente terminar así: SELECT * FROM tabla WHERE numero = 1; DROP TABLE tabla;
Si haces sentencias preparadas lo que obtienes es un error porque el valor que estas pasando es " 1; DROP TABLE tabla;", no lo está concatenando al string, sino que está atando el parametro a ese valor en especifico. Basicamente tu SQL se vería así usando sentencias preparadas: SELECT * FROM tabla WHERE numero = "1; DROP TABLE tabla;"
http://php.net/manual/es/mysqli.quickstart.prepared-statements.php |
|
|
|
|
En línea
|
|
|
|
|
engel lex
|
el peso con aes es el mismo procesado que crudo, el peso está en tiempo de computo... en lugar de cifrar todo es preferible algo como $nombre_md5 = $_POST["nombre"];
$pass_md5 = $_POST["pass"];
select * from tabla where nombre_md5=$nombre_md5 and pass=$pass_md5 (este código es solo una simulación de mi idea) en el codigo (asumiendo md5) tienes un segundo campo para los nombres (nombre_md5) donde esté codificado... por qué así? porque si entra una inyección el hash la destruirá y será seguro pasarla ahí no entrará ninguna inyecciom |
|
|
|
|
En línea
|
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
|
|
|
dantemc
 Desconectado
Mensajes: 2.003
:D
|
PAra prevenir una SQLi lo mejor es usar procedimientos almacenados te recomiendo este link https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_SheetSi usas POST o GET es indiferente al igual que si usas https o http pues los datos se visualizan en la capa 7. Otra cosa es validar las entradas, es decir cuando recibas los datos por parte del usuario validar que contenga los datos que permites, esto es usar una lista blanca. Por ejemplo si es un campo tipo nombre, solamente permitirás letras de la A a la Z, nada de símbolso como comillas que es lo que se usa generalmente para visualizar un fallo en la aplicación. si es correo igual + @. así vas validando las entradas y mediante procedimientos almacenados logras una seguridad muy decente para evitar estos ataques. |
|
|
|
|
En línea
|
8-D
|
|
|
|
flacc
|
gracias a todos por las respuestas. Al final no opte por encritar ni comprimir nada, veré lo de las senencia preparadas y luegos procedimientos.
|
|
|
|
|
En línea
|
|
|
|
|
| Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
|
Investigación de Compresión, Usando un Precompresor
Foro Libre
|
xxIv4nxx
|
0
|
1,779
|
18 Junio 2010, 04:22 am
por xxIv4nxx
|
|
|
|
Tipo de cifrado de este hash?
Criptografía
|
chete
|
2
|
3,445
|
17 Mayo 2014, 17:45 pm
por engel lex
|
|
|
|
Cifrado hash SHA1 en C
Programación C/C++
|
mester
|
2
|
2,519
|
29 Mayo 2016, 17:50 pm
por AlbertoBSD
|
|
|
|
Mensaje borrado
Hacking
|
heroes11
|
2
|
2,843
|
6 Diciembre 2016, 21:05 pm
por heroes11
|
|
|
|
Recomendación cifrado/hash.
Seguridad
|
Xyzed
|
8
|
7,428
|
1 Mayo 2021, 06:22 am
por @XSStringManolo
|
 |
