Lộ trình Kỹ sư QA (Tester): Giới thiệu Kiểm thử Bảo mật và OWASP Top 10

Chào mừng bạn trở lại với chuỗi bài viết “Lộ trình Kỹ sư QA (Tester)”. Sau khi đã cùng nhau khám phá những kiến thức nền tảng về Đảm bảo Chất lượng là gì, rèn luyện tư duy của một người kiểm thử, tìm hiểu về các mô hình phát triển phần mềm, và đi sâu vào các loại kiểm thử cũng như kiểm thử thủ công cơ bản, đã đến lúc chúng ta mở rộng phạm vi sang một khía cạnh cực kỳ quan trọng của phần mềm: Bảo mật.

Trong thế giới số ngày nay, một ứng dụng không chỉ cần hoạt động đúng chức năng (functional) mà còn phải đảm bảo an toàn cho người dùng và dữ liệu của họ. Các cuộc tấn công mạng ngày càng tinh vi, và việc bỏ qua kiểm thử bảo mật có thể dẫn đến những hậu quả khôn lường, từ mất dữ liệu nhạy cảm, thiệt hại về tài chính, cho đến hủy hoại danh tiếng của công ty.

Là một Kỹ sư QA, vai trò của bạn không chỉ dừng lại ở việc tìm lỗi chức năng hay hiệu năng. Bạn còn là tuyến phòng thủ đầu tiên giúp phát hiện các lỗ hổng bảo mật phổ biến trước khi chúng bị khai thác bởi những kẻ tấn công. Mặc dù kiểm thử bảo mật chuyên sâu thường do các chuyên gia bảo mật (Penetration Testers – PenTesters) thực hiện, nhưng việc có kiến thức cơ bản và khả năng phát hiện các rủi ro thường gặp là điều *bắt buộc* đối với mọi QA hiện đại.

Trong bài viết này, chúng ta sẽ bắt đầu hành trình khám phá thế giới kiểm thử bảo mật dành cho QA, tập trung vào một tài liệu được coi là kim chỉ nam cho các lỗ hổng web phổ biến nhất: OWASP Top 10. Đây không phải là một bài viết về tấn công mạng, mà là cách giúp QA hiểu và áp dụng tư duy kiểm thử để phát hiện những rủi ro này ngay từ giai đoạn sớm.

Tại sao Kiểm thử Bảo mật Quan trọng với Kỹ sư QA?

Trước khi đi sâu vào OWASP Top 10, hãy cùng nhau củng cố lý do vì sao kiểm thử bảo mật lại nằm trong lộ trình phát triển của một QA:

• Ngăn chặn thiệt hại: Phát hiện sớm lỗ hổng giúp ngăn chặn các cuộc tấn công tiềm tàng, bảo vệ dữ liệu người dùng và tài sản của công ty.
• Tăng cường chất lượng phần mềm: Bảo mật là một phần quan trọng của chất lượng phi chức năng. Một ứng dụng không an toàn không thể được coi là chất lượng cao.
• Tuân thủ quy định: Nhiều ngành công nghiệp có quy định chặt chẽ về bảo vệ dữ liệu (ví dụ: GDPR, HIPAA). Kiểm thử bảo mật giúp đảm bảo ứng dụng tuân thủ các tiêu chuẩn này.
• Giảm chi phí sửa lỗi: Giống như bất kỳ loại lỗi nào khác, lỗi bảo mật càng phát hiện muộn thì càng tốn kém để sửa chữa.
• Nâng cao giá trị bản thân: Một QA có kiến thức về bảo mật là một tài sản quý giá cho đội dự án và công ty.

Kiểm thử bảo mật không chỉ là trách nhiệm của đội bảo mật (nếu có) hay các PenTester. Với tư cách là người kiểm thử (dù là thủ công hay tự động), bạn có cơ hội tương tác với ứng dụng ở nhiều khía cạnh, từ giao diện người dùng, API, đến cách xử lý dữ liệu. Tận dụng những góc nhìn này để tìm kiếm điểm yếu là cách hiệu quả nhất.

