[{"data":1,"prerenderedAt":51},["ShallowReactive",2],{"article-zh-information-security-is-quite-important":3},{"article":4,"related":19,"prevArticle":41,"nextArticle":45,"availableLocales":49},{"id":5,"slug":6,"image":7,"date":8,"published":9,"created_at":10,"updated_at":11,"title":12,"excerpt":13,"content":14,"custom_css":15,"keywords":16,"meta_description":17,"og_image":15,"image_width":18,"image_height":18,"category":15},"f9cf2977-ed78-4aef-a86f-4ece3fd5e606","information-security-is-quite-important","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/articles/bob_alice_information_security.jpg","2025-08-17T14:05:00+00:00",true,"2025-08-21T14:21:15.088194+00:00","2025-09-03T06:00:13.556+00:00","資訊安全應該是必修課？","所有看似完整且自洽的邏輯，一但來了一個必要的第三者，就得重新思考資訊完整性的問題","\u003Cp>「在缺乏『簽章（Signature）』與『不可否認（Non-repudiation）』的系統中，任何表面上的交易紀錄，都只是沙上城堡。」\u003C/p>\n\n\u003Cp>最近剛好參與到一個特別的案例當中，雖然在台灣的系統有很多類似的設計，但是這次實在太有感，想了想還是用故事的方式分享出來，話說。。。\u003C/p>\n\n\u003Cp>在一個名為「Pointland」的數位國度，人人使用點數交易買賣虛擬商品。有一個名為 Alice 的大型點數交易平台。Alice 擁有一個很受歡迎的 App，這個 App 上讓使用者可以用點數兌換商品。但 Alice 不想自己處理所有商品的交易流程，於是找來了 Bob —— 一個第三方開發商。\u003C/p>\n\n\u003Ch3>🧩 交易流程\u003C/h3>\n\u003Cp>Bob 為 Alice 設計了一個交易網站，這個網站的特性是：它只能在 Alice 的 App 的 WebView 裡運行。也就是說，這個網站不接受一般瀏覽器直接訪問，只有從 Alice 的 App 裡打開才會跑起來。Bob 認為這樣可以確保交易只在 Alice 的生態系統裡進行。\u003C/p>\n\n\u003Ch3>🔒 隱藏的風險\u003C/h3>\n\u003Cp>然而，所有的點數扣除和交易請求都是通過前端的 JS SDK 在這個 WebView 裡發起並完成的，Alice處理完這些所有細節，她也在App裡盡可能做了非常多安全驗證與保全措施，但是作為一個第三方網站， Bob 的後端並沒有拿到任何交易驗證的資訊。換句話說，Bob 的伺服器完全不知道這筆交易是真是假，只能相信 Alice 的 App 中的Webview說交易已經成功了。\u003C/p>\n\n\u003Ch3>⚠️ 問題浮現\u003C/h3>\n\n\u003Cp>某天，一個安全測試人員發現，只要用簡易的MITM手段攔截Webview traffic，就能取得user token，再透過模擬扣除點數的行為，就可以輕易偽造交易請求，因為沒有後端的驗證機制，這些交易就能被輕易地「假造」。Bob 這時才發現，原來整個流程缺少了一個後端的校驗環節，他完全沒有辦法去核實這些交易到底是不是合法的。\u003C/p>\n\n\u003Ch2>結論是...無解\u003C/h2>\n\u003Cp>Bob開發團隊的SA，大概是得到了大語言模型的加持，設計了一套非常複雜的驗證體系，極大地增加了\u003Cspan style=\"text-decoration: line-through;\">開發\u003C/span>攻擊難度，複雜到可能連Alice與Bob團隊的所有人都相信這個問題已經解決了。\u003C/p>\n\n\u003Cp>我還記得當年密碼學教科書上有關Bob & Alice的所有示意圖中，大概就有類似的內容，所以看到這個案子的時候，我第一個反應就是，只要Alice不改，那Bob搞得再怎麼複雜，最終大概就是增加bug的程度會比解決問題的程度來的大得多，簡單地說，Alice是在整個體系裡，是唯一知道交易是否存在與交易完整資訊的人，如果她不提供資訊給Bob，那Bob就無法確認這個交易資訊是否為真。\u003C/p>\n\n\u003Ch3>兩個解藥\u003C/h3>\n\n\u003Cp>又夢回當年，課本教的是，Alice只要隨著這封信附上一串簡單的簽章，這個簽章只有Alice能發，而且Bob可以透過Alice更早之前給的算法來驗證，這樣只要簽章錯誤，我們至少知道Alice的信被改過，可以棄用這封信的資訊；亦或，出社會後，比較常見的方案是Alice透過另外一個渠道，完全只有兩人知道且無法被篡改的路徑來傳輸這封信。\u003C/p>\n\n\u003Cp>這兩個方法都是很常見且非常有效的，不過在這個案例中，Alice的開發團隊，大概有什麼難言之隱吧，預設立場就是不改，加個digest可以研議個大半年，基本webhook event也不會做，然後怪Bob團隊沒有更早通知他們有這樣的設計問題，聽到後，有點哭笑不得，彷彿看到一個人指著街上的路人大罵...你怎麼不告訴我，我是傻子。\u003C/p>\n\n\u003Cp>我是覺得Bob還好，發現的早，後面要是有John/William/Bill...各家第三方開發商，自求多福吧！\u003C/p>\n\n\u003Ch3>永動機\u003C/h3>\n\u003Cp>Bob團隊在設計解決方案的時候，興致勃勃地弄了好多花樣，請我幫忙review，看完後，我腦海中浮現的第一個念頭是永動機，如果知道熱力學第二定律，是不是就不會花時間去做這些理論上很難甚至注定無法完成的事呢？我有點慶幸當年母校的老師們在這些基礎課程上，還是有要求的。不然依照我的個性，估計也會弄個永動機出來。\u003C/p>\n\n\u003Ch2>這跟SQA有什麼關係?\u003C/h2>\n\u003Cp>\u003Cb>當然有！\u003C/b>\u003C/p>\n\u003Cp>因為這個問題在開發中期就有被我們提出來，雖然我們不進行所謂的安全測試，但這種比較偏基本系統設計偏誤，所以在API測試當中就確認會有這些問題。。。中文不好表達複數，沒錯，Alice還不知道是\"這些\"。\u003C/p>\n\n\u003Cp>\u003Cb>我們的業務裡不含安全測試，但如果有安全疑慮，我們還是會口頭上/郵件裡/報告中提醒客戶，別上線裸奔，但要不要接受，想不想改，就完全取決於管理者們的智慧了。\u003C/b>\u003C/p>\n\n",null,"資訊安全,Information Secruity,密碼學,簽章","資訊安全有時候不能只看自己，你自己足夠安全，但需要跟外部交換資訊時，卻忽略一些基本原則，有時候反而更可怕",1024,[20,27,34],{"id":21,"slug":22,"title":23,"excerpt":24,"image":25,"date":26,"category":15},"deb70edd-ff7f-4b6e-b230-fa1c83dc0afa","qaptly-v0175-codex-support","Qaptly Desktop 開始支持 Codex","Qaptly Desktop 的 AI Assistant 從 v0.17.5 開始正式開放 Codex 支持。如果你本來就是 ChatGPT 訂閱用戶，現在可以直接讓 AI Assistant 使用 Codex，在日常測試設計與自動化調整上節省成本。","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/blog_pictures/qaptly_support_codex.jpg","2026-05-16T13:01:00+00:00",{"id":28,"slug":29,"title":30,"excerpt":31,"image":32,"date":33,"category":15},"eebc38be-6eec-4e68-af7f-e5dd6c611a0f","ai-agent-workflow-critical-things","AI 協作進入 workflow 之後，那些最容易被低估、卻最關鍵的幾件事","過完年後，基本上都在幫幾間新創與大公司內部的開發部門導入 agentic development。這段時間看了不少團隊的做法，也有一些很直接的感受，想趁這個機會整理一下。","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/articles/ai-workflow.jpg","2026-03-24T16:10:00+00:00",{"id":35,"slug":36,"title":37,"excerpt":38,"image":39,"date":40,"category":15},"1092dc59-4718-4902-809c-74cfdfc5fffd","from-tool-to-process-challenges","從單點工具到流程閉環的虛實與挑戰","探討2026年AI在軟體開發生命週期中的實踐，從單點工具普及化到流程閉環協作的轉變，以及QA自動化的真實與虛假繁榮。","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/blog_pictures/from_tool_to_process.png","2026-03-02T03:06:00+00:00",{"slug":42,"title":43,"date":44},"stress-test-or-volume-test","從系統崩潰來看壓力測試的誤區","2025-07-25T09:32:00+00:00",{"slug":46,"title":47,"date":48},"testability-is-the-most-important-thing-of-SQA","軟體品質的核心，是可測試性","2025-09-02T10:02:00+00:00",[50],"zh",1786449983124]