Comment assurer la sécurité du Web

1. Introduction

Au début du développement d'Internet, c'était encore l'ère du navigateur IE. À cette époque, le but de chacun. surfer sur Internet consistait à partager des informations et à obtenir des nouvelles via le navigateur. Avec le développement rapide d'Internet, les pages Web peuvent faire de plus en plus de choses. Vous pouvez non seulement lire des actualités et jouer à des jeux, mais aussi faire des achats et discuter. Ces fonctions ont grandement enrichi nos vies.

Au fur et à mesure que les fonctions des pages Web augmentent progressivement, certains chapeaux noirs ont commencé à apparaître et tentent de réaliser des bénéfices par certains moyens techniques. Par exemple, les virus chevaux de Troie peuvent surveiller votre clavier et envoyer le contenu que vous tapez sur le clavier à la machine du pirate informatique. En analysant le contenu, le pirate informatique peut facilement obtenir votre compte de jeu et votre mot de passe. Après cela, certains logiciels antivirus sont nés, dédiés à la résolution de divers virus sur Internet. Avec un développement continu, les logiciels antivirus sont devenus un logiciel indispensable pour un ordinateur.

Pourquoi un tel problème de sécurité se produit-il ?

La sécurité est en fin de compte une question de confiance. Si chacun se connecte selon les procédures normales et ne recherche pas de gain personnel, il n'y aura pas de problèmes de sécurité à discuter.

Le fondement de la sécurité réside dans la confiance, mais il n'est pas facile d'amener tout le monde à se faire confiance. Au stade actuel, ce que nous pouvons faire, c'est : continuer à améliorer la protection de la sécurité, réduire de moins en moins les failles et rendre les attaques illégales de plus en plus difficiles. Cela réduira progressivement le nombre de chapeaux noirs et les créateurs de virus.

1. Comment faire du bon travail en matière de sécurité

Pour faire du bon travail en matière de sécurité, vous devez d'abord comprendre les attributs des problèmes de sécurité. À travers d'innombrables pratiques, les prédécesseurs ont finalement résumé les attributs de. sécurité en trois éléments de sécurité, qui sont les suivants :

1) Confidentialité

Protéger le contenu des données contre les fuites. Des méthodes de cryptage sont généralement utilisées.

2) Intégrité

Protéger que le contenu des données est complet et n'a pas été falsifié. La méthode de signature numérique est généralement utilisée.

3) Disponibilité.

Les données sont disponibles à tout moment. Se défend généralement contre le DOS.

2. Évaluation de la sécurité

Après avoir les 3 éléments de sécurité, nous pouvons évaluer les problèmes de sécurité.

1) Classification des actifs

Découvrez les données les plus importantes. Découvrez l'espace d'hébergement des données les plus importantes, comme dans une base de données, la base de données doit alors se concentrer sur la défense. Connaître l'espace d'hébergement de la base de données, par exemple : sur un serveur, alors ce serveur doit faire une défense secondaire. Découvrez l'espace hôte du serveur, par exemple : au niveau du réseau OSI, vous devez alors faire une défense générale au niveau du réseau.

2) Analyse des menaces

Identifier les menaces (sources pouvant causer des dommages). Découvrez les risques (les pertes possibles sont appelées risques).

3) Analyse des risques

Adopter une analyse décisionnelle multicritères, soit : risque = niveau de menace * faisabilité de la menace. Calculez toutes les menaces, classez les risques finaux et hiérarchisez les problèmes présentant des risques plus élevés.

4) Confirmez la solution

Identifiez l'implémentation dangereuse et déterminez la solution. La solution ne doit pas modifier l’intention initiale de l’exigence commerciale. La solution doit être transparente pour les utilisateurs et ne pas changer leurs habitudes.

Après avoir terminé l'évaluation de sécurité, nous aurons une solution de sécurité pour les travaux de sécurité ultérieurs, il nous suffit de suivre ce plan et il n'y aura aucun problème.

