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

就如同SQLi以及XSS，OWASP與Computerphile同樣也提供一些很棒的相關資源。CSRF攻擊手段會欺騙受害者的瀏覽器傳送看似合法，但非受害者意圖的要求。

如果使用Flask，可以利用Flask-WTF程式庫，輕輕鬆鬆地修正範本和JavaScript中的幾行指令。

QRadar應用程式中的認證外洩

絕對不可以在應用程式當中的任何地方印出認證密碼，但有些開發人員會在其應用程式中外洩認證密碼。

原始碼中含有認證密碼

一般而言，從很多層面來說，此為不良的安全措施。如果認證密碼是屬於應用程式的一部分，則應該可由使用者進行配置。如果它是測試╱驗證檔案，則應該從應用程式移除或在最後建置過程中移除該檔案。

註記碼中含有認證密碼

如同前述，有些原始碼已經被開發者變成註記碼，但這些註記碼中還含有效的認證密碼，這認證密碼甚至還能夠登入其他外部來源。

列印在日誌中

稽核變更絕對是良好做法，例如可以記錄參數或值已變更的事實；不過，請勿在自身的應用程式日誌中記錄Token值或密碼。絕對不要做這種事：

logger.info("Changed token to : 
%s" % token)

另外，要注意變更Token值時不要將值寫入日誌中：

logger.info("Changed token.")

查詢字串

無論如何，都不該使用GET來進行建立、修改或刪除，因為往往查詢字串常記錄為「/app/updateToken/123-abc-xyz」，並顯示在日誌內。

與檔案系統或作業系統互動

類似XSS和SQLi，當與運行應用程式的伺服器互動時，未受信任的輸入可能會是個災難。

目錄╱路徑

App可以讓使用者上傳或刪除檔案。若App只是單純問使用者：「你要刪除哪個檔案？」且允許使用者指定檔名，App只要附加檔名至基底路徑（Base Path），使用者可跳脫或穿過至其他檔案：

file_to_delete = "../logs/audit.
log"
file_to_replace = "../../../etc/
passwd"
base_directory = "/store/app/
user_files/"
os.delete(base_directory + file_
to_delete )
os.replace( base_directory + 
file_to_replace )

若想要在磁碟上修改檔案，需要確保那些檔案是所想要修改的檔案！請參閱與避免目錄跳脫相關文章或OWASP指引。

指令注入

若不是最糟，也同樣糟糕的是指令注入。若需要觸發外部腳本或在主機上與作業系統互動，可能就會碰到這個問題，且如同許多本文所列出的問題一樣，問題的根源是不受信任的輸入。

import subprocess

ip = "192.168.2.1"
syslog_path = "something"
unique_id = "haxor & touch 
badFileOrCommand.txt"

subprocess.Popen(['exec python 
target.py {0} {1} {2}'.format
(ip, syslog_path, unique_id)],
shell=True)

以上的範例顯示三個變數被傳入到另一個Python腳本，其中的&告訴作業系統需要執行另一個指令。在這個案例中，只有新增一個檔案，但卻有可能是執行了該帳戶有權限可以執行的任何指令，請參閱相關的論壇或OWASP文章。

造成應用程式驗證審核延長的一些問題

過多的檔案、未註解的程式碼、龐大的程式碼等等，都是造成應用程式驗證審核延長的問題。

過多檔案

如果決定為了「以防萬一」而將每個JavaScript程式庫納入所撰寫應用程式的「/static」資料夾中，審查者需要看看你是否已經採取或使用什麼安全措施。

未註解的程式碼

如果有龐大複雜的程式碼，其中又沒有註解，這就要花很多時間辨認。在手動檢查程式碼時，得沿途做一些註解。

龐大的程式碼

這是指無法改變的部分，如果應用程式有很多這類情形，其程式大小會超過其他沒有過多龐大程式碼的應用程式。請記住，應用程式越大，驗證時間就越久。

確保自己的QRadar應用程式安全無虞

請想一想，安全工程只是最佳資源之一。安全的應用程式開發不只是讓應用程式能夠運作，而是要從意圖不軌使用者的角度來看待所撰寫應用程式。這並不容易，因為開發人員的時間與資源有限，而且安全性有時是事後諸葛。但必須記住，駭客有很多時間，而且安全性是他們的焦點。

可以按照應用程式的大小，安排專屬資源來執行安全程式碼檢查，或將安全檢查列入程式碼檢查核對清單中。