Lộ trình Kỹ sư QA (Tester): Kiểm thử Bảo mật Cơ bản cho Kỹ sư QA

Tại sao Kỹ sư QA cần quan tâm đến Kiểm thử Bảo mật?

Trong thế giới kỹ thuật số ngày càng phức tạp và đầy rẫy các mối đe dọa, bảo mật không còn là trách nhiệm riêng của các chuyên gia bảo mật nữa. Với vai trò là người gác cổng chất lượng cuối cùng trước khi sản phẩm đến tay người dùng, Kỹ sư QA có vị trí độc đáo để phát hiện sớm và ngăn chặn nhiều lỗ hổng bảo mật tiềm ẩn. Việc tích hợp các nguyên tắc và kỹ thuật kiểm thử bảo mật cơ bản vào quy trình làm việc hàng ngày không chỉ nâng cao chất lượng sản phẩm mà còn giúp giảm thiểu rủi ro pháp lý, tài chính và uy tín cho tổ chức.

Kiểm thử bảo mật đối với QA không nhất thiết phải biến bạn thành một hacker mũ trắng. Nó tập trung vào việc hiểu các mối đe dọa phổ biến, tư duy phản biện về cách kẻ tấn công có thể lạm dụng các chức năng của ứng dụng, và áp dụng các kỹ thuật kiểm thử để tìm ra những điểm yếu cơ bản. Giống như khi bạn phát triển tư duy của một người kiểm thử để tìm ra lỗi chức năng hay phi chức năng (Kiểm thử Chức năng vs Kiểm thử Phi Chức năng), bạn cũng cần áp dụng tư duy đó cho khía cạnh bảo mật.

Trong Lộ trình học Kỹ sư QA, việc làm quen với các khái niệm bảo mật cơ bản là một bước tiến quan trọng, đặc biệt khi các mô hình phát triển Agile (Các Mô Hình SDLC, Vai trò của Kỹ sư QA trong Agile) ngày càng phổ biến, đòi hỏi bảo mật phải được xem xét liên tục, không chỉ ở giai đoạn cuối.

Các Mối đe dọa Bảo mật Phổ biến mà Kỹ sư QA nên biết

Bạn không cần phải là một chuyên gia bảo mật để nhận biết các mối đe dọa phổ biến. Tổ chức OWASP (Open Web Application Security Project) cung cấp một danh sách các rủi ro bảo mật hàng đầu cho ứng dụng web, gọi là OWASP Top 10. Việc nắm vững các mục trong danh sách này sẽ giúp bạn có cái nhìn tổng quan về những gì cần tìm kiếm. Dưới đây là một số điểm phổ biến mà Kỹ sư QA có thể dễ dàng bắt gặp:

Injection (Tiêm nhiễm)

Đây là khi dữ liệu độc hại được gửi đến ứng dụng, khiến nó thực thi các lệnh không mong muốn. Phổ biến nhất là SQL Injection (tấn công cơ sở dữ liệu) và Cross-Site Scripting (XSS) (tiêm nhiễm mã độc vào trình duyệt người dùng).

Ví dụ đơn giản cho SQL Injection: Thay vì nhập tên người dùng thông thường, kẻ tấn công nhập `’ OR ‘1’=’1`. Nếu ứng dụng không xử lý dữ liệu đầu vào cẩn thận, câu lệnh SQL có thể trở thành:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'

Phần `’1’=’1’` luôn đúng, do đó, kẻ tấn công có thể đăng nhập mà không cần mật khẩu hợp lệ.

Ví dụ đơn giản cho XSS: Kẻ tấn công nhập một đoạn mã JavaScript vào một trường nhập liệu, ví dụ: ``. Nếu ứng dụng hiển thị nội dung này mà không mã hóa hoặc lọc, mã JavaScript sẽ được chạy trong trình duyệt của người dùng khác khi họ xem nội dung đó.

Broken Authentication (Xác thực bị hỏng)

Các lỗ hổng liên quan đến chức năng xác thực và quản lý phiên làm việc, cho phép kẻ tấn công giả mạo danh tính của người dùng khác. Điều này bao gồm mật khẩu yếu, quản lý phiên không an toàn, cho phép tấn công Brute Force, v.v.

Sensitive Data Exposure (Lộ dữ liệu nhạy cảm)

Ứng dụng không bảo vệ dữ liệu nhạy cảm (thông tin cá nhân, tài chính, mật khẩu) một cách đầy đủ. Dữ liệu có thể bị lộ trong quá trình truyền tải (không dùng HTTPS) hoặc lưu trữ (không mã hóa).

