Bảo mật ứng dụng web

18 câu rút từ các phần của chuỗi. Trả lời ở đây cũng được tính cho quiz của từng bài.

1. Câu 1/18·Cơ bảnĐiểm khác biệt chính giữa threat modeling và pentest là gì?

   Threat modeling chỉ dành cho team bảo mật, còn pentest do kỹ sư thiết kế thực hiệnThreat modeling tìm lỗi thiết kế ở thứ sắp xây khi sửa còn rẻ (đổi sơ đồ), còn pentest tìm lỗ hổng khai thác được trong thứ đã chạyThreat modeling thay thế được pentest vì liệt kê được đầy đủ mọi rủi roThreat modeling tìm lỗi implementation như injection, còn pentest tìm lỗi thiết kế
2. Câu 2/18·Trung cấpMột worker chạy trong VPC của công ty, xử lý file mà người dùng ngoài upload lên S3. Nhóm cho rằng worker "nằm trong mạng nội bộ nên an toàn". Nhận định nào đúng?

   Đúng, vì VPC và security group đã chặn mọi truy cập từ bên ngoàiĐúng, miễn là worker có quét malware trước khi xử lýSai, nhưng chỉ vì worker cần được cập nhật thư viện thường xuyênSai, vì ranh giới tin cậy đi theo nguồn gốc dữ liệu chứ không theo mạng; nội dung file là byte do kẻ lạ chọn nên cần sandbox và quyền tối thiểu
3. Câu 3/18·Trung cấpReact escape mọi giá trị render dưới dạng text. Vì sao XSS vẫn còn là rủi ro trong ứng dụng React?

   Vì React chỉ escape được chuỗi ngắn, chuỗi dài hơn một ngưỡng sẽ bị bỏ quaVì escape của React có thể bị tắt bằng CSP nên cần bật lại ở phía serverVì escape chỉ áp dụng cho text và attribute do React quản lý; các sink như dangerouslySetInnerHTML, href kiểu javascript:, JSON trong thẻ script, DOM API trực tiếp hay thư viện bên thứ ba đi vòng qua nóVì React không escape ký tự < và > trong text node
4. Câu 4/18·Nâng caoVì sao bài khuyến nghị strict CSP dựa trên nonce kèm 'strict-dynamic' thay vì allow-list theo domain?

   Allow-list dễ bị bypass qua endpoint của domain được tin (JSONP, script gadget, file upload); nonce sinh mới mỗi response nên kẻ chèn <script> không đoán được, còn 'strict-dynamic' cho script đã tin nạp thêm script khácNonce mã hoá nội dung script nên kẻ tấn công không đọc được codeAllow-list không được trình duyệt hiện đại hỗ trợ nên policy không có tác dụngNonce có thể dùng lại giữa các request để tận dụng cache của CDN
5. Câu 5/18·Trung cấpMột đồng nghiệp nói "API đã cấu hình CORS chặt nên không cần lo CSRF". Vì sao nhận định này sai?

   Vì CORS chỉ áp dụng cho request GETVì CORS chỉ nới lỏng quyền đọc response; simple request như form POST vẫn được gửi và thực thi, trình duyệt chỉ giấu responseVì CORS chỉ có hiệu lực khi dùng HTTP chứ không phải HTTPSVì trình duyệt kiểm tra CORS sau khi server xử lý xong nên server luôn từ chối được request
6. Câu 6/18·Trung cấpVì sao việc đặt Access-Control-Allow-Origin bằng đúng Origin của request kèm Allow-Credentials: true là một lỗ hổng?

   Vì trình duyệt không chấp nhận origin cụ thể khi có credentialsVì nó làm preflight luôn thất bạiVì nó chỉ ảnh hưởng tới hiệu năng cacheVì nó tin mọi origin, nên website bất kỳ có thể đọc dữ liệu cá nhân của người dùng đang đăng nhập; với SameSite=Lax thì vẫn mở cho mọi origin cùng site, kể cả subdomain bị bỏ quên có XSS
7. Câu 7/18·Trung cấpVì sao RFC 9700 khuyến nghị dùng PKCE cho mọi client, kể cả confidential client đã có client_secret?

   Vì client_secret có thể bị lộ nên PKCE là cách thay thế nó hoàn toànVì PKCE mã hoá authorization code khi nó đi qua trình duyệtVì PKCE ràng buộc code với client đã khởi tạo luồng, nên code bị chặn hoặc bị tiêm vào phiên của kẻ tấn công thì vô dụngVì PKCE thay thế được state và nonce nên có thể bỏ hai tham số đó
8. Câu 8/18·Trung cấpMột SPA gửi ID token trong header Authorization để gọi API và API chấp nhận vì chữ ký hợp lệ. Vấn đề lớn nhất là gì?

   ID token được phát cho frontend (aud là client_id), không mang scope; API đang chấp nhận token dành cho một ứng dụng khác và mất khả năng phân quyền theo scopeID token luôn là opaque string nên API không thể validate được chữ kýID token hết hạn nhanh hơn access token nên người dùng sẽ bị đăng xuất liên tụcKhông có vấn đề gì về bảo mật, chỉ là khác quy ước đặt tên
9. Câu 9/18·Nâng caoServer phát token bằng RS256 và verify bằng một hàm lấy thuật toán từ header. Kẻ tấn công làm gì để giả mạo token mà không cần private key?

   Đổi alg thành none và để trống chữ ký.Đặt alg là HS256 và ký HMAC bằng chính chuỗi public key làm secret; thư viện dùng public key đó để verify và thấy khớp.Dùng kid trỏ tới file /dev/null để verifier dùng khoá rỗng.Brute-force private key RSA từ public key trong JWKS.
