Recientemente, con bastante frecuencia comenzaron a hacerme una pregunta sobre qué tan seguro es usar varias extensiones listas para usar, es decir, paquetes escritos para el lenguaje R, ¿existe la posibilidad de que la cuenta publicitaria caiga en las manos equivocadas?
En este artículo, hablaré en detalle sobre cómo funciona el mecanismo de autorización dentro de la mayoría de los paquetes y las API de servicios de publicidad, y cómo usar los paquetes descritos en el artículo de la manera más segura posible.
La información en este artículo no es técnicamente la más fácil, por lo tanto, para que el texto no sea tan seco y técnico como la ayuda habitual, me atrevo a probar el papel de guía y lo guiaré a través de los materiales de este artículo para su percepción más simple.
Nuestro autobús turístico ya ha llegado, tome asiento y consulte nuestro itinerario actual.
Contenido
- Cómo funciona el proceso de autorización en la mayoría de los servicios de publicidad modernos
- ¿De dónde vino la pregunta de seguridad?
- Lo que te amenaza con una intercepción simbólica
- Qué hacer si alguien ha tomado posesión de tu token
Cómo usar los paquetes R de manera más segura para trabajar con los sistemas de publicidad API
5.1. ryandexdirect y rym: paquetes para trabajar con las API Yandex.Direct y Yandex.Metrica
5.2. rfacebookstat- Paquetes para trabajar con la cuenta de publicidad de Facebook
5.3. rvkstat: paquetes para trabajar con la cuenta VK
5.4. rmytarget - Paquetes de paneles de MyTarget
- Conclusión
Cómo funciona el proceso de autorización en la mayoría de los servicios de publicidad modernos
El lugar de encuentro de nuestro grupo de excursiones es el protocolo OAuth.
Casi todos los servicios con los que API tuve que trabajar llevan a cabo la autorización utilizando el protocolo OAuth 2.0, ya han escrito con más detalles al respecto en el centro, que están interesados en dar un paseo en su naturaleza, por favor, tienen esa oportunidad, pueden hacerlo aquí y aquí .
Si explica su significado en pocas palabras, entonces OAuth permite que la aplicación (en nuestro caso, el paquete R será dicha aplicación), a la que ha otorgado permiso, realice algunas acciones en su nombre, sin la necesidad de transferir su nombre de usuario y contraseña de la cuenta publicitaria a esta aplicación, nuevamente por razones de seguridad.
En lugar de un nombre de usuario y contraseña, el protocolo OAuth usa un token, esta es una cadena generada que consiste en un conjunto de letras y números, que almacena información en forma cifrada:
- En nombre de qué usuario la aplicación ejecuta la solicitud
- ¿El usuario realmente permitió el acceso de esta aplicación a sus datos?
- ¿Tiene el usuario los permisos necesarios para trabajar con los materiales publicitarios a los que se refiere
Para el proceso de autorización y trabajar con la API, generalmente necesita registrar la aplicación en la API. Además, esta aplicación debería recibir la confirmación del equipo de soporte de API de un sistema de publicidad en particular, es decir, Inicialmente, el autor describe en detalle cómo y por qué usará la API, todo esto se verifica, modera, y solo si el soporte del lado de la plataforma publicitaria no tiene preguntas de seguridad, el autor del paquete tendrá acceso a la API, y con la ayuda de su aplicación registrada usted paquete, puede autenticarse utilizando la ID y el secreto emitido para esta aplicación.
¿De dónde vino la pregunta de seguridad?
Estamos avanzando, intentemos averiguar dónde surgió la pregunta de seguridad al usar paquetes.
En general, el tema de la seguridad del acceso a los paneles publicitarios está más que justificado, ya que las oficinas de publicidad tienen dinero, y a menudo no lo suficientemente pequeño, por lo que la seguridad de las cuentas publicitarias es un problema mucho más grave que la seguridad del acceso, por ejemplo, a un perfil de usuario regular en las redes sociales.
El hecho es que, en la mayoría de los casos, al autorizar, R redirige a los usuarios de los paquetes al navegador, inicialmente para confirmar el acceso a la cuenta, en esta etapa está en la página de servicio con la API con la que va a trabajar. Después de la confirmación, el usuario es redirigido a la página donde se generará el token, o al código de confirmación de autorización, que posteriormente debe ingresarse en la consola R.
Por lo tanto, la mayoría de los usuarios están preocupados porque los sitios donde se genera el token en sí o el código de confirmación de autorización son de terceros y no tienen nada que ver con el servicio de publicidad en sí, por supuesto, tienen un contador de Google Analytics o un contador Yandex.Metrica, y el propietario del sitio, que, en la mayoría de los casos, también es el autor del paquete, según muchos, a través de este sitio puede tomar posesión de sus tokens y obtener acceso para administrar sus materiales publicitarios a través de ellos.
Lo que te amenaza con una intercepción simbólica
Hablemos de lo que generalmente le permite hacer una ficha si cae en manos de un atacante.
El token debe almacenarse de la misma manera que todos los demás datos necesarios para acceder a la cuenta, es decir, Si el token cae en cualquiera de las manos, el que lo haya tomado podrá administrar sus materiales publicitarios: eliminarlos, cambiar, por ejemplo, será posible cambiar el texto del anuncio y el enlace al que lleva.
La buena noticia es que, como escribí anteriormente, el protocolo OAuth le permite dar la oportunidad de administrar sus materiales publicitarios sin proporcionar un nombre de usuario y contraseña de su cuenta, es decir. incluso si alguien ha tomado posesión de tu token, no podrá robar tu cuenta con su ayuda. Ni una sola API le permite solicitar, y aún más, cambiar su contraseña, para que no se le quite su cuenta, pero anunciar su sitio a través de su cuenta es fácil.
Qué hacer si alguien ha tomado posesión de tu token
Si sucedió que transfirió accidentalmente su ficha, no se asuste. De hecho, este no es el fin del mundo, en la mayoría de los casos hay una serie de acciones que restablecen los tokens emitidos anteriormente, por ejemplo, en esta sección de la referencia de la API Yandex.Direct, el proceso de recuperación de tokens emitidos anteriormente se describe en detalle.
En la mayoría de los casos, independientemente de la API de sistema de publicidad con la que esté trabajando, será suficiente con cambiar la contraseña de su cuenta.
Cómo usar los paquetes R de manera más segura para trabajar con los sistemas de publicidad API
Y ahora hemos llegado a la parte más interesante de nuestro recorrido, luego hablaré sobre cómo es más seguro usar los paquetes que desarrollé, ya que estoy bien familiarizado con las API de los sistemas con los que trabajan.
Quiero señalar que todos los tokens emitidos se almacenan en el lateral de la plataforma de publicidad, y no en la aplicación a través de la cual funciona el paquete R, por lo que incluso el usuario de la aplicación registrada para trabajar con la API de la plataforma de publicidad no tiene acceso al token en sí.
ryandexdirect y rym : paquetes para trabajar con las API Yandex.Direct y Yandex.Metrica
Ambos paquetes usan el servicio Yandex OAuth; para más detalles, vea este enlace .
Hay 2 funciones en el paquete ryandexdirect para la autorización:
yadirAuth - autorización en dos pasosyadirGetToken - solicitud de un token de autorización
Cuando se usa la función yadirAuth, es decir, recomiendo usarla cuando se trabaja con ryandexdirect, el proceso de autorización continúa de acuerdo con el esquema descrito aquí , la única vulnerabilidad en este caso es el período desde el momento en que se genera el código de confirmación hasta que se ingresa en la consola R.
Explicaré por qué, así es como Google Analytics muestra datos sobre visitas a la página de generación del código de verificación .
Es decir el código viene después del signo '?' y se considera un parámetro GET que captura el contador de Google Analytics, pero la vida útil de dicho código de verificación termina inmediatamente después de usarlo, es decir, justo después de ingresarlo en la consola R. La vida útil máxima de dicho código es de 10 minutos.
La segunda función, yadirGetToken , realiza la autorización de acuerdo con el otro esquema descrito aquí . Y cuando se usa, no se genera ningún código de confirmación, es decir después de otorgar permiso al paquete para acceder a los datos, accede a la página de generación de tokens. El token en la URL en sí se devuelve después del signo '#', esto no es un parámetro get, sino un ancla, o como esta parte de la URL también se llama hash. El navegador no transmite estos datos; en consecuencia, no se transfiere más a los informes de Google Analytics, es decir, Las visitas a esta página en los informes se muestran así:
En este segundo caso, no existen riesgos, pero la desventaja de usar la función yadirGetToken es que no guarda las credenciales en un archivo en su PC y, por lo tanto, no puede usar estos datos entre diferentes sesiones de R, lo cual no es muy conveniente. Almacenará el token obtenido con su ayuda, y lo usará en los scripts como una cadena de texto, la vida útil de dicho token es de 1 año, después de lo cual el paquete no podrá reemplazarlo automáticamente, como sucede cuando se usa la función yadirGetAuth.
Hay una función rym_auth en el paquete rym para autorización, que es un análogo completo de la función yadirAuth, cuyo esquema de operación ya he descrito en detalle.
rfacebookstat : paquetes para trabajar con la cuenta de publicidad de Facebook
El proceso de autenticación en la API de Facebook Marketing se describe en detalle aquí .
Para aprobar la autorización, el paquete rfacebookstat tiene la función fbGetToken , funciona igual que la función yadirGetToken del paquete ryandexdirect descrito anteriormente, es decir. todo se implementa a través de la autenticación en un solo paso. No hay peligro de que su token sea interceptado a través de los informes de Google Analytics, hay una pantalla de cómo se ve una visita a la página de generación de tokens en Google Analytics.
rvkstat : paquetes para trabajar con la cuenta VK
El proceso de autenticación de Vkontakte se describe en la Ayuda de la API .
En rvkstat, puede usar una de dos funciones para la autorización:
vkAuth proporciona autenticación en dos pasos, esencialmente un análogo de la función yadirAuth descrita al comienzo de este bloque, pero solo para autorización en la API de Vkontakte, y no Yandex.
La peculiaridad de trabajar con Vkontakte API en este caso es que registrar su aplicación y acceder a la API es bastante simple allí, no necesita completar formularios en los que debe describir en detalle cómo y por qué utilizará la API. Entonces, dado que usa su aplicación cuando trabaja con rvkstat, incluso interceptar el código de confirmación no funciona, porque está vinculado a su aplicación, y para interceptar un token con él, necesita conocer la identificación y el secreto de su aplicación, el código en sí no le permitirá obtener un token para usted.
La función vkGetToken permite obtener el token de la manera más rápida, además, el token recibido está vinculado al dispositivo desde el que se solicitó, es decir. incluso si alguien lo obtiene, puede usarlo solo desde la misma PC desde la que se le solicitó. Al mismo tiempo, el token en la URL cuando se genera es después del signo '#' y, como dije antes, no entra en los informes de Google Analytics.
Por el momento, hay 3 esquemas de autorización en la API MyTarget, para obtener detalles sobre cada uno, consulte la documentación .
La función myTarAuth está destinada a la autorización en la API MyTarget en rmytarget, de manera predeterminada utiliza el esquema de autorización de concesión de código de autorización, que le permite trabajar con la API MyTarget sin tener que acceder personalmente a ella. Es decir Ya registré la aplicación, fue aprobada por el soporte de la API MyTarget y usted le da acceso para trabajar con la cuenta en su nombre.
El Código de autorización Grant es un esquema de autorización de dos etapas, es decir, similar al implementado por la función yadirAuth en el paquete ryandexdirect.
Funciona de la siguiente manera:
- Inicia la función, después de lo cual se abre el navegador.
- En la página del servicio MyTarget, otorga permiso para acceder a su cuenta.
- Será redirigido a la página del paquete donde se genera el código de confirmación. La vida útil máxima de este código es de 1 hora, pero finaliza inmediatamente después de recibir un token con él.
- Ingrese el código de confirmación copiado en la consola R y obtenga un token para trabajar con la API.
En este caso, el código de confirmación es un parámetro de obtención y se registra en los informes de Google Analytics.
Pero, si observa detenidamente, además del código (obtener el código del parámetro) , la URL contiene un parámetro más: el estado . Esta es una cadena, también un token que genera el paquete rmytarget y se envía al navegador inmediatamente después de que se inicia la función, este parámetro es único y se le adjunta el código de confirmación de autorización. Incluso si intercepta tanto el código de confirmación como el token de estado, aún no puede usar esta combinación porque En primer lugar, no hay ningún lugar para ingresar el token de estado, y como ya escribí es único, e incluso si hubiera un lugar para ingresarlo, no se puede volver a enviar. Por lo tanto, este esquema de autorización es completamente seguro.
Pero si es lo mismo, esta opción aún le parece sospechosa, entonces rmytarget y la función myTarAuth permiten usar los dos esquemas de autorización restantes:
- Concesión de credenciales de cliente , solía trabajar con datos de cuentas personales a través de API
- Grant de credenciales de cliente de agencia , solía trabajar con los datos de sus propios clientes de agencias / gerentes.
En este caso, debe acceder de forma independiente a la API MyTarget, en este momento solo las entidades legales pueden obtenerla, y se emite manualmente, para solicitar acceso necesita usar el formulario de comentarios, puede encontrar todos los detalles aquí .
Entonces, si aún logró registrar su aplicación para trabajar con la API MyTarget, puede autenticarse con bastante facilidad usando uno de los dos esquemas enumerados anteriormente usando la función myTarAuth , para esto, pase el valor FALSE al argumento code_grant y use los siguientes argumentos:
- grant_type : el tipo de su cuenta, en este caso una cuenta de cliente normal, toma los valores "client_credentials" o "agency_client_credentials".
- agency_client_name : inicio de sesión del cliente desde la cuenta del agente, solo se usa si grant_type = "agency_client_credentials".
- client_id : se le emite un ID al confirmar el acceso a la API MyTarget.
- client_secret : emitido cuando confirma el acceso a la API MyTarget junto con el ID de cliente.
Código de muestra de autorización de concesión de credenciales del cliente myTargetAuth <- myTarAuth(code_grant = FALSE, grant_type = "client_credentials", client_id = "XXXXXXXXXX", client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
Código de muestra para el esquema de autorización Agencia Cliente Credenciales Subvención myTargetAuth <- myTarAuth(code_grant = FALSE, grant_type = "agency_client_credentials", client_id = "XXXXXXXXXX", client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", agency_client_name = "xxxxxxxxx@agency_client")
En el caso de utilizar este enfoque, la autenticación pasará sin ninguna interacción con el sitio del paquete rmytarget.
Conclusión
Aquí es donde termina nuestro recorrido, ya que hoy se publican más de 10,000 paquetes en los repositorios principales: CRAN y más de 80,000 en GitHub, en conclusión, quiero decir algunas palabras más sobre la seguridad de su uso.
En primer lugar, preste atención a si hay un paquete que necesita en CRAN, ya que este es el repositorio oficial para el lenguaje R, los paquetes están sujetos a una moderación bastante estricta por parte de un equipo de especialistas de este repositorio antes de ser publicados allí. Y el paquete no se publicará allí hasta que cumpla con la política de CRAN . Por lo tanto, si el paquete está presente en CRAN, puede estar seguro de que su uso es seguro para usted.
Además, quiero señalar que el código de todos los paquetes para el lenguaje R está abierto, siempre puede ver el código de cualquiera de sus funciones antes de iniciarlo.
También trate de encontrar artículos sobre la aplicación de este paquete, los usuarios de R están bastante dispuestos a compartir información, y probablemente encontrará casos de uso de paquetes más o menos populares. Si escriben sobre un paquete, significa que lo están usando, y aparentemente nadie tuvo problemas con él.
También mire quién es el autor del paquete, hay dos formas de hacerlo:
- Después de instalar el paquete, ejecute el
utils::packageDescription("_")$Author - Ver el archivo DESCRIPTION en la fuente del paquete.
Intente encontrar alguna información sobre el autor en la World Wide Web, si una persona es pública en lo más mínimo, es poco probable que arriesgue su reputación para obtener un token de acceso a su cuenta publicitaria y sus materiales publicitarios. A menudo, una reputación es más cara que el dinero recibido de manera dudosa.
Si instala un paquete desde GitHub, instálelo desde el repositorio del autor, y no desde cualquier rama, por regla general, hay muchas de esas ramas en repositorios populares:
El hecho es que el autor del paquete no actualiza las ramas, lo que significa que no recibirá su versión más reciente. Y además, el usuario de GitHub que creó la sucursal puede realizar cambios en su propio código, independientemente de si decide confiar en dichos cambios.
Puede ver desde qué repositorio se creó su rama en su página en GitHub.
No transfiera sus tokens a nadie bajo ninguna circunstancia, almacénelos de la misma manera que almacena las contraseñas de las cuentas, incluso si necesita mostrar un ejemplo de código, hágalo sin especificar tokens.
Recuerde, en la gran mayoría de los casos, usar paquetes R es completamente seguro para usted, espero que este artículo me haya ayudado a convencerlo y hable sobre cómo funciona el proceso de autorización en la API de las plataformas publicitarias más populares.
Buena suerte, ten cuidado pero no cedas ante la paranoia.