Méthodes d'attaque courantes sur le front-end Web et méthodes pour empêcher les attaques_HTML/Xhtml_Production de pages Web

La sécurité rencontrée dans le développement frontal de sites Web est facilement ignorée par les gens, car la plupart des gens pensent que ces codes exécutés dans le navigateur client ne provoqueront pas de risques de sécurité côté serveur. Cet article expliquera brièvement les problèmes de sécurité souvent rencontrés. le front-end du site Web et quelques stratégies d'adaptation

Avec le développement de la technologie frontale, des problèmes de sécurité sont apparus discrètement à chaque utilisateur du serveur, volant des données utilisateur, créant un code de ver malveillant auto-répliquant, permettant aux virus de se propager entre les utilisateurs et provoquant l'abandon du serveur. De plus, les utilisateurs peuvent devenir des attaquants sans qu'ils le sachent. Ce n'est certainement pas choquant. L'application de clients riches est de plus en plus répandue et les problèmes de sécurité front-end augmentent également. Aujourd'hui, je présenterai brièvement quelques méthodes d'attaque et méthodes courantes pour prévenir les attaques.

Attaques courantes

XSS (Cross Site Script), attaque de cross-site scripting. Il s'agit d'un attaquant malveillant qui insère du code HTML malveillant dans une page Web lorsqu'un utilisateur parcourt la page, le code HTML malveillant intégré sera exécuté, atteignant ainsi l'objectif particulier de l'utilisateur malveillant. XSS est une attaque passive Parce qu’elle est passive et difficile à exploiter, de nombreuses personnes ignorent souvent sa nocivité. Cependant, avec l'avancement continu de la technologie frontale et le nombre croissant d'applications client riches, cette question a attiré de plus en plus d'attention. Pour donner un exemple simple : si vous êtes actuellement un utilisateur sur le site sns, il existe une vulnérabilité dans la fonction de publication d'informations qui peut exécuter js. Si vous entrez un script malveillant à ce moment-là, alors les navigateurs de toutes les personnes qui le verront. vos nouvelles informations exécuteront ce script et une fenêtre contextuelle apparaîtra (annonces pop-up très sympas :)), si vous adoptez un comportement plus radical, les conséquences sont inimaginables.

CSRF (Cross Site Request Forgery), requête falsifiée cross-site. Comme son nom l'indique, il permet aux utilisateurs d'utiliser leur propre identité pour atteindre certains des objectifs que l'attaquant doit atteindre en forgeant des demandes de connexion à l'insu de l'utilisateur. Les attaques CSRF sont différentes des attaques XSS CSRF qui doivent être déclenchées par le comportement actif de l'attaquant. On dirait qu'il y a une suspicion de "pêche" haha.
Les navigateurs multi-fenêtres semblent contribuer à la tyrannie à cet égard, car la nouvelle fenêtre ouverte contient toutes les sessions en cours. S'il s'agit d'une seule fenêtre de navigateur similaire à IE6, il n'y aura pas de problème de ce type, car chaque fenêtre en a une. un processus indépendant. Donnons un exemple simple : vous jouez à White Society et vous voyez quelqu'un envoyer un lien. Vous cliquez dessus, puis un formulaire d'envoi de cadeaux est forgé dans ce lien. Ce n'est qu'un exemple simple, et le problème est évident. .

Détournement de cookies, en obtenant les autorisations de la page, écrivez une simple demande au site malveillant dans la page, et transportez le cookie de l'utilisateur. Après avoir obtenu le cookie, vous pouvez directement assumer l'identité de. l'utilisateur volé via le cookie Connectez-vous au site. Il s'agit d'un détournement de cookies. Pour donner un exemple simple : quelqu'un a écrit un journal très intéressant et l'a ensuite partagé avec tout le monde. De nombreuses personnes ont cliqué pour voir et partager le journal. Cependant, la personne qui a écrit le journal avait d'autres intentions. La demande vers l'extérieur du site est secrètement cachée dans le journal. Ensuite, tous ceux qui liront ce journal enverront leur cookie à quelqu'un sans le savoir, et pourront alors se connecter à cette personne via le compte de cookie de n'importe quelle personne.

Que devons-nous faire ?

Il peut être grossièrement divisé en deux catégories : 1. Utilisateurs généraux 2. Développeurs de sites Web.

