Đáp án Quiz Security — 74 câu hỏi có giải thích

Đáp án: C

Prepared statement / tham số hoá: WHERE email = $1 rồi truyền giá trị riêng. DB coi tham số là dữ liệu thuần, không bao giờ phân tích nó thành câu lệnh — nên không có cách nào chèn SQL vào.

Đáp án: D

bcrypt hoặc argon2 (argon2id nếu chọn mới), mỗi mật khẩu một salt riêng do thư viện tự sinh. Điểm cốt lõi: hàm băm phải chậm có chủ ý — SHA-256 nhanh nên không phù hợp dù có salt.

Đáp án: B

Thu hồi (revoke) key trước tiên và phát key mới. Bot quét GitHub liên tục và thường tìm thấy secret trong vòng vài phút, nên phải coi như key đã bị lộ. Dọn lịch sử git là việc làm sau, không thay thế việc thu hồi.

Đáp án: C

Đọc mô tả lỗ hổng và xem nó có áp dụng với cách mình dùng không (nhiều lỗ hổng chỉ xảy ra ở tính năng bạn không dùng, hoặc chỉ ở dependency của dev), rồi nâng phiên bản có bản vá.

Đáp án: D

Một thông báo ngắn, không tiết lộ nội bộ cùng mã lỗi để client xử lý, và một id lỗi để đối chiếu. Stack trace, câu SQL, tên tệp, phiên bản thư viện thì chỉ ghi vào log phía server.

Đáp án: A

Khi mật khẩu đã bị lộ — rò rỉ từ site khác, bị dò, hay bị lừa qua phishing đơn giản. Kẻ tấn công có mật khẩu vẫn thiếu yếu tố thứ hai. Đây là biện pháp hiệu quả nhất so với công sức bỏ ra cho việc bảo vệ tài khoản.

Đáp án: A

Không ghi mật khẩu, token, số thẻ, OTP và dữ liệu cá nhân nhạy cảm. Log đi qua nhiều hệ thống và nhiều người truy cập được hơn DB, nên nó thường là nơi rò rỉ dễ nhất mà ít ai để ý.

Đáp án: C

Clickjacking: kẻ tấn công nhúng trang thật của bạn vào iframe rồi phủ lớp trong suốt lên, người dùng tưởng đang bấm nút trên trang của chúng nhưng thực ra bấm vào trang bạn — với phiên đăng nhập của họ.

Đáp án: B

Dữ liệu sinh giả hoặc bản sao đã che/thay thế thông tin cá nhân. Staging thường có mật khẩu yếu hơn, ít giám sát, nhiều người truy cập — nên copy nguyên dữ liệu thật là nhân bản rủi ro sang chỗ yếu nhất.

Đáp án: D

Nó kiểm soát bao nhiêu phần URL hiện tại được gửi kèm khi người dùng bấm sang site khác. Nếu URL chứa token đặt lại mật khẩu hay id nội bộ, mặc định lỏng sẽ để lộ chúng cho site ngoài và cho analytics của họ.

Đáp án: A

HTTPS bảo vệ dữ liệu khi đang di chuyển: TLS mã hoá nội dung, kiểm tra tính toàn vẹn và xác thực danh tính server qua certificate. Sau khi request tới được ứng dụng, dữ liệu trở lại dạng gốc — mọi rủi ro ở tầng lưu trữ, phân quyền hay logic vẫn còn nguyên.

Đáp án: A

Hashing là hàm một chiều: cùng input cho cùng output độ dài cố định, không có đường quay lại. Encryption là phép biến đổi hai chiều có khoá: ai giữ khoá đúng thì khôi phục được dữ liệu gốc. Vì vậy mật khẩu phải hash, còn dữ liệu cần đọc lại (số thẻ, token) thì encrypt.

Đáp án: A

403 Forbidden. 401 Unauthorized nghĩa là "chưa xác thực hoặc credential không hợp lệ" và đi kèm header WWW-Authenticate; 403 nghĩa là "đã biết bạn là ai, nhưng bạn không được phép". Với tài nguyên nhạy cảm mà việc lộ sự tồn tại đã là rủi ro, có thể chủ động trả 404 thay cho 403.

