底下是對一個古老的 Chat Server 進行 Buffer Overflow 攻擊的實作案例:
https://www.onsecurity.io/blog/buffer-overflow-easy-chat-server-31/

這個弱點被記載在 CVE-2004-2466 弱點資料庫中, CVSS 分數有 5 分, 不算是很嚴重的漏洞, 但足以讓這台 Chat Server 服務停擺.

從上面那個實作來看, 當攻擊字串增加到 250 個字元的時候, 就會觸發這個弱點, 造成損害.
當我們知道他有這個漏洞之後, 在尚未來得及修補漏洞之前, 只要把字串限制在 250 個字元以下, 就能暫時性的避開這個威脅.

現在的問題是:
你們知不知道, 你們的 Chat Server 有沒有類似的弱點可能被觸發?
有誰(最好是獨立第三方, 不是你們自己)能夠證明: 這個弱點是否存在?
你們可能會被觸發漏洞的字數是多少? 有沒有第三方公正單位可以驗證?

在還沒確認你們有沒有弱點之前, 限制字數在一定數量以下, 是否可以降低被觸發機率?

還有另外一個問題: 上面那個弱點, 是一開始就被發現的嗎?
不是喔, 她從這個 Chat Server 一開始上市就存在, 但是都沒有人發現她, 直到產品陸續更版到 3.1, 才突然被人發現; 然後趕快去回測, 發現過去的所有版本, 都有這個問題.

這證明上面那個弱點一直都存在, 只是沒有人去把它挖出來用.

但是你怎麼知道: 會是誰? 在哪一天? 把她挖出來做甚麼用?
如果是被資安研究員或白帽/灰帽駭客挖到, 那你很幸運, 有機會補好;
萬一被黑帽駭客挖到, 那你可能被打得哇哇叫, 還不知道發生甚麼事情?

當然, 如果你們不在意服務是否會停擺的問題, 就不需要關心這個議題.

就程式面來說，確實是如你朋友所說的。

但就用戶體驗感來說。一次貼幾千字文字到聊天室上。
你覺得有人會想看吧??

有時候看東西不能只看一面。
就工程師而言，確實會先往效能評估。
但有時你得往體驗方向去思考。

另外，多說一件事。不要認為一次傳幾MB的文字是一件好事。
畢竟你認為單純是1對1。這樣是最多2人。的確是還好。
但如果沒加上發言秒數限制的話。
或是多人聊天室。
一次幾MB出去。10人就幾10MB了。100人呢???
雖然這樣說也不是很好。畢竟沒那麼多人這樣子傳。

問題是...這是正常使用的情況下。如果不正常使用呢??
思考下吧!