Tout d’abord, parlons de cela en tant qu’utilisateur général de produits Web, nous sommes souvent passifs et exploités sans le savoir. Nous pouvons alors :
1 Pour accéder aux applications Web avec des niveaux de sécurité plus élevés, vous devez ouvrir une fenêtre de navigateur distincte.
2 Pour les liens postés par des inconnus, il est préférable de les copier et de les ouvrir dans une nouvelle fenêtre. Bien sûr, le meilleur moyen est de les ignorer - -.

Pour les développeurs, il faut l’analyser dans une perspective relativement détaillée :
La caractéristique des attaques XSS est que le code de l’attaquant doit pouvoir obtenir les autorisations d’exécution sur le navigateur de l’utilisateur. Alors d’où vient le code ? Pour éviter que de telles attaques ne se produisent, nous pouvons effectivement effectuer un filtrage strict à l'entrée et à la sortie. Avec ce genre de double assurance, il faut dire que 99 % des problèmes similaires ont été résolus par nos soins, et le 1 % restant est le cas. séquelles causées par ces navigateurs merdiques, je pense que ce genre de problème deviendra de moins en moins important à l'avenir.

Ici j'ai trié les formes de vulnérabilités xss

La valeur du code malveillant est affichée comme le contenu d'une certaine balise (si l'entrée est HTML, le HTML sera analysé). Par exemple, après avoir entré le nom d'utilisateur et l'avoir mis à jour, le nom d'utilisateur sera affiché dans). une certaine balise sur la page Si vous entrez

popper.w

Donc s'il est affiché directement sur la page sans filtrage, un code js tiers sera introduit et exécuté.

Stratégie : filtrer les balises HTML et certains caractères spéciaux (" < > &, etc.) où la saisie HTML n'est pas requise, et les convertir en caractères qui ne sont pas interprétés et exécutés par le navigateur

Le code malveillant est affiché comme attribut d'une certaine balise (en utilisant " pour tronquer l'attribut afin d'ouvrir de nouveaux attributs ou méthodes malveillantes). Cette situation est souvent causée par les développeurs qui peuvent enregistrer certaines informations sur certaines balises DOM afin pour mettre en œuvre des fonctions. Les informations saisies par l'utilisateur, telles que le nom d'utilisateur que vous saisissez, apparaîtront sous forme de titre dans la balise de la page. Si vous saisissez un contenu soigneusement conçu, jetez un œil à ceci

.

popper.w" onclick="alert(1)

Ce que j'ai entré ici est "popper.w" onclick="alert(1)", bien sûr, vous pouvez écrire plus de contenu ci-dessus.

Stratégie : filtrez certains caractères qui peuvent être tronqués dans l'attribut. Les guillemets simples et doubles qui existent dans l'attribut lui-même doivent être transcodés.

Le code malveillant est affiché sous forme de code html lui-même (éditeur html commun). Cette situation pose le plus de problèmes, je ne donnerai donc pas d'exemple ici.

Stratégie : il est préférable de filtrer sur liste blanche les balises html et les attributs de balise saisis par l'utilisateur. Vous pouvez également effectuer un filtrage spécial sur certaines balises et attributs vulnérables.

Le code malveillant est affiché sous forme de chaîne json (créant de nouvelles variables js malveillantes ou même du code exécutable via la troncature de variable. La clé de ce problème est que les informations saisies par l'utilisateur peuvent faire partie du code js dans la page). .

Stratégie : filtrez certains caractères qui peuvent être tronqués dans l'attribut. Les guillemets simples et doubles qui existent dans l'attribut lui-même doivent être transcodés.

Pour le détournement de crsf et de cookies

Caractéristiques : Dissimulation élevée Parfois, les vulnérabilités XSS sont d'abord exploitées puis trompées

Stratégie
Détectez les soumissions des utilisateurs via un référent, un jeton ou un code de vérification.
Essayez de ne révéler aucune information relative au numéro unique de l'utilisateur (ID utilisateur) dans le lien sur la page.
Pour les opérations de modification, de suppression et de soumission des utilisateurs, il est préférable d'utiliser l'opération de post.
Évitez les cookies à l'échelle du site et définissez des cookies uniquement pour le domaine.

ok, je vais juste l'écrire ici~

Ce qui précède présente quelques problèmes de sécurité courants, principalement du point de vue du hack js. Avec le développement et les progrès continus de la technologie front-end, davantage de problèmes de sécurité peuvent apparaître devant nous. Pour les développeurs, la plupart des problèmes peuvent être évités. la phase de développement, donc ce qui fait peur, ce ne sont pas les hacks. Ce qui fait peur, c'est notre laxisme dans la sécurité de nos produits~.