Duda con seguridad de envio de datos desde POST a PHP

Saludos amigos de CLab

Tengo una función que automáticamente toma todos los datos de un formulario via $_POST y los convierte a un vector asociativo para insertarlos directamente en la base de datos... Sin necesidad de hacer algo como:

Código :

$datos['nombre'] = $_POST['nombre'];
$datos['apellido'] = $_POST['apellido'];

O...

Código :

$sql = "INSERT INTO personas(nombre,apellido) values ('".$_POST['nombre'].....................

El problema se me presenta cuando pienso en la seguridad. ¿Es posible que alguien cree un formulario fuera de mi sistema para modificar otros datos de mi tabla, como el campo "date_created", o el nivel de acceso, por ejemplo...

¿Sólo con el uso de HTTP_REFERER podría bloquear esta posibilidad o algo más es o no es necesario?

He leído y visto que algunos frameworks usan una codificación o encriptación en los formularios pero esa vía me parece demasiado engorrosa a la vez que consumiría muchos recursos tal vez de forma innecesaria...

En fin. Espero sus sugerencias y gracias de antemano, como siempre.

Lo mejor es hacer un archivo de configuración con los campos validos por insert.

Config.php

Código :

$ValidFields["table"]["Field1"] = true;
$ValidFields["table"]["Field2"] = true;
$ValidFields["table"]["Field3"] = true;

Y listo, según la tabla, haces el build de tu sql, utilizando de post, solo los campos que esten dentro de $ValidFields["table"]

Saludos

Tomando la idea de Dano pero cambiándola un poco, yo en el lugar de asignarle true a los campos le asignaria el tipo de dato. Ejemplo

Código :

$ValidFields["table"]["Field1"] = string;
$ValidFields["table"]["Field2"] = array ( type="enum", "opcion1", "opcion2");  //type seria enum o set
$ValidFields["table"]["Field3"] = boolean;
$ValidFields["table"]["Field4"] = integer;
$ValidFields["table"]["Field5"] = float;
.
.
.

Y cuando vaya a crear el sql verifico la matriz $_POST lo ubico en ValidFields para validarlo con alguna funcion apropiada. Otra cosa es que le podrias asignar el nombre de una función para aplicar una validación muy especifica, en fin son ideas.

saludos

Me parece buena tu idea Maik, pero eso me gusta mas hacerlo dinámico, así no tengo que estar actualizando mi PHP.

Ver referencia de SHOW COLUMNS.


Saludos

Lo único que el SHOW COLUMNS no cargaría más el uso de la base de datos?

Bueno, yo lo de los campos los validaba con un prefijo de una letra que indicaba el tipo y mayusculas o minusculas si el campo era obligatorio u opcional, respectivamente...

ejemplo: Nnumero = numero entero obligatorio...

Lo cual era bueno porque con esa letrica validaba en JS y en PHP de una vez y mi generador de FORM tomando los datos de la tabla automaticamente me creaba el form con los names y su prefijo, dependiendo si el campo era null o no null y el tipo, etc...

pero viendo la vulnerabilidad de $_POST y de HTTP_REFFERER creo que me va a tocar romper esta técnica y aplicarla de la manera de maik o de dano.. preferiría la primera porque la segunda me parece que gasta más BD. Al menos que esos datos se generen solos en un archivo físico a partir de una función en PHP que lea las características de la BD y que el programador pueda ejecutarla de nuevo cada vez que hayan cambios en la BD... Lo cual seria buena idea, no?

Un abrazo.

Indeed

Ninguna idea es excluyente de la otra, de hecho se complementan muy bien. Y sí asi seria el uso que le darias a SHOW COLUM de ejecutarlo al crear la tabla y en cada cambio sobre ella.

Maik: Claro... Bueno, ahora estoy con 2 proyectos encima pero apenas termine voy a tratar de hacer el generador de archivos de validaciones o algo por el estilo, y los pongo en la dedicatoria

juuuul llego tarde a este post... pero veo ideas muy interesantes...

Duilio esperaremos tu dedicatoria...

Aclarando:

Primero:

Código :

esto:
$datos['nombre'] = $_POST['nombre'];
$datos['apellido'] = $_POST['apellido'];

lo puedes hacer asi:
$datos = $_POST;

Segundo:

Tu aplicacion de verdad necesita hacer un numero tan increible de distintos querys como para querer automatizar completamente la fabricacion de los querys?. Lo haces para no tener que escribirlos? Si es asi dejame decirte que pasaras mas tiempo pensando en como NO te dañen tu base de datos (y por ende escribiendo codigo) que lo que tardarias en escribir cada query independientemente (Aun asi te pueden joder la DB) (checate la historia de la funcion stripslashes.

tercero:

Es completamente posible alterar el formulario para agregar nuevas casillas y enviar nuevos datos y valores. La extencion webdeveloper o firebug de firefox te permite hacerlo. El HTTP_REFERER no te protegeria de mucho porque esa es una variable que manda el cliente. NUNCA DEJES LA SEGURIDAD EN MANOS DEL CLIENTE . Ademas no pienses que el metodo POST te da mas seguridad que el metodo GET. Alguien concientemente intencionado en atacarte no encontrara ninguna diferencia.

cuarto:

encriptacion de los formularios? Nunca he visto eso y de cualquier forma tendria que ser leible por el lado cliente asi que puede ser modificado. Ademas un framework decente aunque puede que si fabrique querys mas dinamicamente tambien lo hace mas inteligentemente. Yo uso un framework desarrollado entre varios colegas que esta enfocado a la estructura de las bases de datos y aun asi siempre procuro hacer que entren solo los datos que deben. Te pongo un estracto de como usaria mi framework para por ejemplo agregar una noticia.

Código :

class Union_Noticia extends io_Object {
   public $catName;
   public $cat = array();
   function setUp(){
      $this->table = 'noticias';
      $this->loadFromTableDB($this->table,'not_');
   function agregarNoticia(){
      $this->id = $_POST['id']:
      $this->content = $_POST['content']:
   }
}

ahora, tambien tengo la forma the hacer $this->loadfromPOST(); pero eso solo lo uso cuando el formulario lo genera un motor.

quinto:

Si, es inteligente tu aporte pero de que sirve que especifiques el tipo de datos que contendra tu DB si aun asi el atacante no quedra meter otro tipo de datos, o si?. Me explico, si tienes un campo ADMIN con un valor boolean. Obviamente ahi solo puede haber o 1 o 0. Si vas a impedir que segun el tipo de dato se ejecute el query pues lo que harias es un "verificador de que tu atacante ha hehco las cosas bien para asi ejecutar el query). En otras palabras solo cuando el ataque sea efectivo tu dejarias que tuviera exito. Tienes que hacer lo contrario. Cuando el ataque sea efectivo impedir que tenga exito.

sexto:

Show columns te da todas las columnas de la db inclusive las que no deberian de editarse.

enfin:
simplificando todo yo me inclino por la idea de dano. Sin embargo nunca recuerdo haber hecho eso. En un proyecto viejo (www.asterisk2billing.org) recuerdo que creamos un archivo con todos los querrys que usabamos con define() y simplemente pasabamos el querry como array. Era practico.

En fin, son consideraciones.