網上應用系統保安
網絡技術的發展加上企業環境的改變，意味著現今網上應用系統在公司、公共與政府服務中變得更加盛行。雖然網上應用系統可帶來便利和提升效率，但也產生新的保安威脅，若未作好妥善處理，對機構中的資訊科技架構可能會造成潛在而顯著的風險。
現今傳統網絡保安措施與技術已不足以保障網上應用系統和避免新的威脅，尤其是現在的攻擊瞄準了網上應用系統設計上的保安漏洞，在發展應用系統時需同時考慮衡量技術和管理兩者的保安。
網上應用系統的一般保安漏洞
OWSAP是一個遍佈世界的自願參加者社群，目標是讓網上應用系統的保安顯而易見。人們和機構可以根據應用系統保安風險的資訊作出決策。
透過 OWASP的指導以建立網上應用系統的保安是一個不錯的參考機構歸納出網上應用系統十大關鍵保安漏洞，系統的開發者應該注意這些一般性的保安漏洞，並制定程式開發的標準，避免這樣的問題在編碼階段發生。
1.
跨網址程式編程攻擊（ Cross Site Scripting, XSS）
跨網址程式編程攻擊（ XSS）的潛在威脅是允許在受害者的瀏覽器執行手稿程式（Script），導致劫持用戶對話、竄改網站並可能植入蠕蟲等等。此保安漏洞是由應用系統讀入了沒有經過驗證或加密的數據並將它傳給瀏覽器所造成。
跨網址程式編程攻擊（ XSS）的潛在威脅是允許在受害者的瀏覽器執行手稿程式（Script），導致劫持用戶對話、竄改網站並可能植入蠕蟲等等。此保安漏洞是由應用系統讀入了沒有經過驗證或加密的數據並將它傳給瀏覽器所造成。
2.
植入式保安漏洞
這一個保安漏洞的潛在威脅是攻擊者可透過非預期的命令或改變系統數據藉以欺騙應用系統。植入式保安漏洞中尤以在網上應用系統的 SQL插入漏洞最為常見。當使用者提供的數據被傳送到詮釋器作為命令或查詢時，就會產生植入式攻擊。
這一個保安漏洞的潛在威脅是攻擊者可透過非預期的命令或改變系統數據藉以欺騙應用系統。植入式保安漏洞中尤以在網上應用系統的 SQL插入漏洞最為常見。當使用者提供的數據被傳送到詮釋器作為命令或查詢時，就會產生植入式攻擊。
3.
惡意程式執行
易於受遠程文件包含（ Remote File Inclusion, RFI）破壞的程式碼的潛在威脅是允許攻擊者有機會引入惡意程式碼與數據，導致毀滅性的攻擊如入侵整個伺服器。惡意程式執行的攻擊會影響到PHP、 XML以及任何可接收使用者的檔名或檔案的架構
易於受遠程文件包含（ Remote File Inclusion, RFI）破壞的程式碼的潛在威脅是允許攻擊者有機會引入惡意程式碼與數據，導致毀滅性的攻擊如入侵整個伺服器。惡意程式執行的攻擊會影響到PHP、 XML以及任何可接收使用者的檔名或檔案的架構
4.
不安全的直接物件參照
這個潛在威脅是攻擊者不需要透過授權就可以操作接達其他物件的參照。當開發者展示內部完成物件的參照時，例如檔案、目錄、數據庫記錄或鍵值作為劃一資源定位（ URL）或表單文件的參數，直接物件參照便會發生。
這個潛在威脅是攻擊者不需要透過授權就可以操作接達其他物件的參照。當開發者展示內部完成物件的參照時，例如檔案、目錄、數據庫記錄或鍵值作為劃一資源定位（ URL）或表單文件的參數，直接物件參照便會發生。
5.
跨網站請求偽造（ Cross Site Request Forgery, CSRF）
這一個保安漏洞的潛在威脅是強迫登入者的瀏覽器寄發預先驗證的要求給具保安漏洞的網上應用系統後，強迫使用者的瀏覽器執行惡意行為而使攻擊者獲利。 CSRF攻擊可與其所攻擊的網上應用系統的權力一樣。
這一個保安漏洞的潛在威脅是強迫登入者的瀏覽器寄發預先驗證的要求給具保安漏洞的網上應用系統後，強迫使用者的瀏覽器執行惡意行為而使攻擊者獲利。 CSRF攻擊可與其所攻擊的網上應用系統的權力一樣。
6.
資料洩漏和不適當誤差處理
這個保安漏洞的潛在威脅是攻擊者可以使用這個弱點竊取敏感數據，或導致更多嚴重的攻擊。應用系統所存在的多種問題可使其不故意地洩露有關內部組態的資訊、工作或違反隱私權。
這個保安漏洞的潛在威脅是攻擊者可以使用這個弱點竊取敏感數據，或導致更多嚴重的攻擊。應用系統所存在的多種問題可使其不故意地洩露有關內部組態的資訊、工作或違反隱私權。
7.
身份驗證功能和對話管理的缺失
此點的潛在威脅是攻擊者可能會組合密碼、密碼匙或授權的權標以假裝成其他使用者的身份。當帳戶憑證與交談的權標沒有受到合適的保護時會造成這個保安漏洞。
此點的潛在威脅是攻擊者可能會組合密碼、密碼匙或授權的權標以假裝成其他使用者的身份。當帳戶憑證與交談的權標沒有受到合適的保護時會造成這個保安漏洞。
8.
不安全的加密儲存設備
這個潛在的威脅在於當攻擊者使用未經妥善保護的數據來進行身份盜竊與其他的犯罪行為，例如偽造信用卡。這個漏洞是由於網上應用系統並沒有做好加密的功能以保護數據和憑證。
這個潛在的威脅在於當攻擊者使用未經妥善保護的數據來進行身份盜竊與其他的犯罪行為，例如偽造信用卡。這個漏洞是由於網上應用系統並沒有做好加密的功能以保護數據和憑證。
9.
未加密的網絡通訊
這個保安漏洞來自網絡通訊架構傳輸數據時可能洩漏敏感性資料。原因是當需要保護傳輸敏感數據的網絡通訊時，該網絡的傳輸並沒有加密。
這個保安漏洞來自網絡通訊架構傳輸數據時可能洩漏敏感性資料。原因是當需要保護傳輸敏感數據的網絡通訊時，該網絡的傳輸並沒有加密。
10.
無權限的劃一資源定位（ URL）接達
這一個保安漏洞使攻擊者透過直接接達 URL而有機會進行未授權的操作。這個保安漏洞的形成是因為當應用程式避免顯示連結或 URL給未授權的使用者時，只保護某些部份敏感的功能。
這一個保安漏洞使攻擊者透過直接接達 URL而有機會進行未授權的操作。這個保安漏洞的形成是因為當應用程式避免顯示連結或 URL給未授權的使用者時，只保護某些部份敏感的功能。
保護網上應用系統的行政措施
為了強化網上應用系統的保安與協助數據處理的保護，以下是行政方面的建議措施。
為發展與維護網站和/或網上應用系統提供一個方向並列入關鍵的指引。
把網上應用系統編碼與發展的作業實務列入關鍵的指引。軟件發展小組應遵守一系列安全的網上應用系統編碼作業實務，用來抵抗一般的網上應用程式保安漏洞。
收集和管理敏感資訊及使用者數據時要符合政策與法規。
編製保安及品質保證計劃，並採用品質保證方法，如重新檢查原始碼、滲透測試、用戶驗收測試等等。
在網上應用系統推出前或系統作出任何重大更改或升級後，進行完整的資訊科技保安審計。
保護網上應用系統的技術措施
部署網上應用系統帶來好處亦帶來了新的保安風險。為了有效地處理這些風險，在整個發展周期中應該考慮多樣化的保安控制。為了幫助了解所建議的保安控制與發展周期中地方可能相關的地方，本節將透過發展周期的各階段指出需要特別注意的保安考慮。
需求階段
在本階段中應用系統發展小組應該收集和項目有關的部門所需的所有系統與保安規格。系統需求應提供發展小組這應用系統的主要目的概覽，包含這個應用系統什麼該做及什麼不該做。此資訊將協助發展小組定義應用系統關鍵的保安控制。
正確地建立系統和使用者的保安需求在設計、發展和測試階段中是非常重要的，這將增加網上應用系統全面性的保安，並確保使用者對結果滿意度。
設計階段
定義安全的編碼標準
安全的編碼標準是告訴開發人員如何去撰寫應用系統的程式碼、開發保安程式碼時的指引，對識別高風險區域、數據輸入與其它界面和誤差處理等如何作出適當的評論。不同的機構包括OWASP和電腦緊急應變小組（Computer Emergency Response Team, 或 CERT）建議一些安全的編碼作業實務。
1.
驗證所有輸入參數的有效性，以防止 SQL插入攻擊及跨網址程式編程攻擊：
程式設計師應發展一個集中模組，以驗證輸入參數。
程式設計師應根據允許輸入參數類型的格式，檢查各項輸入參數
過濾 "~!#$%^&*[]<>'\r\n" 等特殊字符的輸入，
不可依賴客戶端手稿程式去進行必須的驗證
應用系統必須只能接受那些嚴格限制與預期的字符數據，若一數字符合預期，只有數字的字符可被接受，若是文字則只有字母可被允許。輸入數據的形式是否合適也應作出驗證，若預期是一個電郵地址，則應透過適當安排的文字、數字、@符號、破折號及點號作出驗證。
所有進入應用系統的數據應強制最小或最大長度。此技術應使用在帳戶號碼，交談憑證與使用者名稱等等。所有這些技術限制了入侵攻擊潛在缺口的數目。
2.
對應用程式回應進行淨化（ Sanitised application response）
應發展一個集中模組，以進行淨化工作。檢查所有輸出、調用返回碼及錯誤碼（例如後端數據庫的調用），以確保跟據預期的處理程序執行。舉例說，在回應中不必要的內部系統資料，如內部 IP 地址、內部主機名稱、內部目錄結構、內部伺服器錯誤的詳細錯誤信息不應洩露在客戶端。大多數應用系統／網站伺服器允許自訂錯誤頁面。
應發展一個集中模組，以進行淨化工作。檢查所有輸出、調用返回碼及錯誤碼（例如後端數據庫的調用），以確保跟據預期的處理程序執行。舉例說，在回應中不必要的內部系統資料，如內部 IP 地址、內部主機名稱、內部目錄結構、內部伺服器錯誤的詳細錯誤信息不應洩露在客戶端。大多數應用系統／網站伺服器允許自訂錯誤頁面。
3.
超文本傳輸規約（ HTTP）的可信性
程式編寫員不應信賴及依賴 HTTP REFERER 標頭、表單字段或 cookies 確定保安措施，因這些數據均可被偽冒。除非採用了有效的加密算法核實 HTTP 標頭是否完整，否則不要信賴這些來自客戶瀏覽器的參數。此外由於隱藏參數容易被攻擊者操縱，故不能認為用戶無法修改隱藏參數。
程式編寫員不應信賴及依賴 HTTP REFERER 標頭、表單字段或 cookies 確定保安措施，因這些數據均可被偽冒。除非採用了有效的加密算法核實 HTTP 標頭是否完整，否則不要信賴這些來自客戶瀏覽器的參數。此外由於隱藏參數容易被攻擊者操縱，故不能認為用戶無法修改隱藏參數。
4.
保護敏感的對話值
保存伺服器上敏感的對話值以防客戶端修改。不應將敏感資料儲存在任何客戶瀏覽器的 cookies 中。倘若敏感數值不得不儲存在客戶瀏覽器中，應採用較強的加密技術保護數據的機密性及完整性。
保存伺服器上敏感的對話值以防客戶端修改。不應將敏感資料儲存在任何客戶瀏覽器的 cookies 中。倘若敏感數值不得不儲存在客戶瀏覽器中，應採用較強的加密技術保護數據的機密性及完整性。
5.
加密含有敏感資料的頁面及防止快取記憶
在傳輸過程中，含有敏感資料的頁面應使用適當的算法及密碼匙進行加密，例如保密插口層（ Secure Socket Layer, SSL）、傳輸層保安（ Transport Layer Security, TLS）。使用已簽署的 Java微應用程式或 ActiveX獲取及顯示敏感資料，及設置適當的 HTTP標頭屬性，以防止瀏覽器或代理伺服器對含有敏感資料的個別頁面進行快取記憶。
在傳輸過程中，含有敏感資料的頁面應使用適當的算法及密碼匙進行加密，例如保密插口層（ Secure Socket Layer, SSL）、傳輸層保安（ Transport Layer Security, TLS）。使用已簽署的 Java微應用程式或 ActiveX獲取及顯示敏感資料，及設置適當的 HTTP標頭屬性，以防止瀏覽器或代理伺服器對含有敏感資料的個別頁面進行快取記憶。
6.
對話管理
對話識別碼應比較長、複雜並包含難以預測的隨機數字。在對話中，應經常更改對話識別碼，以縮短對話識別碼的有效期。此外，對話識別碼不應儲存在劃一資源定位、永久性 cookies 、隱藏的超文本標示語言字段及 HTTP標頭中。程式編寫員可考慮在客戶瀏覽器的對話 cookies 中儲存對話識別碼。透過保密插口層／傳輸層保安保護對話識別碼，使攻擊者無法從網絡中竊取。應用系統應提供登出功能及執行閒置對話超時。當用戶登出後或閒置對話過期時，須確保不但刪除客戶端的 cookies（如可能的話），亦刪除瀏覽器的伺服器端對話狀態及與後端伺服器的連接。
對話識別碼應比較長、複雜並包含難以預測的隨機數字。在對話中，應經常更改對話識別碼，以縮短對話識別碼的有效期。此外，對話識別碼不應儲存在劃一資源定位、永久性 cookies 、隱藏的超文本標示語言字段及 HTTP標頭中。程式編寫員可考慮在客戶瀏覽器的對話 cookies 中儲存對話識別碼。透過保密插口層／傳輸層保安保護對話識別碼，使攻擊者無法從網絡中竊取。應用系統應提供登出功能及執行閒置對話超時。當用戶登出後或閒置對話過期時，須確保不但刪除客戶端的 cookies（如可能的話），亦刪除瀏覽器的伺服器端對話狀態及與後端伺服器的連接。
7.
限制終端用戶的接達權
確保終端用戶帳戶僅有權接達獲授權的操作程式，並限制接達後端數據庫，或運行結構化查詢語言指令、操作系統指令。如應用系統向接達程式作出系統調用，不應直接調用真實檔案名稱及目錄路徑。倘若攻擊者獲取源碼，則可發現系統資料。利用網站伺服器的對映功能作為過濾
確保終端用戶帳戶僅有權接達獲授權的操作程式，並限制接達後端數據庫，或運行結構化查詢語言指令、操作系統指令。如應用系統向接達程式作出系統調用，不應直接調用真實檔案名稱及目錄路徑。倘若攻擊者獲取源碼，則可發現系統資料。利用網站伺服器的對映功能作為過濾
8.
建立應用系統審計及報告的中央模組
9.
使用最適當的認證方法識別及驗證輸入的用戶查詢
執行 Threat Modelling模式
建立安全的應用系統需要瞭解此應用系統所面對的威脅， Threat Modelling的過程可協助我們確定在整體應用程式方案上的威脅、攻擊、漏洞與抵禦措施。
Threat Modelling可透過以下步驟達成：
步驟一：
確定關鍵的保安目的。
步驟二：
將應用系統的重要特性列出並建立整體的看法。
步驟三：
解構應用系統以確認需要被評估而會影響特性與模組的安全。
步驟四：
確定所有威脅。
步驟五：
確定所有保安漏洞。
設計網上應用程式保安的架構
網上應用系統結構一般包括三個層級，把對外網站伺服器、內部的應用系統伺服器及數據庫伺服器隔開。憑藉這些層級結構，即使攻擊者可入侵對外網站伺服器，其仍需另尋方法攻擊內部網絡。這是縱深防禦的原則。
這是縱深防禦的原則，縱深防禦對資訊保安而言是一個實用的方法，其基本概念主要是在於多層次的保安以保護重要資產。保安的層次包含輸入驗證，數據庫層的概念，伺服器的組態，代理伺服器、網上應用系統防火牆、數據加密與作業系統強化等。
發展階段
就減低程式碼保安論點疑慮而言，這是最重要的階段。注意到保安編碼標準可協助改善保安狀況，並減少會導致保安事故之常見錯誤發生的次數。此外執行保安風險評估，也有助於確認所需的保安控制。
測試與品質保證階段
在任何應用系統推出前，全面測試是非常重要的。除用戶驗收測試之外，尚有其他測試，例如系統測試、壓力測試、廻歸測試、和單元測試等對於驗證系統功能的效能和準確性是有用的。本節敘述一些測試，可用來增加已發展的程式或系統的可靠性與安全程度。
網上應用系統單元測試
網上應用系統單元測試是發展階段中的一個重要部份，其設計是用來協助確定網上應用系統中的保安漏洞。單元測試包含了個別程式或模組的測試，以確保程式內部的操作或模組的執行與規格一致。單元測試應包括對一般保安問題的測試，例如緩衝區溢出，尤其當模組與其他組件合併，此測試更為重要。如果沒有執行單元測試，便很難在發展階段中執行自動保安測試程序。
有許多不同的工具，能幫助找出並消除網上應用系統的保安漏洞。但值得注意的是，這些工具只能應付一小部分有效的網絡保安應用程式所需之測試。只是依賴這些工具，而不集中改善軟件發展生命周期的保安，這是錯誤的保安觀念，因為自動掃描工具的能力仍只限於找出及確定某種類的保安漏洞。
編碼覆檢
編碼覆檢能幫助確定出保安漏洞，確保維持保安發展標準及整體程式設計的一致性。一般而言系統發展經理、系統管理員、與數據庫的管理員，會一起檢查應用程式原始碼的運作，並作出適當的建議加以改善。此外藉由對原始碼的檢視，可以確定及評估隱藏或保安性的內容，如密碼匙和密碼所採用的保護措施是否適當。
市場上可以找到一系列的自動掃描工具，協助我們進行編碼覆檢。然而若結合網上應用系統掃描工具，這些工具只能用來確定一般的錯誤，而不是較複雜的保安問題。因此不應以這些工具取代人的分析。
在任何編碼覆檢開始之前，項目小組應先定義出編碼的哪一部份是屬於高風險和可能易受攻擊。一般來說，能提供接達控制、組態管理、審計、記錄、授權驗證、提供與第三者或操作系統連結的界面，以上具備這些功能的程式或作業系統，都應接受覆檢。這項覆檢動作，通常參考 threat modelling或風險評估和設計分析的資料，以決定此項目的哪一個範圍應該是編碼覆檢的一部份。
應用系統推出前階段
在應用系統推出前和作出重大改動後，應執行資訊科技保安審查。每個修復的保安漏洞都需更新及反映在程式碼內，接下來，每一項保安漏洞修復都需要一次程式碼更新。因此，要持續維護安全的應用系統，必須評估每項修復所帶來的影響。
維修與支援階段
保安是一持續的過程，保安問題在應用系統推出後仍不斷出現。應繼續執行保護與偵測的機制，來確保應用系統安全地與順暢地執行。重要的持續保安措施如下：
應用系統記錄的覆檢
為了偵測網上應用系統的不正常狀況，記錄覆檢是必要的。許多網絡伺服器支援詳盡的記錄，它們保存了所有在網上應用系統的指令。藉由定期審視網絡接達記錄和指令，便有可能預見網上應用系統未來的保安問題。一旦發現不正常的劃一資源定位（URL），可能代表某種網絡攻擊已經發生。
此外，應用系統的擁有者也可要求執行網上應用系統的審計追蹤，定期查閱那些可疑的指令或顯示不正常情況的報表。
版本控制與獨立發展環境
維護應用系統的完整性應以適當的保安控制，例如版本控制與各項獨立環境供系統發展、系統測試、驗收測試與現場操作。生產與發展環境應同時進行。發展應用系統的工作人員除了某些必要狀況外不可取得生產資訊。
網上應用系統防火牆（Web Application Firewalls, WAF）
標準的防火牆可以限制或允許經過機構授權的接達行為，但在機構的網上應用系統防火牆仍然無從理解其運作中網上應用系統的特定內容。
一般而言網上應用系統防火牆通常安裝於網絡伺服器之前，這些網上應用系統防火牆的形式如同標準防火牆，可能是軟件或硬體，目的是讓網絡伺服器免受攻擊為主。防火牆有兩種保護方式：
1.
以辨識碼為基礎： WAF透過檢查網絡請求方式，對照攻擊辨識碼特徵檔以確定攻擊。
2.
以不正常行為作為基礎：網上應用系統防火牆透過偵測不正常的傳輸模式確定攻擊。
網上應用系統的驗收清單
網上應用系統一經驗收後，應執行獨立的保安評估來評估網上應用系統和原始碼，以確保完全符合公司政策或項目的保安需求。對網上應用系統項目來說，這類評估是必要的且可能會外判至外部人員。保安控制的測試案例，需要在項目的初步階段實行，且應包含用戶驗收測試。
應盡早在項目的初步階段，考慮其保安性。必須與開發人員溝通對保安的期望與需求，特別是授權機制、數據輸入的認證、與審計追蹤。
以下是在評估網上應用程式保安時，需要檢視範圍的一些例子：
身份識別及認證
1.
使用者與其使用程序如何認證 ?
2.
認證程序是否遵照規格的指示，以及是否遵守機構的保安政策？
3.
如果認證過程是以密碼為基礎，使用者的密碼如何處理與保存？這些密碼處理機制，是否符合機構的保安政策？這些密碼是寫定的密碼，或內建於原始程式碼中 ?
4.
這些應用系統是否需要在每次連線時針對每一個連結作授權認證？
數據保護
1.
數據保護機制是否符合機構的保安政策？
2.
所有受保護的數據是否經由正確的方式傳輸？
3.
如果使用加密，如何操作？加密的操作程序是否完全遵照機構的保安政策？
記錄
1.
審計追蹤記錄的機制，是否符合規格？
2.
這些應用系統的審計記錄，是否容易受到那些未授權的刪除、修正或洩露？
處理錯誤
1.
錯誤訊息是如何被處理？洩漏的數據，有沒有可能被後來的攻擊行為所利用？應用程式的失敗，會導致系統處於危險狀態嗎？
操作
1.
是否有強制執行職務分工（ Segregation of duties）和最少權限原則？
2.
在啓動前，所有的內建使用者身份、測試的使用者身份、和預設密碼值的身份是否已從作業系統、網絡伺服器及其應用程式本身中移除了？
3.
系統管理程序、改動管理程序、運作復原程序、和備份程序，是否有完整且清楚的界定？
這份清單尚有不足之處，因應保安需求，與網上應用系統目的之特殊性，應根據特殊需求以涵蓋額外測試案例或檢查標準。
此外，當任何的資訊系統外判給第三方服務提供者時，須執行適當的保安管理程序來保護數據，並減輕資訊科技項目或服務外判時帶來的保安風險。建議讀者可參閱 "資訊科技服務外判保安"一文得知更多有關外判所需保安考慮的資訊。
給網上應用系統擁有者預防網上攻擊的指引
為避免被利用作為網絡攻擊的跳板，採用保安科技可協助並預防和偵測任何不正常行為。
實施合適的保安事故處理程序是必須的。在許多案例中，通常是第三者如客戶，首先發現提供網絡服務的網站已經出現問題。在仿冒詐騙中，詐騙網站通常分屬不同區域管轄權，真正網站的管理者只能提醒客戶注意與原本網站相似的網頁，不要去瀏覽這些詐騙網站。另一個可能的做法就是告知及要求詐騙網站所寄存的網絡服務供應商，將此詐騙網站相關連線刪除。
研究系統與應用程式中的紀錄有助於調查網上攻擊事故的行徑。本文先前所述之跨網址程式編程攻擊蠕蟲案例中，受害者的網頁只扮演一個將顧客引導到惡性網站的角色，客戶電腦裡查不到任何攻擊者留下的線索。因此，任何可能受害的網頁或網站，都必須能夠追蹤任何跨網站指令攻擊的方法，並刪除受影響的網頁，杜絕更多病毒的感染。
若想讓跨網址程式編程攻擊成功，攻擊者需先將惡意程式植入受害者的網上應用系統。為了預防此事發生，此類惡意訪客的輸入資料需先經過濾。除了移除輸入資料中的特殊字元並將輸出作動態編碼之外，需建立「白名單」（white-list）法則。在「白名單」法則中，唯有符合先前設定的型態資料才允許進入，其他則全部過濾刪除。
對保安事故的偵測與監控、遏制及預防機制是有必要建立的。應保留系統記錄與其他支援資訊，作為提供回溯保安事故時的佐證。為了隨時面對更糟的情況，應該建立、記錄並維護關於網站應用系統安全機制的處理與報告程序。
所有員工也應有警覺訓練，確保能完全掌控任何保安事故的處理與報告程序
對於任何可疑的系統入侵應立即有跟進行動，且應遵照保安事故處理程序與報告之指引方針。
網上應用系統系統應定期由一群獨立、可靠及可信賴的第三者來評估，以決定網站維持所需最少的控制去遏制可接受的風險。
對保安風險評估的執行也應優先於其他網上應用系統的更新或改變。
另一個可能的預防措施是聘用外部專家去定期檢查網上現存的詐騙網站。一旦發現詐騙網站，便可立即通知客戶與網站用戶，讓仿冒詐騙事故降到最低。
相關主題:
參閱資料予:
