Kiểm thử hiệu năng và kiểm thử bảo mật

Kiểm thử hiệu năng và kiểm thử bảo mật là những loại kiểm thử đặc biệt (cả về phương pháp thực hiện và người thực hiện, thường sẽ có một đội QA riêng care về mảng này), là một phương pháp khá khó và đòi hỏi nhiều kiến thức chuyên môn sâu rộng của tester. Ngay cả với những tester có thâm niên kinh nghiệm thì đây cũng là một thử thách và đòi hỏi họ phải chuyên môn hóa trong phương pháp kiểm thử này. App của bạn làm ra có thể rất bắt mắt, logic nghiệp vụ tốt, tiện lợi mang đến sự hài lòng cho người sử dụng... Nhưng chưa chắc là nó đã đáp ứng được các yêu cầu của Kiểm thử hiệu năng (hiệu năng, khả năng chịu tải và mức độ đáp ứng request...) và Kiểm thử bảo mật (bảo mật thông tin, dữ liệu người dùng...). Các vấn đề này thật sự chỉ phát sinh khi app được đưa vào sử dụng thực tế với hàng ngàn user, hàng ngàn connection trong cùng 1 lúc hoặc các hacker tấn công app của bạn hàng ngày hàng giờ... vấn đề tiềm ẩn mà 1 tester trong quá trình test thông thường thì không thể nhận ra được.

Bug về Kiểm thử hiệu năng và Kiểm thử bảo mật không ảnh hưởng tới nghiệp vụ nhưng nó ảnh hưởng rất lớn tới hiệu suất của app và sự hài lòng của người dùng đối với ứng dụng của bạn. Thử hình dung xem khách hàng sẽ phản ứng như thế nào khi họ vào ứng dụng của bạn thường xuyên phải chịu đựng cảnh màn hình trong trạng thái loading vô thời hạn, không thể submit hoặc view bất cứ thứ gì hoặc thông tin của họ bị ăn cắp và là đích đến của 1 loạt các tin rác hoặc tệ hơn là bị mất tiền vì thông tin tài khoản ngân hàng bị lộ.... mất thời gian vào những thứ không đâu, nhận được sự bực bội... Liệu họ có muốn tiếp tục sử dụng ứng dụng của bạn nữa hay không? Mà bạn biết rồi đấy, một ứng dụng dù có hay đến đâu mà không có người dùng thì cũng là một ứng dụng bỏ đi. Chúng ta sẽ cùng đi tìm hiểu về chúng nhé (len)

I. Kiểm thử hiệu năng (performance testing)

1. Tìm hiểu chung

Kiểm thử hiệu năng được thực hiện để xác định hệ thống hoặc hệ thống con thực hiện một khối lượng công việc cụ thể nhanh thế nào. Nó cũng có thể dùng để xác nhận và xác minh những thuộc tính chất lượng khác của hệ thống như là khả năng mở rộng, độ tin cậy và sử dụng tài nguyên. Kiểm thử hiệu năng là một phương pháp khá khó và đòi hỏi nhiều kiến thức chuyên môn sâu rộng của tester. Ngay cả với những tester có thâm niên kinh nghiệm thì đây cũng là một thử thách và đòi hỏi họ phải chuyên môn hóa trong phương pháp kiểm thử này:

• Ứng dụng web phải được duy trì với tải lớn. Kiểm thử hiệu năng bao gồm 1 số loại như :

  • Kiểm thử tải (Load testing) : kiểm thử hiệu năng của ứng dụng với các tốc độ kết nối mạng khác nhau. Kiểm thử khi có nhiều người dùng cùng truy cập hoặc cùng yêu cầu một trang xem hệ thống có thể duy trì hoạt động được không? Hoặc kiểm thử khi người dùng tải lên hoặc tải xuống một số lượng dữ liệu đặc biệt lớn…
  • Kiểm thử áp lực (Stress testing) : tức là việc đẩy hệ thống ra ngoài giới hạn của nó, thử làm gián đoạn trang web bằng cách tăng lượng tải cao hơn và kiểm tra xem hệ thống phản ứng như thế nào và phục hồi như thế nào.
  • Volume testing : đề cập tới việc kiểm thử phần mềm ứng dụng với một lượng dữ liệu nhất định. Số lượng này có thể là kích thước cơ sở dữ liệu hoặc nó cũng có thể là kích thước của 1 tập tin giao tiếp là đối tượng của volume testing (định nghĩa trong các thuật ngữ chung). Ví dụ : nếu bạn muốn thực hiện test volume cho ứng dụng của bạn với kích thước DB cụ thể, bạn sẽ mở rộng DB của bạn tới một kích thước này rồi thực hiện kiểm thử hiệu năng của ứng dụng trên DB đó. Một ví dụ khác là khi có những yêu cầu ứng dụng của bạn tương tác với một tệp tin giao tiếp (có thể bất cứ file nào như là .dat, .xml) những tương tác này có thể là đọc và/hoặc viết trên file. Bạn sẽ tạo một file mẫu có kích thước bạn muốn và sau đó test chức năng của ứng dụng với file đó để test hiệu năng.

  Load testing là khái niệm chủ yếu của việc kiểm thử mà có thể tiếp tục hoạt động ở một mức tải cụ thể, cho dù đó là một lượng lớn dữ liệu hoặc lượng lớn người sử dụng. Cái này gọi chung là khả năng mở rộng của phần mềm. Hoạt động load testing liên quan khi thực hiện hoạt động phi chức năng thường được gọi là kiểm thử sức chịu đựng (độ bền). Volume testing (kiểm tra khối lượng) là một cách kiểm tra chức năng. Stress testing là một cách để kiểm tra (độ) tính tin cậy. Load testing là một cách để kiểm tra hiệu năng. Đây là mốt số thỏa thuận về các mục tiêu cụ thể của performance testing. Những thuật ngữ như load testing, performance testing, reliability testing, và volume testing thường sử dụng thay thế cho nhau.

• Kiểm thử hiệu năng ứng dụng với các tốc độ kết nối mạng khác nhau.

  • Trong kiểm thử tải phải kiểm tra xem khi có nhiều người dùng cùng truy cập hoặc cùng yêu cầu một trang thì sao? Hệ thống có thể duy trì hoạt động trong giờ bận được không? Trang web phải nắm bắt được nhiều yêu cầu đồng thời của người dùng, dữ liệu đầu vào lớn từ các người dùng, kết nối đồng bộ với DB, tải lớn trên các trang đặc biệt…
  • Kiểm thử chịu tải: Thông thường stress test có nghĩa là đẩy hệ thống vượt ra ngoài giới hạn của nó. Kiểm thử chịu tải một trang web là làm gián đoạn trang web đó bằng cách tăng lượng tải cao hơn và kiểm tra xem hệ thống phản ứng lại với từng mức tải cụ thể đó như thế nào? Hệ thống phục hồi lại như thế nào? Tải có thể nhận dữ liệu đầu vào từ các phần đăng nhập, đăng ký, seach…
  • Trong kiểm thử hiệu năng web, các chức năng của trang web trên các hệ điều hành, các nền tảng phần cứng khác nhau phải được kiểm tra để tìm ra các lỗi phần mềm, thất thoát bộ nhớ…

Các yếu tố ảnh hưởng đến load test:

• Việc lập kế hoạch: Kế hoạch được vạch ra rõ ràng sẽ cho ta một kết quả khả quan, ngược lại nếu phức tạp sẽ cho ta kết quả của nó có xu hướng rối rắm.
• Mục tiêu được đặt ra: ta sẽ có câu trả lời rõ ràng.
• Kỹ năng của tester.
• Môi trường thử nghiệm kiểm thử tải
• Cơ sở dữ liệu: Trong môi trường kiểm thử, cơ sở dữ liệu phải được nạp sẵn hoặc là một bản sao của dữ liệu hiện hành hoặc là dữ liệu giả mà nó có kích thước và nội dung như dữ liệu hiện hành
• Công cụ kiểm thử tải: Phải có các tính năng quan trọng như: tham số hóa dữ liệu, nắm bắt các dữ liệu động, theo dõi cơ sở hạ tầng và hỗ trợ nhiều giao thức cho các ứng dụng

Các yếu tố được kiểm thử bởi kiểm thử tải:

• Thời gian đáp ứng
• Tỷ lệ lỗi
• Lưu lượng dữ liệu
• Số yêu cầu trên 1 giây
• Số người dùng đồng thời
• Tài nguyên máy
• ...

2. Một số gợi ý về cách lập kịch bản trong Performence testing