Đáp án: D

SHA-256 được thiết kế để chạy nhanh, mà nhanh là đúng thứ kẻ tấn công cần: một GPU dò được hàng tỷ ứng viên mỗi giây. Mật khẩu phải dùng hàm hash chuyên dụng có tham số chi phí — Argon2id, bcrypt hoặc scrypt — cùng salt ngẫu nhiên cho từng người dùng.

Đáp án: D

Reflected: payload nằm trong request (thường là query string), được server phản chiếu vào response, nên phải dụ từng nạn nhân bấm link. Stored: payload được lưu vào database rồi phục vụ lại cho mọi người xem — phạm vi rộng hơn và thường bị xếp mức nghiêm trọng cao hơn.

Đáp án: B

CORS là cơ chế của trình duyệt bảo vệ người dùng: mặc định Same-Origin Policy không cho trang A đọc phản hồi từ origin B; header CORS là cách origin B nói "tôi cho phép A đọc". Nó không chặn request tới server, nên không thay được xác thực và phân quyền.

Đáp án: B

Không đủ. Tên file và Content-Type đều do client cung cấp. Cần kiểm tra nội dung thật (magic bytes), dùng allowlist loại file, đặt lại tên khi lưu, lưu ngoài thư mục phục vụ tĩnh, và trả về với Content-Type cố định kèm Content-Disposition: attachment khi phù hợp.

Đáp án: D

Bỏ ép đổi mật khẩu định kỳ khi không có dấu hiệu bị lộ, và bỏ các quy tắc tổ hợp ký tự bắt buộc. Thay vào đó: khuyến khích mật khẩu dài, đối chiếu với danh sách mật khẩu đã rò rỉ, cho phép dán, và chỉ bắt đổi khi có bằng chứng tài khoản bị ảnh hưởng.

Đáp án: A

HttpOnly khiến cookie vô hình với JavaScript: trình duyệt vẫn tự gửi kèm request, nhưng document.cookie không đọc ra. Nhờ đó một lỗi XSS không lấy được trực tiếp token phiên. Bộ ba nên đi cùng nhau: HttpOnly, Secure, SameSite.

Đáp án: A

Tài khoản ứng dụng chỉ nên có đúng các quyền nó dùng — thường là SELECT, INSERT, UPDATE, DELETE trên tập bảng cụ thể — và không sở hữu schema, không có quyền DROP, không phải superuser. Việc di trú schema chạy bằng một tài khoản riêng, chỉ dùng lúc triển khai.

Đáp án: C

Chủ yếu khi dùng dangerouslySetInnerHTML với dữ liệu chưa làm sạch. JSX escape văn bản theo mặc định, nên <div>{userInput}</div> là an toàn. Rủi ro còn ở href={userInput} (javascript:) và các thuộc tính nhận URL.

Đáp án: A

Thiếu kiểm tra chủ sở hữu (IDOR / broken object level authorization): xác thực chỉ trả lời "anh là ai", còn phải trả lời "anh có quyền với tài nguyên này không". Truy vấn nên là WHERE id = ? AND user_id = ?.

Đáp án: D

Site của kẻ tấn công khiến trình duyệt bạn gửi request tới site thật, và cookie được gửi kèm tự động nên request trông như hợp lệ. Chặn bằng SameSite=Lax hoặc Strict trên cookie phiên, cộng CSRF token cho các thao tác ghi.

Đáp án: C

Tin alg trong header của token. Kẻ tấn công đổi nó thành none (không chữ ký) hoặc chuyển RS256 sang HS256 rồi ký bằng public key. Server phải cố định thuật toán khi xác minh, không đọc từ token.

Đáp án: D

CORS bảo vệ người dùng: nó ngăn JavaScript ở origin A đọc response từ origin B. * nghĩa là cho mọi origin đọc. Nó không bảo vệ server — curl hay một service khác vẫn gọi API bình thường.

Đáp án: A