OWASP Top 10 là Gì và Tại sao QAs nên Quan tâm?

OWASP (Open Web Application Security Project) là một tổ chức phi lợi nhuận hoạt động nhằm cải thiện bảo mật phần mềm. Họ cung cấp các tài nguyên miễn phí, bao gồm tài liệu, công cụ và tiêu chuẩn.

OWASP Top 10 là một báo cáo tiêu chuẩn của OWASP, liệt kê 10 rủi ro bảo mật ứng dụng web nghiêm trọng nhất được cập nhật định kỳ dựa trên dữ liệu thực tế từ cộng đồng bảo mật toàn cầu. Đây là điểm khởi đầu tuyệt vời cho bất kỳ ai muốn tìm hiểu về bảo mật ứng dụng web, đặc biệt là các Kỹ sư QA.

Việc nắm vững OWASP Top 10 giúp QA:

• Hiểu được các kiểu tấn công và lỗ hổng phổ biến nhất mà ứng dụng web có thể gặp phải.
• Biết cách “nghĩ như kẻ tấn công” ở mức độ cơ bản để tìm ra điểm yếu.
• Xây dựng các trường hợp kiểm thử (test cases) hoặc kịch bản kiểm thử (test scenarios) tập trung vào bảo mật.
• Trao đổi hiệu quả hơn với nhà phát triển và chuyên gia bảo mật về các vấn đề được tìm thấy.

Đi Sâu vào OWASP Top 10 (Phiên bản 2021) và Cách QA Có Thể Kiểm Thử

Chúng ta sẽ cùng xem xét từng hạng mục trong OWASP Top 10 phiên bản 2021 và thảo luận về những cách cơ bản mà một Kỹ sư QA có thể tiếp cận để kiểm thử:

A01: Broken Access Control (Kiểm soát truy cập bị lỗi)

Giải thích: Các lỗ hổng xảy ra khi người dùng có thể truy cập vào các chức năng hoặc dữ liệu mà họ không được phép. Ví dụ: người dùng thường có thể truy cập trang quản trị hoặc xem/sửa dữ liệu của người dùng khác chỉ bằng cách thay đổi URL hoặc tham số request.

Tại sao nguy hiểm: Dẫn đến lộ lọt dữ liệu, thay đổi dữ liệu trái phép, hoặc chiếm quyền kiểm soát tài khoản.

Cách QA có thể kiểm thử:

• Thử truy cập các trang/chức năng yêu cầu quyền cao hơn: Đăng nhập bằng tài khoản người dùng thường, sau đó thử truy cập trực tiếp vào các URL dành cho admin hoặc người dùng có quyền đặc biệt.
• Thử truy cập dữ liệu của người dùng khác: Nếu có chức năng xem hồ sơ hoặc đơn hàng, thử thay đổi ID trong URL hoặc request body/parameters để xem dữ liệu của người dùng khác.

          # Ví dụ thay đổi ID trong URL
          URL gốc: https://your-app.com/profile?user_id=123
          Thử thay đổi: https://your-app.com/profile?user_id=456
          

• Kiểm tra các thao tác dựa trên ID: Khi thực hiện hành động (ví dụ: xóa bài viết, cập nhật thông tin), kiểm tra xem hệ thống có xác minh rằng người dùng hiện tại có quyền thực hiện thao tác đó trên đối tượng cụ thể (bài viết/thông tin) hay không.
• Thử truy cập các chức năng sau khi đăng xuất: Sau khi đăng xuất, thử sử dụng nút “quay lại” của trình duyệt hoặc nhập lại URL của các trang/chức năng cần đăng nhập để xem có truy cập được không.

A02: Cryptographic Failures (Lỗi mã hóa)

Giải thích: Trước đây gọi là Sensitive Data Exposure. Lỗ hổng này liên quan đến việc không bảo vệ đúng cách dữ liệu nhạy cảm như mật khẩu, số thẻ tín dụng, thông tin cá nhân. Thường do không mã hóa dữ liệu khi lưu trữ hoặc truyền tải.

