Développer des composants métier coté serveur Flashcards
Côté backend, comment peut on se défendre contre une faille XSS ?
Le but d’une attaque XSS est de faire exécuter sur une application cliente (navigateur web), un code malicieux.
En plus de devoir bien sur protéger les accès au(x) serveur(s) qui héberge(nt) le site avec des mots de passes solides (et ainsi se protéger d’ajout de code malicieux directement dans le code source de l’application). Il faut également controller toutes les données envoyées par le frontend qui sont vouée à être insérées en BDD car les données peuvent véhiculer du code malicieux. Si du code malicieux se retrouve par mégarde inscrit en base de données, alors cela peut ouvrir la voie pour des attaques type XSS sur les navigateurs des utilisateurs du site.
Il faut alors analyser chaque donnée envoyée par le frontend (les données des champs d’un formulaire par exemple) et utliser diverses approches (lib, REGEX, …) pour détecter et invalider des bouts de codes potentiellement malicieux.
En outre, il ne faut utiliser qu’en dernier recours des fonctions permettant d’interpréter une chaine de caractère (cela peut permettre l’exécution côté frontend de code malicieux). Comme par exemple la fonction ‘eval()’ en JS qui peut être très dangereuse si elle n’est pas suffisament contrôlée de toute part. Ou encore l’utilisation de la propriété html ‘innerHTML’ qui interprètre le texte inséré dedans.
Côté backend, comment peut on se défendre contre une attaque CSRF ?
Une attaque CSRF exploite la confiance établie entre le frontend et le backend ; comme par exemple suite à l’authentification d’un utilisateur sur le site. Une personne malveillante peut alors faire exécuter des requêtes sensibles sans que l’utilisateur victime en ait connaissance.
Pour se protéger contre ça, on peut par exemple utiliser un jeton CSRF dans chaque formulaire généré du site. Ce jeton doit systématiquement être vérifié lors de la soumission d’une requête. Ainsi, l’utilisateur soumettant la requête aura pleinement conscience de son action étant donné qu’il devra forcemment passer par le formulaire prévu à cet effet.
L’utilisation de la protection CORS (gérée par la plupart des frameworks Web backend) peut limiter les approches possibles de la personne malveillante pour déclencher une attaque CSRF.
D’autres moyens de protections existent encore
Dans le design pattern MVC, a-t’on un lien entre la partie M et la partie C ?
L’application backend a parfois besoin de manipuler des données. Le lien entre le Controlleur et le Model représente ce type d’interaction possible.
Le but est de séparer complètement la couche de contrôle des données de la couche représentant les données elles-même. Ainsi, nous ne devrions pas retrouver des requêtes SQL dans un controlleur afin de bien respecter un principe aimé des développeurs/ses : le principe de séparation des responsabilités dans une architecture applicative.
Dans le design pattern MVC, a-t’on un lien entre la partie M et la partie V ?
Non ! nous irions complètement à l’opposé de la philosophie du design pattern MVC. Un scénario catastrophe dans une application serait de se retrouver avec des données corrompues en base de données. Le C du MVC est la couche qui, justement, a la responsabilité du contrôle entre la vue (le frontent, celui auquel on ne doit jamais faire confience) et le modèle.
Durant votre formation, avez vous vu un design pattern qui permet de découper en plusieurs partie une architecture applicative ?
Oui ! le MVC !
Quel est l’acronyme de MVC ?
- Model
- Vue
- Controller
Dans un controlleur, je souhaite retourner une réponse au client dans le cas où tout s’est bien passé. Quel status HTTP(s) je devrais utiliser ?
Un status 2xx, le 200 par exemple [ne pas hésiter à jeter un oeil sur la documentation en ligne pour voir les differents status 2xx existant]
Dans un controlleur, je souhaite retourner une réponse au client dans le cas où le serveur a rencontré une erreur. Quel status HTTP(s) je devrais utiliser ?
Un status 5xx, le 500 par exemple [ne pas hésiter à jeter un oeil sur la documentation en ligne pour voir les differents status 5xx existant]
Quel(s) intéret(s) y a-til de protéger les champs d’un formulaire côté backend (taille max d’un champ, complexité d’un password, …) étant donné qu’on peut faire toutes ces vérifications côté frontend (html/javascript) ? (et donc éviter de dupliquer des vérifications à deux endroits différents)
Il ne faut jamais croire ce qui provient du frontend. Il est aisé de désactiver les vérifications mises en place en ouvrant le débuggeur de son navigateur. De plus, il est aussi tout à fait possible d’effectuer directement des requêtes vers le backend sans passer par un navigateur (en utilisant des outils comme postman par exemple).
Il faut donc nécessairement des vérifications côté backend (dans la couche controlleur du design pattern MVC) sous peine de risquer la corruption de la base de données qui fait partie des pires scénarios possibles dans une application web.
Qu’est-ce qu’un test d’integration ?
Les tests d’intégration vérifient le bon fonctionnement de l’application en connectant les différents composants ‘externe’ qu’elle utilise. Un composant ‘externe’ peut désigner par exemple ; la base de données, une API externe, des fichiers de configuration, en bref, tout ce qui sort du code de l’application qui est testée.
Contrairement à un test unitaire, un test d’intégration peut utiliser un ensemble de fonctions. Les tests d’intégration sont aussi plus difficiles à écrire et à maintenir que les tests unitaires.
Voici quelques exemples de tests d’intégrations :
- tester si un controlleur récupère bien l’ensemble des articles stockées dans la BDD
- tester si un service (ou middleware) génère un mot de passe (en utilisant un package externe) avec un degré de complexité attendu
- tester si la fonction de connexion à la base de données arrive bien à récupérer les données de connexion situées dans un fichier de configuration
Qu’est-ce qu’un test end to end ?
Un test end-to-end (e2e) va tester une fonctionnalité de l’application du point de vue de l’utilisateur. Il s’agit d’un test dit de “haut niveau” et fait donc partie des tests qui sont les plus longs à écrire et couteux à maintenir. La création de test e2e se concentre alors avant tout sur les parcours “vitaux” de l’application (ex : le tunnel de vente d’un site e-commerce, la soumission du formulaire d’authentification, …)
Connaissez vous des outils permettant de contrôler la qualité du code que vous produisez ? En quoi ces outils sont particulièrement efficaces dans le cadre d’un travial en équipe ?
Ces outils sont des linters :
[stack JS] eslint, prettier, …
[stack PHP] rector, phpstan, …
En informatique, on peut répondre à une problématique d’une multitude de manière différentes. Par extension, un bout de code peut être écrit de differentes manières pour implémenter une fonctionnalite. Ainsi, des outils comme les linters permettent d’hamoniser les pratiques entre développeurs(ses) et donc de produire du code plus lisible et plus maintenable dans le temps.
C’est quoi un paradygme de programmation ? pouvez vous en lister 2 ?
Les langages de programmations sont en partie créé pour répondre à des besoins spécifiques (prioriser la rapidité d’exécution du programme, se focaliser sur la lisibilité et la maintenabilité du code, etc..). Donc selon le besoin, les languages peuvent intégrer des caractéristiques générales et c’est cela qu’on appelle un paradigme de programmation. Certains langage peuvent être multi-paradigme.
- La programmation orientée objet est un paradigme de programmation (par exemple ; javascript, python, php, java, …)
- La programmation événementielle est un paradigme de programmation (par exemple ; javascript, python, …)
En utilisant le (très simple) paradigme de programmation procédurale, il me suffit d’une ligne pour afficher un message simple (un simple console.log en javascript par exemple). En programmation orientée objet, il me faut créer une classe avec une méthode, instancier la classe puis exécuter la méthode de mon objet instancié pour afficher un simple message. Pourquoi s’enquiquiner avec de la programmation objet ?
Pour des programmes simples et qui ne sont pas voués à beaucoup évoluer, utiliser le paradigme de programmation objet (la POO) n’est en effet pas vraiment pertinent. Par contre ce paradigme devient particulièrement efficace pour des projets qui devront évoluer durant des mois voir des années. La POO demande plus d’effort à court terme mais à moyen/long terme, cette approche facilite grandement la réutilisabilité du code, sa modularité et permet de structurer les programmes de manière plus intuitive en les organisant autour d’entités autonomes et interconnectées.
En programmation orientée objet, quelle est la différence entre une classe et un objet ?
Un classe est un peu comme une recette de cuisine inscrite dans un livre tandis qu’un objet est un gateau créé à l’aide de la recette. Autrement dit, une classe est un modèle permettant de créer (d’instancier) des objets.