Không đủ. Content-Type và tên tệp đều do client khai. Phải kiểm nội dung thật (magic bytes / thư viện đọc ảnh), giới hạn kích thước, tự sinh tên tệp mới, và lưu ngoài thư mục web root.

Đáp án: D

Thông báo chung cho cả hai trường hợp: "email hoặc mật khẩu không đúng". Phân biệt rõ sẽ thành công cụ dò tài khoản (user enumeration) — kẻ tấn công biết email nào đã đăng ký để tập trung tấn công.

Đáp án: D

Nói với trình duyệt: từ giờ chỉ kết nối domain này bằng HTTPS, trong max-age đã khai. Nhờ đó lần sau người dùng gõ http:// thì trình duyệt tự đổi sang HTTPS trước khi gửi, không còn request HTTP để bị chặn giữa đường.

Đáp án: B

Có, luôn luôn. Validate ở client chỉ để phản hồi nhanh cho người dùng. Kẻ tấn công gọi thẳng API bằng curl, bỏ qua toàn bộ giao diện. Nguyên tắc: mọi thứ đến từ client đều không tin được.

Đáp án: C

Kết hợp: giới hạn theo tài khoản (chặn dò mật khẩu một người) và theo IP (chặn quét nhiều tài khoản), cộng khoá tạm thời có thời gian tăng dần. Đừng khoá vĩnh viễn — nó thành công cụ để chặn người dùng thật.

Đáp án: C

Ba thuộc tính bắt buộc: httpOnly (JavaScript không đọc được, nên XSS không lấy được phiên), Secure (chỉ gửi qua HTTPS), SameSite=Lax (chống CSRF). Cộng thời hạn hợp lý và đường dẫn hẹp nhất có thể.

Đáp án: C

Thiệt hại không còn giới hạn. Một lỗ hổng SQL injection nhỏ khi đó cho phép xoá bảng, đọc mọi dữ liệu, hay thay đổi cấu hình DB. User của ứng dụng chỉ nên có quyền đọc/ghi trên các bảng nó cần.

Đáp án: D

Chặn đánh cắp authorization code: client sinh một code_verifier bí mật, gửi bản băm của nó khi bắt đầu, rồi gửi bản gốc khi đổi code lấy token. Ai lấy được code mà không có verifier thì không đổi được gì.

Đáp án: D

Cấm script inline và eval, chỉ cho phép script từ nguồn khai báo (dùng nonce hoặc hash cho script cần inline). Vì phần lớn payload XSS là inline script, đây là phần mang lại hiệu quả cao nhất.

Đáp án: B

Path traversal: ?file=../../.env đọc được tệp ngoài thư mục dự định. Chặn bằng cách nối đường dẫn, chuẩn hoá (path.resolve), rồi kiểm tra kết quả có còn nằm trong thư mục gốc cho phép hay không.

Đáp án: B

Không. Ẩn nút chỉ là trải nghiệm người dùng. Ai cũng mở tab network, thấy endpoint, rồi gọi lại bằng curl. Mọi quyết định phân quyền phải được thực thi ở server, cho cả đọc và ghi.

Đáp án: D

Sinh bằng nguồn ngẫu nhiên an toàn (crypto.randomBytes), dùng một lần, hết hạn sau 15–60 phút, và bị vô hiệu ngay khi đã dùng hoặc khi có yêu cầu reset mới. Lưu bản băm của token trong DB, không lưu bản gốc.

Đáp án: D

Phân biệt rõ: cần đọc lại thì mã hoá (không băm); chỉ cần so khớp thì băm. Với CMND, mã hoá bằng khoá quản lý ngoài DB (KMS hoặc secret manager), giới hạn ai giải mã được, và ghi log mỗi lần giải mã.

Đáp án: D

Lưu bản băm, hiện bản gốc một lần duy nhất lúc tạo. Nếu đối tác mất key thì phát key mới, không có chức năng xem lại. Đây là cùng nguyên tắc với mật khẩu: hệ thống không cần biết giá trị gốc.

Đáp án: D