Tại sao nguy hiểm: Dẫn đến lộ lọt dữ liệu cá nhân/nhạy cảm, có thể gây ra gian lận tài chính, đánh cắp danh tính.

Cách QA có thể kiểm thử:

• Kiểm tra sử dụng HTTPS: Đảm bảo toàn bộ ứng dụng sử dụng giao thức HTTPS, đặc biệt là các trang đăng nhập, đăng ký, thanh toán. Kiểm tra xem có cảnh báo bảo mật trên trình duyệt không.
• Kiểm tra dữ liệu trong Request/Response: Sử dụng tab “Network” trong Developer Tools của trình duyệt (hoặc proxy như Burp Suite/ZAP – sẽ nói thêm ở dưới) để xem dữ liệu được gửi đi và nhận về. Kiểm tra xem dữ liệu nhạy cảm (ví dụ: mật khẩu) có bị truyền dưới dạng văn bản thuần (plain text) không.
• Kiểm tra cách lưu trữ mật khẩu (ít khả thi hơn với Black Box): Mặc dù không thể xem trực tiếp cơ sở dữ liệu với Black Box Testing, nhưng nếu có quyền truy cập (ví dụ: là Gray Box Tester hoặc có dữ liệu test), kiểm tra xem mật khẩu có được lưu trữ dưới dạng mã hóa mạnh (hash) chứ không phải văn bản thuần không.
• Quan sát thông báo lỗi: Đôi khi thông báo lỗi chi tiết có thể tiết lộ cấu trúc database hoặc các thông tin nhạy cảm khác.

A03: Injection (Tiêm nhiễm)

Giải thích: Xảy ra khi dữ liệu người dùng không đáng tin cậy được gửi đến trình thông dịch (interpreter) như cơ sở dữ liệu, hệ điều hành, hoặc trình duyệt, khiến trình thông dịch thực thi các lệnh không mong muốn. Phổ biến nhất là SQL Injection (tấn công CSDL) và Cross-Site Scripting (XSS – tiêm mã độc vào trình duyệt người dùng khác).

Tại sao nguy hiểm: Cho phép kẻ tấn công truy cập, sửa đổi, hoặc xóa dữ liệu trong CSDL (SQLi), hoặc chạy mã độc trong trình duyệt của người dùng khác (XSS), đánh cắp cookie phiên làm việc, chuyển hướng người dùng.

Cách QA có thể kiểm thử:

• Thử các chuỗi SQL Injection: Nhập các chuỗi đặc biệt vào các trường nhập liệu (input fields) như tên đăng nhập, mật khẩu, tìm kiếm, hoặc URL parameters.

          # Ví dụ chuỗi SQLi đơn giản
          ' OR '1'='1
          " OR "1"="1
          admin' -- 
          

  Quan sát xem ứng dụng có phản ứng lạ không (ví dụ: đăng nhập thành công mà không cần mật khẩu, hiển thị lỗi CSDL).

• Thử các chuỗi Cross-Site Scripting (XSS): Nhập các đoạn mã JavaScript vào các trường nhập liệu (comment, profile description, search).

          # Ví dụ chuỗi XSS đơn giản
          
          
          "><script>alert('test')</script>
          

  Kiểm tra xem mã có bị thực thi không (ví dụ: hiển thị pop-up), hoặc xem mã có được hiển thị nguyên văn hay đã được lọc/mã hóa đúng cách khi lưu trữ và hiển thị.

• Kiểm tra input ở mọi nơi: Không chỉ các form, mà cả URL parameters, HTTP headers (nếu có công cụ hỗ trợ), và bất kỳ nơi nào ứng dụng nhận dữ liệu từ người dùng.

A04: Insecure Design (Thiết kế kém bảo mật)

Giải thích: Lỗ hổng này tập trung vào các vấn đề thiết kế hoặc kiến trúc không đầy đủ hoặc thiếu các biện pháp kiểm soát bảo mật cần thiết. Đây không phải là lỗi cài đặt mà là lỗi ở giai đoạn thiết kế.

