經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)

經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦

- 2月 04, 2021

通常在寫程式往往著重於功能實踐而遺忘了

程式夠不夠安全或者也不曉得如何去判定程式是否有合乎安全

而安全性指標較常在網頁應用系統中被人重視

全球知名的非營利OWASP組織(Open Web Application Security Project)專注在增進軟體安全。

網頁:https://owasp.org/

就曾發起眾多與安全相關的專案

OWASP Top 10(十大網站安全風險)

OWASP API Security Top 10

OWASP Mobile Top 10(十大行動裝置安全風險)

OWASP Internet of Things Project (十大物聯網安全風險)

Application Security Verification Standard(系統安全驗證)

Software Assurance Maturity Model(軟體安全成熟度)

OWASP Enterprise Security API (ESAPI)

本篇就只針對

2017 OWASP Top 10(十大網站安全風險)

進行一個筆記整理分享

1. Injection ：注入攻擊

在網路應用程式，尤其以SQL Injection裡很常見。Injection之所以會發生，是因為使用者提供的資料傳輸到一個interpreter，沒有經過妥善的檢查、排除特殊符號或參數化查詢(Prepared statement)等處裡

使此輸入被當成指令（Command）或是查詢（Query）。攻擊者就能用惡意的資料欺騙interpreter，而達到執行指令或是竄改資料的目的。

(除了是 2017 版的第一名，同時也是 2013 版的第一名!)

除了SQL注入當然也包含其他種類注入，比如

XML Injection也算其中一種(就被歸類到第四名的 XXE , XML 外部處理器弱點)

攻擊手法:

1.有資料輸入欄位

2.使用網址列傳遞變數

3.未過濾特殊字元

4.顯示SQL錯誤訊息

以 .NET C# Code 來看實際程式發生案例

Bad 寫法

當有心人士輸入

Username: alice@bank.com

Password: ' or 1=1)#

就可以進入本來應該只有 alice才有權限的頁面

改善方案:

使用過濾字串函數過濾非法的字元

使用 Prepared Statements、Stored Procedures

嚴密檢查來自用戶端所有輸入值

控管錯誤訊息檢視權限僅管理者可以閱讀

控管資料庫及網站使用者帳號權限

2.Broken Authentication ：無效身分驗證

通常是發生於脆弱的帳戶認證機制，或是採取了不安全的管理機制。Account credentials和session tokens 因經常沒有受到正確及嚴密的保護，而被攻擊者使用密碼、或keys，或是authenticationtokens來冒用其他使用者的身份。

例如：登入未加密、Session 無控管、 Cookie 未保護等。

攻擊手法:

1.利用網路封包監聽使用者帳密

2.網站設計不良，可直接繞過驗證頁

3.使用者忘記登出，而讓攻擊者有機可趁

4.弱密碼攻擊(全數字或全英文、帳號密碼相同、長度不夠、用生日)

5.多組密碼帳號共用(Facebook,Gmail,IG都同一組或是都用Google帳戶註冊的)

改善方案:

1.驗證密碼強度及密碼定期更換機制

2.設定完善的 Timeout 機制

3.使用完善的 Cookie Session 保護機制

4.不允許外部 Session

5.登入及修改資訊頁面使用 SSL 加密

6.多因素認證(一些身分確認問題、圖片轉成正的、圖片中出現XXX的點選、

手機驗證碼、驗證隨機碼)

3.Sensitive Data Exposure：機敏資料外洩

一些應用程式或API在傳遞過程中未做像是加密等保護措施，當資料未加密、或使用脆弱的金鑰時，容易使得密碼被攻破，造成機敏資料外洩的風險，將重要資料暴露在危險之中。

常見於網路應用程式對於資料的保護不足，若駭客取得這些金融資訊、個人資料，即可偽造、竊取身分，或進行其他的犯罪行為。例如:信用卡盜刷、個人可是別資訊(PII)盜取冒用

攻擊手法:

中間人攻擊(MITMA)

