Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Le SPA est-il faillible? (avec notes)

210 vues

Publié le

Par Franck Desert

La plupart des organisations faisant du développement web ont déjà ou veulent introduire cette "nouvelle" technique qu’est le SPA… toutefois est-ce fait de façon sécuritaire? Une brève exploration du passé nous montrera ce que nous avons appris et probablement oublié avec cette nouvelle guerre du « Front-End ». Par la suite, nous allons voir ce qu’est une SPA, les changements que ça apporte aux étapes de développement ainsi que les avantages et inconvénients pour les développeurs et les utilisateurs. Le tout sera accompagné d’exemples vous montrant que les directions initialement prises doivent changer. Finalement, nous verrons ce qu’il faut retenir du passé pour ne pas répéter les mêmes erreurs.

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Le SPA est-il faillible? (avec notes)

  1. 1. Le SPA est-il faillible? La plupart des organisations faisant du développement web ont déjà ou veulent introduire cette "nouvelle" technique qu’est le SPA… Toutefois est-ce fait de façon sécuritaire? Une brève exploration du passé nous montrera ce que nous avons appris et probablement oublié avec cette nouvelle guerre du « Front-End ». Par la suite, nous allons voir ce qu’est une SPA, les changements que ça apporte aux étapes de développement ainsi que les avantages et inconvénients pour les développeurs et les utilisateurs. Le tout sera accompagné d’exemples vous montrant que les directions initialement prises doivent changer. Finalement, nous verrons ce qu’il faut retenir du passé pour ne pas répéter les mêmes erreurs. 1
  2. 2. Au sujet du gars … Franck Desert Analyste en sécurité, Architecte organique senior 2
  3. 3. Les origines du terme application à une page ne sont pas claires, bien que le concept ait été discuté au moins dès 2003. Stuart (stunix) Morris a écrit le site Web autonome sur slashdotslash.com avec les mêmes objectifs et fonctions en avril 2002 et, plus tard la même année, Lucas Birdeau, Kevin Hakman, Michael Peachey et Evan Yeh ont décrit une application de page unique. Brevet US 8 136 109. Le terme a été introduit par Steve Yen en 2005. MVC 1980 MVVM 1991 Gang of Four SOLID, KISS, DRY, YAGNI JavaScript peut être utilisé dans un navigateur Web pour afficher l'interface utilisateur, exécuter la logique de l'application et communiquer avec un serveur Web. Des bibliothèques Open Source matures sont disponibles pour prendre en charge la création d'un SPA, réduisant ainsi la quantité de code JavaScript que le développeur doit écrire. Une application web monopage (en anglais single-page application ou SPA) est une application web accessible via une page web unique. Le but est d'éviter le chargement d'une nouvelle page à chaque action demandée, et de fluidifier ainsi l'expérience utilisateur. Deux méthodes existent pour ce faire : l'ensemble des éléments de l'application est chargé (contenu, images, CSS et JavaScript) dans un unique fichier HTML, soitles ressources nécessaires sont récupérées et affichées dynamiquement en fonction des actions de l'utilisateur. L'enregistrement en local de la page définissant une application web monopage et la possibilité de continuer à l'exécuter en local est l'une des propriétés importantes des applications web monopage qui les distingue des applications web standards qui 3
  4. 4. reposent sur l'existence d'un serveur HTTP avec lequel elles échangent données, continuations applicatives et interfaces. Quand les applications web monopages gèrent des données et permettent de les modifier, pour conserver ces données modifiées, il est nécessaire que ces applications modifient leur code, c'est-à-dire : elles doivent être capable de se modifier pour que la sauvegarde locale de l'état modifié de l'application (dont les données) soit persistant. TiddlyWiki est un exemple d'application web monopage. YAGNI (You Aren't Gonna Need It) DRY (Don't Repeat Yourself) KISS (Keep It Simple, Silly or Keep It Simple & Stupid) https://siderite.blogspot.com/2017/02/solid-principles-plus-dry-yagni-kiss-final.html https://thefullstack.xyz/dry-yagni-kiss-tdd-soc-bdfu https://softwareengineering.stackexchange.com/questions/73065/what-are-dry-kiss- solid-etc-classified-as 3
  5. 5. The term user experience was brought to wider knowledge by Donald Norman in the mid-1990s.[4] He never intended the term "user experience" to be applied only to the affective aspects of usage. A review of his earlier work [5] suggests that the term "user experience" was used to signal a shift to include affective factors, along with the pre- requisite behavioral concerns, which had been traditionally considered in the field. Many usability practitioners continue to research and attend to affective factors associated with end-users, and have been doing so for years, long before the term "user experience" was introduced in the mid-1990s.[citation needed] In an interview in 2007, Norman discusses the widespread use of the term "user experience" and its imprecise meaning as a consequence thereof.[6] Several developments affected the rise of interest in the user experience Recent advances in mobile, ubiquitous, social, and tangible computing technologies have moved human-computer interaction into practically all areas of human activity. This has led to a shift away from usability engineering to a much richer scope of user experience, where users' feelings, motivations, and values are given as much, if not more, attention than efficiency, effectiveness and basic subjective satisfaction (i.e. the three traditional usability metrics[7]).[8] In website design, it was important to combine the interests of different stakeholders: marketing, branding, visual design, and usability. Marketing and branding people 4
  6. 6. needed to enter the interactive world where usability was important. Usability people needed to take marketing, branding, and aesthetic needs into account when designing websites. User experience provided a platform to cover the interests of all stakeholders: making web sites easy to use, valuable, and effective for visitors. This is why several early user experience publications focus on website user experience.[9][10][11][12] User experience design https://en.wikipedia.org/wiki/User_experience_design User experience design (UX, UXD, UED or XD) is the process of enhancing user satisfaction with a product by improving the usability, accessibility, and pleasure provided in the interaction with the product.[1] User experience design encompasses traditional human–computer interaction (HCI) design, and extends it by addressing all aspects of a product or service as perceived by users.[2] UX and VR https://www.renacen.com/blog/5-keys-applying-virtual-reality-user-experience/ 4
  7. 7. Responsive web design (RWD) is an approach to web design that makes web pages render well on a variety of devices and window or screen sizes. Recent work also considers the viewer proximity as part of the viewing context as an extension for RWD.[1] Content, design and performance are necessary across all devices to ensure usability and satisfaction.[2][3][4][5] A site designed with RWD[2][6] adapts the layout to the viewing environment by using fluid, proportion-based grids,[7][8] flexible images,[9][10][11] and CSS3 media queries,[4][12][13] an extension of the @media rule, in the following ways:[14] The fluid grid concept calls for page element sizing to be in relative units like percentages, rather than absolute units like pixels or points.[8] Flexible images are also sized in relative units, so as to prevent them from displaying outside their containing element.[9] Media queries allow the page to use different CSS style rules based on characteristics of the device the site is being displayed on, most commonly the width of the browser. Responsive web design has become more important as the amount of mobile traffic now accounts for more than half of total internet traffic.[15] Therefore, Google 5
  8. 8. announced Mobilegeddon in 2015, and started to boost the ratings of sites that are mobile friendly if the search was made from a mobile device.[16] Responsive web design is an example of user interface plasticity.[17] Adaptive web design (AWD) promotes the creation of multiple versions of a web page to better fit the user's device, as opposed to a single version that other web design techniques use. Adaptive web design encompasses a range of other strategies that can be combined with responsive web design.[1] https://en.wikipedia.org/wiki/Adaptive_web_design Techniques Adaptive web design uses multiple page layouts for a single web page and sometimes progressive enhancement (PE). The adaptive model is a "mobile separate" layout, in contrast to "mobile first", unobtrusive JavaScript, and progressive enhancement of RWD.[citation needed] "Mobile separate", unobtrusive JavaScript, and progressive enhancement "Mobile separate" is the same concept as "mobile first", except the design layout of AWD is to have a separate base mobile layout versus the single design layout of RWD. Browsers of basic mobile phones do not understand JavaScript or media queries, so a recommended practice is to create a basic mobile layout and use unobtrusive JavaScript and progressive enhancement for smart phones, rather than rely on graceful degradation to make a complex, image-heavy site work.[3][4][5][6] La dégradation élégante dans le domaine de la conception web correspond au début des années 2000 découlant de l'adoption massive à deux nouveaux concepts tels que la séparation du fond (sémantique XHTML) et de la forme (CSS), l'adoption des standards du W3C grâce à l'émergence de nouveaux navigateurs sur le marché (Firefox, Opera). Cette idée de régression était soutenue par l'amélioration rapide et continue des technologies du moment, les développeurs visant d'abord les navigateurs les plus récents et considérant ensuite les anciennes versions. Amélioration progressive vs dégradation élégante Ces deux méthodes ont un même but, rendre le contenu accessible au plus grand nombre. Ce qui les oppose est leur approche du problème : 5
  9. 9. dégradation élégante : l'approche est dite top-down, on développe d'abord pour une configuration précise, puis on s'efforce d'étendre le nombre de configurations capables de rendre le contenu correctement ; l'amélioration progressive : l'approche est dite bottom-up ou par couche ; les couches sont développées de la plus basique et la plus universelle à la plus spécifique, comme suit : couche sémantique (XHTML, XML) : contenu accessible pour tous (tout est balisé) ; fonctionnalité accessible pour tous (tout est « cliquable ») ; couche visuelle (CSS) : la mise en forme est gérée par des feuilles de style externes ; couche événementielle (JavaScript, AJAX) : les comportements évolués sont non-obstrusifs et gérés par des fichiers externes respect des préférences utilisateur. 5
  10. 10. Thin server architecture stateful server architecture stateless server architecture Architecture serveur Thin server architecture Un SPA déplace la logique du serveur vers le client, le rôle du serveur Web évoluant vers une API de données ou un service Web pur. Dans certains milieux, ce changement d’architecture a été appelé «architecture de serveur mince» pour souligner que la complexité a été déplacée du serveur vers le client, avec l’argument que cela réduit la complexité globale du système. stateful server architecture Le serveur conserve l'état nécessaire en mémoire de l'état du client de la page. De cette façon, lorsqu'une requête frappe le serveur (généralement des actions utilisateur), le serveur envoie le code HTML et / ou JavaScript approprié avec les modifications concrètes pour amener le client au nouvel état souhaité (en ajoutant / supprimant / mettant à jour une partie du fichier) client le DOM. Dans le même temps, l'état du serveur est mis à jour. La plupart de la logique est exécutée sur le serveur et HTML est généralement également rendu sur le serveur. À certains égards, le serveur simule un navigateur Web, reçoit des événements et effectue des modifications delta de l’état du serveur qui sont automatiquement 6
  11. 11. propagées au client. Cette approche nécessite davantage de mémoire serveur et de traitement serveur, mais l'avantage est un modèle de développement simplifié car a) l'application est généralement entièrement codée sur le serveur et, b) les données et l'état de l'interface utilisateur sont partagés dans le même espace mémoire. besoin de ponts de communication client / serveur personnalisés. stateless server architecture Ceci est une variante de l'approche serveur avec état. La page client envoie des données représentant son état actuel au serveur, généralement par le biais de requêtes Ajax. En utilisant ces données, le serveur est capable de reconstruire l’état du client de la partie de la page à modifier et de générer les données ou le code nécessaires (par exemple, JSON ou JavaScript), qui sont renvoyés au client à un nouvel état, en modifiant généralement l’arbre DOM de la page en fonction de l’action client qui a motivé la requête. Cette approche nécessite l'envoi de davantage de données au serveur et peut nécessiter davantage de ressources de calcul par requête pour reconstruire partiellement ou totalement l'état de la page du client sur le serveur. Dans le même temps, cette approche est plus facilement évolutive car aucune donnée de page par client n'est conservée sur le serveur et, par conséquent, les requêtes Ajax peuvent être distribuées vers différents nœuds de serveur sans partage de données de session ni affinité de serveur. 6
  12. 12. Cycle de vie de la page Un SPA est entièrement chargé dans le chargement de page initial, puis les régions de page sont remplacées ou mises à jour avec de nouveaux fragments de page chargés à partir du serveur à la demande. Pour éviter un téléchargement excessif des fonctionnalités inutilisées, un SPA télécharge souvent progressivement davantage de fonctionnalités à mesure qu'elles deviennent nécessaires, que ce soit de petits fragments de la page ou des modules d'écran complets. De cette manière, il existe une analogie entre les "états" dans un SPA et les "pages" sur un site Web traditionnel. Comme la "navigation par état" dans la même page est analogue à la navigation par page, en théorie, tout site Web basé sur une page pourrait être converti en une seule page en remplaçant uniquement les parties modifiées par des pages consécutives dans une autre page. L'approche SPA sur le Web est similaire à la technique de présentation SDI (Single Document Interface) utilisée couramment dans les applications de bureau natives 7
  13. 13. Challenges SPA modèle Bibliothèques JavaScript côté client traitant de divers problèmes. Structures Web côté serveur spécialisées dans le modèle SPA L'évolution des navigateurs et la spécification HTML5 conçue pour le modèle SPA Search engine optimization (SEO) Client/Serveur code partitionné Historique du navigateur Ajout de chargements de page à un SPA Vitesse de charge initiale Accélérer le chargement de la page Ceci est un scénario de compromis "payez-moi maintenant ou payez-moi plus tard". Challenges with the SPA model Because the SPA is an evolution away from the stateless page-redraw model that browsers were originally designed for, some new challenges have emerged. Each of these problems has an effective solution with: Client-side JavaScript libraries addressing various issues. Server-side web frameworks that specialize in the SPA model The evolution of browsers and the HTML5 specification designed for the SPA model Search engine optimization (SEO) En raison de l'absence d'exécution de JavaScript sur les moteurs de recherche de certains moteurs de recherche Web populaires, SEO (Search engine optimization) a toujours posé problème aux sites Web publics souhaitant adopter le modèle SPA 8
  14. 14. En raison de l'absence d'exécution de JavaScript sur les moteurs de recherche de certains moteurs de recherche Web populaires, [20] SEO (Search engine optimization) a toujours posé problème aux sites Web publics souhaitant adopter le modèle SPA [21]. Entre 2009 et 2015, Google Webmaster Central a proposé puis recommandé un "schéma d'analyse AJAX" [22] [23] utilisant un point d'exclamation initial dans les identificateurs de fragment pour les pages AJAX avec état (#!). Un comportement spécial doit être implémenté par le site SPA pour permettre l'extraction des métadonnées pertinentes par le robot du moteur de recherche. Pour les moteurs de recherche qui ne prennent pas en charge ce schéma de hachage d'URL, les URL hachées du SPA restent invisibles. Ces URI "hash-bang" ont été considérés comme problématiques par un certain nombre d'auteurs, y compris Jeni Tennison au W3C, car ils rendent les pages inaccessibles à ceux qui n'ont pas JavaScript activé dans leur navigateur. Ils rompent également les en-têtes de référence HTTP, car les navigateurs ne sont pas autorisés à envoyer l'identificateur de fragment dans l'en-tête Referer. [24] En 2015, Google a déprécié sa proposition d'analyse de hash-bang AJAX. [25] Les applications peuvent également rendre la première page chargée sur le serveur et les mises à jour de pages ultérieures sur le client. Cela est traditionnellement difficile, car le code de rendu peut devoir être écrit dans un autre langage ou une autre structure sur le serveur et dans le client. L'utilisation de modèles sans logique, la compilation croisée d'une langue à une autre ou l'utilisation du même langage sur le serveur et le client peuvent aider à augmenter la quantité de code pouvant être partagée. Comme la compatibilité SEO n'est pas triviale dans les SPA, il convient de noter que les SPA ne sont généralement pas utilisés dans un contexte où l'indexation par moteur de recherche est une exigence ou souhaitable. Les cas d'utilisation incluent des applications qui recouvrent des données privées cachées derrière un système d'authentification. Dans les cas où ces applications sont des produits grand public, un modèle classique de «redessinage» est souvent utilisé pour la page de destination et le site marketing des applications, qui fournit suffisamment de métadonnées pour que l'application apparaisse comme une requête dans un moteur de recherche. Les blogs, les forums de support et autres artefacts traditionnels de redécalage de pages sont souvent placés autour du SPA, ce qui peut générer des termes pertinents pour les moteurs de recherche. Une autre approche utilisée par les frameworks Web centrés sur le serveur, comme ItsNat basé sur Java, consiste à rendre tout hypertexte sur le serveur en utilisant le même langage et la même technologie de template. Dans cette 8
  15. 15. approche, le serveur connaît avec précision l’état du DOM sur le client, toute mise à jour de petite ou grande page requise est générée sur le serveur et transportée par Ajax, le code JavaScript exact pour amener la page client au nouvel état . Les développeurs peuvent décider quels états de page doivent être explorés par les spiders pour le référencement et être en mesure de générer l'état requis au moment du chargement en générant du code HTML au lieu de JavaScript. Dans le cas du framework ItsNat, cela est automatique car ItsNat conserve l’arborescence DOM du client sur le serveur en tant qu’arborescence DOM W3C Java; le rendu de cet arbre DOM sur le serveur génère du code HTML simple au moment du chargement et des actions DOM JavaScript pour les requêtes Ajax. Cette dualité est très importante pour le référencement car les développeurs peuvent construire avec le même code Java et le même modèle basé sur HTML que l’état DOM souhaité sur le serveur; Au moment du chargement de la page, le code HTML classique est généré par ItsNat, ce qui rend cet état compatible avec le référencement. A partir de la version 1.3, [26] ItsNat fournit un nouveau mode sans état, et le DOM client n'est pas conservé sur le serveur car, avec le client en mode sans état, l'état du DOM est partiellement ou totalement reconstruit lors du traitement de toute requête Ajax basée sur données requises envoyées par le client informant le serveur de l'état DOM actuel; Le mode sans état peut également être compatible avec le SEO car la compatibilité SEO se produit au moment du chargement de la page initiale, sans être affecté par les modes avec ou sans état. Il existe plusieurs solutions pour donner l'impression que le site Web est explorable. Les deux impliquent la création de pages HTML distinctes qui reflètent le contenu du SPA. Le serveur peut créer une version HTML du site et la distribuer aux robots d'exploration, ou utiliser un navigateur sans tête tel que PhantomJS pour exécuter l'application JavaScript et générer le code HTML résultant. Les deux nécessitent beaucoup d'efforts et peuvent finir par causer des problèmes de maintenance pour les grands sites complexes. Il existe également des pièges potentiels en matière de référencement. Si le code HTML généré par le serveur est jugé trop différent du contenu du SPA, le site sera pénalisé. L'exécution de PhantomJS pour générer le HTML peut ralentir la vitesse de réponse des pages, ce qui est un facteur pour lequel les moteurs de recherche - en particulier Google - abaissent le classement. [27] Client/Server code partitioning Une manière d'augmenter la quantité de code pouvant être partagée entre les serveurs et les clients consiste à utiliser un langage de modèle sans logique comme Moustache ou Handlebars. De tels modèles peuvent être rendus à partir de 8
  16. 16. différents langages hôtes, tels que Ruby sur le serveur et JavaScript dans le client. Cependant, le simple partage de modèles nécessite généralement la duplication de la logique métier utilisée pour choisir les modèles corrects et les remplir avec des données. Le rendu à partir de modèles peut avoir des effets négatifs sur les performances lors de la mise à jour d'une petite partie seulement de la page, par exemple la valeur d'une entrée de texte dans un grand modèle. Remplacer un modèle entier peut également perturber la sélection d'un utilisateur ou la position du curseur, alors que la mise à jour de la seule valeur modifiée peut ne pas l'être. Pour éviter ces problèmes, les applications peuvent utiliser des liaisons de données d'interface utilisateur ou des manipulations granulaires pour mettre à jour uniquement les parties appropriées de la page au lieu de restituer des modèles entiers. Historique du navigateur Avec un SPA étant, par définition, "une seule page", le modèle rompt la conception du navigateur pour la navigation dans l'historique des pages à l'aide des boutons Avant / Arrière. Cela pose un problème de convivialité lorsqu'un utilisateur appuie sur le bouton Précédent, en attendant l'état d'écran précédent dans le SPA, mais à la place, la page unique de l'application se décharge et la page précédente de l'historique du navigateur est présentée. La solution traditionnelle pour les SPA était de changer l'identifiant du fragment de hachage de l'URL du navigateur en fonction de l'état de l'écran actuel. Cela peut être réalisé avec JavaScript et permet de créer des événements d’historique d’URL dans le navigateur. Tant que le SPA est capable de ressusciter le même état d'écran à partir des informations contenues dans le hachage d'URL, le comportement attendu du bouton arrière est conservé. Le hachage peut également être utilisé pour les applications à une seule page. Au lieu de l'utiliser pour naviguer jusqu'à un point d'une page, vous utilisez le hachage comme moyen de naviguer d'une page à l'autre. L'avantage de ceci est qu'il ne nécessite pas d'actualisation de la page. Il existe également une méthode appelée hashbanging utilisée pour les applications à une seule page et utilisée pour aider les applications ajax à être plus indexables. Il y a quelques bons articles sur le sujet 8
  17. 17. https://github.com/browserstate/history.js/wiki/Intelligent-State-Handling http://danwebb.net/2011/5/28/it-is-about-the-hashbangs https://developers.google.com/webmasters/ajax-crawling/ Pour répondre à ce problème, la spécification HTML5 a introduit pushState et replaceState, fournissant un accès par programmation à l’URL et à l’historique du navigateur. Analytique Les outils d'analyse tels que Google Analytics s'appuient fortement sur le chargement de nouvelles pages entières dans le navigateur, initié par un nouveau chargement de page. Les SPA ne fonctionnent pas de cette façon. Après le chargement de la première page, toutes les modifications de page et de contenu ultérieures sont traitées en interne par l'application, qui doit simplement appeler une fonction pour mettre à jour le package d'analyse. Faute d'appeler cette fonction, le navigateur ne déclenche jamais un nouveau chargement de la page, rien ne s'ajoute à l'historique du navigateur et le module d'analyse n'a aucune idée de qui fait quoi sur le site. Ajout de chargements de page à un SPA Il est possible d'ajouter des événements de chargement de page à un SPA à l'aide de l'API HTML5 History; Cela aidera à intégrer les analyses. La difficulté réside dans la gestion de ce problème et dans la garantie d'un suivi précis de tous les éléments, ce qui implique de rechercher les rapports manquants et les doubles entrées. Certains frameworks fournissent des intégrations d'analyse open source s'adressant à la plupart des principaux fournisseurs d'analyses. Les développeurs peuvent les intégrer dans l'application et s'assurer que tout fonctionne correctement, mais il n'est pas nécessaire de tout faire à partir de zéro. Vitesse de charge initiale Les applications à une seule page sont moins chargées que les applications basées sur un serveur. Cela est dû au fait que le premier chargement doit mettre à jour l’infrastructure et le code de l’application avant de rendre la vue requise au format HTML dans le navigateur. Une application basée sur un serveur doit simplement transférer le code HTML requis vers le navigateur, réduisant ainsi la latence et le temps de téléchargement. 8
  18. 18. Accélérer le chargement de la page Il existe des moyens d'accélérer le chargement initial d'un SPA, par exemple une approche lourde de la mise en cache et des modules de chargement différé en cas de besoin. Mais il n'est pas possible de s'éloigner du fait qu'il a besoin de télécharger la structure, au moins une partie du code de l'application, et va probablement toucher une API pour les données avant d'afficher quelque chose dans le navigateur. Ceci est un scénario de compromis "payez-moi maintenant ou payez- moi plus tard". La question de la performance et des temps d’attente reste une décision que le développeur doit prendre. 8
  19. 19. En résumé … Avant les SPA, il y avait quoi? • Il s’agissait de MPA (multipage application) • Un client demandait l’accès à une page web • Le serveur lui envoyait le contenu de la page • Les informations nécessaires et disponibles à l’utilisateur étaient envoyées dans le contenu de la page • Très peu de réutilisation de code • MVC (Model – View – Controller) • Possibilité d’utiliser des Frameworks • Symfony • ASP.Net • Etc. 9 https://arxiv.org/abs/cs/0610094 9
  20. 20. En résumé … Avec SPA, c’est quoi? • SPA pour Single Page Application • Une application web qui réécrit dynamiquement la page plutôt que de charger une nouvelle page à chaque fois. Tout le code (HTML, JavaScript et CSS) est reçu au premier chargement. • Le visuel est téléchargé qu’une seule fois • Attention, on ne parle pas de toute l’application, seulement du visuel • L’application est essentiellement faite en JavaScript côté client • Plusieurs Framework aident au développement et utilisent le principe du SPA • Angular, React, Vue.js, etc. • Utilisation d’une API pour la récupération des données Backend • Code divisé en composants etou modules • Aide à la réutilisation du code 10 Une application web monopage (en anglais single-page application ou SPA) est une application web accessible via une page web unique. Le but est d'éviter le chargement d'une nouvelle page à chaque action demandée, et de fluidifier ainsi l'expérience utilisateur. Deux méthodes existent pour ce faire : l'ensemble des éléments de l'application est chargé (contenu, images, CSS et JavaScript) dans un unique fichier HTML, soit les ressources nécessaires sont récupérées et affichées dynamiquement en fonction des actions de l'utilisateur. Le terme a été introduit par Steve Yen en 2005. L'enregistrement en local de la page définissant une application web monopage et la possibilité de continuer à l'exécuter en local est l'une des propriétés importantes des applications web monopage qui les distingue des applications web standards qui reposent sur l'existence d'un serveur HTTP avec lequel elles échangent données, continuations applicatives et interfaces. Quand les applications web monopages gèrent des données et permettent de les modifier, pour conserver ces données modifiées, il est nécessaire que ces applications modifient leur code, c'est-à-dire : elles doivent être capable de se modifier pour que la sauvegarde locale de l'état modifié de l'application (dont les données) soit persistant. 10
  21. 21. TiddlyWiki est un exemple d'application web monopage. Technical approaches There are various techniques available that enable the browser to retain a single page even when the application requires server communication. JavaScript frameworks Web browser JavaScript frameworks, such as AngularJS, Ember.js, Knockout.js, Meteor.js, ExtJS, Vue.js and React have adopted SPA principles. AngularJS is a fully client-side framework. AngularJS's templating is based on bidirectional UI data binding. Data-binding is an automatic way of updating the view whenever the model changes, as well as updating the model whenever the view changes. The HTML template is compiled in the browser. The compilation step creates pure HTML, which the browser re-renders into the live view. The step is repeated for subsequent page views. In traditional server-side HTML programming, concepts such as controller and model interact within a server process to produce new HTML views. In the AngularJS framework, the controller and model states are maintained within the client browser. Therefore, new pages are capable of being generated without any interaction with a server. Ember.js is a client-side JavaScript web application framework based on the model- view-controller (MVC) software architectural pattern. It allows developers to create scalable single-page applications by incorporating common idioms and best practices into a framework that provides a rich object model, declarative two-way data binding, computed properties, automatically-updating templates powered by Handlebars.js, and a router for managing application state. ExtJS is also a client side framework that allows creating MVC applications. It has its own event system, window and layout management, state management (stores) and various UI components (grids, dialog windows, form elements etc.). It has its own class system with either dynamic or static loader. The application built with ExtJS can either exist on its own (with state in the browser) or with the server (e.g. with REST API that is used to fill its internal stores). ExtJS has only built in capabilities to use localStorage so larger applications need a server to store state. Knockout.js is a client side framework which uses templates based on the Model- View-ViewModel pattern. Meteor.js is a full-stack (client-server) JavaScript framework designed exclusively for SPAs. It features simpler data binding than Angular, Ember or ReactJS,[6] and uses the Distributed Data Protocol[7] and a publish–subscribe pattern to automatically propagate data changes to clients in real-time without requiring the developer to write any synchronization code. Full stack reactivity ensures that all layers, from the database to the templates, update themselves automatically when necessary. Ecosystem packages such as Server Side Rendering[8] address the problem of Search Engine Optimization. 10
  22. 22. Aurelia is a JavaScript client framework for mobile, desktop and web. It is similar to AngularJS, but is newer, more standards-compliant, and utilizes a modular approach. Aurelia was written with next-generation ECMAScript.[citation needed] Vue.js (commonly referred to as Vue; pronounced /vjuː/, like view) is an open-source progressive JavaScript framework for building user interfaces. Vue developers also provide Vuex for state management. React (sometimes styled React.js or ReactJS) is a JavaScript library for building user interfaces. It is maintained by Facebook, Instagram and a community of individual developers and corporations. React uses a new language which is a mix of JS and HTML (a subset of HTML). Several companies use React with Redux (JavaScript library) which adds state management capabilities, which (with several other libraries) lets developers create complex applications.[9] Fulcro is a full-stack library that adopts data-driven principles from Netflix's Falcor, Facebook's Relay, and Om Next's adaptations of reactive, functional, data-driven software. It leverages React underneath for raw rendering, gaining all of the advantages of that platform, but provides a clear full-stack model similar to Redux, but using immutable data to gain the advantages of functional programming. It has a pluggable architecture that makes it possible to seamlessly integrate any back-end resources, and has the distinction of providing a support viewer technology that allows developers to debug against the real UI state history of an in-the-field client's session. Websockets are supported as an option and allow one to create the advanced behaviors of Meteor.js with very little code.[10][better source needed] Ajax The most prominent technique currently being used is Ajax.[1] Predominantly using the XMLHttpRequest/ActiveX Object(deprecated) object from JavaScript, other Ajax approaches include using IFRAME or script HTML elements. Popular libraries like jQuery, which normalize Ajax behavior across browsers from different manufacturers, have further popularized the Ajax technique. Websockets WebSockets are a bidirectional stateful real-time client-server communication technology part of the HTML5 specification, superior to Ajax in terms of performance[11] and simplicity. Server-sent events Server-sent events (SSEs) is a technique whereby servers can initiate data transmission to browser clients. Once an initial connection has been established, an event stream remains open until closed by the client. SSEs are sent over traditional HTTP and have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.[12] Browser plugins Although this method is outdated, asynchronous calls to the server may also be achieved using browser plug-in technologies such as Silverlight, Flash, or Java applets. Data transport (XML, JSON and Ajax) 10
  23. 23. Requests to the server typically result in either raw data (e.g., XML or JSON), or new HTML being returned. In the case where HTML is returned by the server, JavaScript on the client updates a partial area of the DOM (Document Object Model).[13] When raw data is returned, often a client-side JavaScript XML / (XSL) process (and in the case of JSON a template) is used to translate the raw data into HTML, which is then used to update a partial area of the DOM. 10
  24. 24. https://da-14.com/blog/5-best-javascript-frameworks-2017 https://mmikowski.github.io/no-frameworks/ Frameworks and complexity === insanely long cycle times Top 9 JavaScript frameworks list Angular.js 2 Generally, Angular.js it is one of the most beloved and used JavaScript frameworks for building single page applications. It is available as an open source solution and is supported by Google. The latter is a convincing argument in favor of Angular to become a front-end solution for a web app. Angular JS is highly preferred for hybrid mobile application development. Featured with components like overlays, sidebars, switches and absolute positioned navigation bars, this framework incorporates dynamic functionality to the application. Backbone.js 11
  25. 25. Backbone is amongst some of the most popular web development frameworks for JavaScript developers, and partly for two reasons — it’s easy to understand usability modules, as well as the very straightforward learning curve. Backbone creates single- page applications using the most traditional web development libraries. It is built with the idea in mind that all server-side functions should flow through an API, minimizing the amount of code that needs to be composed in order to achieve the same complex functionality of more sophisticated web frameworks. React.js React.js was created by the team of Facebook developers and came out in 2013. Being pretty new in comparison with other JavaScript frameworks it confidently wins its niche. If you like the user interface of Facebook and Instagram then you might like React.js too. This very framework is behind the front-end scenes of the two social giants. There are other companies that benefit from using it: Atlassian, BBC, Coursera, Dropbox, Flipboard, Netflix, Paypal, WhatsApp. Embre.js Introduced in 2011 this open-source JavaScript framework was declared as the best JavaScript framework for web application development in 2015. Its closest competitors are Angular and React. Ember could be a good solution for a startup or for a business looking to build complex web apps. It has a huge online community, regular updates and wide application of JavaScript that is meant to offer an engaging user experience. The framework is widely accepted for creating feature-rich web applications. The most common websites that have been designed using the framework are LinkedIn, Kickstarter, Blue Apron, and many others. Aurelia.js Being a self-proclaimed web development framework, Aurelia makes the process of site development a creative process. Designed with the latest JS standard, ES6, Aurelia has the ability to function on all modern browsers. Designed on a module-like framework, Aurelia has various small and huge libraries that can be used either in combination or individually, depending upon the kind of application being designed. 11
  26. 26. Meteor.js With a variety of features for backend, frontend development and database management, Meteor rank as the most popular JavaScript frameworks. Since its inception in the year 2012, this framework has grown in terms of performance, UI design and so on. MeteorJS covers all the phases of software development cycle and takes care of such glooming processes as linking, files concatenation and others. It is of current usage in real-time application development for business companies like Mazda, IKEA, Honeywell and many others. Vue.js Introduced back in 2016, Vue has a learning curve that is easier . The framework delivers two-way data binding, server-side rendering, Vue-CLI and optional JSX support. It is one the fastest emerging frameworks till date and is a preferable choice for quick cross-platform solutions. Polymer Polymer is another JavaScript framework from Google. With its material web design and modern outlook, Polymer is one stupefying JavaScript framework that comes with the ability to create and reuse web components. It is featured with Polymer App Toolbox that allows you to create and deliver cutting-edge progressive web applications. The framework is fully interoperable, built for speed and offers support on all modern day browsers. Socket Socket’s gained a lots of momentum in the real-time developer community. With Socket you can enjoy a fully functional real-time communication between the client and the server. Socket is divided into two different parts — the first part is a client- library that runs from the browser, whereas the server-library is built on top of 11
  27. 27. Node.js. Both libraries share a very similar API, and Socket is also event driven; much like Node.js is. With Socket you can implement real-time streaming of binary, instant messaging platforms, interactive document collaboration, real-time stats for your apps and projects (analytics), and so much more. Remember that the process of choosing a framework depends not only on its functionality but also how it can be used within your own project. 11
  28. 28. https://da-14.com/blog/5-best-javascript-frameworks-2017 https://mmikowski.github.io/no-frameworks/ Frameworks and complexity === insanely long cycle times Top 9 JavaScript frameworks list Angular.js 2 Generally, Angular.js it is one of the most beloved and used JavaScript frameworks for building single page applications. It is available as an open source solution and is supported by Google. The latter is a convincing argument in favor of Angular to become a front-end solution for a web app. Angular JS is highly preferred for hybrid mobile application development. Featured with components like overlays, sidebars, switches and absolute positioned navigation bars, this framework incorporates dynamic functionality to the application. Backbone.js 12
  29. 29. Backbone is amongst some of the most popular web development frameworks for JavaScript developers, and partly for two reasons — it’s easy to understand usability modules, as well as the very straightforward learning curve. Backbone creates single- page applications using the most traditional web development libraries. It is built with the idea in mind that all server-side functions should flow through an API, minimizing the amount of code that needs to be composed in order to achieve the same complex functionality of more sophisticated web frameworks. React.js React.js was created by the team of Facebook developers and came out in 2013. Being pretty new in comparison with other JavaScript frameworks it confidently wins its niche. If you like the user interface of Facebook and Instagram then you might like React.js too. This very framework is behind the front-end scenes of the two social giants. There are other companies that benefit from using it: Atlassian, BBC, Coursera, Dropbox, Flipboard, Netflix, Paypal, WhatsApp. Embre.js Introduced in 2011 this open-source JavaScript framework was declared as the best JavaScript framework for web application development in 2015. Its closest competitors are Angular and React. Ember could be a good solution for a startup or for a business looking to build complex web apps. It has a huge online community, regular updates and wide application of JavaScript that is meant to offer an engaging user experience. The framework is widely accepted for creating feature-rich web applications. The most common websites that have been designed using the framework are LinkedIn, Kickstarter, Blue Apron, and many others. Aurelia.js Being a self-proclaimed web development framework, Aurelia makes the process of site development a creative process. Designed with the latest JS standard, ES6, Aurelia has the ability to function on all modern browsers. Designed on a module-like framework, Aurelia has various small and huge libraries that can be used either in combination or individually, depending upon the kind of application being designed. 12
  30. 30. Meteor.js With a variety of features for backend, frontend development and database management, Meteor rank as the most popular JavaScript frameworks. Since its inception in the year 2012, this framework has grown in terms of performance, UI design and so on. MeteorJS covers all the phases of software development cycle and takes care of such glooming processes as linking, files concatenation and others. It is of current usage in real-time application development for business companies like Mazda, IKEA, Honeywell and many others. Vue.js Introduced back in 2016, Vue has a learning curve that is easier . The framework delivers two-way data binding, server-side rendering, Vue-CLI and optional JSX support. It is one the fastest emerging frameworks till date and is a preferable choice for quick cross-platform solutions. Polymer Polymer is another JavaScript framework from Google. With its material web design and modern outlook, Polymer is one stupefying JavaScript framework that comes with the ability to create and reuse web components. It is featured with Polymer App Toolbox that allows you to create and deliver cutting-edge progressive web applications. The framework is fully interoperable, built for speed and offers support on all modern day browsers. Socket Socket’s gained a lots of momentum in the real-time developer community. With Socket you can enjoy a fully functional real-time communication between the client and the server. Socket is divided into two different parts — the first part is a client- library that runs from the browser, whereas the server-library is built on top of 12
  31. 31. Node.js. Both libraries share a very similar API, and Socket is also event driven; much like Node.js is. With Socket you can implement real-time streaming of binary, instant messaging platforms, interactive document collaboration, real-time stats for your apps and projects (analytics), and so much more. Remember that the process of choosing a framework depends not only on its functionality but also how it can be used within your own project. 12
  32. 32. avantage non exhaustif … Pour les développeurs • Meilleure réutilisation du code à l’aide de composantes/modules • Le développement est donc simplifier • Serveur sollicité moins souvent pour l’affichage de l’application • Utilisation d’une API pour l’échange d’information réduisant le contenu de l’information envoyée et possibilité de réutilisation sur d’autres applications Pour le client • Accès à la page plus rapide une fois l’application chargée en mémoire • Moins d’information à échanger entre le client et le serveur à chaque appel • Offre la possibilité de sauvegarder l’application pour un accès hors ligne • https://angular-university.io/ 13 https://medium.com/@NeotericEU/single-page-application-vs-multiple-page- application-2591588efe58 pros of the Single-Page Application: SPA is fast, as most resources (HTML+CSS+Scripts) are only loaded once throughout the lifespan of application. Only data is transmitted back and forth. The development is simplified and streamlined. There is no need to write code to render pages on the server. It is much easier to get started because you can usually kick off development from a file file://URI, without using any server at all. SPAs are easy to debug with Chrome, as you can monitor network operations, investigate page elements and data associated with it. It’s easier to make a mobile application because the developer can reuse the same backend code for web application and native mobile application. SPA can cache any local storage effectively. An application sends only one request, store all data, then it can use this data and works even offline. 13
  33. 33. https://blog.angular-university.io/why-a-single-page-application-what-are-the- benefits-what-is-a-spa/ https://www.scalablepath.com/blog/single-page-applications/ https://putaindecode.io/fr/articles/js/webpack/ https://en.wikipedia.org/wiki/Webpack 13
  34. 34. https://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_1_of _2 https://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_2_of _2 https://blog.malwarebytes.com/threat-analysis/2013/03/obfuscation-malwares-best- friend/ https://blogs.cisco.com/security/on_information_entropy https://blogs.cisco.com/security/real-world-dns-abuse-finding-common-ground 14
  35. 35. var _0x98fd = ["x2Ex6Fx76x65x72x6Cx61x70x62x6Cx61x63x6Bx62x67x2Cx20x2Ex73x6Cx69x64x65x4Cx65 x66x74", "x2Ex77x73x6Dx65x6Ex75x63x6Fx6Ex74x65x6Ex74", "x6Dx65x6Ex75x6Fx70x65x6E", "x61x64x64x43x6Cx61x73x73", "x6Dx65x6Ex75x63x6Cx6Fx73x65", "x72x65x6Dx6Fx76x65x43x6Cx61x73x73","x68x61x73x43x6Cx61x73x73", "x63x6Cx69x63x6B", "x23x6Ex61x76x54x6Fx67x67x6Cx65", "x6Dx72x67x69x6Ex6Cx65x66x74", "x74x6Fx67x67x6Cx65x43x6Cx61x73x73", "x2Ex77x73x6Dx65x6Ex75x63x6Fx6Ex74x61x69x6Ex65x72", "x6Fx6E", "x23x6Ex61x76x54x6Fx67x67x6Cx65x2Cx2Ex6Fx76x65x72x6Cx61x70x62x6Cx61x63x6Bx62x 67", "x3Cx73x70x61x6Ex20x63x6Cx61x73x73x3Dx22x77x73x6Dx65x6Ex75x2Dx63x6Cx69x63x6B x22x3Ex3Cx69x20x63x6Cx61x73x73x3Dx22x77x73x6Dx65x6Ex75x2Dx61x72x72x6Fx77x20x6 6x61x20x66x61x2Dx61x6Ex67x6Cx65x2Dx64x6Fx77x6Ex22x3Ex3Cx2Fx69x3Ex3Cx2Fx73x70x 61x6Ex3E", "x70x72x65x70x65x6Ex64", "x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75x2Cx20x2Ex77x73x6Dx65x6Ex75x2D x73x75x62x6Dx65x6Ex75x2Dx73x75x62x2Cx20x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx6 5x6Ex75x2Dx73x75x62x2Dx73x75x62", "x68x61x73", "x2Ex77x73x6Dx65x6Ex75x2Dx6Cx69x73x74x20x6Cx69", "x2Ex6Dx65x67x61x6Dx65x6Ex75", "x73x6Cx6Fx77", "x73x6Cx69x64x65x54x6Fx67x67x6Cx65", "x2Ex77x73x6Dx65x6Ex75x2Dx6Cx69x73x74", "x2Ex77x73x6Dx65x6Ex75x2Dx6Dx6Fx62x69x6Cx65", "x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75", "x73x69x62x6Cx69x6Ex67x73", "x77x73x6Dx65x6Ex75x2Dx72x6Fx74x61x74x65", "x2Ex77x73x6Dx65x6Ex75x2Dx61x72x72x6Fx77", "x63x68x69x6Cx64x72x65x6E", "x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75x2Dx73x75x62", "x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75x2Dx73x75x62x2Dx73x75x62", "x2Ex77x73x6Dx65x6Ex75x2Dx63x6Cx69x63x6B"]; 15
  36. 36. $(function() { var _0x5c8dx1 = $(_0x98fd[0]); var _0x5c8dx2 = $(_0x98fd[1]); var _0x5c8dx3 = function() { $(_0x5c8dx1)[_0x98fd[5]](_0x98fd[4])[_0x98fd[3]](_0x98fd[2]) }; var _0x5c8dx4 = function() { $(_0x5c8dx1)[_0x98fd[5]](_0x98fd[2])[_0x98fd[3]](_0x98fd[4]) }; $(_0x98fd[8])[_0x98fd[7]](function() { if (_0x5c8dx2[_0x98fd[6]](_0x98fd[2])) { $(_0x5c8dx4) } else { $(_0x5c8dx3) } }); _0x5c8dx2[_0x98fd[7]](function() { if (_0x5c8dx2[_0x98fd[6]](_0x98fd[2])) { $(_0x5c8dx4) } }); $(_0x98fd[13])[_0x98fd[12]](_0x98fd[7], function() { $(_0x98fd[11])[_0x98fd[10]](_0x98fd[9]) }); $(_0x98fd[18])[_0x98fd[17]](_0x98fd[16])[_0x98fd[15]](_0x98fd[14]); $(_0x98fd[18])[_0x98fd[17]](_0x98fd[19])[_0x98fd[15]](_0x98fd[14]); $(_0x98fd[23])[_0x98fd[7]](function() { $(_0x98fd[22])[_0x98fd[21]](_0x98fd[20]) }); $(_0x98fd[31])[_0x98fd[7]](function() { $(this)[_0x98fd[25]](_0x98fd[24])[_0x98fd[21]](_0x98fd[20]); $(this)[_0x98fd[28]](_0x98fd[27])[_0x98fd[10]](_0x98fd[26]); $(this)[_0x98fd[25]](_0x98fd[29])[_0x98fd[21]](_0x98fd[20]); $(this)[_0x98fd[25]](_0x98fd[30])[_0x98fd[21]](_0x98fd[20]); $(this)[_0x98fd[25]](_0x98fd[19])[_0x98fd[21]](_0x98fd[20]); }); }); 16
  37. 37. See also a few tutorials on analyzing obfuscated JavaScript: Analyzing Malicious JavaScript by Dejan Lukan. https://resources.infosecinstitute.com/analyzing-javascript/ Advanced obfuscated JavaScript analysis by Daniel Wesemann. https://isc.sans.edu/diary/Advanced+obfuscated+JavaScript+analysis/4246 JavaScript Obfuscation on InfoSec Handlers Diary Blog. https://isc.sans.edu/tag.html?tag=javascript&tag=obfuscation JavaScript Obfuscation - Manual Armor (part 1, part 2) by Aditya K Sood. https://secniche.blogspot.com/2012/04/javascript-obfuscation-manual-armor-1.html https://secniche.blogspot.com/2012/04/javascript-obfuscation-manual-armor-2.html JSDetox Malzilla JavaScript Deobfuscator ExtractScript JS-Beautifier JS-Unpack (see also blog) Rhino Debugger Firebug SpiderMonkey V8 JSNice PoisonJS There are a few tools that you might try when wanting to analyze JavaScript: Exemple Code with Js fiddle and/or Jsbin https://stackoverflow.com/questions/30194953/how-to-decode-this-hex-code- javascript References: [1] JSDetox, http://www.relentless-coding.com/projects/jsdetox/. [2] Detection and Analysis of Drive-by-Download Attacks and Malicious JavaScript Code, http://cs.ucsb.edu/~vigna/publications/2010_cova_kruegel_vigna_Wepawet.pdf. [3] Deobfuscating malicious code layer by layer, http://www.pandasecurity.com/mediacenter/malware/deobfuscating-malicious- code-layer-by-layer/. [4] https://reverseengineering.stackexchange.com/questions/tagged/javascript+deobfus cation https://reverseengineering.stackexchange.com/questions/tagged/javascript+deobfus cation 17
  38. 38. https://reverseengineering.stackexchange.com/questions/18977/is-deobfuscation- of-my-javascript-code-hard-or-easy https://beautifier.io/ https://github.com/denis-ivanov/Jsbeautifier en c# Advanced JavaScript Deobfuscation via Partial Evaluation https://github.com/mindedsecurity/JStillery https://mindedsecurity.github.io/jstillery/# https://github.com/lelinhtinh https://github.com/lelinhtinh/de4js JavaScript Deobfuscator and Unpacker https://lelinhtinh.github.io/de4js/ https://www.dcode.fr/desobfuscateur-javascript http://jsnice.org/ http://nice2predict.org/ https://github.com/eth-sri/Nice2Predict https://github.com/eth-sri/UnuglifyJS https://w3guy.com/online-javascript-code-beautifier/ https://reverseengineering.stackexchange.com/questions/4561/how-to-deobfuscate- an-obfuscated-javascript-file-like-this There are a few tools that you might try when wanting to analyze JavaScript: JSDetox Malzilla JavaScript Deobfuscator ExtractScript JS-Beautifier JS-Unpack (see also blog) Rhino Debugger Firebug SpiderMonkey V8 17
  39. 39. JSNice PoisonJS See also a few tutorials on analyzing obfuscated JavaScript: Analyzing Malicious JavaScript by Dejan Lukan. https://resources.infosecinstitute.com/analyzing-javascript/ Advanced obfuscated JavaScript analysis by Daniel Wesemann. https://isc.sans.edu/diary/Advanced+obfuscated+JavaScript+analysis/4246 JavaScript Obfuscation on InfoSec Handlers Diary Blog. https://isc.sans.edu/tag.html?tag=javascript&tag=obfuscation JavaScript Obfuscation - Manual Armor (part 1, part 2) by Aditya K Sood. https://secniche.blogspot.com/2012/04/javascript- obfuscation-manual-armor-1.html https://secniche.blogspot.com/2012/04/javascript-obfuscation- manual-armor-2.html And, finally, a few questions that have been already answered here: Analyze obfuscated JavaScript code? Analyzing highly obfuscated JavaScript Try to deobfuscate multi layered javascript What is a good tools to reverse the effects of Minify on JavaScript? Or, more generally, search for the javascript and deobfuscation tags (link to the search). http://dean.edwards.name/packer/ https://github.com/mishoo https://github.com/mishoo/UglifyJS https://github.com/mishoo/UglifyJS2 http://lisperator.net/uglifyjs/ 17
  40. 40. https://obfuscator.io/ https://github.com/javascript-obfuscator 17
  41. 41. DÉMO (Wouahhh Malade …) https://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks https://en.wikipedia.org/wiki/List_of_JavaScript_libraries http://jster.net/ Web-application related (MVC, MVVM) The Ultimate Guide to JavaScript Frameworks https://javascriptreport.com/the-ultimate-guide-to-javascript-frameworks/ https://fr.wikipedia.org/wiki/Compilateur_source_%C3%A0_source Un compilateur source à source, transpileur ou transcompilateur est un type de compilateur qui prend le code source d'un langage de programmation et le compile dans un autre langage de programmation. Un compilateur source-à-source opère sur deux langages avec approximativement le même niveau d'abstraction, alors qu'un compilateur traditionnel compile un langage de haut niveau vers un langage de bas niveau. https://en.wikipedia.org/wiki/Source-to-source_compiler 18
  42. 42. List of languages that compile to JS https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS 18
  43. 43. L'envers de la médaille . . . La divulgation d’information sensible • Accès à des URL (Endpoint) • Augmente terriblement la surface d’attaque • Retrouver des mots de passe en clair • Retrouver des clés secrètes • Comme des informations d’identification à différents services • Accès aux messages d’erreur 19 19
  44. 44. L'envers de la médaille . . . 20 20
  45. 45. 21 Capture écran prise le 12-09-2018 à 10h47 21
  46. 46. . . . l'envers de la médaille Les fichiers map, ça vous dit quelque chose? • Aident à déboguer des scripts minifiés • Code minifié ne veut pas dire illisible • Le navigateur doit tout de même être capable de l’interpréter • Permettent de récupérer le code source original • Parfois oubliés en production et accessibles sans être authentifiés • Permettent d’exécuter l’application localement • Possibilité de trouver des failles de sécurité • Accès à certains fichiers non minifiés 22 https://www.thecssninja.com/javascript/source-mapping https://developer.mozilla.org/fr/docs/Outils/D%C3%A9bogueur/Comment/Utiliser_u ne_source_map https://stackoverflow.com/questions/27345520/source-maps-files-in-production-is- it-safe# https://github.com/mozilla/source-map https://developers.google.com/web/tools/chrome-devtools/javascript/source-maps 22
  47. 47. . . . l'envers de la médaille 23 https://en.wikipedia.org/wiki/Webpack You need to use a minifier that's capable of creating source maps. For the most popular options, see our preprocessor support section. For an extended view, see the Source maps: languages, tools and other info wiki page. The following types of preprocessors are commonly used in combination with Source Maps: Transpilers (Babel, Traceur) Compilers (Closure Compiler, TypeScript, CoffeeScript, Dart) Minifiers (UglifyJS) 23
  48. 48. . . . l'envers de la médaille Autres problèmes du SPA • Logique de l’application incluse dans le JavaScript téléchargé • Téléchargement de toute l’application et non du visuel nécessaire • Peut créer des fichiers très volumineux (ex : 2,70 Mo) • Ralentir l’ordinateur du client • Ralentir le serveur si l’application est utilisée par plusieurs personnes • Premier chargement très long 24 24
  49. 49. Comment y remédier • Ne retourner que les informations nécessaires à l’affichage de l’application • Utiliser un modèle MVC pour isoler la logique de l’application • Différencier les environnements de développement et de production • Minifier et « obfusquer » le code avant la mise en production • Ne pas rendre le code original accessible • S’assurer de retirer les commentaires du code en production • Désactiver les SourceMap • Faire une vérification de ce qui est accessible à partir du code 25 25
  50. 50. Comment y remédier • OpenID Connect Relying Party and OAuth 2.0 Resource Server for Apache HTTP Server 2.x https://github.com/zmartzone/mod_auth_openidc/wiki/Single-Page- Applications • La super présentation OWASP sur l’OIDC et l’OAUTH2 https://www.slideshare.net/MarcAndrTousignant/introduction-oauth-20-et- openid-connect-10-102478531 • Faire preuve de recul lors des choix pour la gestion des identités et des mécanismes utilisés et faire un WebApi détaché totalement l’identification afin de ne gérer que les autorisations (AuthN # AuthZ) 26 26
  51. 51. Comment y remédier • OWASP Security Knowledge Framework The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework#t ab=Main • XSS (Cross Site Scripting) Prevention Cheat Sheet XSS Prevention Framework Cheat Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Ch eat_Sheet • https://www.owasp.org/index.php/XSS_Prevention_Framework_Cheat_Sheet 27 27
  52. 52. Comment y remédier 28 28
  53. 53. Ce qu’il faut retenir • Les anciennes méthodes de développement avaient de bonnes pratiques en matière de sécurité et il ne faut pas les oublier • Le modèle MVC est encore disponible pour les SPA • Google avec Angular a réintroduit le MVC • Comparer les Frameworks et choisir celui dont vous avez vraiment besoin • Ce n’est pas parce que c’est hotque l’on doit absolument l’utiliser, ce n’est pas nécessairement plus sécuritaire 29 Peut être une façon hybride pour avoir l’avantage des deux mondes, mais cela sera pour une prochaine fois … ;) https://www.slideshare.net/MehmetAliTastan/spa-vs-mpa https://stackoverflow.com/questions/21862054/single-page-application-advantages- and-disadvantages# Let's look at one of the most popular SPA sites, GMail. 1. SPA is extremely good for very responsive sites: Server-side rendering is not as hard as it used to be with simple techniques like keeping a #hash in the URL, or more recently HTML5 pushState. With this approach the exact state of the web app is embedded in the page URL. As in GMail every time you open a mail a special hash tag is added to the URL. If copied and pasted to other browser window can open the exact same mail (provided they can authenticate). This approach maps directly to a more traditional query string, the difference is merely in the execution. With HTML5 pushState() you can eliminate the #hash and use completely classic URLs which can resolve on the server on the first request and then load via ajax on subsequent requests. 2. With SPA we don't need to use extra queries to the server to download pages. The number of pages user downloads during visit to my web site?? really how many 29
  54. 54. mails some reads when he/she opens his/her mail account. I read >50 at one go. now the structure of the mails is almost the same. if you will use a server side rendering scheme the server would then render it on every request(typical case). - security concern - you should/ should not keep separate pages for the admins/login that entirely depends upon the structure of you site take paytm.com for example also making a web site SPA does not mean that you open all the endpoints for all the users I mean I use forms auth with my spa web site. - in the probably most used SPA framework Angular JS the dev can load the entire html temple from the web site so that can be done depending on the users authentication level. pre loading html for all the auth types isn't SPA. 3. May be any other advantages? Don't hear about any else.. these days you can safely assume the client will have javascript enabled browsers. only one entry point of the site. As I mentioned earlier maintenance of state is possible you can have any number of entry points as you want but you should have one for sure. even in an SPA user only see to what he has proper rights. you don't have to inject every thing at once. loading diff html templates and javascript async is also a valid part of SPA. Advantages that I can think of are: rendering html obviously takes some resources now every user visiting you site is doing this. also not only rendering major logics are now done client side instead of server side. date time issues - I just give the client UTC time is a pre set format and don't even care about the time zones I let javascript handle it. this is great advantage to where I had to guess time zones based on location derived from users IP. to me state is more nicely maintained in an SPA because once you have set a variable you know it will be there. this gives a feel of developing an app rather than a web page. this helps a lot typically in making sites like foodpanda, flipkart, amazon. because if you are not using client side state you are using expensive sessions. websites surely are extremely responsive - I'll take an extreme example for this try making a calculator in a non SPA website(I know its weird). Updates from Comments It doesn't seem like anyone mentioned about sockets and long-polling. If you log out from another client say mobile app, then your browser should also log out. If you don't use SPA, you have to re-create the socket connection every time there is a redirect. This should also work with any updates in data like notifications, profile update etc An alternate perspective: Aside from your website, will your project involve a native mobile app? If yes, you are most likely going to be feeding raw data to that native app from a server (ie JSON) and doing client-side processing to render it, correct? So with 29
  55. 55. this assertion, you're ALREADY doing a client-side rendering model. Now the question becomes, why shouldn't you use the same model for the website-version of your project? Kind of a no-brainer. Then the question becomes whether you want to render server-side pages only for SEO benefits and convenience of shareable/bookmarkable URLs 29
  56. 56. Ce qu’il faut retenir The Single Page Interface Manifesto http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php 30 The Single Page Interface Manifesto Updated: Sept. 21, 2015 Origins of web technology When Tim Berners Lee invented web he was looking for a system to publish scientific documents remotely accessible, visually attractive, easy to code and easy to use for a non-technical person. In a scientific document, external cites to other documents is indispensable, in order that the reader may optionally develop the theme in question. For these reasons the World Wide Web was conceived as a page (document) based system with hyperlinks. Initially the Web was a world of static pages and links but soon the generation of dynamic pages and in general the use of the Web as a support for designing web- based applications complicated everything. The arrival of web applications For many years there has been a strong effort to adapt the web paradigm of pages and links to application development. In a web application the Berners' view of static documents and simple links do not exist. Different application development approaches have been happening: Model 1: direct translation of the original model of pages and links, where pages are 30
  57. 57. dynamically generated. Model 2 o MVC: now links are not directly pointing to a concrete target page, in this case a controller decide what the next page is depending on the operations taken place in page transition. MVC based on components (Model 3?): is the sophisticated version of Model 2 simulating how desktop applications work. It is based on components and events, so any user action implies the complete rebuild and reload of the page partially changing some part according with the action performed. The page and page transition is now managed by components which now what changes take place according to the event, simulating how components work on desktop GUI programming. In recent years the AJAX technique has been introduced, this technique with the help of JavaScript allows partial changes in pages obtaining new data from server without reloading. In spite of partial page change technique is long before the introduction of XMLHttpRequest in Internet Explorer (base of AJAX programming), it has been the boost of its massive use. Now millions of web sites and web applications use AJAX to provide a better experience to end users thanks to more responsive user interfaces partially avoiding the annoying page reloads. In spite of massive use of AJAX, we can say the Web follows a development model we could name as "Model 2 (MVC) enriched with AJAX". When using AJAX, "Model 3" has not much sense because AJAX largely reduces the need of page management based on components. Because AJAX is usually used alongside components (not necessarily present in Model 2), we may classify the current state of art of web development as Model 3.5, where page navigation is partially avoided in case of minor state transitions performed by AJAX and JavaScript. What are the disadvantages of page based navigation and development? Every web developer knows how problematic is page navigation in a web application, besides of bandwidth wasting and process time rebuilding entire pages more problems make web development painful like unwanted caching, back/forward buttons, desynchronized forms caused by the "form auto-fill" feature of some browsers and so on. It is not uncommon to see web applications that hide the menus and buttons of the browser or using frames or iframes (e.g. banks) to avoid the problem of Back/Forward buttons. Page based development forces a style of coding weird, repetitive (plenty of includes) and inefficient (both bandwidth and computing power) not found in desktop development. What is what prevents intensive use of AJAX? In the field of web development we are used to distinguish two kind of web solutions: web applications and web sites. In the first case AJAX is becoming more and more used because this kind of applications do not share some requisites imposed for web sites. In web sites 30
  58. 58. intensive use of AJAX is a problem. In public web sites end users are used to the page concept, bound to the pages some requisites and services are required in any web site like: Bookmarking: Every web page has a different URL, this URL can be saved as bookmark. Because AJAX can partially change the page the URL is the same, the end user cannot save as bookmark a concrete view (state) of the page. Search Engine Optimization (SEO): Any web site wants to be fully indexed by search engines like Google Search. Current crawlers see the Web as Web 1.0, that is, JavaScript code is fully ignored, thereby any partial change performed via AJAX loaded from server is not executed then not indexed by crawlers traversing the web site. Services based on page visits: For instance advertisement services like Google AdSense and page visit monitoring such as Google Analytics, in both cases the number of page loads is important. Therefore any partial change done by AJAX does not count as a new visit. Occasional need of pop-pup windows Because these requisites intensive AJAX is discouraged in web sites. However the difference between a "web site" and a "web application" is becoming smaller because almost any web site is a sort of "web application"... Should we give up AJAX-intensive applications? NO. There are technical solutions for all above listed requisites. Development of web sites based on a single Web page (SPI), is it possible? YES ! This is the time to start this transition, developers and end users all of us will gain. We have the technology and modern browsers are qualified to achieve this objective. To succeed in this "new" way of web development we must to accomplish all of previous requisites of any web site. Goodbye pages, welcome states In an web application without JavaScript, state sequence is equivalent to pages, in a SPI application any partial change implies a new "state" of "the page". Among states we can distinguish two categories of states: Fundamental states Secondary states Differencing between both state types is very important, because fundamental states will become web pages when needed. Fundamental and secondary differentiation is web site dependent. To better understand both types of states we can study a real example: login validation. In a classic page based applications typical login is built by using two pages, one for user and password and one showing user options if login validation was correct; the login page will be reloaded showing some error messages alongside the login form 30
  59. 59. when login entry is wrong. In a SPI web, initial login and the user options page could be the fundamental states, and error messages alongside login could be secondary states. Another example, a web site based on pages to be converted to SPI, in this case fundamental states will be the pages and secondary states will be page states with minor changes, not important enough for bookmarking or to be traversed by crawlers. Single Page Interface and Bookmarking Different pages have different URLs, following the SPI route how can we change a state and at the same time the URL without reloading to allow this new state can be bookmarked by end users?. There is a trick, using the "reference" part of URLs ("hash fragment", shebang or hashbang), this is the last part, if present, following the # character. This reference is used to scroll the page to the concrete location specified by some <a name="ref"></a> mark. This reference part if changed does not reloads the page, hence if the URL reference is changed by using window.location alongside the page state (in this case this new state is "fundamental") with JavaScript and AJAX, then no reload is performed. Because the URL and the fundamental state have changed, end users can save this URL, in some way containing the new state info, as bookmark. When end user wants to come back again to the bookmarked page, the target state is specified in the reference part of the URL, the server will be requested, unfortunately the reference part is not sent to the server because reference part does nothing to do with remote location using HTTP, hence we will need a post-load process. The server will return an initial page in which the target state is not the specified, however the window.location object contains the original URL including the reference part. When loading the target page we can detect with JavaScript whether window.location contains a reference part and whether this reference has the required target state info, if true we can rewrite the URL adding some kind of normal parameter to specify the target state to load. Because the URL has actually changed a new server request is executed, this time the state to load is in a parameter and the server returns a new page with the required state. Another option, better than hashbangs, arises with the advent of HTML 5, the HTML 5 History API. Single Page Interface and Search Engine Optimization (SEO) The easiest way to get our web site is processed by search engine crawlers is to offer two different navigation modes, SPI for end users, pages for web crawlers. The next example shows a link with this idea: <a href="URL page" onclick="return false">…</a> This link will do nothing in a browser with JavaScript enabled because navigation is disabled by "return false" of onclick attribute, but when a bot indexes this link ignores the onclick attribute because JavaScript code is not executed and will process the specified URL as the next page to process. 30
  60. 60. In the field of a SPI application, URLs being used for page/state navigation must contain the target state, the same type of URLs used in SPI bookmarking that is using the reference part to indicate the target state, or the target is directly written as a normal parameter, the later is preferred because it avoids a server request, of course "pretty URLs" can also be used. Currently Google already crawls "AJAX URLs", that is, URLs containing the target state in the reference part following #! as specified in Making AJAX Applications Crawlable, in this case the web site/application must return the expected page being requested with a _escaped_fragment_ parameter. At the same time the SPI web framework can add specific code to the onclick handler before return false or can bind an event listener to the link being used for state/page navigation, registered with addEventListener or attachEvent depending on the browser. This event listener will execute some action to command the server, usually using AJAX, to change the page state. When the link is clicked this state change is not a new page because the attribute onclick="... return false" avoids the default behavior. The technique described before is the simplest and immediate by using visible links compatible with bots and SPI. You can ever separate both functions, for instance using hidden links for end users but not for bots alongside other clickable elements to change SPI states by using JavaScript invisible for bots. The most important feature of a SPI capable framework is page generation as HTML with the required state on loading time and at the same time the same change state must be performed with JavaScript and partial page updating. These requisites are fundamental to provide SPI and page simulation. SPI and Back/Forward buttons Back/Forward buttons are a source of problems on conventional page based web sites and should be avoided as soon as possible. In spite of users are used to avoid Back and Forward buttons when submitting a form with user data (because it carries the risk of buying twice the same plane ticked or book), use of Back/Forward buttons is very widespread. Apparently the SPI paradigm breaks the traditional way of navigation of a web site, because in theory Back/Forward buttons has no sense in SPI (no pages) and web browsers do not provide a good control of these buttons. This is not fully true, Back/Forward behavior can be simulated, instead of page navigation Back/Forward (and history navigation in general) can be used to change the current state to the previous/forward state. In this case a JavaScript code can detect when the reference part of the URL changes and requests the application to change the state accordingly. Because the browser does not change the page your application is now fully responsible of Back/Forward behavior avoiding the typical problems of unexpected Back/Forward use of end users when submitting a form, now in SPI there is no such form and no uncontrolled page navigation by the web application/web site. 30
  61. 61. SPI and services based on page visits Ads services and page visit counters are based on how many pages have been loaded. In both cases you can use hidden <iframe> elements containing an empty web page with the required scripts to execute this kind of services. In the case of advertisement services such as Google AdSense, dynamic insertion of <iframe> implies loading new ads therefore every change state could imply a new reload of <iframe> with ads. Google AdSense seems to detect when the AdSense script is executed within a <iframe> and takes into account the contents of the container page. It may be desirable to add some kind of parameter that identifies the fundamental state that is loading the <iframe>. In the case of visit counters, we can use them to monitor user visits to fundamental states of our SPI web site. In this case we need a hidden <iframe> containing an empty web page with the monitoring scripts. With a simple parameter we can indicate the fundamental state being visited. Our <iframe> should be global (always the same in the page). When the page is first loaded, the fundamental state being loaded (specified in URL) should be indicated to the <iframe> with a parameter. After page loading, every fundamental state change could be notified to <iframe> changing the URL via JavaScript according to the new fundamental state, this URL change will cause a reload of <iframe> (indicating a new visit). SPI and pop-up windows When a new page window is created the SPI model is broken. Fundamentalism is bad, there is no problem if the state of this new window has nothing to do with the state of the parent window, in this case pop-up windows are fine. The problem arises when any action performed on the pop-up window (modal or not modal) has some influence on the parent window, coordination between pages is complicated. For instance there is no a web standard to create modal windows because the page concept has traditionally always been an independent element and therefore its life cycle is difficult to coordinate from another page. Fortunately this problem has solution for some time in SPI, you can simulate modal or not modal windows inside the same web page, no new real page window is created. In the case of non-modal windows, any HTML element with absolute positioning can be a "non-modal window" and you can create modal windows by using absolute positioning, controlling z-index and opacity of elements "on top" of the page ("modal layers"). These solutions are valid in a SPI context. With a little effort, even the state which shows a modal window may be a fundamental state and therefore navigable by search engine bots. A cultural shift for web developers Most of web developers (and web frameworks) think the Web as based on pages, page reduction to a single page implies a radical change of mind and how we make web sites and applications. This change is not so radical thanks to AJAX, AJAX is today mainstream and has reduced the number of pages of typical web sites, in summary it has brought us near of this "new" SPI development model. 30
  62. 62. In the new SPI web the <form> tag disappears and in general the need of sessions used as data managers following page sequences. Now the protagonist is the page client with some symmetry in server (the page in server). In fact, because we get rid of page coordination with sessions we are freed of a source of problems like the bad practice of some users who open several windows with the same page, this practice usually breaks the session and the application in general. SPI programming is based on events the same as in desktop, because in desktop most of applications runs in the same frame window and when child windows exist these are fully managed by the main window and genuinely modal. Following the paradigm evolution of web development, this "new" approach could be named Model 4. A cultural shift for end users? Not very much, with bookmarking and Back/Forward simulation end users are not going to differentiate a SPI web site and the same page based, furthermore the SPI site will be more responsive and the typical blinking and scrolling of page navigation is removed. Technical viability today This manifesto is not a statement of intentions but the expression of the desire to promote a "new" way of building websites that are already real. The above technical study has always had the Java web framework ItsNat as the technological base of SPI web site development. In spite of ItsNat was conceived from day one to this kind of applications/sites, previous techniques could be applied with other web frameworks or these frameworks could evolve to provide facilities for this kind of SPI web sites with page simulation requirements. Some requirements of these SPI web sites to be able of replacing traditional page based web sites, such as page simulation of fundamental states on loading time, are just possible with server centric web frameworks because HTML rendering must be done in server on load time. HTML rendering on load time and the same dynamically loaded and inserted with JavaScript are the key characteristics of a web framework ready to build SPI web sites. Client centric frameworks could have a major role for the realization of so-called secondary states. Two real world examples The web innowhere.com/jnieasy It is made with ItsNat in server and a good example of SPI web site because it sums up all requirements of a SPI web site, explained in this document, to be a satisfactory substitute of a traditional site. In fact, the new SPI version replaced, with no significative aesthetic of functional change, the previous version based on pages. It is based on hashbangs. Characteristics Single Page Interface: Back and Forward buttons are simulated changing to previous or forward visited state. Fundamental states can be saved as bookmarks. 30
  63. 63. SEO compatible: fundamental states are reachable with JavaScript disabled including a modal window. The hashbang #! format is used, that is, Google SEO compatible "AJAX URLs", the page is also requested following the Google convention of _escaped_fragment_ parameter. For instance this state is crawled by Google requesting this URL. Works with JavaScript disabled. Shows an ads banner based on Google AdSense Despite being SPI, browsing through fundamental states is monitored by Google Analytics by using a hidden <iframe> which URL changes when the current fundamental state changes. A simulated modal window avoids creating a new window page, this simulated window is also reachable with a direct URL or a hashbang version with text already in markup on load time consequently SEO compatible. The web www.itsnat.org It is also made with ItsNat in server. In this case JavaScript History API is used. This is the most perfect approach to convert a conventional web site to a SPI SEO compatible version. If History API is not supported by a concrete old browser, conventional page navigation is automatically used. All modern web browsers support the JavaScript History API. The SPI characteristics of this web site are basically the same as the previous example. The Manifesto in other languages Spanish Note: these translations may be slightly out of date because this manifesto is "alive". Ukranian thanks to Mario Pozner Russian thanks to Andrey Geonya Serbo-Croatian thanks to Jovana Milutinovich Slovakian translation thanks to Knowledge Team German thanks to Valeria Aleksandrova. Romanian translation provided by Science Team. Macedonian thanks to Katerina Nestiv Hungarian thanks to Elana Pavlet Estonian thanks to Valerie Bastiaan Links pointing to the manifesto Discussion at DZone Discussion at TheServerSide.com Discussion at YCombinator.com Discussion at JavaHispano.org (in Spanish) Modern Principles in Web Development presentation based on the SPI manifesto 30
  64. 64. 31 31
  65. 65. 32 32
  66. 66. 33 Merci beaucoup! N’hésitez pas si vous avez des questions! 33
  67. 67. https://www.paulirish.com/ https://github.com/kangax https://kangax.github.io/compat-table/es6/ https://fr.wikipedia.org/wiki/Polyfill https://stackoverflow.com/questions/6599815/what-is-the-difference-between-a-shim-and- a-polyfill https://github.com/es-shims/es5-shim https://en.wikipedia.org/wiki/Progressive_enhancement https://fr.wikipedia.org/wiki/Am%C3%A9lioration_progressive https://en.wikipedia.org/wiki/Razorfish_(company) https://fr.wikipedia.org/wiki/Exp%C3%A9rience_utilisateur https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things https://en.wikipedia.org/wiki/Adaptive_web_design Adaptive web design (AWD) https://en.wikipedia.org/wiki/Responsive_web_design responsive web design (RWD) A shim is any piece of code that performs interception of an API call and provides a layer of abstraction. It isn't necessarily restricted to a web application or HTML5/CSS3. A polyfill is a type of shim that retrofits legacy browsers with modern HTML5/CSS3 features usually using Javascript or Flash. Answering your specific question, call it your directory shims if you want to keep the directory generic. 34
  68. 68. ASP.NET - Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET https://msdn.microsoft.com/en-us/magazine/dn463786.aspx https://github.com/MikeWasson/MoviesSPA Another approach to webapplication fingerprinting Another approach to webapplication fingerprinting It has been always important to fingerprint webapplication versions, but now in light of the recent Drupalgeddon attacks (Yet Another Drupal RCE Vulnerability and More Threat Hunting with User Agent and Drupal Exploits) it is even more important. Naturally we can detect the website by just checking the version number, but that’s not always that precise. There are a lot of applications that disable version identification or give false information, which would give a lot of false positives for possible vulnerabilities. Websites can be identified using files like README, stylesheets, templates and other static files. Some existing tools identify version information from the outside using these, but results are not always that precise. They depend often on a (small) pre- generated database of hashes of files. A while ago I worked on another approach, using the original (git) repositories. The small (proof of concept) tool called Identify (http://github.com/dutchcoders/identify) uses not just a predefined list of hashes, but uses the original opensource repository. Being up to date to the latest version is important, and using the actual repositories will keep the tool actual. Plugins for applications like Wordpress are also within public repositories (eg 35
  69. 69. http://plugins.svn.wordpress.org/) and can be probed in the same manner. Another advantage of using the repositories is that semantic versioned tags are being used, which makes it easy to identify accompanying vulnerabilities against the CVE database. Identify first clones the (git) repository of the opensource content management system. Next it will do several http requests (using a predefined list, this is one of the improvements that can be made) against the target website, generate a hash and compare it against all other hashes in the repository. Those resulting files and hashes will be stored in a list, narrowing down the amount possible versions and outputting the results. As this is just a proof of concept, I’m working on some additions to this tool. First I’d like to generate a database containing relevant hashes of static files of several repositories, which will be updated on each start. Using this database and comparing all files and hashes we could narrow the list down of uniquely identifying applications and versions, and therefore the amount of requests we need to do on the target site to identify. Less requests are better. If the list has been narrowed down to just a single version, the next step will be to implement the CVE database to show the vulnerabilities to that specific version. 35

×