elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: (TUTORIAL) Aprende a emular Sentinel Dongle By Yapis


+  Foro de elhacker.net
|-+  Programación
| |-+  Desarrollo Web
| | |-+  PHP (Moderador: #!drvy)
| | | |-+  ctype y la seguridad
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: ctype y la seguridad  (Leído 2,438 veces)
Gogeto

Desconectado Desconectado

Mensajes: 48


Ver Perfil
ctype y la seguridad
« en: 27 Julio 2011, 08:03 am »

Hola.

Estoy haciendo un diseño web en el cual hay de por medio un diseño de búsquedas.
A buscar.php se le pasarán por GET una serie de parámetros y éste se encargará de devolver el array que contiene la respuesta de la DB a la consulta.

Las queries se van a crear dentro de buscar.php, así que tengo que parsear las variables que llegan por GET.

Primero pensé en expresiones regulares o preg_replaces a secas para sustituir, pero luego me dije:
¿Por que tengo que gastar recursos del servidor en reescribir los intentos de un hijo de p*t* de buscar fallos en mi web? Y encontre ctype.
ctype_alnum($string) devuelve 1 si la string es alfanumérica.

Invocando ctype_alnum de esta forma:
Código:
ctype_alnum(str_replace(array('-','+'), '', $_GET['genres']))

Si no es positivo, no se asigna el $_GET a la variable y ese parametro de búsqueda queda no definido, o directamente se corta la ejecución del script.

Si se parsean así las variables ANTES DE HACER NADA MAS CON ELLAS, es seguro? o existe alguna forma de que alguien cuele SQL injection/ LFI /RFI/ cross-site scripting??


En línea

WHK
Moderador Global
***
Desconectado Desconectado

Mensajes: 6.589


Sin conocimiento no hay espíritu


Ver Perfil WWW
Re: ctype y la seguridad
« Respuesta #1 en: 27 Julio 2011, 08:14 am »

Para eso existe mysql_real_escape_string($_GET['x']) o (int)$_GET['x'].

http://foro.elhacker.net/nivel_web/como_evitar_la_inyeccion_sql-t252384.0.html


« Última modificación: 27 Julio 2011, 08:19 am por WHK » En línea

Gogeto

Desconectado Desconectado

Mensajes: 48


Ver Perfil
Re: ctype y la seguridad
« Respuesta #2 en: 28 Julio 2011, 01:43 am »

Eso lo aplico una vez se hacen las consultas a la database; en el momento en que ctype se ejecuta no hay conexión activa con la DB (intento reducir al mínimo el tiempo de cada conexión viva)

El problema es que también hay algún include de por medio, y algún echo con las variables que hace que al ser imprimidas en la pantalla del user pueda resultar en riesgo de seguridad no solo para el servidor sino para el usuario final.

Ademas, algunas variables que son esencialmente enteros, vienen por GET separados por comas, es decir, para buscar contenidos del año 2005 al 2009 $_GET['year'] seria un string de la forma: 2005,2009, que posteriormente un explode romperá en un array para su analisis y con el objetivo de mejorar la escalabilidad
« Última modificación: 28 Julio 2011, 01:46 am por Gogeto » En línea

Gogeto

Desconectado Desconectado

Mensajes: 48


Ver Perfil
Re: ctype y la seguridad
« Respuesta #3 en: 28 Julio 2011, 01:56 am »

Casi lo olvido, mysql_real_scape_string sera aplicado justo antes de usar las variables, pero algunas de ellas son susceptibles de ser usadas en includes o llamadas por ciertas funciones, lo que puede causar ciertos problemas de seguridad.

Lo que quiero saber es si ctype_alnum sera segura aunque al usuario se le ocurra meter el codigo en hexadecimal, decimal, binario o como se le ocurra.

Supongo que unos y ceros si que se saltarían la proteccion ctype_alnum, no?
En línea

WHK
Moderador Global
***
Desconectado Desconectado

Mensajes: 6.589


Sin conocimiento no hay espíritu


Ver Perfil WWW
Re: ctype y la seguridad
« Respuesta #4 en: 28 Julio 2011, 06:00 am »

con esa función no te va a ayudar "2005,2009" por la coma ya que no es alfanumérica.

En ese caso te recomiendo utilizar (int) con format() pero si quieres string puedes usar entonces str_replace() ya que sería como lo mismo que ctype internamente... claro, compilado es mas rápido pero no es recomendable por asuntos de seguridad.

Desde php.net recomiendan mysql_real_escape_string() porque verifica muchisimas cosas, no solamente carácteres y ha sido preparada desde hace mucho y todos lo usamos.

Yo en particular uso:
Código
  1. function toSql($buff = false){
  2. if(!$buff) $buff = $this->data;
  3. return str_replace(array('\\', "\0", "\n", "\r", "'", '"', "\x1a"), array('\\\\', '\\0', '\\n', '\\r', "\\'", '\\"', '\\Z'), $buff);
  4. /* Dont use connection */
  5. }

Porque hay algunos casos en que no tengo una conexión activa antes de procesarlo a la query ya que mis conexiones son automáticas dentro de una clase. Pero aun así la función nativa verifica muchas mas cosas.

Citar
Escapa caracteres especiales en la cadena no escapada, teniendo en cuenta el conjunto de caracteres actual de la conexión para que sea seguro usarla en mysql_query(). Si se van a insertar datos binarios, esta función debe ser usada.

mysql_real_escape_string() llama la función de la libreria de MySQL mysql_real_escape_string, la cual antepone backslashes a los siguientes caracteres: \x00, \n, \r, \, ', " y \x1a.

Esta función siempre debe (con pocas excepciones) ser usada para hacer los datos seguros, antes de enviar una consulta a MySQL.

Citar
Note:

Si esta función no es usada para escapar los datos, la consulta es vulnerable a Ataques SQL Injection.

http://www.php.net/manual/es/security.database.sql-injection.php
http://php.net/mysql_real_escape_string
En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
Lista de fallos de seguridad y soluciones (Proyecto Ontología de Seguridad)
Hacking
murdock_ 0 3,763 Último mensaje 27 Noviembre 2009, 10:33 am
por murdock_
¿Es correcto este uso de Ctype .Net?
.NET (C#, VB.NET, ASP)
adan-2994 4 2,916 Último mensaje 8 Enero 2013, 19:56 pm
por seba123neo
Pregunta libreria <ctype.h>
Programación C/C++
Ja_90 2 3,894 Último mensaje 11 Octubre 2014, 21:27 pm
por Ja_90
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines