網路安全 Web 應用程式攻擊
如今，Web 應用程式無處不在，它們被用來控制幾乎所有你能想象到的東西。在本節中，我們將探討 Web 應用程式的攻擊和安全。
IDOR（“不安全的直接物件引用”）
當開發人員未實現訪問資源的授權要求時，就會出現 IDOR 漏洞。
Eve，只需更改一個識別符號，例如文件 Rest 引數，她就可以訪問 Alice 的文件。
當 Web 應用程式未能強制執行物件之間的授權時，就會發生這種情況，允許攻擊者列舉值並測試對其他資料點的訪問。
例如，我們可能有以下虛擬碼，其中沒有顯示任何授權跡象
$id = getInputFromUser();
$doc = getDocument($id);
return $doc;上面的程式碼要求使用者輸入，不進行任何驗證或清理，然後直接使用 getDocument 函式進行查詢並返回所請求的文件。
更好的實現是檢查許可權
$id = getInputFromUser();
$user = findUsername();
$doc = "";
if (hasAccessToDocument($user, $id)) {
$doc = getDocument($id);
} else {
$doc = "Not authorized for this document";
}
return $doc;
像這樣的漏洞很容易找到，因為您只需更改一個簡單的數字，然後檢視是否可以訪問他人的資料。首先檢查使用者是否已授權可以防止此漏洞。
避免“魔術數字”
應用程式想要避免在引用資料時使用數字序列。在 IDOR 示例中，文件的識別符號是 1000 到 1002。有時這些數字被稱為“魔術數字”，因為它們直接指向伺服器上的資源（例如，透過資料庫），並且所有值都可以輕鬆列舉。例如，攻擊者可以檢查從 0 到 10000 的所有文件識別符號，並記錄任何提供資料訪問的結果。
雖然應該正確實現授權，但使用 GUID（“全域性唯一識別符號”）或 UUID（“通用唯一識別符號”）引用資料也很有幫助。這些識別符號被設計為全域性唯一且由於生成數字的內建熵而無法列舉。
GUID 可能看起來像這樣
- 3377d5a6-236e-4d68-be9c-e91b22afd216
SQL 注入
許多 Web 應用程式都連線到資料庫。資料庫儲存了 Web 應用程式希望儲存和使用的所有資訊。
SQL 注入是一種允許攻擊者操縱 Web 應用程式開發人員使用的 SQL（“結構化查詢語言”）的技術。這通常是由於缺乏資料清理而發生的。SQL 被開發人員經常用於訪問資料庫資源。
在上面圖形中 Eve 發出的請求中，我們看到她輸入的值是：1000' OR '1'='1
這會導致結果 SQL 查詢返回表中的所有行，因為資料庫將該語句評估為始終為真。 想一想：資料庫收到一個請求，其中值可以是 1000 或 1 等於 1；它每次都會返回一個值！我們可以使用許多不同的 SQL 函式和操作來操縱語法，這個例子只是眾多例子中的一個。
下面是一個包含 SQL 注入漏洞的虛擬碼示例。
$username = getUserName();
$pw = getPassword();
$user = mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}
為了讓攻擊者利用這一點，他們可以簡單地針對目標域構建一個包含攻擊的 URL，如下所示
/login?username=admin&password=password' OR '1'='1密碼變數設定為包含 SQL 字元，導致生成的 SQL 字串返回一行，即使我們不知道密碼。生成的 SQL 查詢將是
SELECT * FROM userTable WHERE username = 'admin' AND password = 'password' OR '1'='1'引數化查詢是擊敗 SQL 注入的推薦解決方案。在引數化查詢中，開發人員會仔細確保查詢的每個輸入都被定義為特定的值和型別。下面是一個來自上述程式碼的示例，該示例被認為是一個安全的實現：
$username = getUserName();
$pw = getPassword();
$parameterizedQuery = prepare_query("SELECT * FROM userTable where username = ? and password = ?");
$parameterizedQuery.setString(1, $username)
$parameterizedQuery.setString(2, $password)
$user = parameterizedQuery.execute();
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}在上面的示例中，開發人員已仔細說明引數 1 應為字串幷包含使用者名稱，第二個引數包含密碼。
XSS（“跨站指令碼”）
XSS 使用伺服器來攻擊伺服器的訪問者。該攻擊不針對伺服器本身，而是針對使用者。
伺服器僅用於將攻擊者的值（通常是 JavaScript）反射給訪問者，然後訪問者在自己的瀏覽器中執行攻擊者的資料。攻擊者必須構造一個伺服器不清理和過濾的輸入，這樣，當訪問者單擊包含攻擊者值的連結，或訪問攻擊者在其攻擊中使用的網頁上的資源時，使用者就會執行攻擊者提供的程式碼。
下面是 Eve 向 Alice 傳送包含 XSS 攻擊的連結的圖形示例
這種攻擊稱為反射型 XSS，涉及 Eve 找到漏洞，然後向毫無戒心的使用者傳送包含攻擊的連結，並讓他們單擊該連結。該連結包含攻擊，並使 Web 伺服器將攻擊返回給點選該連結的受害者。
背後的程式碼可能是這樣的虛擬碼示例
$nickname = etNickName();
echo "Greeting $nickname, nice to meet you!";另一種 XSS 稱為儲存型 XSS 攻擊。在儲存型 XSS 攻擊中，攻擊者能夠將內容儲存在網頁上，而這些內容在每次有人訪問該網站時都會被反射。它不一定需要有人點選連結。
此圖形描述了 Eve 如何能夠儲存惡意 JavaScript，以便在任何人訪問該資源時在其瀏覽器中執行
XSS 攻擊可以完成許多事情，例如
- 竊取可用於身份驗證的 cookie
- 篡改網站，呈現 Web 伺服器未打算使用的內容
- 透過網路釣魚讓使用者在假登入表單中留下憑據
為了防禦 XSS，有幾項最佳實踐需要遵循
- 讓 Web 伺服器返回 CSP（“內容安全策略”）標頭，該標頭嚴格決定 JavaScript 的來源和執行方式
- 安全地編碼 Web 伺服器返回給使用者的輸出，有效地將 HTML 字元轉換為編碼的安全字元
HTML 編碼
HTML 編碼允許 Web 應用程式以安全的方式返回通常不安全的字元。例如，以下特殊字元可以編碼為其對應的字元
| 特殊字元 | HTML 實體 |
|---|---|
| < | < |
| > | > |
| " | " |
| & | & |
| ' | ' |
這會生成可以安全顯示的輸出。然後，我們可以使用客戶端的 JavaScript 將 HTML 實體安全地轉換為值。
CSP（“內容安全策略”）
Web 伺服器可以控制允許在網站上執行哪些型別的 JavaScript。這並不能消除漏洞，但當存在未知漏洞時，它會增加縱深防禦。
一種常見且嚴格的 CSP 是為 Web 應用程式使用者提供所有接受的 JavaScript 原始檔的列表。
此外，CSP 通常會阻止執行內聯 JavaScript。
為了更輕鬆地實現和檢測正在進行的攻擊，CSP 允許客戶端將 CSP 違規報告給伺服器提供的 URL。
Web 應用程式掃描
市面上有許多 Web 應用程式掃描器。它們允許掃描應用程式是否存在 SQL 注入和 XSS 等漏洞。與網路漏洞掃描器相反，Web 應用程式掃描器通常基於啟發式方法而不是簽名和已知漏洞列表。
Web 應用程式掃描器非常有用，特別是當它們整合到 CI（“持續整合”）和 CD（“持續交付”）等開發流程中時。