Vô hiệu toàn bộ phiên cũ (thường giữ lại phiên đang thao tác). Nếu không, kẻ đã chiếm được phiên vẫn dùng tiếp bình thường — và người dùng tưởng đổi mật khẩu là đã an toàn.

Đáp án: B

Dùng API spawn với mảng tham số (spawn('ffmpeg', ['-i', filePath, ...])), không dùng exec với chuỗi lệnh. Không có shell diễn giải thì ;, &&, backtick, $() chỉ là ký tự thường trong tham số.

Đáp án: D

Hai thứ mất ngay: tiền (mỗi SMS là chi phí thật, kẻ tấn công đốt ngân sách của bạn) và uy tín (dịch vụ của bạn thành công cụ gửi tin rác tới số lạ). Phải giới hạn theo số điện thoại, theo IP, và theo tài khoản.

Đáp án: D

Bảo toàn bằng chứng (sao lưu log, ảnh chụp trạng thái) rồi chặn đường đang bị dùng. Xử lý theo thứ tự: ghi nhận → cách ly → xác định phạm vi → thu hồi credential → khôi phục → thông báo theo nghĩa vụ.

Đáp án: C

JavaScript đọc được localStorage, nên bất kỳ lỗ XSS nào (kể cả từ một dependency bị chèn mã) đều lấy được token. Cookie httpOnly thì script không đọc được — đổi lại phải xử lý CSRF bằng SameSite.

Đáp án: D

Ba nhóm: xác thực, phân quyền, và xử lý đầu vào (kèm truy vấn DB, lệnh shell, đường dẫn tệp). Một dòng sai ở đó là một lỗ hổng, còn sai ở phần hiển thị thì chỉ là bug.

Đáp án: A

Open redirect: kẻ tấn công gửi https://site-that-thuc.com/login?next=https://site-gia.com. Liên kết trông đáng tin vì bắt đầu bằng domain thật của bạn, nhưng đích đến là trang lừa đảo.

Đáp án: C

Đây là IDOR (Insecure Direct Object Reference), thuộc nhóm Broken Access Control — hạng mục số 1 trong OWASP Top 10. Xác thực đã có nhưng thiếu kiểm tra quyền trên từng bản ghi, nên chỉ cần đổi :id là đọc được hoá đơn của người khác. Cách sửa: mọi truy vấn phải ràng buộc theo chủ sở hữu.

Đáp án: B

Mass assignment: request {"email":"…","role":"admin"} sẽ ghi luôn cột role vì tên field khớp thuộc tính entity. Cách chặn là dùng DTO khai báo tường minh danh sách field cho phép (allowlist) và ánh xạ thủ công, thay vì gán cả object từ body.

Đáp án: A

SameSite quyết định cookie có được gửi kèm cross-site request hay không. Strict không gửi trong mọi điều hướng từ site khác; Lax (mặc định của trình duyệt hiện nay) chỉ gửi với điều hướng cấp cao nhất bằng GET; None gửi mọi lúc và bắt buộc đi kèm Secure.

Đáp án: D

JWT là stateless: server chỉ xác minh chữ ký và exp, không tra cứu bảng phiên nào, nên không có chỗ để đánh dấu "token này đã bị thu hồi". Cách xử lý thực tế: access token đặt hạn ngắn (5–15 phút), phần thu hồi làm ở refresh token — lưu trong database, xoay vòng và huỷ khi đăng xuất.

Đáp án: D

Open redirect. Kẻ tấn công phát tán link https://site-that-nguoi-dung-tin.vn/login?next=https://site-gia.example, nạn nhân thấy domain quen nên bấm, rồi bị đưa sang trang giả để nhập lại thông tin. Cách chặn: chỉ chấp nhận đường dẫn nội bộ, hoặc so khớp với allowlist domain.

Đáp án: C

Credential stuffing phân tán: kẻ tấn công có sẵn danh sách email/mật khẩu rò rỉ, chạy qua botnet nên mỗi IP chỉ thử vài lần. Cần thêm giới hạn theo tài khoản và theo cặp (tài khoản, IP), cộng thêm phát hiện bất thường ở mức toàn hệ thống.

