ThinkPHP のセキュリティに関する考慮事項

爱喝马黛茶的安东尼
リリース: 2019-12-16 17:33:42
転載
3943 人が閲覧しました

ThinkPHP のセキュリティに関する考慮事項

この記事では主に、ThinkPHP のセキュリティ上の注意事項について説明します。これは、ThinkPHP の推奨セキュリティ標準プラクティスとして使用できます。

まず、絶対的な安全はありませんが、十分な安全意識を持っていれば、安全上の危険を可能な限り排除することができます。フレームワークを標準的に使用すると、一見素朴なセキュリティ問題を回避できます。この記事で説明するセキュリティ上の注意事項は、主に本番環境でのセキュリティ戦略を指しますが、ローカル開発の場合、デバッグ時にセキュリティが最優先に考慮されない場合があります。

ThinkPHP は、開発経験を考慮しながらも、フレームワークの根本的なセキュリティを非常に重視しています。セキュリティの脆弱性は頻繁に報告されていますが、公式はそれらをできるだけ早く修正し、ほとんどの脆弱性は開発するだけでよい これは、ユーザーが一定のセキュリティ意識を持っていれば回避できるものですが、今年は国内の複数のセキュリティチームとの協力関係も構築し、脆弱性や隠れた危険を事前に発見し、迅速に修正することが可能です。フレームワーク内で悪用される可能性があります。

標準化された展開

多くの開発者は、この点に特別な注意を払っていません。セキュリティは全体的な問題です。リンクに問題がある場合、その結果は次のとおりです。真剣に、導入されたセキュリティ ポリシーは基本的なセキュリティ問題です。

多くの開発者は、公式の展開仕様に従って展開しないことがよくあります。必ず WEB ルート ディレクトリがアプリケーション ルート ディレクトリではなくパブリック ディレクトリを指すようにし、エントリ ファイルの場所を勝手に変更しないでください。 。エントリーファイルとリソースファイル以外のアプリケーションファイルはパブリックディレクトリ配下に配置しないでください。

デバッグ モードをオフにする

運用環境にデプロイする場合は、デバッグ モードをオフにしてください。環境変数を変更することでデバッグ モードをオフにできます。

APP_DEBUG=false
ログイン後にコピー

ローカル開発であっても実稼働環境への展開であっても、構成ファイルを変更してデバッグ モードを直接オン/オフにすることはお勧めできません。代わりに、環境変数を使用する必要があります (ローカル開発では定義できます)。 .env ファイル) 。

デバッグ モードをオフにした後は、システムの健全性ステータスと動作の監視は主にログまたは使用する監視サービスに依存します。したがって、ログや実行状況を定期的に確認する習慣を身に付ける必要があります。

リクエスト変数フィルタリング

ユーザー入力を決して信用しないでください。これは賢明な言葉です。リクエスト変数を可能な限りフィルタリングすることで、ほとんどの脆弱性や隠れた危険を効果的に防ぐことができます。

リクエスト変数を取得するためにフレームワークが推奨するメソッドは、Request クラスの param メソッドです (必要な場合を除き、get メソッドや post メソッドを使用して取得しないでください。ましてや、ネイティブの $_GET/$_POST や他の方法で取得できます)。

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

明確な型を持つリクエスト変数の場合、param メソッドを使用するときに型キャストを使用できます。例:

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

または、メソッド パラメータを直接使用してリクエスト変数を取得します

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

すべてのデータを処理する必要がある場合は、グローバル フィルタリング方法を設定できます。さまざまなアプリケーション要件に応じて、default_filter フィルタリング ルールを設定します (デフォルトではフィルタリング ルールはありません)。一般的なセキュリティ フィルタリング機能には、stripslashes、htmlentities、htmlspecialchars、strip_tags などが含まれます。ビジネス シナリオに応じて最適なフィルタリング方法を選択してください。

複数のデータを取得する必要がある場合は、悪意のあるデータ送信によって引き起こされる権限の問題を避けるために、取得する変数名を指定する唯一の方法を使用することをお勧めします。

public function index(Request $request)
{
    // 指定表单数据名称
    $data = $request->only(['name','title']);
}
ログイン後にコピー

データベース操作またはモデル操作を使用してデータを書き込む場合、不正なフィールドや不要なフィールドがデータベースに書き込まれるのを避けるためにフィールドを指定することもできます。

// 模型
User::allowField(['name','title'])
    ->save($data);
// 数据库
Db::name('user')
    ->field(['name','title'])
    ->insert($data);
ログイン後にコピー

モデルには、データが外部から変更されるのを防ぐ読み取り専用フィールド関数もあります。

アップロードの検出

Web サイトのアップロード機能も非常に攻撃されやすい入り口であるため、アップロード機能のセキュリティ チェックは特に必要です。

システムの think\File クラスは、ファイル サフィックス、ファイル タイプ、ファイル サイズ、アップロードされた画像ファイルの合法性チェックなど、ファイル アップロードのセキュリティ サポートを提供します。アップロード操作中にこれらの合法性が有効になっていることを確認してください。性的検査については、マニュアルのアップロードの章を参照してください。

SQL インジェクション

ThinkPHP のクエリは、PDO のプリペアクエリとパラメータバインディングメカニズムを均一に使用するため、SQL インジェクションの発生を効果的に回避できます。しかし、それが絶対に安全であるというわけではなく、適切なコーディング標準を備えていない場合、依然として悪用される可能性があります。

最も単純な原則の 1 つは、ユーザーにクエリ条件 (またはフィールドの並べ替え) を決定させたり、クエリ データを制御させたりしないことです。

一部の文字列クエリ条件 (ネイティブ クエリを含む) または特殊なクエリ (ORDER 部分を含む) では、手動パラメータ バインディングが必要です。

// 错误的
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
]);
ログイン後にコピー

whereExp メソッドと whereRaw メソッドを使用するクエリの場合は、パラメーター バインディングも使用する必要があります。

Db::name('user')
    ->whereRaw('id > ? AND status = ?',[10, 1])
    ->select();
ログイン後にコピー

バリデーターの使用

多数のフォームを検証する必要がある状況では、データのコンプライアンスを均一に検証するためにバリデーター関数を使用することをお勧めします。バリデーターの検証操作は、コントローラーまたはルーティング ステージで validate メソッドを使用して処理される必要があります。モデルのデータ検証機能は、新しいバージョンではキャンセルされ、推奨されなくなりました。バリデーターの操作時には、安全に処理されたデータが渡される必要があります。モデルとデータベース。

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,
ログイン後にコピー

升级到安全版本

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

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

ThinkPHP のセキュリティに関する考慮事項

业务逻辑安全

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

服务器安全

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

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

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

以上がThinkPHP のセキュリティに関する考慮事項の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:thinkphp.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート
私たちについて 免責事項 Sitemap
PHP中国語ウェブサイト:福祉オンライン PHP トレーニング,PHP 学習者の迅速な成長を支援します!