3. Principes de sécurité

Après avoir une solution de sécurité, nous pouvons également formuler quelques principes de sécurité. Suivre les principes peut nous aider à obtenir deux fois le résultat avec la moitié de l'effort.

1) Principes de la liste noire et de la liste blanche

La solution de la liste blanche fait référence à l'autorisation de ressources sûres. Le système de liste noire fait référence à la désactivation des ressources non sécurisées. Nous devrions privilégier l’utilisation de la solution de liste blanche car la liste noire ne peut généralement pas compter toutes les ressources dangereuses. Par exemple, il existe de nombreuses façons d'attaquer XSS, notamment les scripts, les CSS, les balises d'image, etc. Même si vous ajoutez ces balises à la liste noire, rien ne garantit que d'autres balises ne présenteront pas de risques d'attaque XSS.

2) Principe du moindre privilège

Accordez uniquement les autorisations nécessaires, n'autorisez pas trop et réduisez les risques d'erreurs. Par exemple : les utilisateurs Linux disposant d'autorisations ordinaires ne peuvent utiliser que les répertoires du dossier ~. Si quelqu'un souhaite supprimer la bibliothèque et s'enfuir, lors de l'exécution de rm -rf /, il vous indiquera qu'il n'y a aucune autorisation.

3) Principe de défense en profondeur

Ce principe est similaire à la théorie du canon. Le niveau de sécurité dépend souvent de la planche la plus courte. Autrement dit : ne laissez aucune lacune. Les chapeaux noirs peuvent souvent utiliser les lacunes comme point de rupture pour creuser des failles plus importantes.

4) Principe de séparation des données et du code

Lorsque les données utilisateur sont exécutées sous forme de code, les frontières entre les données et le code sont confuses, entraînant des problèmes de sécurité. Par exemple : XSS l'utilise pour attaquer.

5) Principe d'imprévisibilité

Ce principe consiste à augmenter le seuil d'attaque et à prévenir efficacement les attaques basées sur la falsification et la contrefaçon. Par exemple, l'utilisation de uuid au lieu d'une clé primaire à incrémentation automatique de type numérique dans la base de données peut empêcher les attaquants de deviner l'identifiant, permettant ainsi d'effectuer des opérations par lots. Le jeton profite également de l'imprévisibilité. L'attaquant ne peut pas construire le jeton et ne peut pas attaquer.

En gardant ces principes de sécurité à l’esprit, introduisons plusieurs cas courants d’attaque et de défense.

2. Cas d'attaque et de défense de sécurité

Il existe de nombreux cas d'attaque et de défense de sécurité. Nous introduisons ici principalement quelques problèmes de sécurité qui apparaissent plus fréquemment.

(1) Attaque client

Inclut principalement : les attaques XSS, les attaques CSRF et le détournement de clics.

1. Attaque XSS

L'essence de l'attaque XSS est d'exécuter les données utilisateur dans le cadre du code HTML, confondant ainsi la sémantique d'origine et générant une nouvelle sémantique.

Comme le montre l'image, nous avons enregistré un nom d'utilisateur <script>alert(document.cookie)</script>, tous ceux qui peuvent voir ce nom d'utilisateur Sur chaque page, le cookie du navigateur actuel apparaîtra. Si la logique du code est d'envoyer le cookie au site Web de l'attaquant, celui-ci peut se connecter en se faisant passer pour l'utilisateur actuel.

Il existe de nombreuses façons d'attaquer XSS, et des attaques XSS peuvent exister partout où les utilisateurs interagissent. Par exemple :

• Toutes les zones de saisie.

• fenêtre.emplacement.

• window.name.

• document.referrer.

• document.cookie.

• stockage local.

• ...

Comme il y a tellement d'endroits où les utilisateurs interagissent avec la page, il doit y avoir des méthodes d'attaque XSS qui n'ont pas été découvert. Une fois découvert par un chapeau noir, cela peut avoir de graves conséquences, il faut donc y prêter attention.

