前言

今天客戶又寄來最新一份資安風險的報告要求我們要修正

他們採用的是 HP Fortify SCA

但不得不說客戶每次掃描的規則似乎都不同

第一次掃出 A B C

=> 我們修正完 A B C

=> 第二次掃出 D E F (這次沒掃到A B C 代表修正成功?)

=> 我們修正完 D E F

=> 第三次又掃出 A B C

=> ???

那為什麼第二次沒掃出 A B C 有問題?

我們也是根據 Fortify 上的建議解法修正了耶...

這次的新問題

客戶這一年裡前前後後應該也掃了十幾次

我們也改了十幾次...

永遠都是某次改後，後來又被掃出來Orz

不過這次第一次遇到 JavaScript 發生 Open Redirect 問題

第一步當然是先去 Google 何謂 Open Redirect vulnerability

初步看起來應該是因為我們把重新導向的目標來源是參數

讓有心人士可以透過修改參數的方式來進行攻擊

大部分看解法都是在 C#, PHP 等後端防範

像是檢查是否為合法路徑、參數是否有非法字元

例如下面這段 JavaScript 一樣

function goPage() {
    var dest = $('#myInput').val();
    window.open(dest,'_black');
}

可參考此網頁說明

發生情境

以我們發生這問題的情境是要讓使用者下載 Excel 報表

但下載方法是通用的，只要把檔名傳到後端就可下載對應的檔案

所以在 JavaScript 端就有個方法是

function downloadExcel(filename) {
    var url = '/api/function?filename=' + filename;
    window.open(url, '_blank');
}

C# 端

public ActionResult FunctionName(string filename)
{
    var dir = new DirectoryInfo(Path.GetTempPath());
    var files = dir.GetFiles(filename);
    var file = files[0];
    var name = Path.GetFileName(file.FullName);
    var mimeType = MimeMapping.GetMimeMapping(name);
    var stram = new FileStream(file.FullName, FileMode.Open, FileAccess.Read, FileShare.Read);
    return File(stream, mimeType,HttpUtility.UrlEncode(file.FullName,Encoding.UTF8));
}

我們能做些什麼

呃... 其實也只能在 window.open 前檢查 url 是否合法

我們參考了 這篇的解法

接下來只能等客戶下次掃完看有沒有成功解決此風險囉

結語

資安報告真是個頭痛的東西

被掃出來又不能不處理

只能邊改邊學，之後盡量在開發時就避開這些問題囉