將此篇文章跟 Facebook 上的朋友分享將此篇文章跟 Plurk 上的朋友分享將此篇文章跟 Twitter 上的朋友分享列印轉寄
2018/12/18

攸關資安營運中心運作 程式開發首重測試驗證

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

IBM Security
本文將介紹如何運用IBM QRadar App架構開發客製化應用程式,先說明何謂應用程式、Flask,然後說明何謂安全工程、如何避免應用程式提交遭到拒絕、那些是造成應用程式驗證審核延長的問題、該如何確保自己的QRadar應用程式安全無虞,以及使用SDK進行應用程式測試。


安全工程與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保護。

這篇文章讓你覺得滿意不滿意
送出
相關文章
善用vSphere Replication 虛機異地備援隨時應變
建生態系組合方案更全面 壓低成本跨越推廣障礙
2FA實體金鑰 保護帳密免遭竊
遵循法規兼顧安全 萬物聯網資安有保障
視覺化地圖還原定位紀錄 重現使用者移動軌跡
留言
顯示暱稱:
留言內容:
送出
熱門點閱文章