Mỗi ứng dụng web khi xây dựng, dựa vào nhu cầu và khả năng đáp ứng cấu hình host server sẽ có một yêu cầu tối thiểu cho ứng dụng web về các thông số sau: lượng xử lý truy cập cho phép trong cùng 1 lúc (Throughput), thời gian tối thiểu cho mỗi request/response (response time), lưu lượng tối đa truy cập (query) vào server, đường truyền (bandawidth, lag latency) và hiệu suất xử lý back-end (Resource utilization). Để thực hiện load test, bạn cần thu thập yêu cầu tải trọng cho ứng dụng web từ nhà cung cấp và cấu hình host server. Bạn cần giả lập môi trường cài đặt ứng dụng web và học cách dùng performance tool để giả lập các lưu lượng truy cập (Vd: LoadRunner, Jmeter). Để vượt qua loại test này, ứng dụng web cần chạy đúng và không xảy ra lỗi trong tất cả function được test với giả lập trọng tải bằng hoặc dưới yêu cầu tối thiểu.

Ví dụ : Kiểm thử load test cho Website A: cho 100user login cùng lúc, sau đó thử 200user, 500user, 1000user,... và xem kết quả xử lý của website: thời gian đáp ứng bao nhiêu ms, mỗi user thực hiện một chức năng khác nhau => có chức năng nào không đáp ứng được hay không? có xảy ra lỗi gì hay không?...

Việc thực hiện Performance/Load test có nhiều mục đích khác nhau, và tùy thuộc vào từng mục đích, ta xây dựng các scenario các kịch bản, tình huống). Nguyên tắc cơ bản của việc xây dựng scenario cho performance testing sẽ thông qua một ví dụ thực tế về Load testing, để từ đó có những gợi ý cho việc xây dựng scenario cho các loại test khác

Chúng ta hãy phân tích trường hợp của một web site bán sách qua mạng. Sau đây là một số chức năng đã được hiện thực trong web site này:

• Khách hàng vãng lai (unregistered client) có thể truy cập web site để xem trưng bày của các cuốn sách mới nhất của cửa hàng mà không cần phải login vào. Khách hàng loại này vẫn có thể truy cập tới giới thiệu chi tiết của cuốn sách.

• Khách hàng đăng ký (registered client) có chức năng như khách hàng vãng lai, nhưng khi login vào hệ thống, có thể tra cứu các loại sách khác, xem một số chương mẫu của cuốn sách trước khi quyết định mua (add to cart) và thanh toán.

Xét về phương diện hành xử (behavior) của người sử dụng chúng ta có thể hình dung có những trường hợp sau:

Case 1: Người dùng truy cập vào trang chủ của web site, chỉ xem lướt các đầu sách trưng bày tại đây, cùng lắm là xem chi tiết phần brief description của 1, 2 cuốn sách rồi rời site.

Case 2: Người dùng truy cập vào web site, register một tài khoản của web site.

Case 3: Người dùng vào web site, login để tìm kiếm một số cuốn sách mà họ đang cần. Sau khi search xong, tìm hiểu, họ quyết định không mua, log out khỏi hệ thống.

Case 4: Người dùng login vào web site, tìm kiếm, và đặt hàng mua sách.

Case 5: Người dùng login vào web site,, loại bỏ cuốn sách đã đăng ký, không mua nữa.

Case 6: Một cách tổng quát, ta có thể kể tới việc admin site upload sách mới, nội dung lên site, kiểm tra và xử lý đơn hàng, cập nhật hệ thống.

Như vậy đứng về phương diện resource (nguồn) mà hệ thống đáp ứng cho các yêu cầu của người dùng, chúng ta thấy:

• Yêu cầu của khác hàng vãng lai truy cập tới resource của hệ thống ở mức thấp nhất. Nếu chi tiết của cuốn sách được thiết kế tĩnh, đơn giản gắn liền với cuốn sách thì có thể yêu cầu không cần truy cập xuống database, hoặc nếu thiết kế động, thì mức độ truy cập database cũng rất nhỏ, chỉ là retrieve.

• Những khách hàng đăng ký một tài khoản sẽ có thể bao gồm một loạt hành vi liên quan, như khai báo form, account, password, web site kiểm tra security code, gửi email để kích hoạt tài khoản v.v... Các hành vi này liên quan tới resource của web application server, database server.

• Những khách hàng login vào, tìm kiếm qua hệ thống search sẽ chiếm giữ resource của database server khi truy xuất dữ liệu.

• Những khách hàng đi sâu hơn vào việc đặt mua hàng, trả lại hàng sẽ là những trường hợp tiêu tốn nhiều resource nhất. ...

Chúng ta đã xét qua các trường hợp hành xử của khách hàng (danh từ kỹ thuật gọi là các use case), và cũng xét tới mức độ yêu cầu đối với hệ thống của từng hành vi. Giờ chúng ta xét tới sự tương quan giữa chúng với nhau.

