Maison >cadre php >PensezPHP >Considérations de sécurité pour ThinkPHP

Considérations de sécurité pour ThinkPHP

爱喝马黛茶的安东尼
爱喝马黛茶的安东尼avant
2019-12-16 17:33:423996parcourir

Considérations de sécurité pour ThinkPHP

Cet article discute principalement avec vous des précautions de sécurité de ThinkPHP, qui peuvent être utilisées comme pratique standard de sécurité recommandée de ThinkPHP.

Tout d'abord, il n'y a pas de sécurité absolue. Tant que vous êtes suffisamment conscient de la sécurité, vous pouvez éliminer autant que possible les risques pour la sécurité. L'utilisation standard du framework peut vous aider à éviter certains problèmes de sécurité apparemment naïfs. Les précautions de sécurité décrites dans cet article font principalement référence à la stratégie de sécurité dans l'environnement de production. Dans le cas du développement local, la sécurité n'est parfois pas la première considération pour le débogage.

Tout en considérant l'expérience de développement, ThinkPHP attache toujours une grande importance à la sécurité sous-jacente du framework. Bien que des vulnérabilités de sécurité soient fréquemment signalées, le responsable les corrigera dès que possible, et la plupart des vulnérabilités. il suffit de le développer. Cela peut être évité si les utilisateurs ont un certain niveau de sensibilisation à la sécurité. Cette année, nous avons également établi des relations de coopération avec plusieurs équipes de sécurité nationales, ce qui aidera à découvrir à l'avance et à corriger rapidement les vulnérabilités ou les dangers cachés qui pourraient survenir. être exploité dans le cadre.

Déploiement standardisé

De nombreux développeurs n'y prêtent pas une attention particulière. S'il y a un problème dans un lien, les conséquences seront les mêmes. Sérieusement, la politique de sécurité déployée est un problème de sécurité fondamental.

De nombreux développeurs ne déploient souvent pas conformément aux spécifications de déploiement officielles. Assurez-vous de pointer votre répertoire racine WEB vers le répertoire public au lieu du répertoire racine de l'application, et ne modifiez pas l'emplacement du fichier d'entrée à volonté. . Ne placez pas d'autres fichiers d'application, à l'exception des fichiers d'entrée et des fichiers de ressources, dans le répertoire public.

Désactiver le mode débogage

Lors du déploiement dans un environnement de production, assurez-vous d'avoir désactivé le mode débogage. Vous pouvez désactiver le mode débogage en modifiant les variables d'environnement.

APP_DEBUG=false

Qu'il s'agisse d'un développement local ou d'un déploiement dans un environnement de production, il n'est pas recommandé d'activer/désactiver le mode débogage directement en modifiant le fichier de configuration. Vous devez plutôt utiliser des variables d'environnement (le développement local peut définir). fichiers .env) .

Après avoir désactivé le mode de débogage, l'état de santé et la surveillance du fonctionnement du système reposent principalement sur les journaux ou le service de surveillance que vous utilisez. Par conséquent, vous devez prendre l’habitude de vérifier régulièrement les journaux et l’état d’exécution.

Demander un filtrage de variables

Ne faites jamais confiance aux entrées de l'utilisateur, c'est un sage dicton. Filtrer autant que possible les variables de requête peut prévenir efficacement la plupart des vulnérabilités et des dangers cachés.

La méthode recommandée par le framework pour obtenir les variables de requête est la méthode param de la classe Request (n'utilisez pas la méthode get ou post pour l'obtenir sauf si nécessaire, et encore moins utilisez le natif $_GET/$_POST et d'autres méthodes pour l'obtenir).

public function index(Request $request)
{
    $name = $request->param('name');
    // 在这里可以根据你的业务需求进行更严谨的过滤
    // 例如 $name = $request->param('name','','htmlentities,strtolower');
    // 或者使用验证器进行专门的验证
}

Pour les variables de requête avec des types clairs, vous pouvez utiliser le transtypage lors de l'utilisation de la méthode param, par exemple :

public function index(Request $request)
{
    // 强制转换字符串数据
    $name = $request->param('name/s');
    // 强制转换整型数据
    $name = $request->param('id/d');
    // 强制转换浮点型数据
    $name = $request->param('score/f');
}

ou utiliser directement les paramètres de la méthode pour obtenir la variable de requête

public function index(string $name)
{
    // 在这里可以根据你的业务需求进行更严谨的过滤
    // 或者使用验证器进行专门的验证
}

Si vous devez traiter toutes les données, vous pouvez définir une méthode de filtrage globale. Définissez les règles de filtrage default_filter pour différentes exigences d'application (aucune règle de filtrage par défaut). Les fonctions de filtrage de sécurité courantes incluent les stripslashes, htmlentities, htmlspecialchars, strip_tags, etc. Veuillez choisir la méthode de filtrage la plus appropriée en fonction du scénario commercial.

Si vous devez obtenir plusieurs données, il est recommandé d'utiliser la seule méthode pour spécifier le nom de la variable à obtenir afin d'éviter les problèmes d'autorisation causés par certaines soumissions de données malveillantes.

public function index(Request $request)
{
    // 指定表单数据名称
    $data = $request->only(['name','title']);
}

