TibaMe: 道德駭客實務入門及CEH認證班
Teacher: 林煌錡 (Alex Lin)

The class on 4/8 introduced web server hacking, web application hacking and database injection. I separated the contents into three parts. This note is about web application hacking.

Part2: Web application hacking

Introduction

OWASP “Web Security” vs “API security”

The answers below is from ChatGPT and it’s very accurate.
OWASP (Open Web Application Security Project) is a nonprofit organization that provides resources and guidance on best practices for securing web applications and APIs. While web applications and APIs share many common security principles, there are some differences between the two.

OWASP Web Security focuses on securing traditional web applications, such as those built with HTML, CSS, and JavaScript. This includes securing the web server, web application framework, user authentication and authorization, and preventing common web application attacks such as cross-site scripting (XSS) and SQL injection.

OWASP API Security, on the other hand, focuses on securing APIs (Application Programming Interfaces), which are used to allow different software applications to communicate with each other. This includes securing the API server, handling authentication and authorization, and preventing common API vulnerabilities such as injection attacks, broken access control, and insufficient logging and monitoring.

In general, web applications are designed to be accessed through a browser and provide a user interface for interacting with the application, while APIs are designed for programmatic access and allow different software applications to communicate with each other. This means that while web applications and APIs share many common security principles, there are some differences in the specific security considerations that need to be taken into account when securing each type of application.

真心建議每一位Server開發者都仔細閱讀 OWASP
“Web Security Top10” and “API Security Top10”。
漏洞可以用工具掃瞄，但設計上的缺陷是掃瞄不出來的。

OWASP Web Security Top 10

2017
A1:2017 Injection (注入攻擊)
A2:2017 Broken Authentication (無效的身分驗證)
A3:2017 Sensitive Data Exposure (敏感資料外洩)
A4:2017 XML External Entity (XXE XML 外部處理器弱點)
A5:2017 Broken Access Control (無效的存取控管)
A6:2017 Security Misconfiguration (不安全的組態設定)
A7:2017 Cross-Site Scripting (XSS) (跨站腳本攻擊)	前端攻擊
A8:2017 Insecure Deserialization (不安全的反序列化弱點)
A9:2017 Using Components With Known Vulnerabilities (使用已知漏洞元件)
A10:2017 Insufficient Logging and Monitoring (記錄與監控不足)

2017 => 2021 from OWASP official site

2022 new items
A04:2021 Insecure Design (不安全設計)
A08:2021 Software and Data Integrity Failures (軟體及資料完整性失效)
A10:2021 Server-Side Request Forgery (SSRF) (伺服端請求偽造)

🔸 A1:2017 Injection (注入攻擊)

Command Injection

Server端處理 user input 時如果使用System call，又沒有過濾 input data，就有可能執行了不該執行的command.
Hacker can use the linux operators to execute multiple commands, e.g. |, ; , ||, && .
1
2
3
4
ls -l `|` wc -lwc |
cat test.txt ; mkdir mydir ; cd Download |
mkdir mydir && cd mydir
cat test1.txt || cat test2.txt
System calls in Django

subprocess.call

subprocess.run

subprocess.popen

subprocess.check_output

os.system
防禦方法
我覺得最直接的方法就是Server端處理user input時不要使用System call.
Prevention from Imperva.com
課堂練習1

System calls in Django
subprocess.call
subprocess.run
subprocess.popen
subprocess.check_output
os.system

SQL Injection

In part 3.

LDAP Injection

…

Useful Hacking Technology 🔥

各種hacking和injection大全： https://github.com/swisskyrepo/PayloadsAllTheThings 非常詳細，有提供各種hacking腳本。

🔸 A2:2017 Broken Authentication (無效的身分驗證)

我覺得對於駭客而言，找漏洞繞過驗證，遠比暴力破解密碼有效率的多。
漏洞介紹：https://ithelp.ithome.com.tw/articles/10216516
弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api2-broken-authentication.htm

🔸 A3:2017 Sensitive Data Exposure (敏感資料外洩)

下面兩個漏洞都是利用記憶體洩漏來竊取有用資訊。

Heart Bleed CVE-2014-0160

算是比較舊的漏洞。
Heart Bleed Wiki
這裡有檢測方法：https://github.com/0x90/CVE-2014-0160

NginX CVE-2017-7529

漏洞利用方法：https://github.com/liusec/CVE-2017-7529
影响版本：Nginx version 0.5.6 - 1.13.2
Check NginX command:

nginx -v

No need to worry about the issue if you use the latest NginX version.

🔸 A4:2017 XML External Entity (XXE XML 外部處理器弱點)

Server使用xml格式傳送資料，如果沒有禁用ENTITY的話，駭客就有可能將ENTITY注入封包回傳server，得到有用資訊。
I think most of the servers use JSON format now. If the server uses JSON, no need to worry about this.

1	<!ENTITY xxe SYSTEM "file:///etc/passwd">

具體攻擊方法可以參考果核數位這篇：https://www.digicentre.com.tw/industry_detail?id=38

🔸 A5:2017 Broken Access Control (無效的存取控管)

