injection

ProductHunt 上面的 bot 問題

在「Bots, so many bots (wakatime.com)」這邊看到的，原文在「Bots, so many Bots」這邊。

作者用釣魚的方式 (對 LLM 的 prompt injection) 以及分析的方式保守估算 ProductHunt 上面至少有 60% 的帳號是 bot，但也提到了一個悲哀的事實，想辦法讓機器人 upvote 以及留言，讓你得到更多正面的回饋，就有機會登上 newsletter 並且得到更多對「真人」的曝光：

Is launching on ProductHunt worth it? Even though most comments and upvotes are bots, there’s probably still some real humans using ProductHunt... maybe. If you pay the bots and get featured in the newsletter, my guess is more real humans will see your product.

yeah，這也是產業鏈...

polyfill.io 被放 malicious code 的事件

台灣的圈子蠻多人是從「請儘速遠離 cdn.polyfill.io 之惡意程式碼淺析」這邊看到的，一些 code 相關的分析部分可以移駕過去看。裡面提到的 GitHub 上面 alitonium 所寫的 comment 蠻值得讀一下 (第一次點的時候會出現 GitHub 的警告，再點一次應該就會跳到正確的 comment 上)。

polyfill.js 算是老專案了，從 https://github.com/polyfillpolyfill/polyfill-service/graphs/contributors 這邊可以看到是 2013 年開始有記錄，主要是針對舊的瀏覽器 (像是 IE11)，透過 javascript 的方式補上對應的功能。

現在的瀏覽器都是一直在更新，大多數的情況不太需要 polyfill 了，但畢竟很多舊的案子還在用，在這次 domain 被中國公司拿走後，Cloudflare 在今年 2024/2/29 就有先寫一篇算是預警的文章了：「polyfill.io now available on cdnjs: reduce your supply chain risk」，不過這種事情都是還沒發生前大家不會有太多重視，接下來就是 GitHub 上面的討論，然後是真的被動手加 malicious code 進去後，有人發現的討論。

後續大家都被迫要開始處理這件事情，GitHub 的作法看起來沒什麼問題：先標注 malicious repository 但是還是讓人可以進去翻歷史資料與討論。

不過 Cloudflare 這邊動作有點大，直接主動幫 CDN 客戶過濾了：「Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet」，這篇在 Hacker News 上也有討論：「Cloudflare automatically fixes Polyfill.io for free sites (cloudflare.com)」。

這個「越界」有點多，這應該也是直接讓 CEO Matthew Prince 出來掛文章作者的原因。這次 Cloudflare 主動做的事情包括了將免費的客戶預設開啟過濾，而付費的客戶則不會主動開啟，但提供一鍵開關：

Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.

另外也允許所有客戶關掉這個保護：

All customers can turn off the feature at any time.

所以後續就會有另外一條大支線討論：在使用者沒有事前同意的情況下，以「安全」為名主動更改使用者頁面上的東西，這件事情是不是可以接受？如果以「安全」為名可以接受，為什麼是免費的先動，付費的卻不動？雖然我猜 Cloudflare 會裝死到底就是了...

密碼裡面不能有 SELECT/INSERT/UPDATE/DELETE/DROP

這是在 Hacker News 上看到的：「Password may not contain: select, insert, update, delete, drop (uni-lj.si)」，原網站在「Password reset - ID portal」，熱鬧的地方在於原作者 (或是外包商？) 也在 Hacker News 上面回應...

禁止密碼裡面有某些字元還蠻常見的，但這次看到的很有趣 (然後被貼到 Hacker News 上)：

Your password must also not contain the following character combinations: script, select, insert, update, delete, drop, --, ', /*, */.

從網域及英文版的介面可以查到這是盧比安納大學的系統，作者 (或是外包) 在 id=39079030 提到了這是上面的要求：

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management.

I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

就... 很好玩？

GitHub Copilot 產生出來程式的安全性問題

看到「Encoding data for POST requests」這篇大家才回頭注意到 GitHub Copilot 首頁的範例本身就有安全漏洞：

async function isPositive(text: string): Promise<boolean> {
  const response = await fetch(`http://text-processing.com/api/sentiment/`, {
    method: "POST",
    body: `text=${text}`,
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
    },
  });
  const json = await response.json();
  return json.label === "pos";
}

其中 text=${text} 是一個 injection 類的漏洞，首頁的範例應該是被挑過的，但仍然出現了這個嚴重的問題，從這邊可以看出 GitHub 與 OpenAI 在這條線上的問題...

相對路徑的攻擊方式 (Relative Path Overwite，RPO)

在「Large-scale analysis of style injection by relative path overwrite」這邊看到的，記得這個方式不是新方法，不過還是有人會中...

這種攻擊是組合技，基礎是引用 css 或是 js 時使用相對路徑 (像是 static/style.css 這樣的引用法)，再加上 https://www.example.com/a.php 這樣的頁面通常也可以吃 https://www.example.com/a.php/，甚至是後面再加東西... 在某些情境下組不出來，但精心策劃後就有機會在頁面上弄出奇怪的 xss 或是其他攻擊了。而論文內列出了常見的的組合：

然後拿 Alexa 的排名來看，其實還是有些站台可以打：

防禦的方式也不算太難，absolute path 是個還不錯的方式：

One option is to use only absolute URLs, taking away the relative path expansion.

而 base tag 也是個方式 (不過在 IE 上還是有問題)：

Alternatively you can specify a base tag, though Internet Explorer did not appear to implement the tag correctly (i.e., was still vulnerable) at the time of the evaluation.

另外作者也提到了 document type 的方式 (看起來是建議用 html5 的 <!DOCTYPE html>)，然後 IE 另外做些處理避免失效：

One of the best mitigations is to avoid exploitation by declaring a modern document type that causes rendering in standards compliant mode. This defeats the attack in all browsers apart from IE. For IE it is also necessary to prevent the page being loaded in a frame by using X-Frame-Options , using X-Content-Type-Options to disable ‘content type sniffing,’ and X-UA-Compatible to turn off IE’s compatibility view.

不過大型站台本來就因為業務需求，會把 asset domain 切開 (然後透過 CDN 加速)，而且會設計系統讓 programmer 很容易使用這樣的架構，反而因此比較不會用到 relative path，中這個攻擊的機會就低多了...