Đáp án: A

Xoay khoá trước tiên — thu hồi khoá cũ, phát khoá mới, cập nhật nơi lưu bí mật. Mọi việc khác (viết lại lịch sử, thêm scanner) đều là bước sau, vì khoá đã nằm trong lịch sử Git suốt 3 tháng phải được coi như đã lộ ra ngoài.

Đáp án: A

HSTS chặn SSL stripping: chuyển hướng 301 chỉ hoạt động *sau khi* một request HTTP đã rời máy người dùng, và kẻ đứng giữa có thể chặn đúng request đó. Với HSTS, trình duyệt nhớ rằng domain này chỉ dùng HTTPS và tự nâng cấp mọi truy cập tiếp theo ngay tại máy.

Đáp án: A

Trả thông báo trung tính giống hệt nhau cho cả hai trường hợp: "Nếu email này có trong hệ thống, chúng tôi đã gửi hướng dẫn đặt lại mật khẩu." Khác biệt về nội dung, mã trạng thái hay thời gian phản hồi đều biến form thành công cụ liệt kê tài khoản (user enumeration).

Đáp án: A

Chưa đủ. Ẩn nút chỉ là trải nghiệm, không phải kiểm soát truy cập. Mọi endpoint thay đổi dữ liệu phải tự kiểm tra vai trò và quyền sở hữu ở phía server; phần giao diện chỉ đi kèm để người dùng không thấy thao tác họ không dùng được.

Đáp án: A

Giá trị lớn nhất của CSP với XSS là chặn script nội tuyến; khai báo 'unsafe-inline' chính là mở lại cánh cửa đó. Cách làm đúng là dùng nonce hoặc hash cho từng script hợp lệ, kết hợp strict-dynamic để không phải liệt kê thủ công các script được nạp tiếp theo.

Đáp án: C

SSRF (Server-Side Request Forgery): kẻ tấn công đưa URL trỏ vào 169.254.169.254 (metadata của cloud), localhost hay dải IP nội bộ, biến server thành cầu nối vào mạng riêng. Đây là con đường của sự cố Capital One năm 2019, dẫn tới rò rỉ dữ liệu hơn 100 triệu người.

Đáp án: C

Không ghi thông tin xác thực và dữ liệu nhạy cảm: token, mật khẩu, số thẻ, mã OTP, khoá API, cookie phiên. Log thường được chuyển tiếp sang hệ thống tập trung, giữ nhiều tháng và được truy cập rộng hơn database — nên một token nằm trong log là một phiên bị lộ.

Đáp án: D

Kênh SMS nằm ngoài tầm kiểm soát của ứng dụng: SIM swap, chuyển hướng ở tầng SS7, và mã hiển thị trên màn hình khoá đều lấy được mã. TOTP sinh mã cục bộ từ bí mật chia sẻ nên không có kênh truyền để chặn. NIST đã hạ khuyến nghị với SMS từ năm 2016.

Đáp án: B

Prepared statement tách cấu trúc khỏi dữ liệu: database phân tích và lập kế hoạch cho câu lệnh với các placeholder trước, rồi mới nhận giá trị. Vì cây phân tích đã cố định, chuỗi ' OR 1=1-- chỉ được hiểu là một giá trị chuỗi, không bao giờ trở thành cú pháp.

Đáp án: A

Dữ liệu cần đọc lại thì phải mã hoá hai chiều: AES-GCM với khoá do dịch vụ quản lý khoá (KMS, Vault) nắm giữ, tách hoàn toàn khỏi database. Kèm theo: hiển thị dạng che một phần theo mặc định, ghi log mọi lần giải mã, và chỉ giải mã đúng lúc cần.

Đáp án: A

Không cần. CSRF khai thác việc trình duyệt tự động gửi kèm thông tin xác thực (cookie, HTTP Basic, chứng chỉ client). Header Authorization phải do JavaScript đặt, mà JavaScript của site khác không đọc được token của bạn, nên không dựng được request hợp lệ.

Đáp án: C