Broken Access Control (Kiểm soát truy cập bị hỏng)

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ị chỉ bằng cách thay đổi URL, hoặc người dùng A có thể xem hồ sơ của người dùng B chỉ bằng cách thay đổi ID trong URL.

Cross-Site Scripting (XSS)

Đã đề cập ở phần Injection, đây là một loại tấn công phổ biến. Kẻ tấn công tiêm mã độc (thường là JavaScript) vào các trang web mà người dùng khác truy cập. Mã này có thể đánh cắp cookie phiên, chuyển hướng người dùng đến trang web lừa đảo, hoặc thực hiện các hành động thay mặt người dùng.

Insecure Deserialization (Deserialization không an toàn)

Khi ứng dụng deserial hóa dữ liệu không đáng tin cậy, điều này có thể dẫn đến việc thực thi mã từ xa, tấn công replay, hoặc tấn công injection.

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

Ứng dụng không ghi lại các sự kiện bảo mật quan trọng hoặc không giám sát đầy đủ các hoạt động đáng ngờ, khiến việc phát hiện và phản ứng với các cuộc tấn công trở nên khó khăn.

Kiểm thử Bảo mật Cơ bản mà Kỹ sư QA có thể Thực hiện

Kỹ sư QA có thể đóng góp vào bảo mật bằng cách tích hợp các kiểm thử bảo mật cơ bản vào quy trình kiểm thử thủ công và tự động thông thường của mình. Dưới đây là một số kỹ thuật và điểm kiểm tra:

Kiểm thử Đầu vào (Input Validation Testing)

Đây là một trong những biện pháp phòng thủ cơ bản nhất. Hãy kiểm tra cách ứng dụng xử lý dữ liệu đầu vào trong tất cả các trường nhập liệu (text fields, dropdowns, file uploads, URL parameters, hidden fields, cookies).

• Thử các ký tự đặc biệt: Nhập các ký tự như `’`, `”`, `;`, `–`, `<`, `>`, `&`, `|`, `(`, `)`, `[`, `]`, `{`, `}`, `\`, `/`, `#` vào các trường. Xem ứng dụng phản ứng thế nào. Có lỗi SQL xuất hiện không? Mã HTML/JavaScript có bị hiển thị nguyên văn hay được xử lý an toàn (escape/sanitize)?
• Thử các chuỗi injection cơ bản:
  • SQL Injection: `’ OR ‘1’=’1`, `” OR “1”=”1`, `’) OR (‘1’=’1`, `’ UNION SELECT null, null, null –`
  • XSS: ``, ``, `

  Nhập các chuỗi này vào các trường văn bản, URL, tên file, v.v.

• Kiểm tra giới hạn và định dạng: Vượt quá độ dài tối đa cho phép, nhập các kiểu dữ liệu sai (số vào trường chữ, chữ vào trường số), nhập dữ liệu với định dạng không hợp lệ (email sai định dạng). Đảm bảo ứng dụng xử lý các trường hợp này một cách an toàn, không để lộ thông báo lỗi chi tiết về cấu trúc hệ thống.

Kiểm thử Xác thực (Authentication Testing)

Kiểm tra tất cả các khía cạnh của quá trình đăng nhập và đăng ký.

• Thử các kịch bản đăng nhập thất bại:
  • Tên người dùng đúng, mật khẩu sai.
  • Tên người dùng sai, mật khẩu đúng.
  • Tên người dùng sai, mật khẩu sai.
  • Để trống cả hai trường.
  • Sử dụng các ký tự đặc biệt trong tên người dùng/mật khẩu.

  Kiểm tra thông báo lỗi. Thông báo lỗi có chung chung (“Tên đăng nhập hoặc mật khẩu không đúng”) hay tiết lộ chi tiết (ví dụ: “Người dùng không tồn tại”)? Thông báo chung chung an toàn hơn.

• Kiểm tra chức năng Quên mật khẩu: Quy trình có an toàn không? Link reset mật khẩu có hết hạn sau một lần sử dụng hoặc sau một khoảng thời gian nhất định không? Có thể đoán được token reset không?
• Thử tấn công Brute Force (một cách có kiểm soát): Sau bao nhiêu lần đăng nhập sai thì tài khoản bị khóa hoặc yêu cầu mã xác minh bổ sung? Hệ thống có giới hạn tốc độ thử không?
• Kiểm tra Đăng ký: Có thể tạo nhiều tài khoản với cùng một email/tên người dùng không? Có thể sử dụng các ký tự đặc biệt trong thông tin đăng ký không?

Kiểm thử Ủy quyền (Authorization Testing)

Sau khi đăng nhập, kiểm tra xem người dùng có thể truy cập vào những tài nguyên hoặc chức năng mà họ không có quyền hay không.

• Đăng nhập bằng tài khoản người dùng thường. Thử truy cập trực tiếp các URL dành cho quản trị viên hoặc người dùng có vai trò khác.
• Thử truy cập dữ liệu của người dùng khác bằng cách thay đổi ID trong URL hoặc các request API (ví dụ: từ `/users/123` sang `/users/456`).
• Kiểm tra các nút, menu, chức năng mà lẽ ra người dùng không có quyền không bị hiển thị, hoặc nếu cố gắng truy cập thì nhận được thông báo lỗi phù hợp (ví dụ: “Bạn không có quyền truy cập”).

Kiểm thử Quản lý Phiên (Session Management Testing)

Kiểm tra cách ứng dụng quản lý trạng thái đăng nhập của người dùng.

• Sau khi đăng xuất, nhấn nút Back của trình duyệt. Bạn có thể quay lại các trang yêu cầu đăng nhập trước đó không? Nếu có, nội dung có hiển thị hay yêu cầu đăng nhập lại?
• Đăng nhập trên một trình duyệt/thiết bị, sau đó thử đăng nhập trên trình duyệt/thiết bị khác. Phiên làm việc trước có bị vô hiệu hóa không?
• Đóng trình duyệt mà không đăng xuất. Phiên làm việc kéo dài bao lâu? Cookie phiên có được đánh dấu là `HttpOnly` và `Secure` không (có thể kiểm tra bằng Developer Tools)?

Kiểm thử Xử lý Dữ liệu Nhạy cảm

Xác định dữ liệu nào là nhạy cảm (mật khẩu, số thẻ tín dụng, thông tin cá nhân).

• Kiểm tra xem dữ liệu này có được truyền qua kết nối an toàn (HTTPS) không. Có thể kiểm tra bằng cách xem URL (có `https://`) và biểu tượng khóa trên trình duyệt.
• Kiểm tra xem dữ liệu nhạy cảm có được lưu trữ dưới dạng văn bản thuần trong cơ sở dữ liệu hoặc log file không (điều này thường cần sự hỗ trợ của dev hoặc access vào môi trường dev/test).
• Mật khẩu có được hiển thị dưới dạng dấu chấm/sao khi nhập không?

