善用QRadar App架構　開發客製化安全監控程式

安全工程與QRadar應用程式

應用程式安全對每個軟體專案來說都很重要，特別是資安專案，這就是為何QRadar應用程式提交的驗證程序需要接受安全工程審核（圖2）。作為安全開發團隊的成員，希望這篇文章能就應用程式驗證程序的注意事項，提供應用程式開發人員深入洞察。請注意，大部分的QRadar應用程式皆部署於Flask架構的Python，因此大多數範例都以Python和Flask當作設計基礎。如果選擇不同的技術堆疊，這裡所描述的概念仍然頗有助益，但必須修改範例才能符合當下的需要。

▲圖2 應用程式安全對每個軟體專案來說都很重要，特別是資安專案。

請留意，世上沒有一體適用的安全防護解決方案，也沒有任何工具能夠偵測所有問題。安全工程工具最重要的用處是確認問題，並且未雨綢繆。

如何避免應用程式提交遭到拒絕

每個應用程式在提交過程中都要接受個別的安全審核。本文所述的訣竅和討論可指引使用者了解審核的項目類型，以及經常被詢問的問題，以減少應用程式提交因常見錯誤而遭到拒絕的機會。

如同前述，在X-Force App Exchange上提交的所有QRadar應用程式都要接受安全審核。檢查應用程式是否有問題，並在應用程式未能通過應用程式安全驗證程序時通知開發人員。

這裡提供一些範例，介紹被視為不安全的應用程式提交時常碰到的問題。附帶一提，也將提供許多問題的簡易修正方法，而這些範例可協助編寫安全的應用程式，並概述應用程式驗證的審核項目。

QRadar應用程式中的SQL資料隱碼攻擊（SQLi）

在驗證應用程式安全時遭遇的頭號問題就是SQL資料隱碼攻擊。如果無法理解此論述的負面意涵，請閱讀OWASP文章或觀看Computerphile提供的YouTube影片，此類攻擊讓心懷不軌的惡意人士皆可恣意攻擊資料庫，例如：

# Do NOT do it this way.
cmd = "update people set
name='%s' where id='%s'" % 
(name, id) curs.execute(cmd)
#OR
cmd = "update people set name=
"+name+" where id="+id curs.
execute(cmd)

一般而言，應該一律使用參數化的SQL陳述式（有時稱為Prepared Statements）。如果使用危險方式建立查詢（例如字串格式化或串連），一旦變數中出現不被信任的資料，系統對SQL資料隱碼攻擊毫無防備。即使認定既有變數的來源安全，但請記住，日後使用者可能可編輯相同的變數。或者，如果編寫的程式碼可重複使用，有心人士可能會使用不安全的資料來呼叫你的函數以進行SQL資料隱碼攻擊。

因此，使用參數化的SQL陳述式才是上策。應用程式驗證能帶來額外好處，只要檢查到安全的參數化SQL時，就表示應用程式可以輕鬆通過驗證。如果使用不安全的查詢建構，就必須花時間來回檢查原始碼，以判斷是否有漏洞會被濫用。以下表單提供更多的範例和實作詳細資料：

https://developer.ibm.com/answers/questions/417797/how-to-prevent-sql-injection-in-an-app/

這裡整理一下三個SQL注入重點摘要，包括：使用參數化（Prepared）SQL陳述式來提供使用者資料輸入；若要建立動態查詢（指令），請使用白名單方法來設定；將所有資料視為不受信任，即使資料現在可以信任但未必能永續確保其可靠性，而且這樣可以加快驗證速度。

QRadar應用程式中的跨網站指令碼（XSS）

說到不受信任的資料，另一個很常見的問題就是跨網站指令碼。類似SQLi，這是在混合資料與指令時造成。OWASP和Computerphile(YouTube)詳細說明了這些資料隱碼攻擊。簡言之，XSS攻擊可讓惡意使用者將他們自己的JavaScript注入其他人的頁面，然後進行不當用途。

雖然要修正XSS很簡單，但不如SQLi預防那樣明確。以下將提出一些要點，但建議深入閱讀「OWASP的XSS預防指南」。

許多熱門的JS架構都有一些XSS預防版本內容，建議深入閱讀以了解自身的架構必須提供哪些防範。要點是確認資料跳脫，一個很好的範例是jQuery的.text()和.html()函數。.html()函數會將字串的常數值內容放入目標DOM元素中，因此，如果傳遞，將會插入指令碼元素。若使用相同字串搭配.text()，將導致插入以下內容：

編碼的字串不會建立指令碼元素，而是顯示預定文字。

不跳脫QRadar API提供的資料

談到不受信任的資料，不應毫無保留地相信QRadar API所取得的任何資料。原因是，QRadar並未對API取得資料的輸出進行任何清理。雖然不是所有欄位都無法信任，但將資料全部視為不受信任會比較簡單。例如，可以為日誌來源命名為，如此就可以跳脫此日誌來源名稱讓QRadar在顯示日誌來源名稱時執行以上的Scripts。

QRadar應用程式中的跨網站偽造要求（CSRF/XSRF）

跨網站偽造要求是三大漏洞當中的最後一個。你的應用程式容許使用者建立、修改或刪除任何資料嗎？如果是，就需要CSRF保護。