歷史上，有許多資料庫被破等等的問題，都可以歸咎於「軟體」。
我們接下來幾篇，會講曾經因為「軟體」本身的問題，導致其中一個環節被突破，進一步導致更大傷害的例子。

服務被破，是常有的事情。其防禦方式不外乎：

• 將敏感資料作保護
• 實體保護（控管人員進出等）
• 時常注意 security bulletin，並作對應的系統升級
• 環境監控（定期威脅分析與紀錄分析）

談 CVE-2017-5638

Struts2 是一個 Java 的框架，目前是歸屬在 Apache 基金會底下。CVE-2017-5638 最 "有名" 的時候，是在 Equifax 因其導致一億四千多萬名美國人的個資外洩，包括信用卡號、社會安全碼（相當於台灣的身分證字號）、生日、地址等等。

NIST（美國版工研院）對於這個漏洞的解說是：

The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, as exploited in the wild in March 2017 with a Content-Type header containing a #cmd= string.

Jakarta Multipart (一種 Content-Type） Parser 會在檔案上傳後分生錯誤時用不正確的方式來產生錯誤訊息並做錯誤處理，所以攻擊者可以以 Content-Type、Content-Disposition、Content-Length 的 HTTP Header 來執行程式碼。

Parser（語法分析器）是指：依據一定的語法，是對一個文本進行分析，並作轉化的動作。例如 HTML 在瀏覽器中，即是先將純文字塞進語法分析器來做分析，才能做後續的渲染等等動作。

SSTI

這個 CVE，主要是在伺服器端渲染的地方出了問題。
這次的問題是一種注入（injection）攻擊，可以想像成 網頁版的 SQL 注入。正式的名字應該是叫做「伺服器渲染注入攻擊」（好長）
伺服器端渲染，即 server-side render，通常是這樣進行的：

1. 伺服器收到請求，判斷要去讀哪個檔案，可能用語法分析器讀它
2. 依據該頁面的內容、模板程式碼和請求的內容，將該頁面組合起來
3. 返回 HTML （或其他格式）

但是這個流程，有時候會出一些問題。例如說，語法分析器本身有問題（讀一讀自爆）、程式本身有問題（頁面中寫了 shit logic）等等。
SSTI 簡單來說，就是把使用者的輸入，丟進一個韓式，然後轉成網頁。不過，因為有使用者輸入，做「輸入核實」（input santization）就很重要。

攻擊缺口

通常，要做一個同時有檔案上傳的表單，最簡單的方式就是使用 HTTP Post + multipart/form-data。它通常長得像這樣子：

POST / HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------lorem

-----------------------------lorem
Content-Disposition: form-data; name="text"

text default
-----------------------------lorem
Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain

<a.txt 的內容>

由於可以將一個請求分割成多個部分，而不需要發一個以上的請求（因為同時發兩到三個請求的話，要顧慮到一個請求失敗的問題），事情就簡單多了。

Struts2 即是使用 Jakarta 來分析 multipart，它主要負責的範圍是：

1. 先看 Content-Type 是不是 multipart/form-data
2. 是的話，分析它
3. 不是的話，返回一個錯誤，並告知錯誤的問題在哪

不過以上 (3) 的部分代表： Jakarta 必須要分析 Content-Type。

沒做輸入核實

萬一 Jakarta 做了奇怪事情怎麼辦？可能只能祈禱不要出錯。在這個漏洞當中，人們發現 Jakarta 在 Content-Type 看起來很像模板的程式碼時，會直接把它當模板的程式碼來執行。

這種狀況，稱作「遠端程式碼執行」（remote code execution, RCE）。
然後因為 OGNL 模板（這次出問題模板語言）有「執行指令」的語法，所以就可以做各種事情，例如讀檔、重開機、裝軟體，拿下伺服器了。

換句話說，一行 curl -data 'lorem' --header 'lorem' 就爆了。

Equifax 自找的麻煩

其實這個漏洞，在三月左右就被發現，而且有放上 security bulletin。Struts2 團隊在發現問題的一兩週後就做了修正。就時間上來看，攻擊方差不多是在五月左右突破系統並開始撈資料，直到 Equifax 八月才想到要補這個洞時，才發現資料已經被人家破了。又過了一個月，才對外公布這些消息，並作相關的補救措施。

直到現在，許多人還是很怕他們的信用紀錄被盜用。

維護團隊的建議

後來 Struts 的維護團隊發了一封信，其中提到 Equifax 這個超級慢的修漏洞流程，還提到了這些建議。

1. 了解所使用的各個軟體和函示庫，並留意其是否有新漏洞出現
2. 準備一個能夠迅速修補線上環境漏洞的方式
3. 不對任何軟體帶有信任，必須要有冗余的安全機制
4. 做好安全階層防護，例如 HTTP 伺服器被突破的狀況下，不應該使資料庫也受到衝擊
5. 做環境監控，至少要知道有不正常的資料進出