10. Câu 10/18·Nâng caoKhi xoay khoá JWKS định kỳ, vì sao phải publish khoá mới vào JWKS và chờ một khoảng trước khi bắt đầu ký bằng nó?

    Để mọi verifier kịp cache JWKS có khoá mới, tránh cửa sổ mà token mới bị 401 do kid lạ và cooldown refetch.Để khoá cũ tự động hết hạn mà không cần gỡ.Để CDN có thời gian nén file JWKS.Vì JWKS chỉ cập nhật được mỗi ngày một lần.
11. Câu 11/18·Trung cấpEndpoint GET /orders/:id đã có câu if so order.customerId với user hiện tại. Vì sao bài vẫn khuyên đưa kiểm tra quyền sở hữu vào tầng dữ liệu (scoped repository)?

    Vì câu if trong controller chạy chậm hơn một điều kiện where trong databaseVì JWT có thể bị giả mạo nên controller không đáng tin để đọc req.userVì mỗi endpoint mới (invoice, export CSV, huỷ đơn) đều có thể quên câu if, còn repository bắt buộc có scope thì không thể bỏ quaVì kiểm tra trong controller chỉ áp dụng được cho thao tác đọc, không áp dụng cho ghi
12. Câu 12/18·Nâng caoTính năng "nhập từ URL" cho phép server fetch URL do người dùng cung cấp. Cách chặn SSRF nào đáng tin nhất trong số này?

    Từ chối URL có chứa localhost, 127.0.0.1 hoặc dải IP private trong chuỗiPhân giải DNS một lần để kiểm tra IP, rồi để thư viện fetch tự phân giải lại khi kết nốiChỉ cho phép HTTPS vì kẻ tấn công không dùng được chứng chỉ hợp lệ cho IP nội bộKiểm tra trên chính IP mà kết nối thực sự tới, từ chối redirect, và đặt worker sau egress proxy
13. Câu 13/18·Nâng caoCode resolve hostname, kiểm tra IP là public, rồi gọi fetch(url). Vì sao vẫn có thể bị SSRF, và cách sửa đúng là gì?

    Vì IP public có thể bị đổi sang IP private bởi router; cần kiểm tra lại sau khi nhận response.Vì fetch resolve tên một lần nữa, DNS rebinding có thể trả IP public lúc kiểm tra và 127.0.0.1 lúc kết nối; cần kiểm tra và pin IP ngay trong lookup mà socket dùng.Vì chỉ kiểm tra IPv4 là chưa đủ; chỉ cần thêm kiểm tra IPv6 là xong.Vì hostname có thể chứa ký tự Unicode; cần chuẩn hoá hostname trước khi resolve.
14. Câu 14/18·Trung cấpTeam phục vụ file upload của người dùng từ files.acme.com trong khi app chạy ở app.acme.com, và cho rằng như vậy đã cô lập. Điều gì sai?

    Subdomain luôn dùng chung certificate nên dễ bị giả mạo.Subdomain không hỗ trợ header Content-Disposition.Subdomain chậm hơn domain riêng vì phải resolve thêm một lần.Hai subdomain là same-site: cookie scope theo .acme.com vẫn được gửi tới đó và SameSite không bảo vệ, nên nên dùng một registrable domain khác hẳn.
15. Câu 15/18·Trung cấpMột dev lỡ push API key lên repo. Sau khi đã xoá file và force-push viết lại lịch sử, họ coi như xong việc. Bước nào bị thiếu và vì sao nó quan trọng nhất?

    Thông báo cho GitHub để họ xoá commit khỏi mọi bản clone; sau đó key an toànĐổi tên repo để scanner không còn tìm thấy keyThu hồi hoặc xoay credential ngay, vì key coi như đã cháy từ lúc push: clone, fork, ref của pull request và bot quét đã có thể giữ bản saoThêm gitleaks vào pre-commit để lần sau không lặp lại; key cũ không còn nguy hiểm
16. Câu 16/18·Trung cấpVì sao dùng GitHub Actions OIDC để deploy lên cloud tốt hơn lưu AWS_SECRET_ACCESS_KEY trong GitHub secrets?

    Mỗi lần chạy workflow đổi một JWT có chữ ký lấy credential tạm thời, giới hạn theo repo/branch/environment, nên không có secret dài hạn nào để lộ hay phải xoayVì OIDC mã hoá key tĩnh mạnh hơn so với GitHub secrets thông thườngVì OIDC cho phép mọi repo trong org dùng chung một role mà không cần cấu hình thêmVì OIDC tự động che mọi secret trong log, kể cả khi bị encode base64
17. Câu 17/18·Nâng caoMột bản phát hành mới của package có provenance hợp lệ. Có thể kết luận gì?

    Bản đó chắc chắn an toàn vì được build trong CI đã được xác thực.Bản đó an toàn vì npm đã quét mã độc trước khi cấp provenance.Chỉ biết nó được build từ commit và workflow nào; nếu kẻ tấn công điều khiển được chính workflow đó thì provenance vẫn hợp lệ.Provenance chỉ chứng minh người publish có bật 2FA.
18. Câu 18/18·Trung cấpVì sao áp dụng cooldown (từ chối phiên bản mới hơn vài ngày) được xem là biện pháp có chi phí trên hiệu quả tốt?

    Vì phiên bản độc thường bị phát hiện và gỡ trong vài giờ đến một hai ngày, nên chờ đủ lâu thì tránh được phần lớn đợt tấn công.Vì cooldown kiểm tra chữ ký của từng phiên bản.Vì cooldown thay thế được lockfile và frozen install.Vì registry chỉ cho phép tải phiên bản cũ hơn ba ngày.