---
# System prepended metadata
title: 經典駭客攻擊教程
---
---
type: slide
---
# 經典駭客攻擊教程
---
### 章節
* Same Origin Policy
* HTTP Security Headers
* SQL Injection
* Cross Site Scripting (XSS)
* Cross-site request forgery (CSRF)
---
## Same Origin Policy
----
> 「同源」資源才可相互存取，跨來源資源則必須在某些特定情況下，才允許存取。
同源政策是為了防範駭客的攻擊，因為有了這個限制，在正常的情況下，駭客就不能夠任意用一個惡意的網站，去呼叫 facebook 的網路服務。
----
萬一沒有這層防護，駭客就可以任意觸發 facebook 的網路服務裡的刪除留言或是新增留言，在你的 facebook 頁面搞破壞了。
----
#### 「同源政策」(Same Origin Policy) 是網站安全的基礎，又分為兩種：
* DOM 的同源政策
* Cookie 的同源政策
----
### DOM 同源政策規則
對 DOM 的同源政策來說，只要 Scheme、Domain 跟 Port 一致的資源，就會被視為同源
----
### DOM 同源政策範例
#### 以下為一個範例，比較表格內的「資源」，來看是否與下列「HTML檔案」同源
http://login.game.com/dir/page.html
----
### DOM 同源政策潛在的安全問題
* 「同源政策」(Same Origin Policy) 允許對於 HTML tag 產生的 跨來源寫入/嵌入/讀取，但對於JavaScript 程式碼 產生的 跨來源寫入/嵌入/讀取是有限制的。
* DOM 的同源政策規範對於連結(links)、重新導向(redirect)、或是表單(form)等等的跨來源存取是寬鬆的，這樣的特性會被駭客利用在 CSRF 等類型的攻擊上。
----
### Cookie 同源政策
只要 Domain 跟 Path 一致的 Cookie ，就會被視為同源．若是 Cookie 有加上一些特別的設定，便需要判斷 Scheme 是 HTTPS 或是 HTTP 才會送出 Cookie。
----
### Cookie 同源政策限定行為
1. 不同源的 Cookie ，在傳輸時會送到各自來源的主機。
2. 經過設定，子網域與母網域的 Cookie 可以共用。
----
### Cookie 同源政策潛在的安全問題
* 通過共用設定，子網域的 JavaScript 程式碼可以修改/覆蓋母網域的 Cookie
---
## HTTP Security
----
### URL Parameter Leakage ？
`http://shopping.com?user=jayden&pass=mypass12345`
若是在網址上的參數 (query string)，帶上敏感的資訊，例如：使用者的密碼，使用者的信用卡號碼等等．便有可能會無意間間這些敏感資訊外洩。這樣的事情，便稱為URL Parameter Leakage。
以下是幾種 URL Parameter Leakage 發生途徑：
* Referer Request Headers
* 瀏覽器書籤
* 瀏覽器瀏覽紀錄
* Proxy 主機日誌
* 網站主機日誌
----
透過設定Response Headers做駭客Request防禦
----
### 保護網站之 HTTP Response headers - 1
* 利用`X-Frame-Options`的設定來避免Clickjacking(被惡意網站嵌入)：
* `DENY`
* `SAMEORIGIN`
* `ALLOW-FROM https://${allow-host}.com/`
* 設定`X-XSS-Protection`設定來避免XSS攻擊：
* `X-Xss-Protection: 1; mode=block`
----
### 保護網站之 HTTP Response headers - 2
* 利用`Access-Control-Allow-Origin`的設定來限縮可使用的資源跟控制：
Access-Control-Allow-Origin：https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET
* 利用`strict-transport-security`確保你的網站都在安全的 HTTPS 下進行操作
----
### 保護網站之 HTTP Response headers - 3
* 利用`X-Content-Type-Options`的設定來避免 MIME sniffing 攻擊：
X-Content-Type-Options: nosniff
* 設定`Access-Control-Allow-Origin`為跨源存取設定：
Access-Control-Allow-Origin：https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET
----
### 保護 Cookie 的 Header 設定
* 設定了 HttpOnly 的 Cookie 無法被客戶端的 JavaScript 程式碼存取，避免潛在的安全問題。
Set-Cookie: myCookie=parent; Path=/hello ; domain=game.com; HttpOnly
* 設定了 Secure 的 cookie 只能在使用 HTTPS 的情況下被傳輸：
Access-Control-Allow-Origin：https://example.com
----
### Content Security Policy
語法範例
Content-Security-Policy: <規範> <來源>;
Content-Security-Policy: <規範> <來源> <來源>;
Content-Security-Policy: script-src http://*.example.com;
Content-Security-Policy: script-src http://*.example.com game.com;
常用規範
report-uri ：使用report模式，將資料回傳到某個網址
default-src ：某些來源如果沒有設定，預設就會採用default-src
而以下列出幾種預設不會採用default-src的設定
base-uri, form-action, frame-ancestors, report-uri
----
### Content Security Policy
* Host 來源
http://*.example.com
mail.example.com:443
https://store.example.com
* Scheme 來源 在<來源>的區塊，可以只指定scheme，如下面例子所示：
Content-Security-Policy: default-src https: data:;
* 其他
'none' ：禁止任何的來源
'self'：只允許同源的來源 (scheme, domain, port 相同)
'unsafe-inline'：允許 inline 的 JavaScript 或是 CSS 樣式
'unsafe-eval'： 允許 JavaScript 中的危險函式，例如：eval
----
### 公司網站後台範例
---
## SQL Injection
----
## SQL Injection原理說明
SQL 是網站常用來取得資料的程式語法，SQL Injection 便是駭客透過修改 SQL 語句，改變他的語意，達成竊取資料/破壞資料的行為。
----
駭客攻擊所填寫的SQL語句範例
----
如此一來駭客就會將`password=XXXX`這個錯誤的布林值用`or'1'='1'`給覆寫掉，達到攻擊的效果。
----
### SQL Injection Lab 範例練習
> 如沒portswigger會員，先到[portswigger](https://portswigger.net/)註冊會員
* [查詢隱藏的資料](https://portswigger.net/web-security/sql-injection/lab-retrieve-hidden-data)
* [繞過登入驗證](https://portswigger.net/web-security/sql-injection/lab-login-bypass)
----
### SQL Injection Lab 範例練習解答
1. 輸入網址`https://feifei.tw/products?category=Gifts'+OR+1=1--`
* SQL語句
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
3. 找到登入頁面輸入帳號`administrator'--` 密碼隨意
* SQL語句
SELECT * FROM users WHERE username = 'administrator'--' AND password = ''
----
#### SQL Injection Query Parameterization 的防禦手法
* Query Parameterization 防禦的原理主要在於：
先產生 Execution plan 再帶入使用者輸入的參數不使用組字串的方式產生 SQL
----
資料庫執行SQL的時候，資料庫都會先產生 Execution plan，之後依照 Execution plan執行程式．
----
* Query Parameterization 的程式寫法，事先將 SQL 產生 Execution plan，之後再帶入使用者輸入的參數，若帶入使用者的參數後，造成 Execution plan 與預先產出的Execution plan不同，便會報錯誤．讓使用者輸入的參數無法被正常執行。
* 因此，若駭客輸入惡意的字串，造成 Execution plan 與不同與預先產出的 Execution plan 不同，那麼駭客的惡意字串便不會被執行，達成防禦駭客的目的
---
## Cross Site Scripting (XSS)
----
## Cross Site Scripting原理
Cross Site Scripting 簡稱(XSS) 是一種網站應用程序的安全漏洞攻擊，是代碼注入的一種。它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響。這類攻擊通常包含了HTML以及用戶端腳本語言
----
## XSS 攻擊概念
概念上有點像是埋一個地雷在受害的網頁上，該網站的使用者只要一連上該網頁，便會遭受攻擊．以譬喻的方式來說，你可以想像，XSS 攻擊就像是駭客在網站上蓋的違章建築，並且在那些違章建築裡面，做一些邪惡的勾當。
----
### XSS的三種類型
* Reflective XSS
* Persistent XSS
* Dom-based XSS
----
#### Reflective XSS攻擊原理
* 最常見的 XSS 攻擊類型，通常是將惡意程式會藏在網址列裡，放在 GET 參數傳遞，範例如下：
http://www.example.com/upload.asp?id=
* 這種手法要能夠成功攻擊，需要使用社交工程釣魚的技巧，使 User 點擊URL 攻擊才會生效。
* 因為 URL 通常看起來很詭異，所以 Hacker 通常會使用短網址或 HTML Encoder 的方式嘗試欺騙 User
----
假設一個Shopping網站有Reflective XSS漏洞
----
該網站直接將使用者搜尋的輸入，直接顯示在網頁上，正常的使用者輸入了 shoes，那麼預期網頁上就會顯示 shoes。(正常使用者的輸入
----
然而，對於駭客來說，他可以直接輸入程式碼，例如：
----
* 「 ?」可以替換成各種惡意攻擊的程式碼．讓該惡意程式碼在網頁上被執行。
* 例如：偷取你在 shop.com 的 Cookie。
`http://www.shop.com/search?query=`
* 只要你誤點了上面的網址之後，你的 Cookie 就會被送到駭客的網站 badguy.com，駭客取得 Cookie 之後，就可以登入你在 shop.com 的帳號了。
* 由於這項攻擊的惡意程式碼是被輸入的當下馬上被執行，有反射的感覺，因此被稱為Reflective XSS。
----
#### Reflective XSS 攻擊示意圖
----
### Persistent/Stored XSS攻擊原理
Persistent/Stored XSS 的概念，同樣也是在網頁埋地雷，當使用者連到該網頁時，便會遭受到攻擊．但不同於 Reflective XSS 的是，該惡意程式碼是被存到網站的資料庫裡面的．惡意程式碼不是當下被輸入的。
----
#### 舉例來說，有一個心情留言板上面有XSS的漏洞．直接將使用者留言顯示在頁面上。
----
(具有XSS漏洞的心情留言板)
正常使用者會留下正常的字串，而駭客會在留言板裡面留下惡意程式碼，
如下圖的第三筆留言，便是駭客可能會留下的內容。
----
#### Persistent/Stored XSS 攻擊示意圖
----
#### Dom-based XSS攻擊原理
Dom-based XSS 的攻擊原理跟 Reflective XSS 攻擊原理相似，差別只在 Reflective XSS 有經過 Server 端，而 Dom-based 的攻擊只發生在 Client 端。
----
#### Dom-based XSS 攻擊示意圖
----
#### XSS 範例練習
如沒portswigger會員，先到[portswigger](https://portswigger.net/)註冊會員
* [Reflected XSS](https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded)
* [Stored XSS](https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded)
* [DOM XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink)
----
### XSS防禦手法 Contextual Output Encoding
* 防禦 Cross site scripting 就是防禦駭客在你的網頁裡面埋地雷。先前的文章已經有提過，透過過濾字串的方式不可行．駭客還是有可能繞過這些過濾。
* 正確的方式是要針對網頁不同的情境(Context)，在網頁輸出時做特殊編碼的處理，讓原本會被瀏覽器認為程式碼的內容，當成非程式碼處理。
----
透過Encode使程式碼便成非程式碼
這種處理方式便稱為Contextual Output Encoding的防禦手法。
----
### 網頁上的Context
* HTML Entity Context
* HTML Attributes Context
* URL Fragment Context
* Script Context
* Style Context
----
這五個地方，都是駭客可能會插入惡意程式碼的地方，當駭客有機會將輸入的資料在這五個地方輸出的時候，便需要有相對應的編碼處理過，才可以輸出。
----
### 什麼是相對應的編碼處理？
為了方便大家了解，以 HTML Entity Context 的轉換為例：
* `& 會被轉換成 &`
* `< 會被轉換成 <`
* `> 會被轉換成 >`
* `“ 會被轉換成 "`
* `‘ 會被轉換成 '`
* `/ 會被轉換成 /`
----
這部分轉換的程式是不需要自己重新實作的，可已根據你開發網站使用的程式語言，找相對應的函式庫使用。
例如：Java的網站就可以使用 [OWASP Java Encoder Project](https://owasp.org/www-project-java-encoder/) 提供的函式庫來進行使用
---
## Cross-site request forgery (CSRF)
----
根據維基百科的定義，CSRF 的全名是 Cross-site request forgery，跨站請求偽造也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。跟 XSS 相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。
----
# CSRF 譬喻舉例
有如小明在駭客家「無意間」打電話給媽媽，請她買電腦給你。媽媽接到的確實是小明打出來的電話，也是小明的聲音。這跟在正常情況下，小明從宿舍「有意」播出的電話，請媽媽買電腦的情況一模一樣．一但媽媽真的買了電腦，變中了駭客的攻擊了。
----
# CSRF攻擊簡介
可以把媽媽想像成你的網站 Server，小明是你的網站使用者。他「無意間」從駭客的網站發出來一個 HTTP Request，這個 HTTP Request 確實是小明發出的，它送出來的 Cookie 認證，也確實是小明，但小明其實並不知道/也不希望你幫他買電腦，一但你的 Server 替小明下單，那麼駭客的攻擊就生效了。
----
#### 漏洞的原因: Same Origin Policy 的不足之處
如遇到同源規則不符的情況
* Request by script: 會阻擋
* Request by HTML tag: 不會阻擋
----
#### 圖解 Same Origin Policy 的不足之處
----
## 瀏覽器處理 Cookies 的方式
> 如果是對同 domain 對象發出的 HTTP Request，瀏覽器便會將該 domain 的 Cookies 也一併送出。在 CSRF 攻擊中，由於發送 HTTP Request 是某個受害的網站(例如：Netflix)，該網站的 Cookies 也會一並被送出，造成認證通過，使攻擊生效．
----
## CSRF攻擊原理
簡單來說， CSRF 透過 Same Origin Policy對於 HTML tag Request 不設防的特性，發送有效的 Request ，再利用瀏覽器對 Same Site Cookies的處理方式，使攻擊生效．受害網站還以為是使用者自願發出的 HTTP Requests。因為一點擊，攻擊就生效，所以CSRF 被稱為 one-click attack ．駭客用你的Cookies 對 信任你 Cookies 的網站，發起了一個你不知道 Request ．在你不知情之下，可能把你的email清空，發了你不知道的 PO 文，或是買了你不知道的東西．
----
#### Synchronizer Token Pattern 防禦方式的利與弊
CSRF 的正確防禦觀念應該是，「如何確認發送 Request 的來源是合法的來源？」，例如：
* 刪除 gmail 信件的 HTTP Request 就應該從 gmail 發出．而不是從某個奇怪的心理測驗網站，按下「開始測驗」卻是發 HTTP Request到gmail 刪除郵件。
----
## Synchronizer Token Pattern 的原理
Synchronizer Token Pattern 就是利用相同的原理．使用者在發 HTTP Request 的時候，需要將「目前頁面的某個特徵」回傳給「Server」，確認使用者是從正常的網頁發出的 Request。
----
## 正常的網站取出token值回傳
那個「目前頁面的某個特徵」就是存在HTML裡面的 CSRF token，當作隱藏欄位往 Server 送
----
#### 這個 CSRF token必須符合以下條件：
* 在 Server 端根據這個 Session 存一個 CSRF token
* 每次進入該頁面，CSRF token都要變，具有時效性
* 要在使用者已登入的頁面才能取得 CSRF token
* csrf token值必須是不可預測的
----
CSRF 是透過 HTML 標籤發送 Request
----
駭客無法用程式取得token值示意圖
----
#### Synchronizer Token Pattern 有效的原因
1. 因為根據 Same Origin Policy，Client 端的程式是無法讀取不同 Origin 的內容的．
2. 單用 HTML 標籤可以取得整頁 HTML 內容，可是爬不出 CSRF token 的值
----
#### Synchronizer Token Pattern 的好處
好處是可以簡單的達到防禦 CSRF 的效果。
----
#### Synchronizer Token Pattern 的壞處
* 若是頁面有 XSS 漏洞，那麼 CSRF token就可以被駭客「用程式爬取出 CSRF token的值」，此防禦就無效了。
* 必須在 Server 端也存放 CSRF token，會額外佔據server的儲存空間。
----
## Double Submit Cookie 原理
Double Submit Cookie 的方式也是透過在發送 HTTP Reuqet 時多傳一個 csrf token，只有在正常的網站，才會有那個 CSRF token 值．駭客的網站是無從知道的。
----
### Double Submit Cookie 作法
* 在使用者造訪網站的時候，先在給使用者的 Cookie 裡面放上 CSRF token，同時也在 HTML 頁面裡面放上一份 CSRF token。
* 當使用者發送 HTTP Request 的時候，便會同時帶上 Cookie 裡面的 CSRF token ，以及 HTML 裡面的 CSRF token．送給 Server 端。
* 此時，Server 端只要比較：
Cookie 裡面的 CSRF token 值，和使用者送出來的 CSRF token 是否一致
----
就可以知道使用者送出 HTTP Request 的時候，來源是否是正常的網站了。以譬喻的方式來說，以譬喻來說，小明是否從宿舍打電話給媽媽，媽媽只要比對視訊中的宿舍模樣跟照片中的宿舍是否一致就可以了。無需記得宿舍的長相。
----
### Double Submit Cookie 作法
* 在使用者造訪網站的時候，先在給使用者的 Cookie 裡面放上 CSRF token，同時也在 HTML 頁面裡面放上一份 CSRF token。
* 當使用者發送 HTTP Request 的時候，便會同時帶上 Cookie 裡面的 CSRF token ，以及 HTML 裡面的 CSRF token．送給 Server 端。
* 此時，Server 端只要比較：
Cookie 裡面的 CSRF token 值，和使用者送出來的 CSRF token 是否一致
----
### Double Submit Cookie 有效的原因
* 這邊要說明，這樣的觀念是錯誤的．問題出在「用程式串改 Cookie 值跟 CSRF token 值」是不可行的．根據 Same Origin Policy ，駭客的網站的程式是無法存取跟修改其他網站的 Cookie 跟 HTML 頁面的。
* 駭客的網站的程式是無法存取跟修改其他網站的 Cookie 跟 HTML 頁面
----
#### Double Submit Cookie 的好處
好處是可以簡單的達到防禦 CSRF 的效果。
不需要在 Server 端存放額外的空間。
----
#### Double Submit Cookie 的壞處
若是頁面有 XSS 漏洞，那麼 CSRF token就可以被駭客「用程式串改 Cookie 值跟CSRF token值」，此防禦就無效了．建議將 CSRF token 在 cookie 儲存時，設定屬性為 HTTP Only．讓它不被Client端的程式隨意的修改。
----
#### Triple-Submit Cookie 原理
> 前兩篇篇提到的 Synchronizer Token Pattern 是將 csrf token 存一份在 Server 端．而 Double Submit Cookie 的方法，是將 csrf token 存在瀏覽器的 cookie 裡面，讓 server 不需要多儲存 csrf token 這個值。
> 本篇要介紹的 Triple Cookie Submit 防禦方式，綜合了上述兩種做法。
----
> 對於網站來說，便是「如何確認發送 Request 的來源是合法的來源？」。基本上 CSRF 的防禦方式，都是需要多傳一個 csrf token 來確認使用者目前的位置。
> 
----
> Triple Submit Cookie 在使用者拜訪頁面的時候，就先跟使用者做了「約定」。將 csrf token 的 name 和 value 放在 Cookie，存在使用者的瀏覽器，並備份一份 csrf token 的 name在 server 端。另外也存一份 csrf token的 value 在 JavaScript 的變數裡面。
> 
----
當使用者發送 HTTP Request 的時候，Server 會判斷 csrf token name 是否跟 Cookie 中的 csrf token name 相等。另外也會判斷回傳的 csrf token value 是否跟 Cookie 中的 csrf token value 相等。
----
#### Triple Submit Cookie 好處
綜合了 Synchronizer Token Pattern 以及 Double Submit Cookie 的方法，將csrf token 分為name和 value 分別存在 Server 與 Client 端，讓駭客更難破解。
----
#### Triple Submit Cookie 壞處
* 需要額外的儲存空間，在 Server 端維護一份 csrf token name 的值
* 若是頁面有 XSS 漏洞的話，駭客便可以取得 csrf token name 以及 value 做串改．使這個防禦方式失去效果
----
#### CSRF 範例練習
[CSRF - no defenses](https://portswigger.net/web-security/csrf/lab-no-defenses)
[CSRF - request token](https://portswigger.net/web-security/csrf/lab-token-validation-depends-on-request-method)
----
#### 如何利用瀏覽器來防禦 CSRF 攻擊
----
> 前幾篇說明了幾種 CSRF 的防禦方式．主要是透過csrf token的方式，這個方式在許多知名的應用程式框架都有支援，利如：Spring、Ruby on Rails、Django 等等．除了這類的防禦方式之外，隨著瀏覽器的發展，現在我們也可以透過啟用瀏覽器的防禦來防範 CSRF 攻擊了。
>本篇要介紹的，是Google推行的標準 SameSite Cookie 設定。
----
### SameSite Cookie 的防禦思路
* 先前介紹的幾種 CSRF 的防禦方式，其思路都是 「如何確認發送Request的來源是合法的來源？」，而 SameSite Cookie 的思路則是要「讓惡意的來源連發送合法的Request沒有辦法」。
* 回顧先前的例子，CSRF 攻擊便是媽媽要判斷小明是否是在宿舍發出要買電腦的訊息，還是在駭客家發出要買電腦的訊息。
----
### SameSite Cookie 改變了什麼
原本瀏覽器的行為是：不管你現在在哪一個網站，假設你在 aaa.com ，一但你連上 bbb.com (等同發一個HTTP Request)，瀏覽器會自動帶上 bbb.com 的 cookie 給你。
原本的設計立意良善，因為這樣一來，你連到 bbb.com 的時候，因為帶上的bbb.com的 cookie ，所以在 bbb.com 就能維持著登入的狀態。
----
然而， CSRF 攻擊便是駭客利用這種瀏覽器 「自動帶cookie」的特性，來發動攻擊。
----
因為從駭客網站發出來的 HTTP Request 也會帶 Cookie ，跟正常網站發出來的HTTP Request 一樣．造成攻擊生效。
Same Site Cookie 的設定便是要改變這個行為，原本瀏覽器只判斷 HTTP Request 的「對象」來帶 Cookie ，現在要求要同時判斷 HTTP Request 的「來源」是否跟「對象」為同源，才決定要不要自動帶Cookie。
----
(Same Site Cookie的設定讓跨Origin的 Cookie 無法被傳遞)
----
#### SameSite Cookie 的設定
由於跨來源便不會帶上 Cookie 會使得使用者比較不方便．舉例來說，你從某個網站點到某個購物網站的時候，由於都不會帶 Cookie，因此你就需要重新登入或是刷新頁面才會登入．造成不好的使用者體驗．
----
因此 SameSite Cookie 提供兩種設定：
1. Strict (強制瀏覽器對所有跨來源的 HTTP Request 來源都不會自動帶 Cookie)
`Set-Cookie: NAME=VALUE; expires=EXPIRES;path=PATH; domain=DOMAIN;secure; httponly; SameSite=Strict;`
2. Lax (對部分的 HTTP GET Request 開放帶 Cookie)
`Set-Cookie: NAME=VALUE; expires=EXPIRES;path=PATH; domain=DOMAIN;secure; httponly; SameSite=Lax;`
---
## Authentication
----
# Session最佳實踐
* Step 1. 使用者登入畫面
確保網站是使用 HTTPS 連線，避免封包被監聽，使用者密碼外洩。
所有client端對 Login form 的驗證都是沒有用的。
* Step 2. 處理使用者登入資訊
使用者資訊通常在資料庫裡面，比對資料庫資料時，確保程式碼沒有SQL Injection的漏洞。
* Step 3. 創立Session，儲存Session Id，並回傳Cookie給瀏覽器
確保 Cookie 設定為 Http Only。
創立 Session Id 的時候確保資料是唯一的，不可被預測的。
* Step 4. 操作敏感資料時或是閒置太久，要求使用者重新登入
Session 是有時效性的，若是 Session Id 固定不變，用久了會增加外洩的風險，跟某些銀行定期要求你換密碼是同樣的概念。
* Step 5. 閒置太久的使用者，關閉Session
----
# 如何防範 Cookie 小偷
1. 使用 Http Only，避免 cookie 被 JavaScript 程式碼存取
2. 使用 expires，降低 Session Id 外洩的風險
3. 使用 secure，確保在 HTTPS 底下傳送，不會被駭客竊聽取得 Cookie
4. 使用 SameSite功能，避免 CSRF 攻擊
5. 使用 Contextual Output Encoding 避免 XSS 盜取 Cookie
----
## Session Prediction 攻擊
* 若是你的 Session Id 複雜度不夠，太容易被駭客猜測。駭客就可以利用猜測出來的 Session Id 進行攻擊。
* 例如：你網站的 Session Id 是 `20180505225833jayden`
* 正確的防禦方式為：
盡量使用 Web Framework 中內建的 Session Id ，通常大眾使用的 Web Framework 中的Session 管理有一定的安全性，不要自己實作反而造成漏洞。
----
## Session Fixation 攻擊
----
* 若是你的 Session Id 設計成固定的，舉例來說：就像是一個認識別證號碼不認人的俱樂部，其識別證號碼固定 100 組在發．駭客可以先註冊俱樂部，取得其中一組有效的識別證號碼．再騙使用者報這一組張識別證號碼去參加俱樂部。
* 等使用者使用這組識別證號碼過一段時間後，駭客再報這組識別證號碼進入會場．此時俱樂部裡面就會同時有兩個不同的人，卻使用同一組識別證號碼．俱樂部會把這兩個人視為同一人．共享所有資訊。
* Session Fixation 攻擊就是利用同一組 Session Id，但實際上卻是兩個不同的人(駭客跟受害的使用者)．來達到攻擊的效果
----
### 正確的防禦方式便是：
1. Session Id 必須每次登入時都不同的值，才不會被駭客拿來做壞事
2. Session Id 不應該用GET的方式傳遞，避免外洩
3. 頁面不可以有 XSS 漏洞，否則 Session Id 會被竊取
4. 存放 Session Id 的 Cookie 應該設定為 Http Only
5. 存放 Session Id 的 Cookie 應該 secure，確保只在 HTTPS 下傳送
----
## Session Hijacking 攻擊
HTTP 網路連線是不安全沒有加密的，因次當使用者在公共場所或是其他不安全的網路連線下，該網路是有可能被駭客竊聽(sniffing)的．當駭客取得網路封包之後，可以得知使用者透過 Cookie 傳送的 Session Id．
正確的防禦方式便是：
1. 登入頁面務必使用 HTTPS 連線，避免被駭客竊聽
2. 存放 Session Id的 Cookie 應該 secure，確保只在 HTTPS 下傳送
----
### 密碼怎麼管理？怎樣加密才安全？
----
## 1. 要擋掉常見的密碼
可以搜尋 rockyou.txt，這個檔案裡面列出許多常見的密碼，例如：qwerty, 12345678等等。
http://scrapmaker.com/data/wordlists/dictionaries/rockyou.txt
----
1. 要擋掉常見的密碼
可以搜尋 rockyou.txt，這個檔案裡面列出許多常見的密碼，例如：qwerty, 12345678等等。
http://scrapmaker.com/data/wordlists/dictionaries/rockyou.txt
2. 需要限制密碼「至少」幾個字元 (至少8個字元以上)
3. 常見的密碼要求(例如：大小寫, 數字, 特殊字元) 是無用的
4. 使用現代化的雜湊算法
建議不要使用 MD5或是SHA1等較簡單的雜湊算法，建議使用 SHA 512 或 bcrypt 或是 scrypt 來作加密。
5. 「鹽」 (Salt) 必須是隨機的，並且每個使用者的鹽不同
----
案例：Facebook是怎麼保存你的密碼
從程式碼我們可以看出，facebook 儲存密碼的方式也是透過類似的方式，先經過幾次雜湊算法之後，再加鹽之後再經過雜湊算法．一層一層地加密。
---
自動化掃描漏洞
----
由於本課程主要會以講解漏洞原理以及防禦手法為主，一來，若是不懂漏洞原理，工程師看到掃出來的結果，不一定能以正確的方式修復，二來，以業界的經驗來說，除了自動化工具之外，系統還是要搭配專業的資安人員以黑箱和白箱的方式進行檢測。
----
* 在學完了所有的課程內容之後，這邊要跟同學介紹幾個常見的自動化掃描漏洞的方式。
* 白箱測試 & Static Scan
白箱測試，是指測漏洞的人看得到實際的程式碼，因此可以依據程式邏輯來決定測試資料的輸入值要如何設計。使用 veracode, checkmarx 等工具是常見用來做白箱測試的工具。
* 黑箱測試 & Dynamic Scan
黑箱測試，是指測漏洞的人看不到實際的程式碼，模擬真實駭客入侵的情境，使用 veracode 的 DAST 功能是常見用來做黑箱測試的工具
----