Rõ ràng không phải tất cả người dùng truy cập tới web site đều cùng làm một hành vi giống nhau. Sẽ có một tỷ lệ phân bố của các hành vi của người sử dụng, và đó chính là mối tương quan mà ta đang bàn tới. Việc xác định mối tương quan này sẽ quyết định tới hiệu quả của bài toán kinh tế trên thực tế. Việc test hệ thống với mức hành vi tương ứng yêu cầu resource cao chiếm quá nhiều sẽ dẫn tới hệ thống của chúng ta khó thiết kế, và nếu thiết kế được thì đòi hỏi vốn đầu tư không nhỏ, khi sử dụng lại không tiết kiệm.

Để có thể xác định được mối tương quan này, nếu là tiến hành xác định performance của một hệ thống đã vận hành, người ta phân tích history log của web site đó. Khi nhìn vào số liệu, người ta sẽ biết được bao nhiêu % người dùng sẽ tiến hành các hành vi nào trên hệ thống, từ đó, đưa ra tỷ lệ tính toán phù hợp. Ví dụ: 30% khách hàng truy cập web site, không register, không login; 2% người dùng mới register account; 60% khách hàng login để tìm kiếm gì đó, và chỉ có 5% khách hàng đặt mua sách...

Tới đây có thể các bạn sẽ đặt câu hỏi là: Trong trường hợp web site chưa launch không có history log thì sao. Tất nhiên, lúc đó sẽ dựa vào một số số liệu từ các web site cùng loại tương ứng, rồi kết hợp với kế hoạch kinh doanh của đơn vị. Ở đây tôi muốn nhấn mạnh, các giá trị tương quan đưa vào sử dụng có liên quan mật thiết tới bài toán kinh tế. Vì vậy, không thể đưa ra một con số trong ý tưởng, điều mà các nhân viên phòng marketing hay làm, mà không tính toán đến thực tế - những con số "trên trời" có thể đưa tới Load Test/Performance Test thất bại, và thậm chí cả kết quả của dự án - system architect xây dựng hệ thống quá tốn kém do nhu cầu đáp ứng các yêu cầu "không thực tế" này. Việc xây dựng một hệ thống đáp ứng 5000 concurrent user rõ ràng là sẽ khác xa về quy mô khi cần để đáp ứng 8000-10000 concurrent user.

Quay trở lại với mục tiêu của bài viết này, sau khi đã có số liệu tương quan về các hành vi tương tác với hệ thống, chúng ta sẽ dễ dàng phân phối số VUser trong tổng số concurrent user yêu cầu để tạo các scenario. 1 scenario trong Performance/Load Test là một chuỗi các hành vi tương tác với hệ thống từ lúc người dùng truy cập hệ thống cho tới khi họ rời khỏi hệ thống.

Áp dụng cho các trường hợp minh họa ở trên với các case, ta có thể có các trừơng hợp để test như sau đối với 5000VUser chẳng hạn:

Trường hợp / Functions / VUsers

Case 1 / Access --> [Details] / 1500 Case 2 / Access --> Acc_Registering / 100 Case 3 / Access --> Login --> Search -->[Demo_View] --> Logout / 3000 Case 4 / Access --> Login --> Search -->[Demo_View] --> Add_to_Cart --> Logout / 250 ....

Chúng ta có thể có các tập scenario khác nhau để test, tùy theo mục đích test của ta. Ở trên đưa ra minh hoạ cho 1 tập scenario để test trong trường hợp web site vận hành tương tác với người dùng cuối. Nếu việc admin cập nhật hệ thống đòi hỏi tốn nhiều resource, ảnh hưởng hiệu năng của web site, trên thực tế, chúng ta sẽ tiến hành việc udate website vào ban đêm chẳng hạn, thì chúng ta vẫn có thể xây dựng một tập scenario cho việc update hệ thống này với số lượng người dùng cuối truy cập hệ thống vào ban đêm.

Sau khi đã có các scenario, việc ứng dụng tools để triển khai các kịch bản (scripts) có thể phân theo từng function đã phân tích ở trên. Tới lúc triển khai script, sẽ tùy thuộc vào test tool đang sử dụng. Chú ý một điều là các test tool, đều được xây dựng trên một nguyên tắc các scenario chạy đồng thời, tức là các case 1 - 4 ở trên sẽ chạy song song. Còn việc phân kịch bản (script) thành các function để có thể dùng lại hay không tùy thuộc vào tool. Ví dụ: Với Load Runner, ta có thể viết thành function dùng chung - ví dụ, login, logout, add_to_cart...; trong khi đó, ở OpenSTA, chúng ta chỉ có thể viết liên tục - tính khả tái sử dụng trong OpenSTA không có, do hạn chế của tool, việc gọi các function/procedure sẽ gây ra memmory leak.