Đánh giá khả năng khai thác trong ngữ cảnh của bạn trước: ứng dụng có gọi tới hàm bị lỗi không, đầu vào có do người dùng kiểm soát không, package có chạy ở production hay chỉ ở khâu build. Sau đó mới chọn: nâng phiên bản, ghim bản vá, hay ghi nhận chấp nhận rủi ro có thời hạn.

Đáp án: A

Khoá phải nằm ở backend của bạn; ứng dụng di động gọi backend bằng phiên người dùng, backend mới gọi API bên thứ ba. Mọi bí mật đóng gói cùng ứng dụng đều lấy ra được bằng cách giải nén gói cài đặt hoặc chặn lưu lượng trên thiết bị đã can thiệp.

Đáp án: D

Container không phải ranh giới bảo mật mạnh như máy ảo. Nếu không bật user namespace, root trong container chính là uid 0 trên host, nên một lỗi ở runtime hoặc một volume mount sai cấu hình sẽ trao quyền cao trên máy chủ. Khai báo USER không phải root trong Dockerfile.

Đáp án: A

Bật Block Public Access ở cấp tài khoản. Cấu hình này áp lên toàn bộ bucket hiện có và bucket tạo sau, nên một chính sách sai ở một bucket cũng không tạo ra quyền truy cập công khai. Bổ sung bằng SCP ở cấp tổ chức để không ai tắt được thiết lập đó.

Đáp án: D

Cảnh báo cho các sự kiện hiếm và có tác động cao: thay đổi quyền, tạo khoá truy cập mới, đăng nhập thành công từ vị trí hoặc thiết bị lạ của tài khoản quản trị, tắt cơ chế ghi log, và truy cập hàng loạt vào dữ liệu nhạy cảm. Cảnh báo cho sự kiện thường ngày chỉ tạo mỏi cảnh báo.

Đáp án: C

Dùng API nhận mảng tham số thay vì chuỗi lệnh: execFile("convert", [input, output]) trong Node, subprocess.run([...], shell=False) trong Python. Không có shell thì ;, |, $() chỉ là ký tự trong tên file. Kèm theo: kiểm tra tên file theo allowlist và chạy với quyền tối thiểu.

Đáp án: B

Token phải ngẫu nhiên đủ mạnh (từ nguồn ngẫu nhiên mật mã, ≥128 bit), dùng một lần, hết hạn trong 15–60 phút, và được lưu ở dạng hash trong database. Sau khi đổi mật khẩu thành công thì huỷ toàn bộ phiên đang mở và thông báo cho người dùng qua email.

Đáp án: D

Luôn kẹp giá trị ở phía server: đặt mặc định hợp lý và trần cứng (ví dụ mặc định 20, tối đa 100), bỏ qua giá trị vượt trần thay vì báo lỗi. Đây là nhóm rủi ro "Unrestricted Resource Consumption" trong OWASP API Security Top 10.

Đáp án: A

Khai thác thứ tự phân giải nguồn gói: khi tên gói nội bộ (@congty/utils hoặc congty-utils) cũng tồn tại trên registry công khai với phiên bản cao hơn, nhiều cấu hình sẽ tải bản công khai. Chặn bằng cách gắn scope cho registry nội bộ và đăng ký trước tên gói trên registry công khai.

Đáp án: A

RBAC: quyền gắn với vai trò ("editor được sửa bài"). ABAC: quyết định tính theo thuộc tính tại thời điểm truy cập ("được sửa nếu là tác giả, bài chưa xuất bản, và trong giờ làm việc"). RBAC dễ hiểu và dễ kiểm toán; ABAC linh hoạt hơn nhưng khó suy luận và khó kiểm thử hơn.

Đáp án: C

Math.random() là bộ sinh giả ngẫu nhiên không dành cho mật mã: trạng thái nội bộ khôi phục được từ một chuỗi đầu ra, nên token tiếp theo đoán được. Dùng nguồn ngẫu nhiên mật mã: crypto.randomBytes(32) (Node), crypto.getRandomValues() (trình duyệt), secrets (Python).