沒有控制好server上的檔案存取權限的話，駭客就有可能用 LFI(Local File Inclusion)取的檔案內容，比如Config檔案竊取帳密，或是上傳惡意腳本並執行已取得server控制權。
You can find more details regarding the “CVE-2022-29597: Local File Inclusion” at https://github.com/TheGetch/CVE-2022-29597
我覺得使用Docker可以起到一定的防護。

🔸 A6:2017 Security Misconfiguration (不安全的組態設定)

只要server上的應用程式、伺服器或平台本身設定有問題，就有可能被攻擊或被竊取資訊。
案例：IBM 沒有管控好網頁服務上的log檔案，攻擊者找到有用的雲端服務認證資訊。
推薦閱讀 https://3bodymo.medium.com/how-i-hacked-ibm-and-got-full-access-on-many-services-ecf1dab4a054 ，該文章作者成功從IBM的server log中取得IBM的一些認證資訊, e.g. AWS, gitlab, Jenkins…

🔸 A7:2017 Cross-Site Scripting (XSS) (跨站腳本攻擊) 🔥

這是十種攻擊中唯一的前端攻擊，主要攻擊前端瀏覽網頁的用戶。
在網頁中注入腳本，這個腳本就會被所有瀏覽網頁的瀏覽器執行。感覺這是一個門檻很低又行之有效的攻擊手法。這類攻擊不太好防。

被動注入
在別人網頁的留言板中注入惡意腳本，所有瀏覽網頁的用戶都中招。
主動注入
在自己的網頁中注入惡意腳本，這就是惡意網站了，把網站link寄給受害者，受害者點開就中招。
Demo web page i created: http://maochun.rojak.fun/2023/04/13/learning-notes/xss-test-page/ 打開就會執行腳本<script>alert(document.cookie)</script>(沒有惡意腳本)
課堂練習
靶機網頁上有一個輸入框，輸入 <script>alert(document.cookie)</script> ，按下submit輸入的腳本被執行。
XSS Wiki
https://en.wikipedia.org/wiki/Cross-site_scripting

🔸 A8:2017 Insecure Deserialization (不安全的反序列化弱點) • 🔥

序列化和反序列化在現在server的開發中非常常用。Django架構中REST Framework就是使用Serialization & deserialization.
看了這篇 https://medium.com/gdg-vit/deserialization-attacks-d312fbe58e7d
提到 insecure deserialization statement like

1 2	# Insecure deserialization user = pickle.loads(serialized_obj)

⭐ 之後打算去自己的server中找找看有沒有不安全的反序列化。
我覺得這個弱點很容易被忽略。

案例：Microsoft Exchange Proxylogon
https://www.cc.ntu.edu.tw/chinese/epaper/0057/20210620_5706.html (漏洞基本介紹)
https://hackmd.io/@1chig0/rkzZhA5Hd (有攻擊做法詳解)
我真的覺得微軟的東西漏洞太多。

🔸 A9:2017 Using Components With Known Vulnerabilities (使用已知漏洞元件)

現在Server開發多少都會用到第三方元件，如果元件本身含有漏洞，Server就可能因此被攻擊。
不使用第三方元件的話，一是開發進度緩慢，二是你也不能保證自己寫的沒漏洞。
我的想法是盡量使用用戶數多名氣大的第三方元件，有漏洞的話會比較快被發現和修補。當然要避免使用漏洞太多，或含有惡意腳本的第三方元件。

案例：FCKeditor 使用量很大的文字編輯器
https://www.acunetix.com/vulnerabilities/web/fckeditor-arbitrary-file-upload/
https://brucebin.pixnet.net/blog/post/56799578
http://www.netqna.com/2014/03/fckeditor.html

🔸 A10:2017 Insufficient Logging and Monitoring (記錄與監控不足)

這個部分非常重要，這個大家都懂。
可以參考：https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring 做到更加完備。

🔸 References:

https://owasp.org/www-project-top-ten/2017/
https://owasp.org/Top10/zh_TW/

OWASP API Security Top 10

2019
API1:2019 Broken Object Level Authorization (不安全的物件授權)
API2:2019 Broken User Authentication (無效的身分驗證)
API3:2019 Excessive Data Exposure (資料暴露不當)
API4:2019 Lack of Resources & Rate Limiting (缺乏資源與速率存取的限制)
API5:2019 Broken Function Level Authorization (無效功能權限控管)
API6:2019 Mass Assignment (批量配置不當)
API7:2019 Security Misconfiguration (安全配置錯誤)
API8:2019 Injection (注入攻擊)
API9:2019 Improper Assets Management(版本控管不當版本控管不當)
API10:2019 Insufficient Logging & Monitoring (記錄與監控不足)

常用見的有 SOAP & REST

🔸 API1:2019 Broken Object Level Authorization (不安全的物件授權) 🔥

以下內容引用自：https://apisecurity.io/encyclopedia/content/owasp/api1-broken-object-level-authorization.htm

這個issue位列第一，可見有多常見和嚴重了。
這是一個讓我覺得我的server最急需改進的地方。

🔸 API2:2019 Broken User Authentication (無效的身分驗證)