1) Impact des attaques XSS

Après avoir été attaqué avec succès par XSS, l'attaquant peut obtenir une grande quantité d'informations sur l'utilisateur, telles que :

Identifier l'utilisateur UA. Identifiez les extensions du navigateur utilisateur. Identifiez les sites Web qu’un utilisateur a visités. (Via la propriété CSS Visited.) Obtenez la véritable adresse IP de l’utilisateur. (Via WebRTC, etc.) Vol de cookies (falsification des identifiants des utilisateurs, vol d'informations sur les utilisateurs.) Phishing XSS. (Injectez une fenêtre contextuelle de connexion dans la page, faisant croire à l'utilisateur qu'il s'agit d'une fenêtre contextuelle de connexion au sein du site Web (en fait à partir d'un site Web de phishing). Une fois que l'utilisateur se connecte, le compte et le mot de passe sont divulgués au site de phishing. site Web.)

2) Défense contre les attaques XSS

Actuellement, XSS a attiré l'attention de l'industrie Internet et de nombreux frameworks de développement intègrent des méthodes de rendu HTML sécurisées.

Nous pouvons également personnaliser certaines configurations de sécurité.

Configurez l'en-tête http uniquement dans HTTP afin que le JS frontal ne puisse pas gérer les cookies. Vérification des entrées, en utilisant XssFilter pour filtrer les données dangereuses lorsque les utilisateurs soumettent des données. Inspection de sortie, filtre les données dangereuses lors du rendu de la page.

Signifie simplement : interdire à js d'exploiter les cookies, vérifier le HTML lors de la soumission, vérifier le HTML lors de la sortie (peut être transcodé)

2. Attaque CSRF

CSRF (Cross-site). falsification de demande) La falsification de demande intersite est une méthode d'utilisation de l'identité de l'utilisateur pour effectuer des opérations qui ne sont pas prévues par l'utilisateur.

Par exemple :

L'utilisateur s'est d'abord connecté au serveur B, puis a accédé au serveur C. Le serveur C utilise un script malveillant pour se faire passer pour A afin d'appeler une certaine fonction sur le serveur B. Pour le serveur B, il pense qu'il s'agit d'une requête initiée par A et la traite comme une requête normale.

Imaginez, si C prétend être A et effectue un transfert, cela entraînera certainement beaucoup de pertes économiques.

1) Méthodes de défense CSRF

Il existe principalement les moyens suivants pour se défendre contre le CSRF :

a. Vérification du code de vérification

Exiger de l'utilisateur pour. chaque demande Vérification pour garantir que la demande est authentique. Autrement dit : profiter du fait que les scripts malveillants ne peuvent pas reconnaître les codes de vérification complexes pour garantir que chaque demande est légale.

b. Vérification du référent

Vérifiez si le serveur qui a initié la requête est le serveur cible. Autrement dit : l'en-tête Referer dans la requête HTTP transmet le nom de domaine de la requête en cours. Si ce nom de domaine est le nom de domaine d'un serveur illégal, l'accès doit être interdit.

c.Jeton

Utilisant le principe d'imprévisibilité, chaque demande doit comporter un code aléatoire. Ce code aléatoire est enregistré par les utilisateurs normaux qui ne connaissent pas le code aléatoire et ne peuvent pas répondre à une demande. a été fait en faisant semblant d'être un utilisateur.

(Partage de vidéos d'apprentissage : Tutoriel vidéo php)

3. Détournement de clics

Le piratage de clics est une méthode d'attaque par tromperie visuelle. L'attaquant intègre le site Web qui doit être attaqué dans sa propre page Web via l'imbrication d'iframe, définit l'iframe sur transparent et révèle un bouton sur la page pour inciter les utilisateurs à cliquer.

C'est comme une image avec une couche de papier transparent dessus. Ce que vous voyez est la page de l'attaquant, mais en fait cette page n'est qu'en bas, et ce sur quoi vous cliquez réellement est la page de l'attaquant. une autre page Web.

1) Défense contre le détournement de clics

