Une brève discussion sur les attaques Web dans la protection de sécurité PHP

Les attaques Web courantes sont divisées en deux catégories : l'une consiste à exploiter les vulnérabilités du serveur Web pour attaquer, telles que le débordement de tampon CGI, l'exploitation des vulnérabilités de traversée de répertoire et d'autres attaques ; l'autre consiste à exploiter les vulnérabilités de sécurité du Web ; page elle-même, comme l'injection SQL, les attaques de scripts intersites, etc. L'article suivant présente principalement la protection de sécurité PHP contre les attaques Web. Les amis qui en ont besoin peuvent s'y référer.

Attaque par injection SQL (SQL Injection)

L'attaquant insère des commandes SQL dans le champ de saisie du formulaire Web ou dans la chaîne de la requête de page, trompant le serveur exécution d'une commande SQL malveillante. Dans certains formulaires, les entrées utilisateur sont utilisées directement pour construire (ou affecter) des commandes SQL dynamiques, ou comme paramètres d'entrée pour des procédures stockées. De tels formulaires sont particulièrement vulnérables aux attaques par injection SQL.

Les processus d'attaque par injection SQL courants sont les suivants :

1. Une certaine application Web a une page de connexion qui contrôle si l'utilisateur est autorisé à accéder à l'application. nécessite L'utilisateur saisit un nom et un mot de passe ;

2. Le contenu saisi sur la page de connexion sera directement utilisé pour construire des commandes SQL dynamiques, ou directement utilisé comme paramètres de procédures stockées ; 🎜>
Par exemple :

3. L'attaquant saisit quelque chose comme ' ou '1'='1 dans la zone de saisie du nom d'utilisateur et du mot de passe

$query = 'SELECT * from Users WHERE login = ' . $username . ' AND password = ' . $password;

; 4. Une fois le contenu saisi par l'utilisateur soumis au serveur, le serveur exécute le code ci-dessus pour construire une commande SQL permettant d'interroger l'utilisateur. Cependant, comme le contenu saisi par l'attaquant est très spécial, la commande SQL finale devient :

5. Le serveur exécute une requête ou une procédure stockée pour comparer les informations d'identité saisies par l'utilisateur avec les informations d'identité enregistrées dans le serveur

SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'；

6. Depuis le La commande SQL a effectivement été modifiée par une attaque par injection, elle ne peut plus être utilisée. Authentifie réellement l'utilisateur donc le système autorise incorrectement l'attaquant.

Si un attaquant sait que l'application utilisera directement le contenu saisi dans le formulaire pour des requêtes de vérification d'identité, il tentera de saisir des chaînes SQL spéciales pour falsifier la requête et modifier sa fonctionnalité d'origine en tromper Le système accorde l'accès.

L'environnement système est différent, et les dommages qu'un attaquant peut causer sont également différents. Ceci est principalement déterminé par les autorisations de sécurité de l'application pour accéder à la base de données. Si le compte de l'utilisateur dispose d'autorisations d'administrateur ou d'autres autorisations relativement avancées, l'attaquant peut effectuer diverses opérations sur les tables de la base de données qu'il souhaite effectuer, notamment l'ajout, la suppression ou la mise à jour de données, ou même la suppression directe de la table

Méthodes de prévention :

1. Vérifiez le type et le format des données variables

2. Filtrez les symboles spéciaux

3. Lier variables et utiliser des instructions précompilées

Cross Site Scripting (XSS)

L'attaquant injecte du code malveillant dans la page Web, et d'autres Le code sera exécuté lorsque l'utilisateur chargera le page Web, et l'attaquant peut obtenir divers contenus, y compris, mais sans s'y limiter, des autorisations plus élevées (telles que l'exécution de certaines opérations), du contenu Web privé, des sessions, des cookies, etc. Ces codes malveillants sont généralement du JavaScript, du HTML et d'autres langages de script côté client.

Par exemple :

Si un script 3f1c4e4b6b16bbbd69b2ee476dc4f83a[code]2cacc6d41bbb37262a98f745aa00fbf0 est transmis, le script sera également exécuté. L'utilisation d'une telle URL exécutera la fonction d'alerte JavaScript et fera apparaître une boîte de dialogue : http://localhost/test.php?name=3f1c4e4b6b16bbbd69b2ee476dc4f83aalert(123456)2cacc6d41bbb37262a98f745aa00fbf0

<?php
echo "欢迎您，".$_GET[&#39;name&#39;];

Les méthodes d'attaque couramment utilisées incluent :

voler des cookies pour obtenir des informations sensibles

en utilisant iframe, frame, XMLHttpRequest ou Flash mentionné ci-dessus ; à (Sous attaque) L'identité de l'utilisateur effectue certaines actions de gestion ou effectue certaines opérations générales telles que la publication sur Weibo, l'ajout d'amis, l'envoi de messages privés, etc.

Utiliser un domaine attaquable pour être digne de confiance ; par d'autres domaines Caractéristiques : Demander certaines opérations qui ne sont normalement pas autorisées en tant que source fiable, telles que la conduite d'activités de vote inappropriées. Les effets des attaques DDoS ;

Méthode de prévention : utilisez la fonction htmlspecialchars pour convertir les caractères spéciaux en codage HTML et filtrer les variables de sortie

Cross Site Request Forgeries (CSRF)

L'attaquant falsifie la requête HTTP de l'utilisateur cible, puis envoie cette requête à un site Web présentant une vulnérabilité CSRF. Une fois que le site Web a exécuté cette requête, une attaque de falsification de requête intersites est déclenchée. L'attaquant utilise une connexion HTTP secrète pour permettre à l'utilisateur cible de cliquer sur ce lien sans s'en apercevoir. Étant donné que l'utilisateur a cliqué dessus lui-même et qu'il est un utilisateur légitime disposant d'autorisations légales, l'utilisateur cible peut exécuter un lien HTTP spécifique dans le site Web pour y parvenir. le but de l'attaquant.

C'est différent de la méthode d'attaque XSS qui intéresse les utilisateurs victimes.

Par exemple :

某个购物网站购买商品时，采用http://www.shop.com/buy.php?item=watch&num=100，item参数确定要购买什么物品，num参数确定要购买数量，如果攻击者以隐藏的方式发送给目标用户链接
，那么如果目标用户不小心访问以后，购买的数量就成了100个

防范方法：

      1、检查网页的来源

      2、检查内置的隐藏变量

      3、使用POST，不要使用GET，处理变量也不要直接使用$_REQUEST

Session固定攻击(Session Fixation)

这种攻击方式的核心要点就是让合法用户使用攻击者预先设定的session id来访问被攻击的应用程序，一旦用户的会话ID被成功固定，攻击者就可以通过此session id来冒充用户访问应用程序。

例如:

1.攻击者访问网站http:///www.bank.com，获取他自己的session id，如：SID=123；

2.攻击者给目标用户发送链接，并带上自己的session id，如：http:///www.bank.com/?SID=123；

3.目标用户点击了http:///www.bank.com/?SID=123，像往常一样，输入自己的用户名、密码登录到网站；

4.由于服务器的session id不改变，现在攻击者点击http:///www.bank.com/?SID=123，他就拥有了目标用户的身份，可以为所欲为了。

防范方法：

1.定期更改session id

session_regenerate_id(TRUE);//删除旧的session文件，每次都会产生一个新的session id。默认false，保留旧的session

2.更改session的名称

session的默认名称是PHPSESSID，此变量会保存在cookie中，如果攻击者不抓包分析，就不能猜到这个名称，阻挡部分攻击

session_name("mysessionid");

3.关闭透明化session id

透明化session id指当浏览器中的http请求没有使用cookie来制定session id时，sessioin id使用链接来传递

int_set("session.use_trans_sid", 0);

4.只从cookie检查session id

int_set("session.use_cookies", 1);//表示使用cookies存放session id
int_set("session.use_only_cookies", 1);//表示只使用cookies存放session id

5.使用URL传递隐藏参数

$sid = md5(uniqid(rand()), TRUE));
$_SESSION["sid"] = $sid;//攻击者虽然能获取session数据，但是无法得知$sid的值，只要检查sid的值，就可以确认当前页面是否是web程序自己调用的

Session劫持攻击(Session Hijacking)

会话劫持是指攻击者利用各种手段来获取目标用户的session id。一旦获取到session id，那么攻击者可以利用目标用户的身份来登录网站，获取目标用户的操作权限。

攻击者获取目标用户session id的方法:

1.暴力破解:尝试各种session id，直到破解为止;

2.计算:如果session id使用非随机的方式产生，那么就有可能计算出来;

3.窃取:使用网络截获，xss攻击等方法获得

防范方法：

      1.定期更改session id

      2.更改session的名称

      3.关闭透明化session id

      4.设置HttpOnly。通过设置Cookie的HttpOnly为true，可以防止客户端脚本访问这个Cookie，从而有效的防止XSS攻击。

文件上传漏洞攻击(File Upload Attack)

文件上传漏洞指攻击者利用程序缺陷绕过系统对文件的验证与处理策略将恶意代码上传到服务器并获得执行服务器端命令的能力。

常用的攻击手段有：

上传Web脚本代码，Web容器解释执行上传的恶意脚本；

上传Flash跨域策略文件crossdomain.xml，修改访问权限(其他策略文件利用方式类似)；

上传病毒、木马文件，诱骗用户和管理员下载执行；

上传包含脚本的图片，某些浏览器的低级版本会执行该脚本，用于钓鱼和欺诈。

总的来说，利用的上传文件要么具备可执行能力(恶意代码)，要么具备影响服务器行为的能力(配置文件)。

防范方法：

      1.文件上传的目录设置为不可执行；

      2.判断文件类型，设置白名单。对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码；

      3.使用随机数改写文件名和文件路径：一个是上传后无法访问；再来就是像shell.php.rar.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击；

      4.单独设置文件服务器的域名：由于浏览器同源策略的关系，一系列客户端攻击将失效，比如上传crossdomain.xml、上传包含Javascript的XSS利用等问题将得到解决。

以上就是关于PHP安全防护之Web攻击的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流。感谢大家支持php中文网！