PHP OO Seguridad. PHP + Ajax

[carles9000]

Buenas tardes,

No se si es el foro adecuado y si no lo es lo cambio de sitio, disculpen.

Hay un tema que me preocupa mucho y no encuentro información al respecto.

1.- Tengo una aplicación que en la parte cliente uso jquery. La comunicación con el servidor siempre la hago via ajax, hasta aqui todo bien.

2.- En la parte de servidor tengo un php que recibe/envia peticiones/respuestas. Todo con sesiones e incluso valido que solo se pueda acceder via ajax.

A nivel seguridad de la aplicación, como puedo impedir o como se gestiona una posible manipulacion con el inspector del navegador de los datos a enviar al servidor ?

Yo soy capaz de validar la sesion, validar incluso datos, pero creo que se me escapa algo en el lado cliente. Estoy viendo mucha vulnerabilidad y cualquiera con un poco de nocion de programacion y uso del debugger/inspector rápido puede 'hackear' el programa.

Me podeis dar consejos, lecturas, enfoques o consejos para acabar de cerrar el tema de seguridad ?

Gracias por vuestra ayuda.

Carlos.

[marlanga]

Los datos que no quieres que te cambie el cliente los tendras en campos input:hidden. Para que no te los cambien, por cada uno de esos campos, crea uno gemelo que con el name"XXXX_hash" y mete ahí el hash resultante de concatenar al valor originial, alguna palabra secreta que solo el PHP del servidor conoce, y aplicándole alguna función de hash tipo MD5 o SHA256.
Cuando te lleguen los datos, vuelve al calcular el hash sobre el valor, y compáralo con su valor hasheado que también te llega en el formulario. Si son iguales, es que el valor en plano no te lo han cambiado.

Otra proteccion para evitar ataques CSRF es generar una cadena larga de tipo UUID aleatoria o similar y meterla en sesión cada vez que renderizes el formulario, y también en un campo hidden. Cuando te envien el formulario, comparas ese hidden con lo que tengas en sesion, y borras esa firma de la sesión. Si son iguales, es que el cliente ha rellenado el formulario siguiendo el flujo correcto.

Usa https si puedes.

[Triby]

Nunca confíes en el usuario.

1. Verifica la sesión y permisos del usuario
2. Si vas a modificar un registro, primero revisa que existe en la base de datos y cargas la información
3. Nunca actualices campos que no deban modificarse, independientemente de que aparezcan en formulario
4. Haz todas las validaciones que sean necesarias

[carles9000]

Marlanga y Triby, gracias por sugerencias pero no es la solucion al problema que veo, quizas no me he explicado bien.

- En el server si no estas autenticado no podras ejecutar ningun php.
- Tampoco se puede ejecutar un php si no es via ajax.
- La conexión es via SSL

El tema esta en el cliente y en las posible modificaciones que puedan hacer con un inspector y que alteren algun paràmetro. Quizas mi enfoque deberia a ser a que toda la lógica la debemos siempre verificar en el server.

Por ejemplo, imaginemos que en el cliente hay un pequeño javascript y una de las funciones es Eliminar_Registro()

Código Javascript:

function Eliminar_Registro( id ) {
 
       var sendInfo = {
           action: 'delete',
           id: id
       };
 
       $.ajax({
           type: "POST",
           url: "/mi_url",
           dataType: "json",
           success: function (msg) {
               ...
           },
           data: sendInfo
       });
}
 

Casuísticas que veo que se pueden hacer con un inspector:

1.- Imaginemos que el usuario (que evidentemente esta autenticado pero es un listillo y esta jugando con el inspector...) no tiene acceso a la funcion Eliminar_Registro(), pero por la consola la puede ejecutar y esto provocaria la peticion al server y ejecucion del proceso correspondiente.

2.- Imaginemos que crea un break cuando entra en la funcion y si esta en el registro con un id = 10 lo cambia por el 20 y continua. Resultado se hace la llamda al server y casca el 20

Me refiero a este tipo de manipulaciones, y pueden haber muchas mas (cambiar la accion, mas parametros,...... Como lo enfocais ?

Gracias de nuevo

Carlos.

[marlanga]

Para que no te cambien los valores, ya te he explicado cómo se soluciona por la vía rápida.
Otra solución, que también se está poniendo de moda en sistemas que hacen muchas operaciones asíncronas, es usar UUIDs como identificadores en todas las tablas, así es imposible que a mano crees una key que de la casualidad que exista.

Es muy mala idea que una ruta te ejecute acciones distintas. Una ruta, una operación. O te morirás manteniéndolo.

En cuanto a que el usuario ejecute operaciones que no puede, para eso están los sistemas ACL y roles de usuarios. Usa o implementa uno en tu sistema de usuarios.

[carles9000]

Marlanga,

Gracias por tus consejos e ideas. Vamos a intentar debatirla

>> El primer punto no lo veo claro y tener que ocultar el campo o duplicarlo encriptado.

En mi caso yo hago una peticion de un registro via ajax. Aplicando tu técnica, entiendo que cuando recupero el registro podria hacer que el id que me llegue del server, vendria tambien acompañado de un id_key encriptado. Posteriormente cuando yo hiciera una accion (eliminar, modificar, …) enviaria la peticion con el id y id_key. Una vez en el server compararia los 2 valores para ver si hay modificacion. Seria asi el proceso ? Uhmmm parece buena esta solución.


>> Una ruta una operación…

Si yo tengo p.e. un php tipo controler que dependiendo de la accion ejecuta una funcion, p.e

Código PHP:

switch ( accion )
    case ‘alta’:  Funcion_Alta()
    case ‘baja’:  Funcion_Baja()
    case ‘modifica’:  Funcion_Modifica()
 

Me estas aconsejando que en este caso tenga que montar 3 php y cada uno con su accion a ejecutar ? Y entonces desde ajax elegir la ruta del php correspondiente ? Esta práctica es correcta ?

>> Sistema ACL y roles…

Intento entender que cuando entra en el servidor comprobar el role/perfil del usuario y en el caso de q p.e. a la rutina de eliminar desde el navegador y la ejecute, cuando llegue al server valide si la accion esta permitida según su rol, es así. Esta idea tambien me gusta.

>> …usar UUIDs como identificadores en todas las tablas, así es imposible que a mano crees una key que de la casualidad que exista.

Esta me cuesta entenderla…  lo siento.


Vale, vale... creo q voy entendiendo las posibles soluciones. Algun consejo mas amigos ?


Saludos.

(Gracias Marlanga, seguimos... )

Carlos.