# 資訊安全
***
> **即使再小的帆也能遠航**

> 參考自 [Explain this](https://www.explainthis.io/zh-hant/swe/browser)

>###### tags: `資訊安全`
***
# DDoS
1. DDoS 攻擊是「分散式阻斷服務攻擊」(Distributed Denial of Service) 的簡稱
2. 對網站提出大量"假request"，癱瘓對正常request的服務
* 打個比方，如果把一個網站想成一間店，通常一間店一次能接待好幾個客人。但如果突然有成千上萬的「假客人」一起湧進來，那麼店家就被塞爆，真正的客人就進不來。DDoS 正是這個概念。

## 解決方法
### 1. 增加網站可承受的容量
* 最直觀的方法
* 讓自己網站的入口變大，傳統上是購入更多的硬體來增加容量，但缺點是大部分時候，多出來的這些空間是多餘的，會造成成本的浪費
* 現今的雲端廠商都有提供可擴展的資源，平常用不到不用付費，當被 DDoS 攻擊時，可以短暫用來承接突如其來的高流量

### 2. 反向代理 reverse proxy
* 在進入網站前，設置保護屏障，攻擊者會先經過反向代理，所以無法直接找到伺服器位置。這樣一來，攻擊者只能攻擊這個反向代理，而不是我們的伺服器。
* 缺點：
* 效能降低、無法處理較複雜的DDoS攻擊
* ==單純限流及反向代理通常不夠==
* 現在雲端廠商多半有機器學習的解決方案，會去對流量做分析，這概念就像有個智慧守衛會持續監控來訪者，如果發現異常（比如說，突然有很多人同時來敲門想進來），就會採取行動去把假的客人給擋在門外。

### 3. CDN (內容傳遞網路)
假如網站是以靜態資源為主，有個既能協助增加帶寬，又能作為反向代理的存在，就是 CDN (內容傳遞網路)，這也是常見的阻擋 DDoS 的節點。CDN 是分布全球的代理伺服器網路，它可以在離使用者近的地方儲存網站的內容，這樣可以讓網站運作更快。而在被 DDoS 攻擊時，攻擊者訪問到 CDN，只要 CDN 本身帶寬更大，就能承接下來，同時原本的伺服器有 CDN 在前面處理請求，也能免於直接被攻擊。

### 其他方案
* BGP (Border Gateway Protocol 邊界閘道器協定)：可以保護整個網路，將惡意流量重新導向到可以過濾掉它的特殊伺服器。
* 使用強密碼和啟用 2FA (Two-Factor Authentication 雙重要素驗證) 當作額外的安全措施，以防止未經授權的流量進到你的網站中。

# XSS
* **cross-site scripting**
* 會說是cross-site (跨域)是因為，惡意使用者通常是從可信來源進入，避開了同源政策(same origin policy)的檢驗
* 惡意用戶從客戶端，如輸入框，注入攻擊腳本來達到某種目的（例如：竊取 Cookie、Session、密碼等)，導致其他用戶受到波及
* 因為是藉由javascript腳本攻擊，因此幾乎可以做出任何事情
## 攻擊類型
### Stored XSS
* 被**保存在資料庫**中的 Javascript 引起的攻擊稱為 Stored XSS，最常見的就是文章、留言等
* ==若沒有檢查，則 `<script>` 等標籤就會被視為正常的 HTML 做執行==
### Reflected XSS

### DOM-Based XSS
* DOM-Based XSS 是指網頁上的 Javascript 在執行過程中，沒有檢查輸入資料，使得操作 DOM 的過程中帶入了惡意程式碼。


* 此類型的攻擊，或許沒辦法直接讓用戶輸入語法，但可以搭配 Stored XSS 和 Reflected XSS 製造出內容，再藉由 Javascript 動態產生有效的 DOM 物件來執行惡意程式碼。

## 如何防禦
### 前端
DOM-Based 防範 - 檢查輸入欄位：
* 任何的輸入欄位，例如留言欄位、檔案上傳欄位、表單的欄位等，都要有跳脫的機制，讓腳本被轉換成字符串。
* 舉例來說，如果攻擊者輸入 `<script>alert(1)</script>` ，我們把 `<` 轉成 `&lt` ，在畫面上依然是呈現 < 但是對程式來說，它不會被當成 HTML 標籤來解析。
### 後端
Stored、Reflected 防範：
* 過濾關鍵字，如`script`、`onerror`等等

### 共同
[CSP(Content Security Policy)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)：
* 設定只執行來自特定網域的程式腳本，避免惡意攻擊

# CSRF 跨站請求偽造
* Cross Site Request Forgery
* ==等同使用者憑證被偷==。惡意攻擊者使用合法憑證，以原使用者身份進行偽操作
* 舉例來說，某個使用者登入銀行帳戶後，去逛別的網站，但不小心點開惡意網站，該惡意網站中的程式碼用這名使用者的名義，進行未經同意的轉帳操作

## 防禦方法
### 額外驗證
針對比較危險的操作，可以再增加一些驗證，像是圖形驗證碼、簡訊驗證碼等
### 不要用 *GET* 請求來做關鍵操作
* **POST**會安全一些，因為他會需要有“提交”的動作產生
* 但POST也不是一定安全，詐騙網站會利用頁面讓使用者做出“點擊提交”的動作，但相較於GET，使用者相對比較能防範

### 檢查Referrer
* 辨識發出請求的，是在哪個網站
* 在 HTTP 的標頭中有 Referrer 的字段，我們可以檢查這個字段，來確保請求不是來自於其他網站
* 問題：瀏覽器安全性不足時，駭客可以竄改Referrer的值

### CSRF Token
* 利用cookie以外的方式，對使用者身份進行再驗證，如：JWT token
* 可以將token隱藏在表單中

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="123token123">
[...]
</form>

### 瀏覽器本身防護 - SameSite cookies

# SQL Injection
用戶填寫的表格中，刻意填寫 SQL 語句，使得後端獲得文字後，用拼接的方式可能會得到意想不到的 SQL 語句，並且對資料庫做執行。

舉例如下，有一表格查詢語句如下

queryStr = """SELECT * FROM users WHERE username='" + username + "'" 
                            + " AND password='" + password + "';"

用戶可以在表格中填寫： `'OR 1 = 1 --`，使得queryStr變成：

""" SELECT * FROM users WHERE username = 'Jack' AND password = '' OR 1 = 1 --';"

由於1 = 1 必為True，因此用戶不須輸入密碼也能完成登入
## 如何防範
### Escape Parameters
使用正規表達式，檢查用戶輸入是否包含SQL語句的關鍵字，若有則將其替換成其他合法字元
### Query Parameterization
這個防範是最安全的，原理就是資料庫語法中的佔位符號：

SELECT * FROM users WHERE username = $1 AND password = $2 ;

有些程式語言會先將 SQL 語句進行編譯，最後再將參數丟入做執行，因此可以有效防範 SQL Injection 的攻擊。
### Object Relational Mapping (ORM)
使用 ORM 而非原始的 SQL 語句可以直接避免掉 SQL Injection 的問題