Tại sao nguy hiểm: Khó khắc phục hơn lỗi cài đặt đơn thuần, thường đòi hỏi thay đổi kiến trúc lớn.

Cách QA có thể kiểm thử:

• Tham gia vào các buổi thảo luận thiết kế (nếu có): Đặt câu hỏi về các quyết định bảo mật: “Dữ liệu nhạy cảm này được bảo vệ như thế nào?”, “Quy trình đặt lại mật khẩu có an toàn không?”, “Làm thế nào để xác thực người dùng khi gọi API X?”.
• Kiểm thử các quy trình nghiệp vụ phức tạp: Tập trung vào các luồng như đăng ký, đăng nhập, đặt lại mật khẩu, thanh toán, thay đổi thông tin nhạy cảm. Suy nghĩ về các kịch bản lạm dụng (abuse cases).
• Kiểm tra các giới hạn: Hệ thống có giới hạn số lần thử đăng nhập sai không? Có yêu cầu mật khẩu mạnh không? Có bước xác nhận email khi đăng ký không?

A05: Security Misconfiguration (Cấu hình bảo mật sai)

Giải thích: Thường là kết quả của việc cấu hình các thiết lập bảo mật không chính xác, sử dụng giá trị mặc định yếu, hoặc không vá lỗi kịp thời trên server, database, framework, hoặc ứng dụng.

Tại sao nguy hiểm: Có thể mở ra cánh cửa cho kẻ tấn công lợi dụng các lỗ hổng đã biết hoặc truy cập vào các tài nguyên không được bảo vệ.

Cách QA có thể kiểm thử:

• Kiểm tra thông báo lỗi chi tiết: Cố ý gây ra lỗi (ví dụ: truy cập URL không tồn tại, nhập sai dữ liệu) để xem ứng dụng có hiển thị thông báo lỗi quá chi tiết, tiết lộ thông tin về server, database, phiên bản phần mềm hay không.
• Kiểm tra các file cấu hình hoặc log (nếu có quyền truy cập): Mặc dù không phổ biến cho Black Box, nhưng nếu có quyền Gray Box, kiểm tra xem có các file cấu hình nhạy cảm hoặc log có thể truy cập công khai hay không.
• Kiểm tra các tiêu đề HTTP (HTTP Headers): Sử dụng Developer Tools để xem các tiêu đề phản hồi (Response Headers). Tìm kiếm các tiêu đề bảo mật bị thiếu hoặc cấu hình sai (ví dụ: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security).
• Thử các đường dẫn/tên file mặc định: Thử truy cập các đường dẫn hoặc tên file cấu hình mặc định phổ biến của các framework hoặc web server (ví dụ: `/admin`, `/backup`, `.env`).

A06: Vulnerable and Outdated Components (Các thành phần dễ bị tấn công và lỗi thời)

Giải thích: Sử dụng các thư viện, framework, và các thành phần phần mềm khác có chứa các lỗ hổng bảo mật đã được công bố công khai (CVEs – Common Vulnerabilities and Exposures) hoặc đã lỗi thời.

Tại sao nguy hiểm: Kẻ tấn công có thể dễ dàng tìm thấy các lỗ hổng đã biết và khai thác chúng.

Cách QA có thể kiểm thử:

• Quan sát thông báo trong Console của trình duyệt: Đôi khi, sử dụng các thư viện lỗi thời có thể hiển thị cảnh báo trong tab “Console” của Developer Tools.
• Hỏi nhóm phát triển: QA có thể đóng vai trò nhắc nhở hoặc hỏi xem nhóm phát triển có thực hiện quét bảo mật các dependency (các thư viện phụ thuộc) hoặc cập nhật chúng thường xuyên không.
• Kiểm tra phiên bản được hiển thị công khai (nếu có): Đôi khi tiêu đề HTTP hoặc mã nguồn trang (View Page Source) có thể tiết lộ phiên bản của framework hoặc thư viện nào đó.

A07: Identification and Authentication Failures (Lỗi xác định và xác thực)

Giải thích: Các lỗ hổng liên quan đến việc xác minh danh tính của người dùng (authentication). Ví dụ: cho phép tấn công Brute Force (thử mật khẩu liên tục), sử dụng thông tin đăng nhập mặc định/yếu, quản lý phiên làm việc (session) không an toàn.

Tại sao nguy hiểm: Cho phép kẻ tấn công mạo danh người dùng hợp pháp.

Cách QA có thể kiểm thử:

• Kiểm thử Brute Force/Credential Stuffing (trong môi trường test và được cho phép): Thử đăng nhập nhiều lần với mật khẩu sai. Hệ thống có khóa tài khoản hoặc giới hạn tốc độ không? (Chỉ thực hiện nếu được đồng ý và trong môi trường test để tránh làm ảnh hưởng hệ thống thật).
• Kiểm tra chính sách mật khẩu: Hệ thống có yêu cầu mật khẩu mạnh (độ dài, ký tự đặc biệt) không? Có cho phép sử dụng mật khẩu phổ biến không?
• Kiểm thử quản lý phiên (Session Management):
  • Sau khi đăng nhập, kiểm tra xem cookie hoặc local storage có chứa thông tin phiên (session ID) không.
  • Thử sao chép cookie/local storage này vào một trình duyệt khác hoặc chế độ ẩn danh (Incognito) để xem có đăng nhập được mà không cần mật khẩu không.
  • Kiểm tra xem phiên có hết hạn sau một thời gian không hoạt động không.
  • Sau khi đăng xuất, kiểm tra xem session ID có bị hủy bỏ (invalidate) trên server không.

A08: Software and Data Integrity Failures (Lỗi về tính toàn vẹn phần mềm và dữ liệu)

Giải thích: Lỗ hổng liên quan đến việc giả định về tính toàn vẹn của phần mềm, dữ liệu, hoặc các quy trình CI/CD mà không có sự kiểm tra đầy đủ. Ví dụ: cập nhật phần mềm không an toàn, deserialize dữ liệu không an toàn, kiểm tra tính toàn vẹn kém đối với dữ liệu tải lên.

Tại sao nguy hiểm: Có thể cho phép kẻ tấn công chèn mã hoặc dữ liệu độc hại, hoặc thay đổi dữ liệu quan trọng mà không bị phát hiện.

Cách QA có thể kiểm thử:

• Kiểm thử chức năng tải lên file: Thử tải lên các loại file không được phép (ví dụ: file thực thi `.exe`, `.php` vào vị trí chỉ cho phép ảnh), hoặc file có kích thước quá lớn, hoặc file chứa mã độc (web shell). Kiểm tra xem ứng dụng có kiểm tra loại file, kích thước, và nội dung file một cách chặt chẽ không.
• Kiểm tra việc kiểm tra dữ liệu ở cả client-side và server-side: Dù input đã được validate ở giao diện người dùng (client-side), hãy thử vượt qua validation đó (sử dụng Developer Tools hoặc proxy) và gửi request với dữ liệu không hợp lệ để xem server có kiểm tra lại không.
• Quan sát các thông báo lỗi khi xử lý dữ liệu đầu vào phức tạp: Đôi khi các lỗi khi xử lý dữ liệu có cấu trúc (như JSON, XML) có thể tiết lộ lỗ hổng deserialization.

A09: Security Logging and Monitoring Failures (Lỗi ghi nhật ký và giám sát bảo mật)

Giải thích: Thiếu hoặc không đủ khả năng ghi nhật ký (logging) các sự kiện bảo mật, giám sát (monitoring) các hoạt động đáng ngờ, và phản ứng kịp thời khi xảy ra sự cố.

Tại sao nguy hiểm: Gây khó khăn cho việc phát hiện, ứng phó và điều tra các cuộc tấn công.

Cách QA có thể kiểm thử:

