Activa las notificaciones push PhoneGap Spain

Foro

Home Forums PhoneGap Algo de seguridad en el envio de datos Ajax

This topic contains 2 replies, has 2 voices, and was last updated by  kannarius 4 meses .

Viendo 3 respuestas - de la 1 a 3 (de 3 en total)
  • Algo de seguridad en el envio de datos Ajax

    Intervenciones
  • kannarius 
    Participant

    Buenas a todos compis!!!! ayer investigando un poco he visto que una apk se puede descomprimir ,Vamos que el empaquetado de la apk , quedando al aire todo el codigo fuente , almenos la parte de phonegap….

    Cuando hacemos peticiones mediante ajax … no hay problema por que recogemos los datos y trabajamos con ellos , pero cuando el envio de variables es para recogerlas y trabajarlas en el lado del servidor, como puede ser añadir a una Db .. o lo que sea…. que metodo usais para darle cierta seguridad al mismo? , ya que al ver el codigo podemos ver la ruta y las variables que enviamos …. por lo tanto podrian hacer lo mismo desde scripts de cualquier parte…

    Alguien ha pensado o hay alguna manera de realizar eso? , yo pense en hacer uso por ejemplo del ID del dispositivo….. verificar que este en la db antes de aceptar los datos enviados , verificando usuario primeramente. …

    Que opinais? alguien usa otro tipo de planteamiento? Cual seria la forma correcta?… GRacias.!


    gustter 
    Participant

    Hola. Interesante tema.

    Los tópicos de seguridad son muy extensos por lo que a efectos de tu pregunta entiendo que podríamos concentrarnos en una amenaza puntal, el spam a los servicio “de escritura”, es decir, que se envíe a nuestro servidor datos falsos y que éste no puede diferenciarlos de los reales. Los servicios “de lectura” no tiene este problema, sí podrían ser víctimas de ataques de negación de servicio o robo de funcionalidad desde otra App o web, pero es otro tema.

    Si el usuario está registrado y autenticado tendrá una sesión activa y su token (cookie, header o como se implemente) viajará junto a la petición, la cual en todo caso debería ir por https, por lo que a priori el servicio estaría protegido.

    Por lo que el problema se podría restringir a a los servicios “de escritura” para usuarios anónimos; cosas como la registración del usuario, formularios de contáctenos, el envío de tokens de push notifications, etc.

    La primera línea de lucha contra el spam automático son los captcha y aquí surge la primer gran pregunta; ¿por qué las Apps no lo suelen usar? No tengo la respuesta definitiva, pero mi conjetura es que en la web los robots andan rastreando las páginas y detectando formularios y servicios; cuando los encuentran los atacan; en las Apps el rastreo no es posible por lo que es más difícil hacerse de las direcciones en forma automática; sumémosle el hecho que la mayoría de las App están desarrolladas en forma nativa, lo cual no es tan simple “hurgar” en su código, por lo que esta práctica no se usa; pero no significa que la vulnerabilidad no exista –una persona podría extraer la dirección manualmente y comenzar el ataque- por lo que en rigor se debería usar captcha en las App –supongo que si estadísticamente no hay problema la mayoría decide no molestar al usuario-.

    La segunda línea, complementaria, es que toda solicitud incluya una clave que fue enviada previamente a la App, la cual se invalida inmediatamente de verificarla; esto hace que si alguien quiere reenviar un request no sea posible; además la mayoría de los robots fallan con esto. Nuevamente, si alguien hacer un programa específico luego de analizar el comportamiento, podría construir un robot específico.

    La tercera línea, en los casos que sea posible, podría ser una segunda validación de los datos recibidos y si no se validan se eliminan. Por ejemplo, en una registración, la comprobación por email, sms, push, etc. Observar que en casos como un “Contáctenos” esto no sería posible.

    Otra alternativa que puede incluso ser complementaria a las anteriores, podría ser desplegar un certificado digital en la App y hacer una validación de dos puntas; obviamente este certificado se podría extraer de la App, pero nuevamente se requiere mayor sofisticación del atacante. Además, quien no tenga la App no podrá “spamear” nunca el servicio.

    Para terminar, me gustaría destacar que independientemente de la tecnología usada, phonegap o nativas, una aplicación crítica no debería basar su seguridad en un elemento secreto del código, ya que ulteriormente puede ser decompilada y revelar su secreto. Aunque tan cierto como lo anterior es que cuanto más fácil sea, a los “sabios” se le sumarán los idiotas, estos últimos más abundantes que los primeros, por lo que habrá más probabilidad de ataque; incluso sin ninguna razón, solo por molestar.

    Esperemos comentarios de otros foristas pues el tema es realmente interesante e importante. Gracias por plantearlo.

    PD: Habría que abrir un tópico “Captcha y Apps”.


    kannarius 
    Participant

    Ummm muchas gracias , te doy la razon en todo , y bueno he estado pensando algunos sistemas alternativos o ya usados de facil implementacion …. aun sigo pensando alternativas comodas pero que a su vez sean efectivas. Muchas gracias por tu comentario ….
    Bueno , cuando saque algo bien en claro .. posteare mi sistema, que siempre podra ayudar a alguien o incluso con la aportacion de comentarios de los compañeros … mejorar !!!

    Un abrazo.


Viendo 3 respuestas - de la 1 a 3 (de 3 en total)

You must be logged in to reply to this topic.