2025年11月10日 星期一

[研究]AppScan報告_fbp (Cookie) 有【加密的階段作業 (SSL) Cookie 中遺漏安全屬性】弱點

[研究]AppScan報告_fbp (Cookie) 有【加密的階段作業 (SSL) Cookie 中遺漏安全屬性】弱點

2025-11-10

續

[研究]ASP.NET WebForm 網站用 AppScan 掃描發現【加密的階段作業 (SSL) Cookie 中遺漏安全屬性】
https://shaurong.blogspot.com/2025/10/aspnet-webform-appscan-ssl-cookie.html

********************************************************************************

 AppScan 掃描 ASP.NET WebForm 報告下面弱點

加密的階段作業 (SSL) Cookie 中遺漏安全屬性

嚴重性： 中

實體： _fbp (Cookie)

風險： 有可能竊取在加密階段作業期間傳送的使用者和階段作業資訊 (Cookie)

原因： Web 應用程式會透過 SSL 傳送未受保護的 Cookie

修正： 新增 'Secure' 屬性至所有機密 Cookie

經查　_fbp (Cookie)　是下面程式碼產生，如何處理？

<!-- Facebook Pixel Code -->

<script>
    !function (f, b, e, v, n, t, s) {
        if (f.fbq) return; n = f.fbq = function () {
            n.callMethod ?
                n.callMethod.apply(n, arguments) : n.queue.push(arguments)
        };
        if (!f._fbq) f._fbq = n; n.push = n; n.loaded = !0; n.version = '2.0';
        n.queue = []; t = b.createElement(e); t.async = !0;
        t.src = v; s = b.getElementsByTagName(e)[0];
        s.parentNode.insertBefore(t, s)
    }(window, document, 'script',
        'https://connect.facebook.net/en_US/fbevents.js');
    fbq('init', '(略)');
    fbq('track', 'PageView');
</script>
<noscript>
    <img height="1" width="1" style="display: none"
        src="https://www.facebook.com/tr?id=(略)&ev=PageView&noscript=1" />
</noscript>
<!-- End Facebook Pixel Code -->
ChatGPT
AppScan finding：它把 _fbp（由 Facebook / Meta Pixel 在瀏覽器建立的追蹤 cookie）抓到「未標示 Secure 屬性」，因此在 HTTPS 傳輸時被視為一個中度風險（可能被攔截/竊取）。下面我用繁體中文把原因、可行解法、範例程式碼與優缺點列清楚，讓你可以直接採取或交辦給開發/資安團隊處理。
重點簡短結論
  • _fbp 是由 Meta（Facebook）Pixel client-side JavaScript 所建立的 cookie，用於廣告/轉換追蹤。官方文件把 _fbp/_fbc 當成可用於 Conversions API 的瀏覽器 cookie 值。
  • 你本身可以透過幾種方式處理這個 AppScan 警示：（A）移除或停用 Pixel（最直接）／（B）改以 server-side Conversions API（根本解）／（C）在 client 端覆寫 cookie，加上 Secure / SameSite（可快速緩解但非完美）／（D）若必須保留，可向資安接受風險並做文件化與例外。 
為什麼會發生？
Meta Pixel 的 JS 在使用者瀏覽網站時以 document.cookie 建立 _fbp（first-party cookie）。原則上這種 cookie 是由外部 JS 設定的，所以它預設不會是 HttpOnly（JS 必須能讀寫），而 Secure 屬性也不是必然被加上。多個討論與提問指出，Pixel 本身通常不會把 Secure/HttpOnly 一併設好，因此掃描器會回報缺 Secure。
可行處理方案（優先順序 + 說明）
1) 最推薦：移除 client-side Pixel，改用 server-side Conversions API（或 hybrid）
  • 用 server-side（或 server proxy / server GTM）把事件直接送到 Meta，這樣就不用在客戶端依賴 _fbp 來傳遞（或至少可減少依賴），能消除掃描器針對該 cookie 的警示來源，且通常更符合隱私/合規（可搭配同意管理）。
  • 缺點：需後端/infra 改動、測試與驗證，開發成本較高。
2) 快速緩解：在頁面（Pixel 加載後）用 JavaScript 讀取並覆寫 _fbp，加上 Secure、SameSite=None（並設定 domain/path/expiry）
  • 可在 fbq('init', ...) 之後短延遲覆寫 cookie，使 cookie 帶上 Secure 屬性，掃描器通常就會判定為「已標 Secure」。
  • 優點：實作簡單、立刻降低掃描器警示。
  • 缺點／風險：1) 無法把 cookie 設為 HttpOnly（因為要 JS 能讀寫，HttpOnly 就不可能）; 2) Facebook 的 Pixel 或未來版本可能再覆寫 cookie（可能移除 Secure），所以要確保覆寫程式會在 Pixel 每次建立 cookie 後再次執行（例如在 load 後定時/重試幾次）。
下面給你可直接貼在 <head> 或 fbq('init',...) 之後的範例（繁中註解）：
<script>
(function ensureFbpSecure(retries = 5, delay = 500) {
  function setSecureFbp() {
    try {
      var name = '_fbp';
      // 找出 _fbp 的值
      var cookies = document.cookie.split('; ').filter(Boolean);
      var found = cookies.find(function(c){ return c.indexOf(name + '=') === 0; });
      if (!found) return false; // 尚未建立
      var value = found.split('=').slice(1).join('=');

      // 設定 expiry (例如 90 天)，並覆寫同一 cookie，加入 Secure 與 SameSite=None
      var expires = new Date(Date.now() + 90*24*60*60*1000).toUTCString();
      // 不指定 domain（host-only）通常較安全，避免跨子網域問題；若你要跨子網域，可用 '.yourdomain.com'
      document.cookie = name + '=' + value +
                        '; path=/; expires=' + expires +
                        '; Secure; SameSite=None';
      return true;
    } catch (e) {
      return false;
    }
  }

  // 嘗試覆寫，若尚未建立則重試幾次（Pixel 可能晚於本 script 執行）
  if (!setSecureFbp() && retries > 0) {
    setTimeout(function(){ ensureFbpSecure(retries - 1, delay); }, delay);
  }
})();
</script>


注意事項：
  • Secure 只有在 HTTPS 下有意義（你的 URL 已是 https）。
  • SameSite=None 加上 Secure 是讓第三方/跨站情況下 cookie 可以被送出的組合（若你要廣告追蹤跨站）。
  • 若你的網站有多個子網域、或要求 cookie 設在頂級 domain，可把 domain=.yourdomain.com 加回去，但要小心子網域權限問題。
3) 其他選項
  • 覆寫 Pixel 原始程式：不建議直接改第三方供給的 JS，容易日後維護出問題。
  • 例外／文件化風險：若確定無法移除或無法完全修正，可把掃描警示做為第三方 tracking cookie 的已知例外，並在資安風險接受文件中說明（含為何必須保留、減緩措施、同意收集流程等）。許多實務上會這樣處理，但要經由資安/法務同意。
要交給開發/資安團隊的建議（可直接 copy）
參考來源（你可以把這些貼到報告回覆）
(完)













於




















沒有留言:
















張貼留言