II. Kiểm thử bảo mật (Security testing)

1. Tại sao phải kiểm tra bảo mật?

Điều gì xảy ra nếu tất cả các tài liệu mật của tổ chức bạn bị đánh cắp, hoặc điều đó xảy ra với một trong những khách hàng của bạn? Một lỗ hổng trong ứng dụng của bạn hoàn toàn có thể làm tê liệt kinh doanh của bạn và danh tiếng của mình trên thị trường. Tất nhiên, điều này có thể dẫn đến thảm họa khi một lỗ hổng trong ứng dụng của bạn được khai thác bởi một bên thứ ba với những hậu quả như:

• Thiệt hại to lớn đến thương hiệu của tổ chức
• Vĩnh viễn mất niềm tin của khách hàng
• Thời gian chết của phần mềm tàn phá năng suất tổ chức - năng suất của tổ chức thời gian sau khi khắc phục thiệt hại
• Chi phí khắc phục lỗ hổng tốn kém
• Các vụ kiện dân sự và hình phạt pháp lý.
• ......... Do đó, một phần mềm mà không có khả năng bảo vệ dữ liệu và không có khả năng duy trì các dữ liệu theo yêu cầu là không thê sử dụng. Security Testing là có thể coi là một trong những thử nghiệm quan trọng nhất đối với một ứng dụng.

2. Tìm hiểu chung

Security là gì? Security là các biện pháp được thiết lập để bảo vệ một ứng dụng chống lại các hành động không lường trước được rằng các hành động đó sẽ ảnh hưởng hoặc phá hủy ứng dụng. Hành động không lường trước có thể là cố ý hoặc vô ý.

Security testing là gì? Security Testing là việc tìm kiếm tất cả cá lỗ hổng có thể và điểm yếu của hệ thống mà có thể dẫn đến mất thông tin trong tay nhân viên hoặc người ngoài của tổ chức. Security Testing rất quan trọng trong ngành công nghiệp CNTT để bảo vệ dữ liệu của tất cả các phương tiện.

Mục đích của Security Testing? Mục đích của Security Testing là để xác định các mối đe dọa trong hệ thống và đo lường rủi ro tiềm năng của nó. Nó cũng giúp trong việc phát hiện các nguy cơ bảo mật có thể có trong hệ thống và giúp các developer trong việc sửa chữa những vấn đề này thông qua code

Một số case cho kiểm thử bảo mật web:

• Mật khẩu phải ở trong định dạng mã hóa
• Gõ trực tiếp url vào thanh địa chỉ của trình duyệt mà không qua đăng nhập. Các trang nội bộ phải không được mở.
• Sau khi đăng nhập và mở các trang nội bộ, thay đổi url trực tiếp bằng cách đổi tham số ID của trang tới trang thuộc quyền người dùng đã đăng nhập khác. Truy cập phải bị từ chối bởi người dùng này không thể xem trang thống kê của người dùng khác.
• Thử các giá trị đầu vào không hợp lệ trong các trường username, password. Hệ thống phải báo lỗi.
• Các thư mục web, các tệp tin không được truy nhập trực tiếp mà không có tùy chọn “Download”.
• Kiểm tra CAPTCHA cho các đăng nhập tự động
• Tất cả các phiên giao dịch, các thông báo lỗi, các hành vi cố gắng xâm phạm an ninh phải ghi trong log và lưu tại web server.
• Kiểm tra thời gian cookie và session cho ứng dụng
• Đối với các trang web tài chính, nút Back của Browser lại không nên được hoạt động.
• .........

3. Các phương pháp

Kiểm tra Captcha: Sẽ thế nào nếu một buổi sáng đẹp trời, database của bạn bị sập vì quá tải với hàng trăm ngàn tài khoản ảo được tạo? Đó là điều bạn sẽ thấy khi người ta dùng một công cụ tự động truy cập ứng dụng web của bạn và lặp đi lặp lại việc đăng ký tài khoản. Mã Captcha ra đời để giúp phòng tránh việc này. Hãy bảo đảm hệ thống của bạn được cài đặt Captcha hợp lý để hạn chế việc spam những request nhạy cảm khả dĩ có thể làm hỏng hệ thống (đăng ký tài khoản, đăng nhập…). Tuy nhiên, việc cài đặt nên hạn chế tùy tiện vì chúng sẽ gây phiền phức cho user. Hãy thông báo nếu bạn thấy một function nào đó không được cài đặt Captcha hợp lý.

