資訊安全：SQL Injection & CSRF

SQL Injection

又被稱為駭客的填字遊戲。意思是指駭客在可以輸入資料的地方，用一些惡意字串來竄改 SQL 語法，來達成竊取資料等非法目的。

防範方式：Prepare Statement（ＭySQL 的內建機制）

$sql = "INSERT INTO sophiechang_users(nickname, username, password) VALUES(?, ?, ?)";  // 把參數改成問號
$stmt = $conn->prepare($sql);
$stmt->bind_param('sss', $nickname, $username, $password); // 替換成準備好的參數
$result = $stmt->execute(); // 執行 query 語法

CSRF (Cross Site Request Forgery)

CSRF 又被稱為跨站請求偽造，是一種在 Web 的攻擊方式。 CSRF 可以在不同的 domain 底下，卻能偽裝成「使用者本人身份發出的 request」。會有這樣新型的攻擊型態，是因為瀏覽器的機制，當發送 request 的時候，會把 cookie 的內容帶上。假設你點入駭客提供的 A 網站連結，其實背後是發到了 B 網站的 request，如果 B 網站你是在登入的狀態，這樣就可以造成像是使用者本人發出的 request ，即便當時你沒有親自造訪 B 網站。

防範方式（推薦）

• 加上圖形驗證碼、簡訊驗證碼
  經常使用在有金流操作的網站，多了一道檢查就可以確保不會被 CSRF 攻擊。

• 加上 CSRF token
  產生：Server，儲存：Server

  在 form 裡面新增 hidden 的程式碼 （註一），裡面所填的值由 server 隨機產生，並存放在 server 的 session 中。當按下 submit 之後，server 比對表單中的 csrftoken與自己 session 裡存在資料庫的是不是一樣，就可以確定是不是由本人發出的 request。

  （註一）hidden 程式碼

  <input type="hidden" name="csrftoken" value="fj1iro2jro12ijoi1"/>
  

• Double Submit Cookie
  產生：Server，儲存：Client

  一樣在表單中放入 CSRF token，但這次參照值不是存放在 server 裡，而是存在 cookie 裡。這個方式是利用 cookie 要相符合的話。就要從相同的 domain 帶上來。攻擊者無法從不同 domain 帶上相同 cookie。

• Client 端生成的 Double Submit Cookie
  產生：Client，儲存：Client

  若是遇到是以 SPA 為主的專案，要從 sever 端拿到 CSRF token 會有點困難，所以改成從 clinet 生成。由 client 生成的 cookie 只要確保攻擊者無法取得、沒有包含任何敏感資訊的話，就不用擔心安全性考量。

防範方式（最推薦）

• 瀏覽器端的防禦： SameSite cookie

運作原理就是幫 Cookie 加上一層驗證，不允許跨站請求。意思是除了 A 網站這個 domain 發出的請求，其他 domain 發出的 request 不會帶上此 Cookie。而 SameSite 有兩 種模式， Lax 與 Strict，默認會是後者。

Set-Cookie: session_id=ewfewjf23o1; SameSite=Strict
Set-Cookie: foo=bar; SameSite=Lax

Strict 嚴格

<a href="">、<form>、new XMLHttpRequest... 等標籤，只要瀏覽器驗證不是在同一個 domain 發出的 request，就不會帶上 cookie。

Lax 寬鬆
上述的標籤可以帶上 cookie；使用 GET 形式也會帶上 cookie （無法防止 CSRF） ，但若是其他的 POST、DELETE、PUT...都不會帶上 cookie。