今天早上看到這一篇文章 Harvesting credit card numbers and passwords from websites，看了一下，然後覺得：

不過，既然作者講的事情的確是有可能發生，那我們就應該來認真地探討一下這個問題。

文章連結：原文 翻譯

原文章的懶人包

作者說，他或許有，或許沒有寫了一支程式，基本上能夠在任何頁面上竊取個人資訊，並在不被發現的狀況下，可以繞過現行的瀏覽器保護機制，把這些個人資訊傳回去。

不過他後來有說，他是唬爛的，但這真的理論上可行（如果保護沒做好）。

原作者指出的問題

很簡單。我在這邊列舉一下：

• XSS
• npm （以及大部分的套件管理機制）的檢查機制

最嚴重的是 XSS。XSS 是什麼，應該有別人的文章寫過了。基本上，就是想辦法在別人的網站上插入惡意的 code，比較常見的狀況是：網站有表單，然後表單會顯示在網站上，但這表單是直接對頁面插入 HTML Tag，所以如果寫了 <script>alert('lorem')</script> 會爆掉的。
不過，作者文章中說的問題，不一定要有「使用者輸入」才能有效。作者所敘述的方式，是通過依賴包的方式來污染。
寫前端 JS 專案的人應該開始心有戚戚焉了？

談攻擊模式

套件污染（或：惡意套件）

我相信，一定有人會開始講「JS屎語言，糟糕透了，應該用火燒燬」。
不用擔心。這個問題，到處都有。就連 Python 和 CocoaPods 都有可能中標。
原作者所提的攻擊方式，是透過：

1. 對套件管理上傳一個看起來很有用的函式庫
2. 這函式庫內帶惡意程式碼
3. 然後想辦法讓一堆東西用這個函式庫

總之，不管怎麼看，這篇文章主要的問題是：

1. 依賴包氾濫
2. CSP 設定不當

在 Javascript 生態圈中，(1) 這個問題的確比較嚴重。因為 JS 的內建函式庫蠻屎的（node 還有一些，瀏覽器則是真的沒有），所以導致會有滿多事情依賴第三方套件來握的。

套件污染的問題，到處都存在著，而且有可能會有比原作者寫到的攻擊模式，有更大的攻擊面可以使用。就我用過的語言當中，套件管理的程式大多都支持 postinstall 事件掛勾，讓人可以在套件管理程式安裝完成之後，做一些事情（例如編譯？）等等。

例如說，可以參考之前這個案例，其行為是在安裝完成之後，把系統環境變數全部傳回去給別人。因為環境變數中可能會有一些敏感資訊，所以這會蠻嚴重的。

更進一步來說，如果執行套件管理的時候，是用 root 的權限（除非有修改過環境，使其執行毋需 root）的話，那就會有更大的攻擊面可以用。例如說幫你裝程式、幫你砍資料夾之類的。

檢查依賴包?

假設我開始一個專案，先裝 express moment lodash，這三個都是常用的東西。分別是網頁框架、時間處理函式庫、常用算法的函式庫。

$ npm install express moment lodash
...
$ ls -1 node_modules/ | wc -l
      49

我這專案就變成有 49 個依賴包啦。先假設這些函式庫都不搞原作者裡面說的混淆程式碼，假設要人工看，49 個函式庫就算了，若是中、大型專案，基本上就不太可能把每個依賴包都人工看過一次。

即使你要看，要怎麼看？就算這些程式碼都開源了，也不一定有人會真的去看他的內容。搞不好軟體公司連自己員工的程式都不看了，還要看第三方程式？

CSP

原作者提到的這個攻擊，是建立在網站並沒有設定 Content Security Policy (CSP) ，或是有設定卻沒有設定好（等於沒有）的狀況。CSP 主要是為了防止 XSS 的情形，而且還有「回報違規事件」的功能。

CSP 可以：

• 強制所有內容都使用 HTTPS
• 強制瀏覽器只能從某個來源讀取東西
• 強制規定 form 表單的目標 action=<url>

因為很多站台的 CSP 設定並不完整（或是有漏洞），所以原作者的攻擊方式是行得通的。
若 CSP 有設定好，基本上這個攻擊方式也殘廢了，不過還有一種可能：

1. 攻擊方同時打了前端跟後端
2. 後端把 CSP 拔掉（例如說在 express 裡面裝一個拔掉 HTTP Header 的 middleware）

不過這個要很剛好，一次打了兩邊才行。