• Thực hiện các hành động đáng ngờ (trong môi trường test): Thử đăng nhập sai nhiều lần, cố gắng truy cập các trang bị cấm, thử các chuỗi Injection, v.v. Sau đó (nếu có quyền truy cập vào hệ thống log hoặc phối hợp với Dev/Ops), kiểm tra xem các hành động này có được ghi lại trong log không.
• Kiểm tra các thông báo cho người dùng: Khi xảy ra lỗi bảo mật (ví dụ: sai mật khẩu), thông báo có cung cấp đủ thông tin (nhưng không quá chi tiết) để người dùng biết chuyện gì đang xảy ra không?
• Hỏi về quy trình giám sát: Mặc dù không phải là kiểm thử trực tiếp, QA có thể hỏi về việc hệ thống có được giám sát về các hoạt động đáng ngờ hay không. (Điều này liên quan đến các công cụ như Grafana, Kibana, Sentry mà chúng ta đã thảo luận trong bài viết về giám sát lỗi).

A10: Server-Side Request Forgery (SSRF) (Làm giả yêu cầu phía máy chủ)

Giải thích: Xảy ra khi ứng dụng web lấy dữ liệu từ một URL do người dùng cung cấp (ví dụ: nhập URL ảnh để ứng dụng tải về). Kẻ tấn công có thể lợi dụng điều này để buộc server ứng dụng gửi yêu cầu đến một tài nguyên nội bộ hoặc bên ngoài không mong muốn.

Tại sao nguy hiểm: Cho phép kẻ tấn công quét mạng nội bộ, truy cập vào các dịch vụ nội bộ nhạy cảm, hoặc tương tác với các dịch vụ đám mây bằng quyền của server ứng dụng.

Cách QA có thể kiểm thử:

• Kiểm tra các chức năng lấy dữ liệu từ URL: Tìm các chức năng cho phép người dùng nhập URL (ví dụ: nhập URL avatar, nhập URL bài viết để tạo preview).
• Thử nhập các địa chỉ nội bộ hoặc đặc biệt: Thay vì URL bên ngoài, thử nhập các địa chỉ IP nội bộ (ví dụ: `127.0.0.1`, `localhost`, `192.168.1.1`), hoặc các giao thức khác (ví dụ: `file:///etc/passwd` – nếu hệ thống cho phép).

          # Ví dụ thử nhập địa chỉ nội bộ vào trường URL ảnh
          Nhập: http://localhost/admin/dashboard
          

  Quan sát phản ứng của ứng dụng. Nó có trả về nội dung của địa chỉ nội bộ không? Hay báo lỗi?

• Thử nhập các URL trỏ đến các dịch vụ khác trên cùng server hoặc mạng nội bộ.

Tóm tắt OWASP Top 10 và Cách QA Kiểm Thử

Để dễ hình dung, đây là bảng tóm tắt:

Công Cụ Hỗ Trợ QA Trong Kiểm Thử Bảo Mật Cơ Bản

Bạn không nhất thiết phải sử dụng các công cụ quét bảo mật phức tạp như các chuyên gia PenTest. Nhiều công cụ đơn giản và quen thuộc đã đủ để bắt đầu:

• Browser Developer Tools: Tabs như “Elements”, “Console”, và đặc biệt là “Network” là vô giá để kiểm tra request/response, cookie, local storage, và thông báo lỗi.
• OWASP ZAP (Zed Attack Proxy) / Burp Suite Community Edition: Đây là các proxy cho phép bạn chặn, xem, sửa đổi các request/response giữa trình duyệt và server. Phiên bản miễn phí cung cấp các tính năng cơ bản đủ để bạn làm quen với việc kiểm tra luồng dữ liệu và thử các Injection đơn giản. Tuy nhiên, việc sử dụng các công cụ này đòi hỏi tìm hiểu và cẩn thận để tránh gây ảnh hưởng đến môi trường test.
• Browser Extensions: Một số extension đơn giản có thể giúp highlight các trường input hoặc thực hiện các kiểm tra XSS cơ bản, nhưng hãy cẩn trọng khi cài đặt và sử dụng các extension này.

Tích Hợp Kiểm thử Bảo mật vào Quy Trình QA

Đừng coi kiểm thử bảo mật là một hoạt động riêng biệt chỉ diễn ra ở cuối dự án. Hãy tích hợp nó vào quy trình làm việc hàng ngày:

• Trong Lập kế hoạch: Khi viết kế hoạch kiểm thử, cân nhắc các rủi ro bảo mật liên quan đến các tính năng mới hoặc thay đổi. Sử dụng tiếp cận kiểm thử dựa trên rủi ro để ưu tiên các khu vực nhạy cảm.
• Trong Thiết kế Test Case/Scenario: Bên cạnh các bước kiểm thử chức năng, thêm vào các bước kiểm thử “tiêu cực” hoặc “lạm dụng” dựa trên các hạng mục OWASP Top 10 (ví dụ: thử đăng nhập sai, thử nhập ký tự đặc biệt vào input).
• Trong Thực hiện Kiểm thử Thủ công và Tự động: Thực hiện các bước kiểm thử bảo mật đã thiết kế. Đối với kiểm thử tự động (ví dụ: sử dụng Cypress hay Postman cho API), bạn có thể tự động hóa một số kiểm tra cơ bản về Injection hoặc Broken Access Control (ví dụ: gọi API yêu cầu quyền mà không có token).
• Trong Báo cáo lỗi: Khi tìm thấy lỗ hổng bảo mật, báo cáo lỗi một cách rõ ràng, cung cấp đủ thông tin để nhà phát triển có thể tái hiện và sửa chữa.
• Phối hợp với nhóm phát triển: Trao đổi cởi mở về các rủi ro bảo mật và cách phòng chống.

Hạn Chế và Bước Tiếp Theo

Bài viết này chỉ là bước khởi đầu. Kiến thức về OWASP Top 10 giúp bạn có cái nhìn tổng quan về các rủi ro phổ biến, nhưng kiểm thử bảo mật là một lĩnh vực rộng lớn và luôn thay đổi.

• QA không phải là chuyên gia bảo mật: Vai trò của QA là phát hiện các lỗ hổng rõ ràng hoặc phổ biến thông qua việc kiểm thử ở mức độ ứng dụng. Các cuộc tấn công phức tạp hoặc yêu cầu kiến thức chuyên sâu hơn thường cần đến PenTester.
• Luôn cập nhật kiến thức: OWASP Top 10 được cập nhật, các lỗ hổng mới liên tục xuất hiện.
• Học hỏi thêm về công cụ: Nếu có cơ hội, tìm hiểu sâu hơn về cách sử dụng ZAP hoặc Burp Suite để thực hiện các kiểm tra nâng cao hơn trong môi trường test.
• Tìm hiểu về các lĩnh vực bảo mật khác: Bên cạnh web application, còn có bảo mật di động, bảo mật API, bảo mật mạng, v.v.

Kết Luận

Kiểm thử bảo mật không còn là một lựa chọn mà là một yêu cầu thiết yếu đối với Kỹ sư QA hiện đại. Bằng cách làm quen với OWASP Top 10 và áp dụng tư duy kiểm thử để tìm kiếm các lỗ hổng phổ biến, bạn đã thêm một kỹ năng vô cùng giá trị vào bộ công cụ của mình và đóng góp trực tiếp vào việc xây dựng những ứng dụng an toàn hơn.

Hãy bắt đầu áp dụng những kiến thức này vào công việc hàng ngày. Quan sát các chức năng dưới góc độ bảo mật, thử những kịch bản “lạm dụng” đơn giản, và bạn sẽ ngạc nhiên về những gì mình có thể tìm thấy.

Kiểm thử bảo mật là một hành trình học hỏi liên tục. Đừng ngại đặt câu hỏi, tìm tòi, và thực hành. Từng bước nhỏ bạn thực hiện sẽ giúp ứng dụng của bạn mạnh mẽ hơn trước các mối đe dọa từ thế giới số.

Trong bài viết tiếp theo của Lộ trình Kỹ sư QA, chúng ta có thể sẽ khám phá sâu hơn về các loại kiểm thử phi chức năng khác như kiểm thử hiệu năng, hoặc đi sâu hơn vào tự động hóa kiểm thử backend. Hãy cùng chờ đón!

Cảm ơn bạn đã đồng hành!