Le détournement de clics passant principalement par iframe, la défense est principalement basée sur iframe.

Option 1 : frame busting

if (self !== top) {  // 跳回原页面
  top.location = self.location;
}

Les sites Web normaux utilisent des scripts JS pour déterminer s'ils sont intégrés par des sites Web malveillants. Par exemple, si un site Web de blog détecte qu'il est ouvert par une iframe, il le fait. passera automatiquement à la page normale.

Option 2 : Utilisez l'en-tête x-frame-options en HTTP pour contrôler le chargement de l'iframe. Il a 3 valeurs facultatives :

DENY, ce qui signifie que la page n'est pas autorisée à être. affiché via iframe. SAMEORIGIN signifie que la page peut être affichée via iframe sous le même nom de domaine. ALLOW-FROM signifie que la page peut être affichée dans une iframe à partir de la source spécifiée.

配置 iframe 的 sandbox 属性：sandbox = "allow-same-origin" ，则只能加载与主站同域的资源。

（二）服务端攻击

服务器端的攻击的方式也非常多，这里列举几个常见的。

SQL 注入攻击文件上传漏洞登录认证攻击应用层拒绝服务攻击webServer 配置安全

1、SQL 注入攻击

SQL 注入和 XSS 一样，都是违背了数据和代码分离原则导致的攻击方式。

如图所示，我们利用 SQL 注入，就能在不需要密码的情况下，直接登录管理员的账号。

攻击的前提是：后端只用了简单的拼接 SQL 的方式去查询数据。

// 拼接出来的 sql 如下：select * from user where username = 'admin' or 1=1 and password = 'xxx'
// 无论密码输入什么，这条 sql 语句都能查询到管理员的信息

除此之外，SQL 注入还有以下几种方式：

a、使用 SQL 探测，猜数据库表名，列名。

通过 MySQL 内置的 benchmark 探测数据库字段。如：一段伪代码 select database as current if current[0]==='a',benchmark（10000,'猜对了'） 如果表明猜对了，就延迟 10 s 并返回成功。

b、使用存储过程执行系统命令

通过内置的方法或存储过程执行 shell 脚本。如：xp_cmdshell、sys_eval、sys_exec 等。

c、字符串截断

如：MySQL 在处理超长的字符串时，会显示警告，但会执行成功。注册一个 admin + 50 个空格的用户，会触发截断，最终新增一个 admin 用户，这样就能拥有管理员权限了。

1）SQL 注入防御

防止 SQL 注入的最好的办法就是，不要手动拼接 SQL 语句。

最佳方案，使用预编译语句绑定变量：通常是指框架提供的拼接 SQL 变量的方法。这样的语义不会发生改变，变量始终被当成变量。严格限制数据类型，如果注入了其他类型的数据，直接报错，不允许执行。使用安全的存储过程和系统函数。

2、CRLF 注入

在注入攻击中，换行符注入也是非常常见的一种攻击方式。

如果在 HTTP 请求头中注入 2 个换行符，会导致换行符后面的所有内容都被解析成请求实体部分。攻击者通常在 Set-Cookie 时，注入换行符，控制请求传递的内容。

3、文件上传漏洞

上传文件是网页开发中的一个常见功能，如果不加处理，很容易就会造成攻击。

如图所示，攻击者上传了一个木马文件，并且通过返回的 URL 进行访问，就能控制服务器。

通常我们会控制上传文件的后缀名，但也不能完全解决问题，攻击者还可以通过以下方式进行攻击：

• 伪造正常文件

• 将木马文件伪装成正常的后缀名进行上传。

• 如果要避免这个问题，我们可以继续判断上传文件的文件头前 10 个字节。

• Apache 解析方式是从后往前解析，直到找到一个认识的后缀名为止