原因:

加密協定不安全

認證過期

改善方案:

1.軟體中已經被識別的機敏資料，於實作階段應考量於傳輸、儲存時、備份後，採用加密作法。

2/不使用自行創造加密方式，用國際機構驗證且未遭破解的演算法加密。

3/盡可能使用該演算法支援的最大金鑰長度。應對金鑰進行適當保護，金鑰應定期更換。

4/落實完善的 Cookie Session 保護機制

5.正式上線的機器或Server上不能放置開發版本或備份的資料庫、資料檔或程式檔案

6.含有漏洞加密機制(SSL 3.0 , OpenSSL 1.0.1)就該汰換，定期追蹤更新

7.限制帳戶登入出錯次數(比如超過3次就封鎖)避免可以給駭客重複多次try密碼暴力破解

4.XML External Entities (XXE)：XML 外部處理器弱點

2017 年新加入的Issue，主要因為以 XML 為基礎的網路應用程式

沒有做好管控權限，直接讀取外部資源提供的 XML 檔案。

故攻擊者可以利用 XML 來讓系統讀取後，進行文件的共享、監聽內部網路、執行遠端程式執行，進而導致資料外洩，或系統被駭客接管。

駭客強迫 XML 程式存取指定檔案與資源

間接讀取網站原始碼、或config檔案的機密資料、/etc/pwasswd等

改善方案:

1.禁止外部實體引用，關閉 DTD ( Data Type Definition )

2.將 XML 升級到最新，修補或升級有引用的套件。

3.驗證 XML 或 XSL 文件是否有經的過 XSD(Xml schema definition)驗證方法傳入

5.Broken Access Control：無效的存取控管

不須登入可直接操作使用者帳號竊取機密，系統檔案外洩。

常發生情況在跨檔案、路徑攻擊

改善方案:

1.白名單過濾

2.權限控管嚴謹

3.限制檔案下載上傳格式

6.Security Misconfiguration：不安全的組態設定

應用系統中的組態設定可能是容易被忽略的地方，必須注意安全相關的「組態設定」，這通常是由於不安全的預設值、錯誤的 HTTP 標頭配置以及包含敏感信息的詳細錯誤信息所造成的。因此，我們不僅需要對所有的操作系統、框架、函式庫和應用程序進行安全的設定，而且必須即時修補和升級它們。

改善方案:

1.上傳權限控管

1-1.檢查副檔名

1-2.上傳後重新命名

1-3.控管權限：關閉執行權限

2.移除不使用的頁面

3.移除暫存檔案與備份檔案

4.不使用太簡單的命名規則

5.以白名單設定可存取的頁面

7.Cross Site Scripting(XSS) ：跨站腳本攻擊

為了不要跟 "CSS" 混淆，故簡稱XSS。

當應用程式未將使用者提供的資料先驗證或進行內容編碼，就直接將資料傳輸到網路瀏覽器，即可能發生XSS問題。XSS能讓攻擊者直接在受害者的網路瀏覽器上執行Script，攻擊者便可以劫持使用者Sessions、或竄改網站內容等。通常是透過HTML/JavaScript這類不在伺服器端執行、而在使用者端的瀏覽器執行之方式攻擊，讓惡意程式碼得以執行。可用來竊取用戶的cookie，甚至於冒用使用者的身份。像是網路銀行、電子郵件、部落格或其他需要有帳號才能進入的網站。

造成的風險:

1.加密連線可能失效 – 駭客偷取使用者的cookie，取得使用者個人資料

2.駭客可假冒使用者身分，存取具身分控管機制的網站

3.將使用者瀏覽器導向釣魚網站，以騙取帳號密碼等個人資訊或者導向惡意網站，安裝惡意後門程式

攻擊手法:

可以分為兩種：

1.Reflected Attack

常設計在使用者按下時觸發(可能來自釣魚郵件)

常出現於網站的搜尋欄、使用登入介面，用來竊取 Cookie 或是釣魚欺騙

