Cyber Security - XSS

XSS

XSS 全名為 Cross-site Scripting 跨網站腳本攻擊

之所以不叫 CSS 是因為 CSS 已經用來表示網頁前端的 CSS 了，所以這邊改用 X 來表示 cross

XSS 是列入 OWASP 網頁安全漏洞前十大排名、跟前端有關的安全問題
手段為攻擊者透過在網路上注入惡意程式碼，並且讓其他使用者觸發執行該程式碼來進行攻擊

• 通常這些惡意程式碼指的是 JavaScript 或 HTML
• 漏洞的成因，是因為網站後端未過濾或沒有驗證使用者輸入，導致惡意輸入惡意程式碼不會被抓到，前端網頁就傻傻的直接執行了
• 而漏洞的影響可能會導致使用者資訊 (例如 cookie) 被傳送給攻擊者，從而獲得使用者的隱私訊息，或駭客進一步冒用使用者身分、冒充受害的使用者執行動作等

簡單來說就是 : 「當網站沒有做好的驗證，就可以讓駭客輕易輸入惡意程式碼在網站上，就像埋下一個地雷，讓點擊到該網站的其他使用者受到攻擊」

而防止 XSS 的心態是 : 「Don’t trust user input/request 」
任何輸入都有可能是危險的，輸入框包含網址列、input、任何可以讓使用者更動網頁內容的地方

XSS 的常見類型有

1. Reflected (反射型)
2. Stored (儲存型)
3. DOM based (DOM 型)

Reflected XSS (反射型)

反射型 Reflected XSS 是一種非持久性的攻擊，攻擊者透過在網頁中插入惡意程式碼，讓你在瀏覽網頁時執行，從而達到攻擊的目的

但是反射型需要利用社交工程，你必須要用騙的，去誘騙使用者點擊你傳給他的惡意連結，才能達到入侵的目的

反射型特別的地方在於他插入的惡意程式並不會被儲存在網頁當中，且需要引誘使用者透過連結的方式才能發動攻擊

通常會透過觸發 alert() 的方式來檢查網頁中是否有 Reflected XSS 漏洞

反射型的攻擊流程是先構造出帶有惡意程式的 url，接著引誘使用者觸發連結(例如透過釣魚信件)，連結被觸發後，伺服器會將惡意程式碼拼接到 HTML，並回傳給使用者
最後使用者端的瀏覽器解析回傳結果，惡意程式碼被執行，你的電腦被駭

Reflected XSS 實際攻擊

1. 攻擊者先創造一個惡意連結
2. 用社交工程，例如釣魚郵件等方式給受害者
3. 受害者點下去之後，可能就會提交特別的金鑰，或著受害者純粹就只是閱覽了這個惡意的有毒網站，而這些被注入的惡意程式碼就會到處遊歷以後攻擊那些防禦比較弱的網站，並反射攻擊回用戶的瀏覽器

因為他是反射型，不是 Stored XSS，所以沒有存進 Database

Stored XSS (儲存型)

儲存型 Stored XSS 和反射型 Reflected XSS 的攻擊手段類似，不同的是惡意程式碼會被儲存在伺服器當中

當使用者瀏覽該網站就會毫無防備的被攻擊，並不需要被引誘點擊連結才會被打，這種攻擊可能會對伺服器造成永久性的傷害，造成的危害很大

儲存型的攻擊流程是構造惡意程式碼並上傳至該網站的資料庫，當使用者瀏覽該網站時，伺服器端就會將包含惡意程式碼的內容從資料庫取出，並回傳給使用者
當使用者的瀏覽器接收到回結果並分析，惡意程式碼被執行，你的電腦又被駭ㄌ

Stored XSS 實際攻擊

1. 駭客在網站留言板留言，注入 XSS payload
2. Web Application 將 XSS payload 存到 database
3. 惡意程式碼被顯示在網站上
4. 使用者打開網站後看到留言或是點擊觸發，便成為了受害者

DOM Based XSS (DOM 型)

DOM 全名為 Document Object Model
當應用程式缺乏適當的驗證，如允許網頁可出現不可信任的資訊時，或者是允許在使用者瀏覽器中執行腳本程式，可能就會導致有心人士劫持使用者 Session、網頁置換或者是轉址到其他惡意網站等

DOM Based XSS 跟 Reflect 非常像，不同是 DOM Based 惡意程式碼沒有到 server 端被執行而是直接在 client 端就被執行

DOM 型的攻擊流程是通過修改原始客戶端使用的受害者瀏覽器中的 DOM 環境而執行的腳本，以便客戶端程式碼以意外方式運行，也就是說，頁面本身沒有被改變，但頁面中包含的客戶端程式碼由於 DOM 環境中發生的惡意修改而執行不同