• 如：上传一个 abc.php.rar.rar.rar 能绕过后缀名检查，但在执行时，被当成一个 php 文件进行执行。

• IIS 会截断分号进行解析

• 如：abc.asp;xx.png 能绕过后缀名检查，但在执行时，被当成一个 asp 文件进行执行。

• HTTP PUT 方法允许将文件上传到指定位置

• 通过 HTTP MOVE 方法，还能修改上传的文件名。

• 通过二者配合，就能先上传一个正常的后缀名，然后改为一个恶意的后缀名。

• PHP CGI 路径问题

• 执行 http://abc.com/test.png/xxx.php 时，会把 test.png 当做 php 文件去解析。

• 如果用户正好是把一段恶意的 php 脚本当做一张图片进行上传，就会触发这个攻击。

1）文件上传漏洞防御

防御文件上传漏洞，可以从以下几点考虑：

将文件上传的目录设置为不可执行。判断文件类型检查 MIME Type，配置白名单。检查后缀名，配置白名单。使用随机数改写文件名和文件路径上传文件后，随机修改文件名，让攻击者无法执行攻击。单独设置文件服务器的域名单独做一个文件服务器，并使用单独的域名，利用同源策略，规避客户端攻击。通常做法是将静态资源存放在 CDN 上。

4、登录认证攻击

登录认证攻击可以理解为一种破解登录的方法。攻击者通常采用以下几种方式进行破解：

• 彩虹表

• L'attaquant collecte un grand nombre de correspondances entre le texte en clair et MD5 pour déchiffrer le texte chiffré MD5 afin de retrouver le texte original.

• Pour le mot de passe MD5 dans la table arc-en-ciel, nous pouvons ajouter du sel et effectuer un cryptage secondaire pour éviter d'être piraté.

• Attaque de fixation de session

• Utilisez le mécanisme fixe SessionID du système d'application sur le serveur pour obtenir l'authentification et l'autorisation avec l'aide d'autres personnes utilisant le même ID de session.

• Une fois que l'attaquant ne parvient pas à se connecter, le backend renvoie l'ID de session. L'attaquant donne l'ID de session à un utilisateur normal pour qu'il se connecte. Une fois la connexion réussie, l'attaquant peut l'utiliser. SessionID pour faire semblant d'être un utilisateur normal pour vous connecter. .

• Ce problème peut être évité si le navigateur actualise le SessionID à chaque fois que vous vous connectez.

• La session continue d'attaquer

• Parfois, pour le bien de l'expérience utilisateur, le backend ne laissera pas l'utilisateur tant qu'il est en vie. La session n'est pas valide.

• Un attaquant peut maintenir cette session en vie en faisant constamment des requêtes.

1) Méthode de défense par authentification de connexion

Le mot de passe d'authentification multifacteur est la première ligne de défense, mais une fois la vérification du mot de passe réussie, nous pouvons continuer à vérifier : mot de passe dynamique, certificats numériques, codes de vérification SMS, etc. pour assurer la sécurité des utilisateurs. Les SMS et les pages Web étant deux systèmes totalement indépendants, il est difficile pour un attaquant d'obtenir le code de vérification SMS et ne peut donc pas mener d'attaques.

5. Attaque par déni de service de la couche application

L'attaque par déni de service de la couche application, également connue sous le nom d'attaque DDOS, fait référence à l'utilisation d'un grand nombre de requêtes pour provoquer une surcharge des ressources et rendre le serveur indisponible.

Habituellement, il existe les méthodes d'attaque DDOS suivantes :

• Attaque d'inondation SYN Flood

• Utilisez le mécanisme de négociation HTTP à 3 voies pour consommer les ressources de connexion au serveur.

