J'ai récemment joué avec les recherches de localisation HTML5 et il est relativement simple de localiser quelqu'un depuis un appareil comme un iPhone. Je veux écrire une application qui utilise des données de localisation, mais il est important que l'emplacement soit factuel. En d'autres termes, je dois empêcher les gens d'écrire un faux message sur le site Web/service Web de sauvegarde avec des coordonnées GPS simulées. Y at-il moyen de collecter les coordonnées GPS d'un appareil mobile à l'aide des API de géolocalisation HTML5 et de les transmettre en toute sécurité à un service Web de telle sorte que quelqu'un ne puisse pas créer un message avec les mêmes données et le système "pour ainsi dire?Comment obtenir un emplacement vérifié en utilisant HTML5?
Répondre
Non sans un cryptage sérieux sur la charge utile sur le client. Lequel, s'il y a de l'argent impliqué, quelqu'un effectuera l'ingénierie inverse et découvrira comment créer lui-même des charges utiles valides. Rappelez-vous s'il y a de l'argent ou de la célébrité impliqués, alors quelqu'un va penser que l'effort de faire quelque chose comme ça en vaut la peine. Si votre service Web est public et n'utilise pas une sorte de cryptage rien sur le client veillera à ce que quelqu'un avec une connexion réseau ne peut pas renifler votre protocole et simuler les données qu'ils veulent. Et SSL ne le coupera pas. N'importe qui peut proxy the SSL connection on their local network déchiffrer la charge utile et l'inspecter à leur contenu de cœur.
N ° Entièrement d'accord avec la réponse de la sucette floue. Si vous parlez à une machine distante, les données peuvent toujours être fausses. Toujours toujours. Qu'est-ce qui vous rend certain que vous parlez même à un appareil mobile? La chaîne User-Agent? Pfft, ça peut être truqué. Parler à un GPS? Pfft, pourrait provenir d'un chemin prédéfini. Parler à un navigateur Web? Pfft, pourrait être un bot, ou un autre malware.
Et ne croyez pas que le chiffrement (HTTPS) va vous aider. Le client peut modifier n'importe lequel de vos fichiers HTML, CSS ou JavaScript à la volée, par exemple Firebug ou Greasemonkey.
Les raisons pour lesquelles vous ne pouvez pas faire confiance au client sont les mêmes que pour les raisons pour lesquelles des exploits tels que l'injection SQL ou HTML sont si courants. Jamais entendu l'expression "le client a toujours raison"? Eh bien, le client peut avoir raison, mais le client est toujours indigne de confiance.
Le système est là pour être utilisé. Comme les défauts sont découverts, vous les patchez un par un. C'est plus comme un saute-mouton, plutôt que d'atteindre le Saint-Graal. La phrase de Bruce Schneier, “security is a process, not a product”, me vient à l'esprit. Demander un système qui «ne peut pas être joué» est manquant le point. Ce que vous devez faire est de créer un système où le serveur nettoie les données, et/ou rejette les mauvaises données - le test de fuzz n'est pas non plus une mauvaise idée.
Voilà à peu près tout ce que vous pouvez faire de mieux sans expédier des mobiles uniques et personnalisables à vos clients avec l'OS en ROM, et l'intérieur scellé avec de l'époxy.
sceller quelque chose avec l'expoxy ne fait pas une fichue chose pour arrêter l'homme dans les attaques du réseau logiciel milieu, c'est la mentalité très 1980 en essayant de verrouiller le matériel physiquement. Tout est dans le logiciel maintenant. –
ne suggérait pas que Josh époxy ses mobiles (note j'ai dit "mobiles inamplicables", quelque chose qui n'existe manifestement pas). J'essaie juste de souligner mon point que tout peut être MITM'ed le long du chemin. Nous sommes d'accord - croyez-moi! ;-) –
ya c'est un peu ce que je pensais. Je vais devoir trouver un moyen de détecter automatiquement la tricherie potentielle au lieu de la protéger contre cela. Merci pour la contribution. – JoshReedSchramm