Riesgo de seguridad derivado de los datos pasados en $ _GET superglobal

Parece que mi comentario no se publicó aquí, así que lo publicaré como respuesta:

No, no es un problema de seguridad grave. Si su sitio tiene, por ejemplo, una vulnerabilidad de inyección de SQL ciego, esto facilitaría atacar a un usuario específico. Probablemente también sea mucho más fácil raspar su sitio web para los perfiles de usuario, si eso es una preocupación suya. Pero aparte de eso, no puedo pensar en una forma de atacar esto.

Pero si todavía estás preocupado: No, las variables de publicación ocultas no son la respuesta. En su lugar, no pase los identificadores, sino que pase slugs de nombres de usuario / postnames / etc en su lugar (los slugs deben ser desinfectados, de modo que solo contengan caracteres de URL válidos). Esto también es más fácil de usar y seo.

Pero asegúrese de no enviar ningún dato proporcionado por el usuario directamente al usuario final. Primero tienes que desinfectarlo para evitar los ataques xss (y cuenta como lo suministró el usuario, incluso cuando proviene de la base de datos (si los datos de la base de datos son proporcionados por el usuario).

El uso de POST en lugar de los parámetros de URL no tiene ningún beneficio para la seguridad. Los datos POST se pueden cambiar al igual que los parámetros de URL. De hecho, no debe confiar en ningún datos provenientes del usuario, ya sea un parámetro de URL, un parámetro POST, una cookie, un encabezado HTTP o lo que sea. Casi todas las entradas están bajo el control del usuario y pueden ser lo que quieran.

La clave es tratar cada valor que no esté codificado como una amenaza potencial y asegurarse de que no cause ningún daño. Las declaraciones preparadas son una buena opción para las consultas dinámicas, ya que aseguran que los valores se traten como datos en lugar de declaraciones SQL. Para insertar valores en su documento HTML, necesita escapar de HTML; los comandos de shell requieren que los valores se escapen de la shell y así sucesivamente.

Hay dos aspectos de la pregunta aquí:

1. ¿Es seguro usar el ID de la URL (GET)? Respuesta corta, no. Como cualquier otro dato, debe ser validado y filtrado antes de su uso. Esto evita que surjan problemas como la inyección SQL y que la aplicación quede vulnerable. Valide que sea una ID, valide que sea una ID válida y use declaraciones preparadas para reducir aún más el riesgo.

2. Ya que son ID (enteros), ¿es seguro usar algo que el usuario pueda cambiar? Aquí es donde las cosas se ponen un poco más complejas. Esta parte del problema es menos acerca de los datos que le proporcionan (que es el número 1) y más sobre el acceso y la autenticación. Por ejemplo, en la mayoría de las aplicaciones una "vista" en un usuario está bien para que cualquiera la vea. Sin embargo, una "edición" solo se puede permitir al usuario y al administrador. Aquí es donde necesita la capa de protección que verifica quién es el usuario y qué permisos tiene para esa página / recurso. Esto está relacionado con el ítem "Referencias Inseguras de Objetos Directos" de OWASP en su Top 10. Es un problema bastante común, pero la respuesta correcta es la protección de autenticación *, no la ofuscación a través de campos de formulario POST o ocultos.