身分驗證現在最常用也相對來說比較安全的是使用JWT.
可以參考：https://portswigger.net/web-security/jwt 讓JWT做到真正的安全。

我覺得使用JWT要比較注意 refresh token 這個部分。
以下引用自：https://pjchender.dev/webdev/note-jwt/

🔸 API3:2019 Excessive Data Exposure (資料暴露不當)

這個簡單來講就是server端要過濾掉多餘又敏感的內容。有時候為了效能，Server一次把所有data丟到client app，讓client端過濾選取需要的內容，這樣的作法就讓駭客有機會拿到資料。不要覺得這很容易避免，Facebook就踩過這個坑，外洩了百萬user的個資。
弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api3-excessive-data-exposure.htm

案例：Facebook user data leak
News: https://ctee.com.tw/news/global/440241.html

🔸 API4:2019 Lack of Resources & Rate Limiting (缺乏資源與速率存取的限制)

server端要限制API存取速率，限制一定時間內的錯誤數量或是IP的位置…
不然會導致以下問題：

駭客大量發送請求會導致API無法正常運作
駭客破解帳密

弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api4-lack-of-resources-and-rate-limiting.htm

案例：Instagram 密碼重設漏洞
以下引用自：https://www.ithome.com.tw/news/131888

利用了race condition 這個概念。
現在使用 TOTP codes(6個數字)做驗證很多，但我覺得不加限制的話，破解6個數字比破解密碼容易多了。
Instagram獎勵漏洞通報者30000美金 https://www.acunetix.com/blog/web-security-zone/instagram-usd-30000-bounty/ 有使用漏洞影片

🔸 API5:2019 Broken Function Level Authorization (無效功能權限控管)

API的權限控管有缺陷，比如一般使用者能夠使用管理員權限的功能的話就很危險。
弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api5-broken-function-level-authorization

🔸 API6:2019 Mass Assignment (批量配置不當)

From Teacher Alex Lin’s PPT

如果API自動將用戶端輸入的內容轉換為內部物件屬性，卻不考慮這些屬性的敏感度和可暴露度等級，攻擊者則可以非法更新不應該存取的內容。

弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api6-mass-assignment

🔸 API7:2019 Security Misconfiguration (安全配置錯誤)

內部使用的服務不要暴露在外網環境，e.g. DB、Redis、AWS s3、bucket.
Server內的DB, Redis之類不要有對外port.
弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api7-security-misconfiguration

🔸 API8:2019 Injection (注入攻擊)

API和WEB一樣都要面對注入攻擊。
弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api8-injection

案例：CVE-2016-5641 Swagger Injection
Will study the case later.

🔸 API9:2019 Improper Assets Management(版本控管不當版本控管不當)

留下舊的有問題的API，就了留下隱患。
弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api9-improper-assets-management

🔸 API10:2019 Insufficient Logging & Monitoring (記錄與監控不足)

弱點詳細和防護：https://apisecurity.io/encyclopedia/content/owasp/api10-insufficient-logging-and-monitoring

🔸 References:

https://owasp.org/www-project-api-security/
推薦 https://apisecurity.io/encyclopedia/content/owasp/api1-broken-object-level-authorization 有針對每一條提出防護方法。

道德駭客實務入門-4/8課程筆記-2

Introduction

OWASP “Web Security” vs “API security”

OWASP Web Security Top 10

🔸 A1:2017 Injection (注入攻擊)

Command Injection

SQL Injection

LDAP Injection

Useful Hacking Technology 🔥

🔸 A2:2017 Broken Authentication (無效的身分驗證)

🔸 A3:2017 Sensitive Data Exposure (敏感資料外洩)

Heart Bleed CVE-2014-0160

NginX CVE-2017-7529

🔸 A4:2017 XML External Entity (XXE XML 外部處理器弱點)

🔸 A5:2017 Broken Access Control (無效的存取控管)

🔸 A6:2017 Security Misconfiguration (不安全的組態設定)

🔸 A7:2017 Cross-Site Scripting (XSS) (跨站腳本攻擊) 🔥

🔸 A8:2017 Insecure Deserialization (不安全的反序列化弱點) • 🔥

🔸 A9:2017 Using Components With Known Vulnerabilities (使用已知漏洞元件)

🔸 A10:2017 Insufficient Logging and Monitoring (記錄與監控不足)

🔸 References:

OWASP API Security Top 10

🔸 API1:2019 Broken Object Level Authorization (不安全的物件授權) 🔥

🔸 API2:2019 Broken User Authentication (無效的身分驗證)

🔸 API3:2019 Excessive Data Exposure (資料暴露不當)

🔸 API4:2019 Lack of Resources & Rate Limiting (缺乏資源與速率存取的限制)

🔸 API5:2019 Broken Function Level Authorization (無效功能權限控管)

🔸 API6:2019 Mass Assignment (批量配置不當)

🔸 API7:2019 Security Misconfiguration (安全配置錯誤)

🔸 API8:2019 Injection (注入攻擊)

🔸 API9:2019 Improper Assets Management(版本控管不當版本控管不當)

🔸 API10:2019 Insufficient Logging & Monitoring (記錄與監控不足)

🔸 References: