Pregunta:
Mi pregunta es: cuando escribo una función AJAX, puedo escribirla usando un archivo separado. Puedo incluir wp-load.php en ese archivo y usar las funciones principales de WP. Sé que esto está mal. ¿Puedes decirme qué tan mal está? ¿Es un gran riesgo para la seguridad? ¿Qué riesgos y desventajas de seguridad tengo?
Respuesta:
Es increíblemente malo y tiene un gran agujero de seguridad, tendrá que enfrentar estos problemas:
- Su punto final siempre funcionará, incluso si su complemento está desactivado o si cambia de tema
- Su punto final estará activo en todos los sitios en una instalación de varios sitios, no solo en aquellos para los que estaba destinado, lo que puede hacer que el punto final se use en lugares para los que no está previsto.
- El archivo será frágil, mover la carpeta de complementos o colocar el complemento en
mu-pluginshará que el punto final dé 500 errores fatales - Deberá implementar toda la autenticación y validación usted mismo
- Los complementos de almacenamiento en caché no podrán interactuar con su punto final, lo que ralentizará las cosas para las solicitudes comunes
- Dicho punto final puede aceptar cualquier cosa y podría devolver cualquier cosa.
Sería un eufemismo decir que los puntos finales independientes en temas y complementos son un riesgo de seguridad, ya sea un controlador AJAX o un controlador de formulario, o incluso un archivo independiente para imágenes (timthumb hizo esto e incluso los desarrolladores originales lo han rechazado debido a su reputación de seguridad)
Puede usar la API WP AJAX, que es mejor, pero requiere que usted mismo implemente cualquier verificación de autenticación o desinfección, y tiene algunas peculiaridades. Tampoco proporciona ninguna estructura, ya que con un punto final estándar puede recibir cualquier cosa y devolver cualquier cosa (si devuelve algo).
En su lugar, use la API REST con register_rest_route , es más fácil de usar, tiene menos peculiaridades y maneja la autenticación por usted. También le brinda URL y espacios de nombres más amigables, por ejemplo:
function tomjn_rest_test() {
return "moomins";
}
add_action( 'rest_api_init', function () {
register_rest_route( 'tomjn/v1', '/test/', array(
'methods' => 'GET',
'callback' => 'tomjn_rest_test'
) );
} );
Puedes ver esto en:
https://tomjn.com/wp-json/tomjn/v1/test
Con esto puedo hacer varias cosas:
- especificar que el usuario debe iniciar sesión y exactamente lo que necesita para poder hacer esto
- especificar los argumentos
- especificar el tipo y desinfectante para cada argumento por separado
- especificar si son obligatorios o no
- especificar si un punto final es para lectura y escritura o ambos
Todos los cuales son manejados por código escrito para core. Por supuesto, puede implementar todo esto usted mismo a mano en cada controlador WP AJAX, pero esto es mucho más conciso y probado (y hay pocos en la comunidad WP con la experiencia suficiente para hacerlo correctamente), por ejemplo, para que mi punto final anterior solo esté disponible para administradores:
register_rest_route( 'tomjn/v1', '/test/', array(
'methods' => 'GET',
'callback' => 'tomjn_rest_test',
'permission_callback' => function( $req ) {
return current_user_can('manage_options');
}
) );
Como beneficio adicional, hace que ciertas mejores prácticas sean mucho más fáciles de usar, como devolver datos, no HTML, usa HTTP GET PUT POST estándar, etc., y devuelve una respuesta JSON que se puede validar.
¿Qué tiene de malo que un endpoint esté siempre activo?
Anteriormente mencioné que un punto final nativo está activo, incluso si el complemento que está dentro está deshabilitado. La única forma de desactivarlo es mediante comprobaciones internas o eliminando el archivo. Sin embargo, ¿por qué es esto malo?
El quid de esto es que lo que podría ser apropiado en una circunstancia, puede no serlo en otra.
Por ejemplo, escenario 1:
Un administrador instala un complemento que permite a los usuarios iniciar sesión y registrarse en la interfaz sin actualizar la página. Para hacer esto, el complemento tiene un punto final para crear usuarios. Sin embargo, el administrador se da cuenta de que el registro no es lo que quería, solo inicia sesión y desactiva el complemento. Sin embargo, los archivos todavía están allí y los usuarios aún pueden cargar el punto final para crear nuevos usuarios.
Escenario 2:
Se está utilizando un complemento en una instalación de varios sitios para enviar correos electrónicos al administrador de un blog a través de un formulario de contacto. Todo esto funciona como se esperaba, pero hay otros blogs en el sitio que no están interesados en esta funcionalidad. Al cambiar el dominio utilizado para el blog, un atacante puede enviar correos electrónicos a los administradores de estos otros blogs cargando el punto final utilizado por el formulario de contacto en el contexto de los otros blogs en la red, enviando correos electrónicos a cualquier persona que tenga un rol de administrador. en cualquier lugar de la instalación multisitio
Escenario 3:
Un complemento tiene una función de depuración útil que permite a los usuarios cambiar sus correos electrónicos, pero por razones de seguridad ha desactivado esta función. Sin embargo, el punto final que maneja el formulario de cambio de correo electrónico es un archivo independiente, cualquiera que sepa cómo se construye el formulario aún puede cambiar su correo electrónico.