Securisation
- Le code,
- la DB
- et le serveur.
Un attaquant tente de manipuler/d'accéder à des données non autorisées en injectant des commandes SQL via les entrées utilisateur.
Cette injection tente d'accéder à d'autres données que celle prévue initialement.
Entrée utilisateur (String) -> " SELECT * FROM users; --"
Si l'application utilise une requête SQL qui ajoute cette entrée à la fin de celle-ci,
Requête SQL (String) -> " SELECT * FROM table WHERE field = ‘ + user_input + ‘ "
l'injection complètera la commande et ajoutera une nouvelle requête.
Cette injection tente de se connecter sans mot de passe valide.
Entrée utilisateur (String) -> " ‘ OR ‘1’=‘1 "
Si l'application utilise une requête SQL qui ajoute cette entrée à la fin de celle-ci (password)
Requête SQL (String) ->
" SELECT * FROM users WHERE username = ‘" + username + "‘ AND password = ‘« + password + "' "
l'injection complètera la commande et tentera de se connecter sans mot de passe
Cette injection tente d’extraire des données de manière masquée
Entrée utilisateur (String) -> " ‘ UNION SELECT username, password FROM users -- "
Si l'application utilise une requête SQL qui ajoute cette entrée à la fin de celle-ci (password)
Requête SQL (String) ->
" SELECT * FROM users WHERE username = ‘" + username + "‘ AND password = ‘« + password + "' "
l'injection complètera la commande et tentera de récupérer l’ensemble des donnés grâce à l’UNION
Les données fournies par un utilisateur (ex. un paramètre dans une URL) sont utilisées immédiatement par les scripts web de la page sans validation ni échappements adéquats. Exemple : Un attaquant envoie un lien à une victime via un email qui contient le terme de recherche permettant l’attaque.
Les données malveillantes sont enregistrées sur le serveur et plus tard affichées aux utilisateurs dans les pages web. Exemple : Un attaquant poste un commentaire contenant un script malveillant.
Les données non sécurisées d'une source (DOM) sont utilisées dans une opération sensible à l'intérieur du navigateur de l'utilisateur. Exemple : L'application utilise une partie de l'URL directement dans son DOM sans la nettoyer.
Côté Backend :
- On utilise des requêtes paramétrées (Exemple avec PostgreSQL)
Côté frontend :
- N'a pas un impact direct sur les injections SQL.
- Mais il faut toujours prévenir les erreurs de saisies en validant celles-ci.
-
Reflected XSS : Valider et échapper toutes les entrées utilisateur qui sont reflétées par le serveur sur la page web.
-
Stored XSS : Sanitiser et échapper toutes les entrées avant de les stocker et aussi lors de leur affichage sur les pages web.
-
DOM-based XSS : Utiliser des méthodes sécurisées pour manipuler la DOM et éviter d'injecter directement des entrées non « sanitisées » dans la DOM.
Sanitiser une entrée consiste à nettoyer les données fournies par l'utilisateur pour éliminer ou neutraliser les éléments potentiellement dangereux.
Nous utilisons également **HttpOnly **qui prévient ce genre d'attaque.
[Au quotidien, comment s'assurer que l'application n'est pas compromise? Où trouver des informations (logs, monitoring, ...) Qui s'occuperait potentiellement de la surveillance et de la maintenance? Quel est votre interprétation des résultats et quelles mesures ont alors été mises en place ?]
[Tout ce qui a été mis en place pour sécuriser l'application, le serveur, la DB, ... ]
[Avez-vous utilisé des outils de vérification de la sécurité de votre application? Ou avez-vous demandé ou effectué un "pentest" de votre application, par ex. avec un autre groupe? ]
[Présentation des contraintes légales s'appliquant à votre application]
[Explication de ce qui a été mis en place pour respecter le cadre légal dans le cadre de ce projet]
[D'après vous, est-ce que la sécurisation mise en place est suffisante? Pourquoi? Quelles sont les limites ? Et les améliorations à envisager ?]