Kiểm tra việc mã hóa dữ liệu trao đổi: Điều này là tối cần thiết nếu ứng dụng web của bạn có hệ thống tài khoản, thanh toán online hoặc có nhu cầu trao đổi thông tin nhạy cảm với user. Bạn hãy xem gói dữ liệu request/response và đọc chúng để chắc rằng mọi thông tin quan trọng được giấu đi hoặc được mã hóa. Người ngoài không nên dễ dàng xem được hoặc tìm được cách giải mã chúng. Hệ thống có thông tin càng giá trị thì càng cần các biện pháp mã hóa tối tân. Hãy lên danh sách các trường dữ liệu được trao đổi qua hệ thống của bạn, đánh dấu những loại thông tin nhạy cảm và giả lập các tình huống test mà 1 guest (một truy cập lạ) có thể đọc được những thông tin đó. Thêm vào đó hãy liên hệ với đội ngũ developer để hiểu rõ cách nếu ứng dụng web tổ chức mã hóa dữ liệu thế nào và suy nghĩ các điểm yếu có thể. Nếu bạn chỉ mất vài tiếng để tìm ra cách trộm được thông tin, chắc chắn những kẻ xấu cũng vậy.

Kiểm tra SSL và Certificates: Hệ thống SSL (Secure Socket Layer) và Certificate là một biện pháp bảo mật phổ biến nhằm bảo đảm độ tin cậy của ứng dụng web và kênh trao đổi với user. Ta hiểu nôm na chúng như 1 loại chữ ký điện tử để người dùng nhận biết rằng họ đang truy cập một trang web “chính chủ”. Tất cả các website khi đăng ký tên miền thường luôn kèm một Digital Certificate bao gồm 1 số serial và các thông tin cá nhân về tổ chức/doanh nghiệp của họ được đăng ký pháp lý trên hệ thống DNS. Khi một user truy cập vào tên miền đó, thông qua certificate user được bảo đảm rằng họ đã truy cập vào đúng địa chỉ mình cần thay vì một phishing site (những web giả mạo được lập ra với tên miền và giao diện tương đồng với một trang web nào đó nhằm lừa user gửi thông tin của họ đến server giả với mục đích trục lợi). Bạn hãy thu thập các thông tin về Certificate của hệ thống đang test và bảo đảm rằng khi lên live, nếu ứng dụng web của bạn và máy client được thiết lập Trust Certificate đúng và các thông tin được đăng ký chính xác. Hãy thử truy cập vào tên miền với tiếp đầu ngữ “https://…” và “http://…” và xem xét. Một thiết lập đúng sẽ hiện thông điệp về certificate khi bạn dùng “https”.

Kiểm tra việc truy cập tài nguyên thông qua tên miền: Mỗi trang web và tài nguyên trên server (file download, hình ảnh, video…) đều cần được định danh và có thể được truy cập từ client thông qua đường địa chỉ URL (phần ký tự loằng ngoằng phía sau tên miền). Bạn cần bảo đảm user bị chặn truy cập vào tất cả những webpage, những file và thư mục mà họ không được phép truy cập. Ví dụ, giả sử ta có “http://abc.com/lineA/pageA.aspx” là trang web mà hệ thống bạn chỉ dành cho user đã đăng nhập. Bạn hãy thử gõ trực tiếp URL “http://abc.com/lineA/pageA.aspx” vào browser với tư cách một guest (user lạ chưa đăng nhập). Nếu browser truy cập thành công pageA với đầy đủ tính năng, hẳn bạn có 1 bug. Ngoài ra, bạn hãy kiểm tra tất cả các tên định danh của webpage và đường dẫn URL đến các tài nguyên nhạy cảm trên server để bảo đảm chúng không quá phổ thông và dễ đoán. Hãy thử truy cập tài nguyên thông qua 1 số giao thức khác ngoài http (ví dụ : ftp,…) và bảo đảm tất cả giao thức không cần thiết đều được tắt để hạn chế truy cập ngoài ý muốn. Nếu có điều kiện, bạn hãy tìm hiểu về SQL Injection và áp dụng chúng vào việc kiểm thử xem hệ thống có dễ bị tấn công thông qua việc dùng parameter trên URL hay không.

III.