Kiểm thử Xử lý Lỗi (Error Handling)

Kiểm tra các thông báo lỗi của ứng dụng.

• Khi gặp lỗi (ví dụ: nhập dữ liệu sai, truy cập tài nguyên không tồn tại), thông báo lỗi có cung cấp quá nhiều chi tiết kỹ thuật (ví dụ: stack trace, tên cơ sở dữ liệu, câu lệnh SQL) không? Thông tin này có thể bị kẻ tấn công lạm dụng.
• Đảm bảo thông báo lỗi thân thiện với người dùng nhưng không tiết lộ cấu trúc nội bộ.

Công cụ Hỗ trợ Cơ bản cho Kỹ sư QA

Bạn không cần các công cụ phức tạp để bắt đầu kiểm thử bảo mật cơ bản.

• Browser Developer Tools: Trình duyệt hiện đại cung cấp các công cụ mạnh mẽ. Bạn có thể xem và chỉnh sửa HTTP requests/responses, kiểm tra cookie, xem mã nguồn HTML để tìm các dấu hiệu XSS, kiểm tra việc sử dụng HTTPS.
• OWASP ZAP (Zed Attack Proxy): Đây là một công cụ miễn phí, mã nguồn mở rất phổ biến. Đối với QA mới bắt đầu, bạn có thể sử dụng nó ở chế độ “Passive Scan” (Quét thụ động) để ZAP lắng nghe lưu lượng truy cập giữa trình duyệt và ứng dụng của bạn khi bạn thực hiện các kiểm thử chức năng thông thường. ZAP sẽ tự động báo cáo các vấn đề bảo mật mà nó phát hiện được từ lưu lượng này. Điều này không yêu cầu bạn phải biết cách tấn công phức tạp mà chỉ cần chạy ZAP trong khi bạn làm việc bình thường.
• Công cụ kiểm tra HTTP request/response: Các công cụ như Postman hoặc Insomnia rất hữu ích để gửi các request tùy chỉnh và kiểm tra phản hồi của ứng dụng, giúp bạn dễ dàng thử nghiệm các trường hợp injection hoặc kiểm tra ủy quyền bằng cách thay đổi tham số request.

Việc làm quen với các công cụ này sẽ nâng cao khả năng của bạn trong việc phát hiện các vấn đề, tương tự như khi bạn học cách viết Test Case hiệu quả hay báo cáo lỗi chi tiết.

Tích hợp Kiểm thử Bảo mật vào Quy trình SDLC và Agile