這與其他 XSS 攻擊（也就是前面講的 stored 存儲或 reflected 反射）形成對比，由於服務器端，也就是你的 server 缺陷，他的攻擊會被放置在回應的頁面中

總結來說，前兩者是透過 server 端處理注入進的惡意請求來動態觸發；而 DOM based 是透過 client 端直接觸發

DOM Based 實際攻擊

1. 在 DOM Based 的攻擊上，駭客將惡意程式碼注入在網頁上
2. 惡意程式碼顯示在網站上
3. DOM Based 的惡意程式碼沒有在 server 端被執行而是會直接在 client 端點擊網站後被執行

Impact & Prevention

這邊必須先來提提 Cookie

Cookie

• Cookie 儲存在客戶端中，按在客戶端中的儲存位置，可分為非持久的 session Cookie 和持久的 persistant Cookie
  • session Cookie 由瀏覽器維護，儲存在記憶體中，會在你離開網站時刪除，存在時間短暫
  • persistant Cookie 儲存在硬碟裡，有過期時間，除非使用者手動清理或到了過期時間，硬碟 Cookie 不會清除，存在時間較長
• cookie 的用途是記錄使用者狀態的資料
  • 因為 HTTP 協定是無狀態協定，當伺服器接收到請求時，都視為是一個全新的請求，伺服器不會記得使用者上一次做了什麼，而這阻礙了那些互動式網頁的呈現，
  • 舉例來說，在你今天逛蝦皮的時候，你可能在瀏覽好幾個不同的頁面後，買了一盒餅乾和兩瓶飲料，但最後結帳時，由於 HTTP 的無狀態性，如果你沒有額外用其他的東西儲存你的購物車紀錄，那你的伺服器其實是不知道你到底買了什麼的，所以 Cookie 就是用來繞開 HTTP 的無狀態性的方式之一
  • 有了 coookie 伺服器可以設定或讀取 Cookie 中包含的資訊，藉此維護使用者跟伺服器來回要求封包和回應封包的這個對話狀態，當你今天選購了一包餅乾，伺服器在向使用者傳送餅乾網頁的同時，還傳送了一段 Cookie，記錄著這包餅乾商品的資訊，最後結帳時，你的伺服器只要讀取最後的的 Cookie 即可
  • Cookie 的另一個例子是當你登入一個網站時，網站可能會問你要輸入使用者名稱和密碼，並且跟你說你可以勾選”記住密碼”、或是”下次自動登入”，那這原理是因為你前一次登入時，伺服器傳送了包含你的登入憑據（也就是使用者名稱加密碼，但是是以某種加密形式）的 Cookie 到你的硬碟上；那你下一次登入時，如果該 Cookie 還沒被清除，瀏覽器就會傳送該 Cookie，然後你的伺服器會去驗證這段 cookie 憑據，於是你就直接登入了
• 但駭客今天可以透過擷取你的 cookie 資料，跨網站攻擊，讓駭客可以取得你的網站的管理者權限，因而去達到偽造登入的目的
  • 尤其是如果你今天取得的是你的 google 帳密，然後你又把你全家大小各個網站的帳密都存在 google，那你就完蛋ㄌ

Risks

光是一塊小小的餅乾就已經如此危險，那 XSS 的風險呢

• XSS 可以做到的攻擊像是 :

1. 偷你的 cookie
2. 將使用者重新導向到假網站，這時候可能會要你重新輸入帳號密碼之類的，他就會拿到你的帳密了，而且通常假網站都做得微妙微肖，沒有相當的資安意識的一般民眾很容易就會上當
3. 駭客也有可能直接就把你的網站玩壞

Prevention

駭客攻擊手段防不勝防，我們很難去防禦住所有的攻擊手法，我們主要能做的就是不要被社交工程的手段打到

• 作為使用者，我們可以做到：點開網址和輸入帳密之前要三思
• 作為開發者或工程師，我們可以做到利用

1. 白名單過濾
   • 例如除了允許輸入 HTML 的地方，其他都當作純字串處理、使用 HTML 或 URL encode 等等
2. 也可以利用 HttpOnly 去做到保護 cookie
   • 補充說明一下甚麼是 HttpOnly
   • 大致上就是當 cookie 有設定 HttpOnly flag 時，瀏覽器會限制 cookie 只能經由 HTTP、HTTPS 協定來存取
   • 因此當網站有 XSS 弱點時，若 cookie 含有 HttpOnly flag，則攻擊者無法直接經由 JavaScript 存取使用者的 session cookie，可降低使用者身份被盜用的機率