項(xiàng)目五

安全的個(gè)人信息修改Web安全與防護(hù)本任務(wù)要點(diǎn)學(xué)習(xí)目標(biāo)檢測和驗(yàn)證跨站請求偽造漏洞熟悉跨站請求偽造漏洞的檢測方法熟悉跨站請求偽造漏洞的利用方法任務(wù)三

跨站請求偽造漏洞檢測與驗(yàn)證目錄CONTENTS01/跨站請求偽造漏洞檢測與驗(yàn)證跨站請求偽造漏洞檢測與驗(yàn)證01從任務(wù)二可知，CSRF攻擊是攻擊者借助受害者的cookie騙取服務(wù)器的信任，但是攻擊者并不能拿到cookie，也看不到cookie的內(nèi)容。另外，對于服務(wù)器返回的結(jié)果，由于瀏覽器同源策略的限制，攻擊者也無法進(jìn)行解析。因此，攻擊者無法從返回的結(jié)果中得到任何東西，他所能做的就是給服務(wù)器發(fā)送請求，以執(zhí)行請求中所描述的命令，在服務(wù)器端直接改變數(shù)據(jù)的值，而非竊取服務(wù)器中的數(shù)據(jù)。在本書第2.1章節(jié)開發(fā)的代碼中，代碼僅僅驗(yàn)證用戶是否已登錄，若登記即可以修改口令，也沒有驗(yàn)證原口令，所有這里明顯存在CSRF漏洞項(xiàng)目五

安全的個(gè)人信息修改Web安全與防護(hù)本任務(wù)要點(diǎn)學(xué)習(xí)目標(biāo)對跨站請求偽造漏洞進(jìn)行修復(fù)和防范熟悉跨站請求偽造漏洞的修復(fù)防范方法任務(wù)四

跨站請求偽造漏洞修復(fù)與防范目錄CONTENTS01/同源檢測02/Samesite

Cookie03/CSRF

Token04/特定情況下的必要驗(yàn)證同源檢測01既然CSRF大多來自第三方網(wǎng)站，那么我們就直接禁止外域（或者不受信任的域名）對我們發(fā)起請求。在HTTP協(xié)議中，每一個(gè)異步請求都會(huì)攜帶兩個(gè)Header，用于標(biāo)記來源域名：OriginHeader和RefererHeader。通過Header的驗(yàn)證，我們可以知道發(fā)起請求的來源域名，這些來源域名可能是網(wǎng)站本域，或者子域名，或者有授權(quán)的第三方域名，又或者來自不可信的未知域名。在Web應(yīng)用中檢查請求頭中的Header字段，確保請求來自合法的來源。但是，這種方式并不是完全可靠的，因?yàn)楣粽呖梢酝ㄟ^篡改HTTP請求頭的方式繞過Header檢查。Samesite

Cookie02為了從源頭上解決CSRF攻擊，Google起草了一份草案來改進(jìn)HTTP協(xié)議，那就是為Set-Cookie響應(yīng)頭新增Samesite屬性，它用來標(biāo)明這個(gè)Cookie是個(gè)“同站Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite有兩個(gè)屬性值，分別是Strict和Lax。Strict最為嚴(yán)格，完全禁止第三方Cookie，跨站點(diǎn)時(shí)，任何情況下都不會(huì)發(fā)送Cookie。換言之，只有當(dāng)前網(wǎng)頁的URL與請求目標(biāo)一致，才會(huì)帶上Cookie

：Set-Cookie:CookieName=CookieValue;SameSite=Strict;

這個(gè)規(guī)則過于嚴(yán)格，可能造成非常不好的用戶體驗(yàn)。比如，當(dāng)前網(wǎng)頁有一個(gè)GitHub鏈接，用戶點(diǎn)擊跳轉(zhuǎn)就不會(huì)帶有GitHub的Cookie，跳轉(zhuǎn)過去總是未登陸狀態(tài)。Lax規(guī)則稍稍放寬，大多數(shù)情況也是不發(fā)送第三方Cookie，但是導(dǎo)航到目標(biāo)網(wǎng)址的Get請求除外。

Set-Cookie:CookieName=CookieValue;SameSite=Lax;

CSRF

Token03<?php//

生成CSRF

Tokensession_start();if

(!isset($_SESSION['csrf_token']))

{

$_SESSION['csrf_token']

=

md5(uniqid(mt_rand(),

true));}$csrf_token

=

$_SESSION['csrf_token'];//

驗(yàn)證CSRF

Tokenif

($_SERVER['REQUEST_METHOD']

===

'POST')

{

if

(!isset($_POST['csrf_token'])

||

$_POST['csrf_token']

!==

$csrf_token)

{

die('Invalid

CSRF

token');

}

//

處理表單請求}?><!--

表單中包含CSRF

Token

--><form

action="submit.php"

method="post">

<input

type="hidden"

name="csrf_token"

value="<?php

echo

$csrf_token;

?>">

<!--

其他表單字段

-->

<input

type="submit"

value="提交"></form>在應(yīng)用程序中使用CSRFToken可以有效地防止CSRF攻擊。CSRFToken是在服務(wù)器端生成的一段隨機(jī)字符串，該字符串與用戶會(huì)話相關(guān)聯(lián)，作為表單隱藏字段或請求參數(shù)的一部分，一起發(fā)送給客戶端瀏覽器。當(dāng)客戶端提交表單或請求時(shí)，服務(wù)器端會(huì)驗(yàn)證請求中的Token是否與用戶會(huì)話中的Token一致，如果一致則認(rèn)為請求是合法的，否則拒絕請求。這樣，即使攻擊者成功偽造了請求，也無法獲取有效的令牌信息，從而無法完成攻擊。特定情況下的必要驗(yàn)證04<?phpsession_start();

//

驗(yàn)證用戶是否已登錄if

(!isset($_SESSION['user_id']))

{header('Location:

login.php');exit();}

//

處理表單提交if

(isset($_POST['old_password'])

&&

isset($_POST['new_password'])

&&

isset($_POST['confirm_password']))

{$old_password

=

$_POST['old_password'];$new_password

=

$_POST['new_password'];$confirm_password

=

$_POST['confirm_password'];

//

連接數(shù)據(jù)庫$db

=

new

PDO('mysql:host=localhost;dbname=blog',

'username',

'password');

//

查詢用戶的密碼$stmt

=

$db->prepare('SELECT

password

FROM

users

WHERE

id

=

?');$stmt->execute([$_SESSION['user_id']]);$user

=

$stmt->fetch();

//

檢查舊密碼是否正確if

(password_verify($old_password,

$user['password']))

{//

檢查新密碼是否匹配確認(rèn)密碼if

($new_password

===

$confirm_password)

{//

更新用戶的密碼$stmt

=

$db->prepare('UPDATE

users

SET

password

=

?

WHERE

id

=

?');$stmt->execute([password_hash($new_password,

PASSWORD_DEFAULT),

$_SESSION['user_id']]);echo

'密碼已更新！';}

else

{echo

'新密碼與確認(rèn)密碼不匹配。';}}

else

{echo

'舊密碼不正確。';}}?>在特定情況下加入一些特定的驗(yàn)證來防止CSRF攻擊，當(dāng)用戶在應(yīng)用程序中執(zhí)行敏感操作時(shí)，應(yīng)用程序可以要求用戶提供額外的驗(yàn)證信息，例如輸入密碼或者提供其他的身份信息。以任務(wù)一舉例，任務(wù)一中的口令修改可以添加原口令驗(yàn)證，驗(yàn)證成功再修改口令：課堂實(shí)踐一、任務(wù)名稱：檢測利用跨站請求偽造漏洞并進(jìn)行修復(fù)二、任務(wù)內(nèi)容：審計(jì)項(xiàng)目五任務(wù)一所開發(fā)的博客系統(tǒng)個(gè)人信息修改功能代碼，找出跨站請求偽造漏洞并對代碼進(jìn)行修改三、工具需求：瀏覽器、Vscode、Apache、MySQL、PHP四、任務(wù)要求：小組實(shí)操后輪流進(jìn)行展示，老師進(jìn)行點(diǎn)