Bảo mật nên được xem xét trong suốt vòng đời phát triển phần mềm (SDLC), không chỉ ở giai đoạn cuối. Trong môi trường Agile, điều này càng trở nên quan trọng. QA có thể:

1. Tham gia thảo luận yêu cầu: Ngay từ đầu sprint hoặc khi phân tích user story, hãy đặt câu hỏi về khía cạnh bảo mật. Dữ liệu nào là nhạy cảm? Ai có quyền truy cập chức năng này? Làm thế nào để ngăn chặn lạm dụng?
2. Viết Test Case bảo mật cơ bản: Tích hợp các kiểm tra đầu vào, xác thực, ủy quyền vào các Test Case chức năng thông thường của bạn.
3. Thực hiện các kiểm thử bảo mật cơ bản trong mỗi sprint: Không chờ đến cuối dự án. Kiểm tra các chức năng mới triển khai xem có lỗ hổng cơ bản nào không.
4. Phối hợp với Developer: Trao đổi với developer về các lỗ hổng tiềm ẩn bạn tìm thấy. Hiểu cách họ xử lý dữ liệu đầu vào, xác thực, và quản lý phiên giúp bạn kiểm thử hiệu quả hơn. Điều này cũng liên quan đến sự khác biệt giữa Verification và Validation – QA có thể giúp verification việc developer tuân thủ các quy tắc mã hóa an toàn và validation xem ứng dụng có thực sự an toàn khi sử dụng hay không.

Bảng Tóm Tắt: Mối đe dọa & Kiểm thử Cơ bản cho QA

Để dễ hình dung, đây là bảng tóm tắt một số mối đe dọa phổ biến và các loại kiểm thử cơ bản mà Kỹ sư QA có thể thực hiện:

Hợp tác là Chìa khóa

Kiểm thử bảo mật không phải là một hoạt động biệt lập. QA cần hợp tác chặt chẽ với các bên liên quan:

• Developer: Trao đổi về các lỗ hổng tìm thấy, hiểu cách họ cài đặt các biện pháp bảo vệ (mã hóa đầu vào, sử dụng parameterized queries, v.v.). Dev là tuyến phòng thủ đầu tiên.
• Business Analyst/Product Owner: Đảm bảo các yêu cầu bảo mật được định nghĩa rõ ràng ngay từ đầu.
• Chuyên gia Bảo mật (nếu có): Học hỏi từ họ, hiểu rõ hơn về các rủi ro và kỹ thuật kiểm thử nâng cao. Chuyên gia bảo mật thường thực hiện Penetration Testing (kiểm thử xâm nhập) ở mức độ sâu hơn nhiều so với QA cơ bản. QA có thể hỗ trợ bằng cách cung cấp kiến thức về luồng chức năng của ứng dụng.

Việc này giúp xây dựng văn hóa “bảo mật là trách nhiệm của mọi người”, tương tự như cách chúng ta cùng nhau chịu trách nhiệm về chất lượng tổng thể của sản phẩm.

Học hỏi và Nâng cao

Thế giới bảo mật thay đổi rất nhanh. Là một Kỹ sư QA, việc không ngừng học hỏi là rất quan trọng.

• Theo dõi các nguồn thông tin bảo mật uy tín (OWASP, các blog bảo mật).
• Tham gia các khóa học hoặc webinar về bảo mật ứng dụng cơ bản.
• Thực hành trên các ứng dụng thử nghiệm được thiết kế có lỗ hổng (ví dụ: OWASP Juice Shop).
• Tìm hiểu 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, vì đôi khi hiệu năng kém cũng có thể là dấu hiệu của các vấn đề bảo mật (ví dụ: truy vấn cơ sở dữ liệu không hiệu quả do tấn công).

Kết luận

Kiểm thử bảo mật cơ bản là một kỹ năng ngày càng thiết yếu cho mọi Kỹ sư QA. Bằng cách hiểu các mối đe dọa phổ biến, áp dụng tư duy phản biện và tích hợp các kỹ thuật kiểm thử đơn giản vào quy trình làm việc hàng ngày, bạn có thể đóng góp đáng kể vào việc xây dựng các sản phẩm phần mềm an toàn và đáng tin cậy hơn. Điều này không chỉ giúp bạn trở thành một QA giỏi hơn mà còn mở rộng cơ hội phát triển sự nghiệp trong lĩnh vực đang rất được quan tâm này. Hãy bắt đầu từ những điều cơ bản, thực hành thường xuyên và không ngừng học hỏi. Con đường trở thành một Kỹ sư QA toàn diện luôn đòi hỏi sự đa dạng trong kiến thức và kỹ năng. Chúc bạn thành công trên chặng đường Lộ trình Kỹ sư QA của mình!