Open TsaiChihWei opened 4 years ago
此篇內容節錄並改寫自 讓我們來談談 CSRF 和 1 2 請說明雜湊跟加密的差別在哪裡，為什麼密碼要雜湊過後才存入資料庫
此篇內容節錄並改寫自 讓我們來談談 CSRF 和 1 2
雜湊與加密最大的差別在於，雜湊是不可逆的，而加密可逆。使用者的密碼先經過雜湊函式再存入資料庫，即便防止資料庫遭入侵，攻擊者也無法直接看到明碼。
雜湊的特性：
include
require
include_once
require_once
require 與 include 除了引入檔案失敗之後的行為不同之外，可以看成是相同的。 include 引入的檔案發生錯誤的話，會顯示警告，會繼續執行後面的程式碼； 而 require 則是會顯示錯誤，立刻終止程式，不再往下執行。 require_once 和 include_once 會判斷檔案是否重複引入，如果沒有才會去執行引入動作。
攻擊原理：攻擊者利用組合、拼湊的方式注入夾帶惡意 SQL 指令，夾帶進去的惡意指令就會被資料庫伺服器誤認為是正常的 SQL 指令而執行，因此遭到破壞或是入侵。 防範方法：利用 prepare statement 使資料庫不會將攻擊者輸入的內容當成程式碼來執行。
全名為 Cross-site scripting 即「跨網站指令碼」。
攻擊原理：攻擊者注入惡意程式碼（通常是 HYML 及 JavaScript），目的有竊取 Cookie、將頁面導向釣魚網站等等。 防範方法：將注入的惡意程式碼跳脫字元。 PHP 有內建 htmlspecialchars()，JavaScript 可以自己寫一個 escape() function 例：
htmlspecialchars()
escape()
function escape(unsafe) { return unsafe .replace(/&/g, "&") .replace(/</g, "<") .replace(/>/g, ">") .replace(/"/g, """) .replace(/'/g, "'"); }
全名為 Cross-site request forgery 即「跨站請求偽造」又稱作 one-click attack。
攻擊原理：攻擊者利用瀏覽器自動帶上 Cookie 的機制，欺騙用戶的瀏覽器，以受害者的名義傳送惡意請求去做一些未經過授權的操作。 範例：
防範方法：
客戶端：每次使用完網站就登出，讓認證狀態無法維持被利用。
伺服器端：
檢查 Referer：request 的 header 裡面會帶一個欄位叫做 referer，代表這個 request 是從哪個地方過來的，可以檢查這個欄位看是不是合法的 domain，不是的話直接 reject 掉即可。需要注意的地方有三點：
圖型、簡訊驗證：網路銀行轉帳或消費時需要輸入簡訊認證碼
CSRF token：在 form 裡面加上一個 hidden 的欄位，name 為 csrftoken，值為 server 隨機產生，並存在 server 的 session 中，在 submit 後，透過比對表單中的 csrftoken 與 session 內的值是否一致，藉此判斷是否為本人所發送的 request
Double Submit Cookie：方式與上相同，但改儲存在使用者端的 cookie 內，伺服器收到資料時比對 cookie 內的 token 與 form 內的 token 是否相等。
設定 SameSite cookie：原理就是幫 Cookie 再加上一層驗證，分為兩種模式，第一種為 strict 模式任何來自不同網域的 request 都不會帶上 cookie;第二種為 Lax 模式，放寬了一些限制，例如說 <a>, <link rel="prerender">, <form method="GET"> 這些都還是會帶上 cookie。但是 POST 方法 的 form，或是只要是 POST, PUT, DELETE 這些方法，就不會帶上 cookie，但 Lax 模式之下就沒辦法擋掉 GET 形式的 CSRF，這點要特別注意一下。
strict 模式
Lax 模式
<a>
<link rel="prerender">
<form method="GET">
雜湊與加密最大的差別在於，雜湊是不可逆的，而加密可逆。使用者的密碼先經過雜湊函式再存入資料庫，即便防止資料庫遭入侵，攻擊者也無法直接看到明碼。
雜湊的特性：
include、require、include_once、require_once的差別require 與 include 除了引入檔案失敗之後的行為不同之外，可以看成是相同的。 include 引入的檔案發生錯誤的話，會顯示警告，會繼續執行後面的程式碼； 而 require 則是會顯示錯誤，立刻終止程式，不再往下執行。 require_once 和 include_once 會判斷檔案是否重複引入，如果沒有才會去執行引入動作。
請說明 SQL Injection 的攻擊原理以及防範方法
攻擊原理：攻擊者利用組合、拼湊的方式注入夾帶惡意 SQL 指令，夾帶進去的惡意指令就會被資料庫伺服器誤認為是正常的 SQL 指令而執行，因此遭到破壞或是入侵。 防範方法：利用 prepare statement 使資料庫不會將攻擊者輸入的內容當成程式碼來執行。
請說明 XSS 的攻擊原理以及防範方法
全名為 Cross-site scripting 即「跨網站指令碼」。
攻擊原理：攻擊者注入惡意程式碼（通常是 HYML 及 JavaScript），目的有竊取 Cookie、將頁面導向釣魚網站等等。 防範方法：將注入的惡意程式碼跳脫字元。 PHP 有內建
htmlspecialchars()，JavaScript 可以自己寫一個escape()function 例：請說明 CSRF 的攻擊原理以及防範方法
全名為 Cross-site request forgery 即「跨站請求偽造」又稱作 one-click attack。
攻擊原理：攻擊者利用瀏覽器自動帶上 Cookie 的機制，欺騙用戶的瀏覽器，以受害者的名義傳送惡意請求去做一些未經過授權的操作。 範例：
防範方法：
客戶端：每次使用完網站就登出，讓認證狀態無法維持被利用。
伺服器端：
檢查 Referer：request 的 header 裡面會帶一個欄位叫做 referer，代表這個 request 是從哪個地方過來的，可以檢查這個欄位看是不是合法的 domain，不是的話直接 reject 掉即可。需要注意的地方有三點：
圖型、簡訊驗證：網路銀行轉帳或消費時需要輸入簡訊認證碼
CSRF token：在 form 裡面加上一個 hidden 的欄位，name 為 csrftoken，值為 server 隨機產生，並存在 server 的 session 中，在 submit 後，透過比對表單中的 csrftoken 與 session 內的值是否一致，藉此判斷是否為本人所發送的 request
Double Submit Cookie：方式與上相同，但改儲存在使用者端的 cookie 內，伺服器收到資料時比對 cookie 內的 token 與 form 內的 token 是否相等。
設定 SameSite cookie：原理就是幫 Cookie 再加上一層驗證，分為兩種模式，第一種為
strict 模式任何來自不同網域的 request 都不會帶上 cookie;第二種為Lax 模式，放寬了一些限制，例如說<a>,<link rel="prerender">,<form method="GET">這些都還是會帶上 cookie。但是 POST 方法 的 form，或是只要是 POST, PUT, DELETE 這些方法，就不會帶上 cookie，但Lax 模式之下就沒辦法擋掉 GET 形式的 CSRF，這點要特別注意一下。