第一步會先找出目標想要駭入的網站中XSS潛在漏洞，

再製造一個惡意的URL 連結。這個連結是網站中的某個功能。

該功能會接收使用者端提供的資料，並回應到使用者端的畫面，如資料檢索功能。

2.Persistent Attack

另一種是單純的瀏覽網頁，且該網頁中已植入惡意的語法

駭客已先將惡意腳本上傳、儲存在有漏洞的server，只要受害者瀏覽到相關頁面就會執行惡意程式，當使用者造訪被感染的網頁，會自動執行攻擊。

通常Persistent Attack會比Reflected Attack更加危險，使用者完全無法保護自己。

改善方案:

1.請求與回應接要驗證是否有非法字元(除了Client端坐查檢驗證之外，Server端也要加入)

2.建議使用白名單(比如只允許數值就限定數字內容)

3.不建議使用黑名單(可能因過濾不乾淨而讓攻擊者規避規則；在跨站指令碼攻擊中，若想透過黑名單式的過濾方式，是行不通的。因為改寫形式太多)

補充:

另一個也屬於跨網站攻擊的被列入OWASP top 10 2013版本的第8名CSRF

A8.Cross-Site Request Forgery (CSRF)：跨站請求偽造

也被稱為one-click attack 或者session riding，通常縮寫為CSRF 或者XSRF。

絕大部分的網站應用程式都是採用cookie或session的方式進行登入驗證，當通過登入驗證之後，網站就會給你一個通行證存在cookie或seesion中，代表之後的動作中都不需要重複驗證身分了。

這當然是一個好事，沒有人能接受做每一件事都要再輸入一次帳號密碼，但CSRF的攻擊正是鑽了這個機制的漏洞來達到攻擊的目的!

使用已經身份驗證、授權的Cookie來對應用程式發出的攻擊，攻擊者可以誘騙受害者發出"非自行提出的請求"，比如對受害者銀行帳號進行"非自願"的轉帳行為。

攻擊手法:

經常出現釣魚(郵件)連結

https://owasp.org/www-community/attacks/csrf

8.Insecure Deserialization ：不安全的反序列化漏洞

不安全的反序列化漏洞通常是鎖定Java、PHP或是Node.js等平臺常見的攻擊方式，不安全的反序列化會導致遠程代碼執行。即使反序列化缺陷不會導致遠程代碼執行，攻擊者也可以利用它們來執行攻擊，包括:重播攻擊、注入攻擊和特權升級攻擊。

9.Using Components with Known Vulnerabilities ：使用含有已知漏洞的組件

現今軟體開發過程，要求開發人員快速產出，為此通常會引用第三方Open Source Software (OSS)，但卻沒有監控該OSS的弱點問題，包括函式庫、框架以及其他的軟體模組，而OSS會和應用程式以相同的權限執行。如果有一個容易受到攻擊的OSS被駭客利用，就可能會導致嚴重的資料洩漏或者伺服器被駭客利用，而使用有漏洞的應用程式或者是API，都會破壞應用程式的防護並啟用各種攻擊形式。這也意味著，許多開發者在使用OSS的模組或框架的習慣不好，除了會帶來嚴重的資料遺失外，也代表沒有即時升級或更新到最新版。

實際案例:

2019年jQuery主要漏洞

https://kknews.cc/zh-tw/code/zy8rqxl.html

https://www.cvedetails.com/product/11031/Jquery-Jquery.html?vendor_id=6538

Microsoft 資訊安全公告 MS14-059

https://docs.microsoft.com/zh-tw/security-updates/securitybulletins/2014/ms14-059

存在近十年的Linux Sudo漏洞，可讓任何本機使用者取得執行根權限

https://www.ithome.com.tw/news/142469

Apache Struts2再度爆發高風險漏洞，HITCON Zeroday通報：金融電信業者受駭

https://www.ithome.com.tw/news/112591

改善方案:

1.盡量從官網載套件或引入js(例如npm , nuget)