Lorsque vous utilisez des opérations de base de données ou de modèle pour écrire des données, vous pouvez également spécifier des champs pour éviter que des champs illégaux et indésirables ne soient écrits dans la base de données.

// 模型
User::allowField(['name','title'])
    ->save($data);
// 数据库
Db::name('user')
    ->field(['name','title'])
    ->insert($data);

Le modèle dispose également d'une fonction de champ en lecture seule pour éviter que vos données ne soient modifiées par l'extérieur.

Détection de téléchargement

La fonction de téléchargement du site Web est également un point d'entrée très facile à attaquer, le contrôle de sécurité de la fonction de téléchargement est donc particulièrement nécessaire.

La classe thinkFile du système fournit une prise en charge de la sécurité pour les téléchargements de fichiers, y compris des contrôles de légalité pour les suffixes de fichiers, les types de fichiers, la taille des fichiers et les fichiers image téléchargés. Assurez-vous d'avoir activé ces contrôles de légalité lors de l'opération de téléchargement. pouvez vous référer au chapitre de téléchargement du manuel.

Injection SQL

La requête de ThinkPHP utilise uniformément le mécanisme de pré-requête et de liaison de paramètres de préparation de PDO, ce qui peut efficacement éviter l'apparition d'une injection SQL. Mais cela ne signifie pas qu’il est absolument sûr. Si vous ne respectez pas de bonnes normes de codage, vous risquez quand même d’être exploité.

L'un des principes les plus simples est de ne pas laisser les utilisateurs décider de vos conditions de requête (ou du tri des champs) et contrôler les données de votre requête.

Pour certaines conditions de requête de chaîne (y compris les requêtes natives) ou les requêtes spéciales (y compris la partie ORDER), une liaison manuelle des paramètres est requise.

// 错误的
Db::query("select * from think_user where id=$id AND status=$statis");
// 正确的
Db::query("select * from think_user where id=? AND status=?", [ $id, $status]);
// 正确的
Db::execute("update think_user set name=:name where status=:status", [
    'name'     => 'thinkphp', 
    'status'   => 1
]);

Pour les requêtes utilisant les méthodes WhereExp et WhereRaw, vous devez également utiliser la liaison de paramètres.

Db::name('user')
    ->whereRaw('id > ? AND status = ?',[10, 1])
    ->select();

Utiliser le validateur

Pour les situations où un grand nombre de formulaires doivent être vérifiés, il est recommandé d'utiliser la fonction de validation pour vérifier uniformément la conformité des données. L'opération de validation du validateur doit être traitée à l'aide de la méthode validate dans l'étape du contrôleur ou du routage. La fonction de validation des données du modèle a été annulée dans la nouvelle version et il n'est plus recommandé de transmettre des données traitées en toute sécurité lors de l'utilisation du modèle. modèle et base de données.

Attaque XSS

跨站脚本攻击(cross-site scripting,简称 XSS),XSS是一种在web应用中的计算机安全漏洞,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。

在渲染输出的页面中,要对一些数据进行安全处理,防止被恶意利用造成XSS攻击,如果是5.1版本的话,所有的输出都已经经过了htmlentities 转义输出,确保安全。如果是5.0版本的话,你可以自定义一个xss过滤函数,在模板文件中对一些关键内容变量进行函数处理。

CSRF

CSRF 跨站请求伪造是 Web 应用中最常见的安全威胁之一,攻击者伪造目标用户的HTTP请求,然后此请求发送到有CSRF漏洞的网站,网站执行此请求后,引发跨站请求伪造攻击。攻击者利用隐蔽的HTTP连接,让目标用户在不注意的情况下单击这个链接,由于是用户自己点击的,而他又是合法用户拥有合法权限,所以目标用户能够在网站内执行特定的HTTP链接,从而达到攻击者的目的。

开启表单令牌验证,尽量开启强制路由并严格规范每个URL请求,定义单独的MISS路由规则。

遵循请求类型的使用规范并做好权限验证,删除操作必须使用DELETE请求,数据更改操作必须使用POST、PUT 或者 PATCH 请求方法,GET请求不应该更改任何数据。

会话劫持

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

有效的防护策略包括:

在每次会话启动的时候,调用regenerate方法。

Session::start();
Session::regenerate(true);

更改session配置参数,开启安全选项:

'use_trans_sid' => 0,
'httponly' => true,
'secure' => true,

升级到安全版本

官方会对一些安全隐患和潜在漏洞进行修复,并且发布一个更为安全的版本。请确认你升级到更安全的版本,确保底层的安全和健壮性。

目前各个版本的建议版本如下:

Considérations de sécurité pour ThinkPHP

业务逻辑安全

这个属于应用层面的安全,很多漏洞源于某个业务逻辑自身的安全隐患,包括没有做合理的数据验证和权限检查,尤其是涉及资金及财务层面的,一定要做更多的安全检查,并且开启事务。一个好的建议是更多的对应用进行分层设计,减少每层的复杂性,独立的分层设计便于提高安全性。

服务器安全

最后一点是运维阶段需要特别注意的,及时更新服务器的安全补丁,确保没有可利用的公开系统漏洞,包括你的数据库系统安(尤其是数据备份工作)。

PHP中文网,有大量免费的ThinkPHP入门教程,欢迎大家学习!

本文转自:https://blog.thinkphp.cn/789333

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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer