security - seguridad de parse.com
private-key (4)
Recientemente descubrí lo útil y fácil que es parse.com . Realmente acelera el desarrollo y le brinda una base de datos disponible para almacenar todos los datos provenientes de su aplicación web / móvil.
Pero, ¿qué tan seguro es? Por lo que entiendo, debe incrustar la clave privada de su aplicación en el código, lo que le otorga acceso a los datos.
Pero, ¿qué pasa si alguien puede recuperar la clave de su aplicación? Lo intenté yo mismo. Me tomó 5 minutos encontrar la clave privada de una APK estándar, y también existe la posibilidad de crear una aplicación web con la clave privada codificada en su fuente de JavaScript donde casi cualquier persona puede verla.
La única manera de proteger los datos que he encontrado son las ACL ( https://www.parse.com/docs/data ), pero esto todavía significa que cualquiera puede alterar los datos de escritura.
¿Alguien puede iluminarme, por favor?
Al igual que con cualquier servidor back-end, debe protegerse contra clientes potencialmente maliciosos. Parse tiene varios niveles de seguridad para ayudarlo con eso.
El primer paso es ACLs , como dijiste. También puede cambiar los ACLs en el navegador de datos para deshabilitar a los clientes no autorizados para que creen nuevas clases o agreguen filas o columnas a las clases existentes.
Si ese nivel de seguridad no le satisface, puede proxy de su acceso a datos a través de Funciones de la nube . Esto es como crear un servidor de aplicaciones virtual para proporcionar una capa de control de acceso entre sus clientes y su almacén de datos back-end.
Lo que hice fue lo siguiente.
- Restrinja la lectura / escritura para público para todas las clases. La única forma de acceder a los datos de la clase sería a través del código de la nube.
- Verifique que el usuario esté conectado con el parámetro
request.user, y si la sesión del usuario es nula y si el id del objeto es legítimo. - Cuando se verifica al usuario, entonces permitiría recuperar los datos utilizando la clave maestra.
Simplemente mantenga un control estricto sobre sus opciones de seguridad de nivel global (creación de clase de cliente, etc.), opciones de seguridad de nivel de clase (puede, por ejemplo, deshabilitar clientes borrando entradas de instalación. También es común desactivar la creación de campo de usuario para todas las clases). ), y lo más importante de todo, cuidado con las ACL.
Por lo general, utilizo disparadores beforeSave para asegurarme de que las ACL sean siempre correctas. Entonces, por ejemplo, _User objects es donde se encuentra el correo electrónico de recuperación. No queremos que otros usuarios puedan ver los correos electrónicos de recuperación de los demás, por lo que todos los objetos de la clase _User deben tener lectura y escritura establecidas solo para el usuario (con public read false y public write false).
De esta forma, solo el usuario puede manipular su propia fila. Otros usuarios ni siquiera notarán que esta fila existe en su base de datos.
Una forma de limitar esto aún más en algunas situaciones, es usar funciones en la nube. Digamos que un usuario puede enviar un mensaje a otro usuario. Puede implementar esto como un nuevo mensaje de clase, con el contenido del mensaje y los indicadores para el usuario que envió el mensaje y para el usuario que recibirá el mensaje.
Como el usuario que envió el mensaje debe poder cancelarlo, y dado que el usuario que recibió el mensaje debe poder recibirlo, ambos deben poder leer esta fila (por lo que la ACL debe tener permisos de lectura para ambos). ) Sin embargo, no queremos que ninguno de ellos altere el contenido del mensaje.
Entonces tiene dos alternativas: o bien crea un desencadenante beforeSave que comprueba si las modificaciones que los usuarios intentan hacer en esta fila son válidas antes de confirmarlas, o establece la ACL del mensaje para que nadie tenga permisos de escritura, y crea funciones en la nube que validan al usuario y luego modifican el mensaje usando la clave maestra.
El punto es que debes hacer estas consideraciones para cada parte de tu aplicación. Hasta donde yo sé, no hay forma de evitar esto.
Tomé el siguiente enfoque en el caso en el que solo necesitaba exponer una pequeña vista de los datos del usuario a una aplicación web.
a. Cree un objeto secundario que contenga un subconjunto de los campos de objetos seguros.
segundo. Usando ACL, haga que el objeto seguro solo sea accesible desde un inicio de sesión apropiado
do. Hacer que el objeto secundario sea público
re. Escriba un disparador para mantener el objeto secundario sincronizado con las actualizaciones de la primaria.
También uso las funciones en la nube la mayor parte del tiempo, pero esta técnica es útil cuando se necesita cierta flexibilidad y puede ser más simple que las funciones en la nube si el objeto secundario es una vista sobre múltiples objetos seguros.