Dans les années 1990, client-serveur était roi. La puissance de traitement des ordinateurs et la vitesse croissante des réseaux ont conduit à des applications de plus en plus souvent, bureau brancher middleware backend et de sources de données. Mais ces applications, et les PC qu'ils couraient sur, étaient vulnérables aux virus et autres attaques. Lorsque les demandes ont été mal conçus, ils peuvent laisser des données sensibles exposées.Aujourd'hui, l'application mobile est roi. La puissance de traitement des smartphones et appareils mobiles basés sur Android, iOS, et d'autres systèmes d'exploitation mobiles combinée à la vitesse de large bande des réseaux cellulaires ont conduit à des applications plus mobiles avec un plan de la vieille école: prise en backend middleware et de sources de données.Mais ces applications et les dispositifs qu'ils s'exécutent sur sont vulnérables ... eh bien, vous obtenez l'image. Il a déjà vu avec une différence majeure: alors que la plupart des applications client-serveur a couru à l'intérieur des limites d'un WAN LAN ou d'entreprise, les applications mobiles fonctionnent en dehors des limites des réseaux d'entreprise et ont accès aux services à travers l'Internet public. Cela rend les applications mobiles potentiellement énorme failles de sécurité, surtout si elles ne sont pas correctement architecturée et configuré avec une sécurité adéquate et les contrôles d'accès.Vitesse (sur le marché) tueAujourd'hui, nous avons des outils comme PhoneGap plate-forme de titane et de Appcellerator ainsi que d'une foule d'autres outils de développement pour les plateformes mobiles qui ressemblent à bien des égards les outils de développement intégrés de l'époque client-serveur (tels que Visual Basic et PowerBuilder). Ainsi, les développeurs et les équipes de développement petites peuvent facilement manivelle nouvelles applications mobiles qui lient à des services Web, en les accrochant aux systèmes back-end lancés sur Amazon à grande vitesse.Mais malheureusement, ils le font trop souvent sans tenir compte de la sécurité à l'avant, créant un potentiel d'exploitation. Alors que beaucoup d'attention a été accordée à la sécurité sur l'appareil lui-même, la connexion backend est tout aussi, sinon plus, vulnérable.Si les entreprises ont de la chance, comme basée à Montréal Skytech Communications, ces trous simplement produire des embarras public. Quand un étudiant en informatique dans un lycée professionnel utilisé un scanner de sécurité librement téléchargeable sur mobile app SkyTech (qui permet aux étudiants d'accéder à leurs dossiers et s'inscrire à des cours), il a trouvé des failles de sécurité majeures dans l'application. Ces défauts permis à quiconque d'avoir accès aux renseignements personnels des élèves.Les petits développeurs ne sont pas les seuls qui peuvent se faire prendre par leurs backends applications mobiles. Prenez, par exemple, General Motors bond soudain de l'avant avec son API Web OnStar. La société a été contrainte d'accélérer un effort API publique quand il a découvert une entreprenant Chevy Volt propriétaire avait l'ingénierie inverse son API application mobile pour récupérer statistiques sur les véhicules des centres de données liés au système OnStar pour une utilisation personnelle. Heureusement, il n'était pas méchant. Mais il a fait construire un site web pour les conducteurs d'autres à faire de même-qui peuvent être exposés à des données personnelles dans le processus en utilisant les connexions de ces chauffeurs compte OnStar, en violation des règles de confidentialité de GM. Le site fonctionne maintenant sur une nouvelle API plus sûr.Garder le client (le plus souvent) dumb"Ce genre de chose a été un problème puisque les ordinateurs ont commencé à parler les uns aux autres», a déclaré Kevin Nickels, le président et chef de la direction de «backend comme un service« fournisseur FatFractal. Pour éviter ce genre de problèmes-ou pire-développeurs ont besoin pour aborder les questions telles que la sécurité et le contrôle d'accès dès le début. «Trop souvent, les développeurs de tenter de répondre à ces après le fait, et non dès le début», a expliqué Nickels.L'un des éléments clés de la conception de la sécurité dans les applications mobiles est de s'assurer que le client de l'application téléphone lui-même, ou le navigateur app-t-très peu de transformation. "La meilleure pratique générale est de laisser le code sur l'appareil en faire le moins possible", a déclaré Danny Boice, le co-fondateur et CTO de Speek, un service en nuage conférence téléphonique qui fonctionne à travers autochtones clients mobiles et les navigateurs Web. (Boice est également un ancien dirigeant en charge du développement Web et mobile pour la société de tests SAT, The College Board.) "Il ya des choses sur le téléphone d'une personne que vous ne pouvez pas contrôler. Nous mettons le plus gros du travail hors de l' client, car vous pouvez contrôler ce que l'application envoie et reçoit. "Il est particulièrement important de gérer l'ensemble d'intégration de données avec d'autres services sur le serveur et non pas sur l'appareil mobile, dit Nickels. "Annonces exposés dans une application, par exemple, pourrait avoir un code malveillant. Nous recommandons aux gens de faire ce genre d'intégration via le backend. De cette façon, les choses venant de l'extérieur de l'application n'aura pas accès à toutes les ressources système du tout."Dan Kuykendall, co-PDG et directeur de la technologie de sécurité Objectifs de test NT fermes, a déclaré le magasin inférieur applications mobiles et traiter les données sur le périphérique client, mieux c'est. «Beaucoup de développeurs pensent,« Le seul trafic qui va venir en est de mon application mobile "," Kuykendall expliqué. "Et ils construisent logique dans le client mobile" renforcement des requêtes pour être envoyés aux systèmes dorsaux de traitement et de transformation des données brutes renvoyées. Mais les demandes de l'application peut facilement être «reniflé» par quelqu'un qui a l'application sur un périphérique qui leur est propre, par un logiciel malveillant sur l'appareil qui pourrait surveiller le trafic sortant, ou par une personne malveillante de surveillance ce qui se dégage des appareils mobiles. "Vous ne voulez pas passer l'application des instructions SQL vers le serveur," Kuykendall dit. "C'est de la folie." Mais comme il le dit, c'est aussi trop souvent.Le bit le plus fondamental de durcissement nécessaire pour les applications mobiles est de crypter le trafic vers le backend-au minimum, en utilisant Secure Socket Layer (SSL). Mais SSL par elle-même ne suffit pas à cause de la nature de la façon dont les périphériques mobiles se connectent. De nombreux smartphones se connectera automatiquement à disposition ouvertes réseaux Wi-Fi dont ils se souviennent, ce qui rend relativement facile de les amener à se connecter à un dispositif de voyous qui peuvent agir comme un proxy SSL, décrypter et re-crypter le trafic tout en enregistrant tout ce qui passe à travers. Alors que SSL est généralement un moyen de défense contre les attaques basées sur le navigateur des séances sur PC, certaines applications mobiles sont vulnérables parce qu'elles reposent sur WebKit pour gérer SSL. WebKit ne manque pas par défaut avec des certificats mauvais comme ceux utilisés dans «homme au milieu» (MIM) attaques-il envoie un message d'erreur à l'application qu'un cert est mauvais, et laisse le code décider ce qu'il faut faire à ce sujet. Dans certains cas, pour contourner les erreurs, les applications se préparent à accepter toute cert, ils sont donc vulnérables aux attaques MIM."Je peux m'asseoir dans un lieu public, comme le centre commercial, avec un ananas connexion Wi-Fi gratuite et mon ordinateur portable", Kuykendall dit, «et offrir un accès Internet vraie avec moi, comme un« homme au milieu », et de voir le trafic venant de personnes de smartphones sans les connaître leur smartphone est connecté à moi. Et quand chercher applications mises à jour, je vois ça. " Depuis de nombreuses applications mobiles chercher les mises à jour sans intervention de l'utilisateur », les utilisateurs ne sont pas incité à la connexion il se trouve." Si les données extraites d'une attaque man-in-the-middle n'a pas sortes de contrôles supplémentaires et de protection, il pourrait alors être utilisée pour attaquer les systèmes dorsaux.Une autre vulnérabilité causée par la mise accorder trop d'importance sur le client est qu'il nécessite plus de données à être stockées sur le client des données qui pourraient être exploitées. Même les données éphémères (informations stockées localement à traiter pour l'affichage ou à envoyer par le serveur et ensuite être éliminés) est vulnérable. "Ce n'est pas si facile d'entrer dans une application en cours d'exécution et voler des trucs,« Nickels dit. "Il s'agit plus d'un problème avec un cache de données ou sur téléphone stockage, en utilisant des bases de données comme SQLite. Vous devez masquer que les données du mieux que vous le pouvez, il chiffrer au repos, et stocke des choses qui ne sont pas faciles à associer les uns aux autres . "
Enregistrer un commentaire