• Par exemple : un attaquant lance un grand nombre de requêtes HTTP, mais n'effectue pas 3 poignées de main, mais seulement 2 poignées de main. À ce moment, le serveur continuera d'attendre jusqu'à l'expiration du délai. À ce moment-là, le serveur sera occupé à traiter un grand nombre de requêtes inutiles et n'aura pas le temps de prendre en compte les requêtes normales.

• Attaque Slowloris

• Envoie les en-têtes de requête HTTP à une vitesse très lente, consommant les ressources de connexion du serveur.

• Par exemple : un attaquant envoie un grand nombre de requêtes HTTP, mais chaque en-tête de requête est envoyé très lentement, envoyant un caractère toutes les 10 secondes afin d'attendre les données, le serveur. ne doit pas toujours maintenir la connexion, donc dès son démarrage, le nombre de connexions au serveur a été rapidement occupé.

• HTTP POST DOS

• Lors de l'envoi HTTP, spécifiez une très grande longueur de contenu, puis envoyez-la à un intervalle long, consommant le serveur ressource de connexion.

• Attaque CC

• Initier en permanence des requêtes pour certaines pages très gourmandes en ressources.

• Par exemple : certaines pages de la page nécessitent de nombreuses opérations back-end ou des requêtes de base de données très chronophages. Avec un grand nombre de requêtes, le processeur, la mémoire et d'autres ressources du serveur peuvent être occupées.

• Limite du serveur DOS

• Injecter un cookie trop long via XSS, ce qui entraîne un dépassement de la longueur de l'en-tête de requête que le serveur Web peut supporter, serveur côté Ce service sera refusé.

• ReDOS

• Visant certaines expressions régulières défectueuses, un grand nombre de requêtes sont initiées, consommant des ressources système.

1) Défense contre les attaques par déni de service de la couche application

Il n'existe actuellement pas de solution particulièrement parfaite pour les attaques par déni de service de la couche application, mais nous pouvons encore apporter quelques optimisations.

Optimisez les performances du code d'application et utilisez rationnellement des solutions de mise en cache telles que Redis et Memcache pour réduire l'utilisation des ressources CPU. Optimisez l'architecture réseau et créez un équilibrage de charge sur le backend. Les ressources statiques sont gérées à l'aide d'un CDN. Limitation de la fréquence des requêtes Le serveur calcule la fréquence des requêtes de toutes les adresses IP et filtre les adresses IP anormales pour les désactiver. Vous pouvez utiliser l'algorithme LRU pour mettre en cache les adresses IP des 1 000 premières requêtes. Si la fréquence d'une requête IP est trop élevée, désactivez-la.

En fait, l'idée principale de la gestion du DDOS est de désactiver les utilisateurs non fiables et de garantir que les ressources sont utilisées par les utilisateurs normaux.

3. Sécurité de la configuration du serveur Web

Lorsque nous déployons des applications Web, nous utilisons souvent Nginx, Apache, IIS, Tomcat, Jboss et d'autres serveurs Web eux-mêmes présentent également certains risques de sécurité. s’il est mal configuré, il est facile d’être attaqué.

Lors de la configuration du serveur Web, vous pouvez vous référer aux points suivants :

1. Exécutez le serveur Web avec les autorisations des utilisateurs

Suivez le principe du moindre privilège et exécutez le serveur Web avec le moins de privilèges, restreignez les autorisations après avoir été envahi.

2. Supprimer le backend visuel

Lors de l'exécution de serveurs Web tels que Tomcat et Jboss, un backend d'opération visuelle sera activé par défaut, fonctionnant sur le port 8080, et le premier accès n'est pas authentifié .

Un attaquant peut utiliser l'arrière-plan visuel pour charger à distance un package de guerre ou télécharger un fichier cheval de Troie pour le contrôle, nous devons donc supprimer la plate-forme visuelle.

3. Mettez à jour la version à temps

Les serveurs Web grand public corrigeront certaines vulnérabilités de temps en temps, alors n'oubliez pas de mettre à jour la version à temps.

Recommandations associées : Sécurité du serveur Web

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!