PHP 開発における CSRF 攻撃の実証と防止-PHPチュートリアル-php.cn

PHP 開発における CSRF 攻撃の実証と防止

墨辰丷

リリース： 2023-03-27 13:50:01

オリジナル

1384 人が閲覧しました

CSRFの正式名称はCross-site request forgery、中国語名はクロスサイトリクエストフォージェリー（クロスサイトリクエストの偽造（もっとスムーズに読んでください））といい、ユーザーに非運用的な行為を強制する手法です。ログインした Web アプリケーションに対するリクエスト、意図した操作の攻撃方法。 XSS と比較すると、CSRF はページブラウザーに対するシステムの信頼を利用し、XSS はユーザーに対するシステムの信頼を利用します。

csrf 攻撃、つまりクロスサイトリクエストフォージェリクロスサイト (ドメイン名) リクエストフォージェリ、フォージェリとは偽造の意味です。 CSRF についてはインターネット上に多数紹介されています。たとえば、CSRF の攻撃方法については、上級記事で詳しく説明されています。CSRF 攻撃の実現は、次のような単純な事実に依存しています。 Web を閲覧するためにブラウザを使用する場合、通常はいくつかのブラウザタブ (またはウィンドウ) を開きます。サイト A にログインすると、サイト A が Cookie を通じてユーザーのセッションを追跡すると、ユーザーがサイト A にログインした後、サイト A は次のことを行います。サイト A に siteA-page.php (URL リソース) というページがあり、サイト B が URL アドレスを知っており、このページのアドレスが siteB-page.php のページに埋め込まれている場合、ユーザーのクライアントで Cookie を設定します。このとき、ユーザーはサイト A のセッションを維持しながらサイト B の siteB-page.php を開きます。その後、siteB-page.php ページがこの URL アドレスをトリガーできる限り (URL をリクエストします)サイト A のリソース）、CSRF 攻撃が達成されます。

上記の説明は非常にわかりにくいので、簡単な例を示してみましょう。

1、バックグラウンドおよび通常のリクエストプロセス

サイトのドメイン名は html5.yang.com で、/get-update.php?uid=uid&username=username アドレスがあり、このアドレスはget メソッドいくつかのパラメーター。このページのロジックが次の場合: uid が正当であるかどうかを判断してユーザー名を更新します。このページのスクリプトは次のとおりです:

<?php
// 这里简便起见, 从data.json中取出数据代替请求数据库
$str = file_get_contents(&#39;data.json&#39;);
$data = json_decode($str, true);

// 检查cookie和请求更改的uid, 实际应检查数据库中的用户是否存在
empty($_COOKIE[&#39;uid&#39;]) ||empty($_GET[&#39;uid&#39;]) || $_GET[&#39;uid&#39;] != $data[&#39;id&#39;] ? die(&#39;非法用户&#39;) : &#39;&#39;;
// 检查username参数
$data[&#39;username&#39;] = empty($_GET[&#39;username&#39;]) ? die(&#39;用户名不能为空&#39;) : $_GET[&#39;username&#39;];

// 更新数据
$data[&#39;username&#39;] = $_GET[&#39;username&#39;];
if(file_put_contents(&#39;data.json&#39;, json_encode($data))) {
  echo "用户名已更改为{$data[&#39;username&#39;]}<br>";
} else {
  die(&#39;更新失败&#39;);
}

ログイン後にコピー

通常、このページへのリンクはサイト A の下に配置されます。たとえば、サイト A の csrfdemo.php ページでは、ユーザーはサイト A にログインした後、このリンクをクリックしてリクエストを送信できます。たとえば、サイト A には次のリンクを含むページスクリプトがあります:

<?php
// 这里用一个data.json文件保存用户数据,模拟数据库中的数据
// 先初始化data.json中的数据为{"id":101,"username":"jack"}, 注意这句只让它执行一次, 然后把它注释掉
// file_put_contents(&#39;data.json&#39;,&#39;{"id":101,"username":"jack"}&#39;);

$data = json_decode(file_get_contents(&#39;data.json&#39;), true);

// 这里为了简便, 省略了用户身份验证的过程
if ($data[&#39;username&#39;]) {
  // 设置cookie
  setcookie(&#39;uid&#39;, $data[&#39;id&#39;], 0);
  echo "登录成功, {$data[&#39;username&#39;]}<br>";
}
?>

 <a href="http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=json" rel="external nofollow" >
  更新用户名为json
 </a>

ログイン後にコピー

次のようにこのページをロードします:

ページ上のリンクをクリックして get-update.php ページに移動します:

上記は通常のリクエストプロセスです。サイト B が CSRF 攻撃をどのように実装しているかを見てください。

2. CSRF 攻撃の最も単純な実装

サイト B のドメイン名は test.yang.com で、ユーザーがサイト A のセッションを維持したままこのページを開くと、サイト B には csrf.php というページがあります。 Bはcsrf攻撃を達成できます。なぜ開かれるのかというと…、実はこの状況はWebを閲覧する際によくあることなのですが、例えばこのブログを書いているときにCSRFについて何かわからないなと思って、行ってみたんです。 Baidu へまあ、Baidu からの結果がたくさんあります。CSRF を非常に詳しく権威ある方法で紹介する CSRF Encyclopedia Knowledge という Web サイトがあれば、おそらくクリックしてしまいますが、この Web サイトは実際にはフィッシング Web サイトです。ある Web サイト上で、よくアクセスするページに私のブログ編集ページの URL アドレスが埋め込まれているため、私のブログに CSRF 攻撃が仕掛けられる可能性があります。さて、本題に入りましょう。csrf.php スクリプトコードを見てみましょう:

<?php
?>
<img src="http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=jsonp">

ログイン後にコピー

上記のコードには PHP コードがなく、img タグと、 img タグは、ユーザー名を更新するサイト A のタグです。リンク、ユーザー名を jsonp に変更し、サイト B の csrf.php ページにアクセスします:

次に、サイト A の csrfdemo.php ページにアクセスします。

ユーザー名が jsonp に変更されていることがわかります。

簡単な分析: サイト B の csrf.php は HTML で img タグを使用しており、img タグには src 属性があり、その属性値はロードする必要がある画像のアドレスを指していることは誰もが知っています。ページがロードされ、画像をロードすることは、src が指すアドレスへの http リクエストを開始することと同じです。画像アドレスをスクリプトアドレスに変更するだけで済み、最も単純な CSRF 攻撃が実現します。このように、CSRF は実際には非常に簡単に実装できますが、誰もが「紳士」であり、そのような「卑劣な」ことをするために暇な人はいません。ただし、他人を傷つける意図を持ってはなりませんし、他人を警戒する意図を持ってはいけません。この最も単純な CSRF 攻撃を簡単に防ぐ方法を見てみましょう。

3. 簡単な予防策

実際、サイト A は get-update.php スクリプトでリクエストヘッダーのソースを特定できます。以下は get-update.php にあります。コードを追加します:

<?php
// 检查上一页面是否为当前站点下的页面
if (!empty($_SERVER[&#39;HTTP_REFERER&#39;])) {
  if (parse_url($_SERVER[&#39;HTTP_REFERER&#39;], PHP_URL_HOST) != &#39;html5.yang.com&#39;) {
    // 可以设置http错误码或者指向一个无害的url地址
    //header(&#39;HTTP/1.1 404 not found&#39;);
    //header(&#39;HTTP/1.1 403 forbiden&#39;);
    header(&#39;Location: http://html5.yang.com/favicon.ico&#39;);
    // 这里需要注意一定要exit(), 否则脚本会接着执行
    exit();
  }
 }

$str = file_get_contents(&#39;data.json&#39;);
// 代码省略

ログイン後にコピー

但是，这样就万事大吉了吗，如果http请求头被伪造了呢？A站点升级了防御，B站点同时也可以升级攻击，通过curl请求来实现csrf，修改B站点的csrf.php代码如下：

<?php
$url = &#39;http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=jsonp&#39;;
$refer = &#39;http://html5.yang.com/&#39;;
// curl方法发起csrf攻击
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
// 设置Referer
curl_setopt($ch, CURLOPT_REFERER, $refer);
// 这里需要携带上cookie, 因为A站点get-update.php对cooke进行了判断
curl_setopt($ch, CURLOPT_COOKIE, &#39;uid=101&#39;);
curl_exec($ch);
curl_close($ch);
?>
<img src="http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=jsonp">

ログイン後にコピー

这样同样可以实现csrf攻击的目的。那么就没有比较好的防范方法了吗？

4，小结

下面我们回到问题的开始，站点A通过cookie来跟踪用户会话，在cookie中存放了重要的用户信息uid，get-update.php脚本通过判断用户的cookie正确与否来决定是否更改用户信息，看来靠cookie来跟踪会话并控制业务逻辑是不太安全的，还有最严重的一点：get-update.php通过get请求来修改用户信息，这个是大忌。所以站点A可以接着升级防御：用session来代替cookie来跟踪用户会话信息，将修改用户信息的逻辑重写，只允许用post方法来请求用户信息。站点B同样可以升级攻击：curl可以构造post请求，劫持session等等，不过这些我还没研究过，后续再说吧。