KIỂM THỬ LOGIC NGHIỆP VỤ

BÁO CÁO BÀI TậP LớN ĐỀ TÀI: KIỂM THỬ LOGIC NGHIỆP VỤ   MỤC LỤC MỤC LỤC 1 LỜI MỞ ĐẦU 2 CHƯƠNG I: KIỂM THỬ LOGIC DỮ LIỆU NGHIỆP VỤ HỢP LỆ 3 1. Tóm lược 3 2. Các ví dụ 3 3. Cách kiểm thử 3 4. Các trường hợp kiểm thử liên quan 4 5. Các công cụ sử dụng 4 6. Các tài liệu tham khảo: 4 CHƯƠNG II: KIỂM THỬ KHẢ NĂNG GIẢ MẠO YÊU CẦU 5 1. Tóm lược 5 2. Các ví dụ 5 3. Cách kiểm thử 6 4. Các trường hợp kiểm thử liên quan: 6 5. Các công cụ sử dụng 6 6. Tài liệu tham khảo 6 7. Cách khắc phục 7 CHƯƠNG III: KIỂM THỬ KHẢ NĂNG KIỂM TRA TÍNH TOÀN VẸN 8 1. Tóm lược 8 2. Ví dụ 8 3. Cách kiểm thử 9 4. Các trường hợp kiểm thử liên quan 10 5. Các công cụ sử dụng 10 6. Tài liệu tham khảo 10 7. Cách khắc phục 10 CHƯƠNG IV: KIỂM THỬ THỜI GIAN XỬ LÝ 11 1. Tóm lược 11 2. Ví dụ 11 3. Cách kiểm thử 11 4. Các kiểm thử liên quan 12 5. Cách khắc phục 12 CHƯƠNG V: KIỂM THỬ SỐ LẦN MỘT HÀM ĐƯỢC SỬ DỤNG 13 1. Tóm lược 13 2. Ví dụ 13 3. Cách kiểm thử 13 4. Các kiểm thử liên quan 13 5. Tài liệu tham khảo 13 6. Cách khắc phục 14 CHƯƠNG V: KIỂM THỬ SỰ TẮC NGHẼN TRONG QUY TRÌNH LÀM VIỆC……….. 15 1. Tổng quan 15 2. Ví dụ 15 3. Phương thức kiểm thử 15 4. Cách khắc phục 16 CHƯƠNG VII: KIỂM THỬ CÁC BIỆN PHÁP NGĂN CHẶN VIỆC SỬ DỤNG SAI MỤC ĐÍCH 17 1. Tổng quan 17 2. Ví dụ 17 3. Phương thức kiểm thử 17 CHƯƠNG VIII: KIỂM THỬ QÚA TRÌNH UPLOAD CÁC DẠNG TỆP TIN KHÔNG PHÙ HỢP 19 1. Tổng quan 19 2. Ví dụ 19 3. Phương thức kiểm thử 19 4. Cách khắc phục 20 CHƯƠNG IX: KIỂM THỬ VIỆC TẢI LÊN CÁC TỆP TIN ĐỘC HẠI 21 1. Tổng quan 21 2. Ví dụ 21 3. Cách kiểm thử 21 4. Các trường hợp kiểm thử liên quan 22 5. Các công cụ 22 6. Tài liệu tham khảo 22 7. Cách khắc phục 23 KẾT LUẬN 24 TÀI LIỆU THAM KHẢO 25   LỜI MỞ ĐẦU Ngày nay công nghệ thông tin ngày càng phát triển nhanh chóng, kéo theo đó là hệ thống mạng và các phần mềm cũng tăng nhanh cả về số lượng, quy mô và chất lượng phần mềm theo chiều sâu. Tuy nhiên một vấn đề phát sinh đó chính là những lỗ hổng có thể gây hại đến hệ thống, ứng dụng, có ảnh hưởng nghiêm trọng về kinh tế, xã hội. Trong số rất nhiều các lỗ hổng được nghiên cứu thì lỗ hổng trong việc thiết kế các giải thuật của các hàm xử lý dữ liệu, hàm logic nghiệp vụ thường là những lỗ hỏng khó phát hiện nhất. Thông thường không thể sử dụng các công cụ quét lỗ hổng với những lỗ hổng này. Những lỗ hổng này thường có thể bị các kẻ tấn công lợi dụng để thực hiện nhiều mục đích xấu, có thể ảnh hưởng nghiêm trọng đến hoạt động của hệ thống, kinh tế của doanh nghiệp, tổ chức… Do đó yêu cầu đặt ra là cần có các công tác kiểm thử logic nghiệp vụ để phát hiện và có cách khắc phục kịp thời các lỗ hổng tiềm tàng chưa bị phát hiện. Việc kiểm thử các lỗ hổng trong logic nghiệp vụ được tiến hành tương tự các quá trình kiểm thử khác. Việc kiểm thử lỗ hổng trong logic nghiệp vụ hiện vẫn sử dụng kỹ thuật thủ công, do đó yêu cầu các nhân viên kiểm thử cần có kiến thức chuyên sâu, hiểu biết về các cấu trúc giải thuật của các hàm xử lý, nắm chắc các kỹ thuật kiểm thử. Do còn nhiều hạn chế về thời gian cũng như nhận thức nên bản báo cáo còn nhiều thiếu sót. Rất mong cô và các bạn góp ý. Xin chân thành cảm ơn.   CHƯƠNG I: KIỂM THỬ LOGIC DỮ LIỆU NGHIỆP VỤ HỢP LỆ 1. Tóm lược Ứng dụng phải đảm bảo rằng chỉ có dữ liệu hợp lệ mới có thể vào được điểm đầu cuối giống như chuyển đến phía máy chủ của một ứng dụng trong hệ thống. Chỉ có dữ liệu cục bộ đã được xác minh có thể khiến các ứng dụng dễ bị tấn công máy chủ thông qua các proxy hoặc tại điểm bàn giao với hệ thống khác. Điều này khác với cách biểu diễn đơn giản trong Phân Tích Ranh Giới Giá Trị (Boundary Value Analysis – BVA) . Nó khó hơn so với BVA và trong hầu hết các trường hợp không thể xác mình một cách đơn giản tại điểm vào, nhưng thường gửi yêu cầu kiểm tra một vài hệ thống khác. Ví dụ: Một ứng dụng có thể hỏi số An Sinh Xã Hội của bạn. Trong BVA, ứng dụng nên kiểm tra định dạng và ngữ nghĩa (giá trị có độ dài 9 ký tự, không tiêu cực và không chứa toàn kí tự 0) của dữ liệu đầu vào, nhưng cũng có những cân nhắc về logic. SSNs là các nhóm và các phân loại. Có phải người này đang chứa 1 file chết? Chúng đến từ một phần nhất định trên đất nước? Các lỗ hổng liên quan đến xác nhận dữ liệu kinh doanh là duy nhất, trong trường hợp đó, chúng là các ứng dụng cụ thể và không giống với lỗ hổng liên quan đến giả mạo yêu cầu. Chúng quan tâm nhiều hơn về dữ liệu logic như phá vỡ các logic quy trình làm việc kinh doanh. Điểm đầu và điểm cuối của ứng dụng nên được xác nhận và giữ lại những dữ liệu nó có, đang sử dụng và đã cho qua được coi là hợp lệ. Ngay cả khi người dùng cung cấp dữ liệu hợp lệ đến ứng dụng, logic kinh doanh vẫn có thể khiến các ứng dụng hành động khác, tùy thuộc vào dữ liệu hoặc hoàn cảnh. 2. Các ví dụ Ví dụ 1: Giả sử bạn quản lý một trang web thương mại điện tử nhiều cấp, cho phép người dùng đặt thảm. Người dùng chọn loại thảm họ muốn, chọn kích thước, trả tiền. Sau đó phần mềm phía người dùng sẽ xác nhận các dữ liệu nhập vào là đúng và hợp lệ như thông tin liên lạc, kích thước, màu sắc của thảm. Nhưng, logic kinh doanh chạy ngầm có hai phần, nếu thảm đó còn, nó sẽ được vận chuyển trực tiếp từ kho của bạn; nhưng nếu đã hết, kho của bạn sẽ gọi tới hệ thống của đối tác và nếu họ còn, họ sẽ chuyển hàng và hoàn trả bởi bên đối tác. Điều gì sẽ xảy ra nếu một kẻ tấn công tiếp tục giao dịch một cách hợp lệ và gửi tin đi như là tấm thảm đó đã hết hàng đến đối tác của bạn? Và điều gì sẽ xảy ra nếu một kẻ tấn công đứng ở giữa, gửi yêu cầu đặt thảm đến kho của đối tác mà không trả tiền? Ví dụ 2: Rất nhiều hệ thống thẻ tín dụng đang tải số dư tài khoản cả ban đêm, nên các khách hàng có thể kiểm tra số tiền dưới một giá trị nhất định nhanh hơn. Ngược lại cũng đúng. Nếu tôi sử dụng thẻ tín dụng vào buổi sáng, tôi không thể sử dụng thẻ vào buổi tối. Một ví dụ khác có thể nếu tôi sử dụng thẻ ở nhiều địa điểm một cách nhanh chóng, nó có thể vượt qua các giới hạn của tôi nếu các hệ thống đang dựa vào các dữ liệu từ đêm hôm trước. 3. Cách kiểm thử Phương pháp kiểm thử chung: Xem xét lại các tài liệu của dự án và sử dụng các cuộc khảo sát tìm kiếm các điểm nhập dữ liệu hoặc các điểm giao dịch giữa các hệ thống phầm mềm. Mỗi lần tìm thấy lỗ hổng, hãy cố gắng chèn các dữ liệu không hợp lên vào ứng dụng hoặc hệ thống. Phương pháp kiểm thử riêng: Thực hiện kiểm thử tính năng giao diện người dùng hợp lệ trên ứng dụng để đảm bảo rằng chỉ các giá trị hợp lệ được chấp nhận. Sử dụng một proxy chặn truy cập thực hiện HTTP POSTGET tìm kiếm các địa điểm mà các biến như chi phí và chất lượng được thông qua. Cụ thể, hãy tìm kiếm các handoffs giữa ứng dụng hoặc các hệ thống mà có thể đưa vào các điểm giả mạo. Mỗi biến được tìm thấy bắt đầu tra cứu lĩnh vực với dữ liệu không hợp lệ một cách hợp lý, chẳng hạn như số an sinh xã hội hoặc các số nhận dạng duy nhất không tồn tại hoặc không phù hợp với logic nghiệp vụ. Kiểm thử này xác minh rằng máy chủ hoạt động đúng và không chấp nhận các dữ liệu không hợp lệ về mặt logic. 4. Các trường hợp kiểm thử liên quan Tất cả các trường hợp kiểm thử “Nhập liệu hợp lệ”. Kiểm thử đối với Kiểm toán Tài khoản và Tài khoản Người dùng Cố định (Testing for Account Enumeration and Guessable User Account (OTGIDENT004)). Kiểm thử về lược đồ quản lý các phiên bỏ qua (Testing for Bypassing Session Management Schema (OTGSESS001)). Kiểm thử về các biến phiên bị lộ (Testing for Exposed Session Variables (OTGSESS004)). 5. Các công cụ sử dụng OWASP Zed Attack Proxy (ZAP): ZAP là một công cụ kiểm thử xâm nhập dễ sử dụng, dùng để tìm các lỗ hổng trong các ứng dụng web. Nó được thiết kế để được sử dụng bởi những người có một loạt các kinh nghiệm an ninh và như vậy là lý tưởng cho các nhà phát triển và thử nghiệm chức năng những người mới để kiểm thử xâm nhập. ZAP cung cấp máy quét tự động cũng như một bộ công cụ cho phép bạn tìm các lỗ hổng bảo mật theo cách thủ công. 6. Các tài liệu tham khảo: Beginning Microsoft Visual Studio LightSwitch Development http:hoặchoặcbooks.google.comhoặcbooks?id=x76L_kaTgdECpg=PA280lpg=PA280dq=business+logic+example+valid+data+examplesource=blots=GOfQ7f4Husig=4jOejZVligZOrvjBFRAT4jy8DIhl=ensa=Xei=mydYUt6qEOX54APu7IDgCQved=0CFIQ6AEwBDgKv=onepageq=business%20logic%20example%20valid%20data%20 examplef=false   CHƯƠNG II: KIỂM THỬ KHẢ NĂNG GIẢ MẠO YÊU CẦU 1. Tóm lược Giả mạo yêu cầu là một phương pháp mà kẻ tấn công sử dụng để phá vỡ ứng dụng frontend để gửi trực tiếp thông tin cho backend xử lý. Mục tiêu của kẻ tấn công là gửi các yêu cầu HTTP POSTGET thông qua một proxy được chặn với các giá trị dữ liệu không được hỗ trợ, bảo vệ hoặc dự đoán bởi các ứng dụng logic nghiệp vụ. Một số ví dụ về yêu cầu giả mạo bao gồm khai thác các tham số dự đoán hoặc dự đoán được hoặc để lộ các tính năng và chức năng ẩn như chức năng gỡ lỗi hoặc trình bày màn hình hoặc cửa sổ đặc biệt rất hữu ích trong quá trình phát triển nhưng có thể làm rò rỉ thông tin hoặc bỏ qua logic nghiệp vụ. Các lỗ hổng liên quan đến các khả năng giả mạo yêu cầu là duy nhất cho mỗi ứng dụng và khác với xác nhận dữ liệu logic nghiệp vụ, trong đó nó tập trung vào việc phá vỡ quy trình làm việc logic. Các ứng dụng nên có các kiểm tra logic để ngăn hệ thống chấp nhận các yêu cầu giả mạo, có thể cho phép kẻ tấn công khai thác logic nghiệp vụ, quy trình hoặc luồng của ứng dụng. Yêu cầu giả mạo là không mới. Kẻ tấn công sử dụng một proxy được chặn để gửi các yêu cầu HTTP POSTGET đến ứng dụng. Thông qua yêu cầu giả mạo, kẻ tấn công có thể phá vỡ logic nghiệp vụ hoặc quy trình bằng cách tìm kiếm, dự đoán và vận dụng các tham số để làm cho ứng dụng nghĩ rằng một quá trình hoặc một công việc đã hoặc chưa diễn ra. Ngoài ra, các yêu cầu giả mạo có thể cho phép phân phối luồng logic chương trình hoặc nghiệp vụ bằng cách gọi các tính năng hoặc chức năng ẩn như gỡ lỗi ban đầu được các nhà phát triển và người thử nghiệm sử dụng ban đầu được gọi là quả trứng Phục Sinh (Easter Egg). Một “quả trứng Phục Sinh” là một câu nói đùa có chủ ý, thông điệp ẩn hoặc tính năng trong một tác phẩm như chương trình máy tính, phim, sách hay trò chơi ô chữ. Theo nhà thiết kế trò chơi Warren Robinett, thuật ngữ được đặt ra tại Atari bởi những nhân viên được cảnh báo trước sự hiện diện của một thông điệp bí mật đã được Robinett che dấu trong trò chơi đã được phân phối rộng rãi của ông, Adventure. Tên gọi này đã gợi lên ý tưởng về một cuộc săn bắt trứng Phục Sinh truyền thống. 2. Các ví dụ Ví dụ 1. Giả sử một trang web thương mại điện tử của một rạp hát cho phép người dùng lựa chọn vé, áp dụng một lần triết khấu cao cấp 10% cho toàn bộ của hàng. Nếu một kẻ tấn công có thể nhìn thấy thông qua một proxy rằng ứng dụng có một trường ẩn (1 hoặc 0) được sử dụng bởi logic nghiệp vụ để xác định giảm giá đã được thực hiện hay không. Kẻ tấn công sau đó có thể gửi 1 hoặc không giảm giá đã được thực hiện giá trị nhiều lần để tận dụng lợi thế của cùng một lần giảm giá nhiều lần. Ví dụ 2. Giả sử một trò chơi điện tử trực tuyến trả thẻ cho các điểm ghi được cho việc tìm kho báu, cướp biển và cho mỗi cấp hoàn thành. Những thẻ này sau đó có thể được đổi thành các giải thưởng. Ngoài ra, mỗi điểm của cấp có một giá trị nhân với một mức. Nếu một kẻ tấn công có thể nhìn thấy thông qua một proxy rằng ứng dụng có một lĩnh vực ẩn được sử dụng trong quá trình phát triển và thử nghiệm để nhanh chóng đạt được mức độ cao nhất của trò chơi họ có thể nhanh chóng đạt được mức cao nhất và tích lũy điểm không cần thiết một cách nhanh chóng. Ngoài ra, nếu kẻ tấn công có thể nhìn thấy thông qua một proxy rằng ứng dụng có một trường ẩn được sử dụng trong quá trình phát triển và thử nghiệm để kích hoạt đăng nhập chỉ ra nơi những người chơi trực tuyến khác, hoặc kho báu ẩn trong mối liên hệ với kẻ tấn công, thì họ sẽ có thể nhanh chóng đi đến những địa điểm đó và ghi điểm. 3. Cách kiểm thử Phương pháp kiểm thử chung. • Xem lại tài liệu của dự án và sử dụng các bài kiểm thử thăm dò để tìm các chức năng có thể dự đoán hoặc được ẩn của các trường. • Mỗi lần tìm thấy sẽ cố gắng chèn dữ liệu hợp lệ vào ứng dụnghoặchệ thống cho phép người dùng đi qua ứng dụnghoặchệ thống đối với quy trình logic nghiệp vụ thông thường. Phương pháp kiểm thử cụ thể số 1. • Sử dụng một proxy chặn kết nối theo dõi HTTP POSTGET tìm kiếm một số dấu hiệu cho thấy các giá trị gia tăng ở một khoảng thời gian đều đặn hoặc dễ đoán được. • Nếu phát hiện thấy một số giá trị có thể đoán được, giá trị này có thể thay đổi và người ta có thể nhận được sự hiển thị bất ngờ. Phương pháp kiểm tra cụ thể 2 • Sử dụng một proxy chặn kết nối theo dõi HTTP POSTGET tìm kiếm một số dấu hiệu của các tính năng ẩn như gỡ lỗi có thể được kích hoạt hoặc kích hoạt. • Nếu có bất kỳ tìm thấy cố gắng đoán và thay đổi các giá trị này để có được một phản ứng ứng dụng khác nhau hoặc hành vi 4. Các trường hợp kiểm thử liên quan: • Testing for Exposed Session Variables (OTGSESS004) • Testing for Cross Site Request Forgery (CSRF) (OTGSESS005) • Testing for Account Enumeration and Guessable User Account (OTGIDENT004) 5. Các công cụ sử dụng OWASP Zed Attack Proxy (ZAP) 6. Tài liệu tham khảo Cross Site Request Forgery Legitimizing Forged Requests http:hoặchoặcfragilesecurity.blogspot.comhoặc2012hoặc11hoặccrosssiterequestforgerylegitimazing.html Debugging features which remain present in the final game http:hoặchoặcglitchcity.infohoặcwikihoặcindex.phphoặcList_of_video_games_ with_debugging_featuresDebugging_features_which_ remain_present_in_the_final_game Easter egg: http:hoặchoặcen.wikipedia.orghoặcwikihoặcEaster_egg_(media) Top 10 Software Easter Eggs http:hoặchoặclifehacker.comhoặc371083hoặc top10softwareeastereggs 7. Cách khắc phục Ứng dụng phải đủ thông minh và được thiết kế với logic nghiệp vụ để ngăn chặn kẻ tấn công dự đoán và thao tác các tham số làm hỏng chương trình hoặc luồng logic nghiệp vụ hoặc khai thác các chức năng ẩn hoặc không có tài liệu ví dụ như gỡ lỗi.   CHƯƠNG III: KIỂM THỬ KHẢ NĂNG KIỂM TRA TÍNH TOÀN VẸN 1. Tóm lược Nhiều ứng dụng được thiết kế để hiển thị các trường khác nhau tùy thuộc vào người sử dụng tình huống bằng cách để lại một số đầu vào ẩn. Tuy nhiên, trong nhiều trường hợp, bạn có thể gửi giá trị các giá trị trường ẩn tới máy chủ bằng proxy. Trong các trường hợp này, phía máy chủ điều khiển phải đủ thông minh để thực hiện các mối quan hệ hoặc phía máy chủ sửa đổi để đảm bảo rằng dữ liệu thích hợp được phép tới máy chủ dựa trên logic nghiệp vụ của người dùng và ứng dụng cụ thể. Ngoài ra, ứng dụng không được phụ thuộc vào điều khiển khôngthểchỉnhsửa, trình đơn thả xuống hoặc trường ẩn để xử lý logic nghiệp vụ vì các trường này không thể chỉnh sửa chỉ trong ngữ cảnh của trình duyệt. Người dùng có thể chỉnh sửa các giá trị của họ bằng các công cụ chỉnh sửa proxy và cố gắng vận dụng logic nghiệp vụ. Nếu ứng dụng đưa ra các giá trị liên quan đến các quy tắc kinh doanh như số lượng, v.v. là các trường không thể chỉnh sửa, nó phải duy trì một bản sao phía máy chủ và sử dụng tương tự để xử lý logic nghiệp vụ. Cuối cùng, ứng dụnghoặcdữ liệu hệ thống, các hệ thống đăng nhập phải được bảo đảm để ngăn chặn đọc, viết và cập nhật. Các lỗ hổng kiểm tra tính toàn vẹn của logic nghiệp vụ là duy nhất trong các trường hợp lạm dụng này là ứng dụng cụ thể và nếu người dùng có thể thực hiện thay đổi thì chỉ có thể viết hoặc cập nhật chỉnh sửa các hiện vật cụ thể vào những thời điểm cụ thể theo logic quy trình nghiệp vụ. Ứng dụng phải đủ thông minh để kiểm tra các chỉnh sửa quan trọng và không cho phép người dùng gửi thông tin trực tiếp tới máy chủ một cách không hợp lệ, không đáng tin cậy bởi vì nó đến từ các điều khiển khôngthểchỉnhsửa hoặc người dùng không được phép gửi thông qua giao diện người dùng. Ngoài ra, các hiện vật hệ thống như các bản ghi phải được bảo vệ khỏi việc đọc, viết và xóa không được phép. 2. Ví dụ Ví dụ 1. Hãy tưởng tượng một ứng dụng ASP.NET chỉ cho phép người quản trị thay đổi mật khẩu cho người dùng khác trong hệ thống. Người quản trị sẽ thấy các trường tên người dùng và mật khẩu để nhập tên người dùng và mật khẩu trong khi những người dùng khác không nhìn thấy cả hai trường. Tuy nhiên, nếu người dùng không phải quản trị viên gửi thông tin trong trường tên người dùng và mật khẩu thông qua proxy, họ có thể lừa máy chủ tin rằng yêu cầu đó đến từ một người quản trị và thay đổi mật khẩu của người dùng khác. Ví dụ 2. Hầu hết các ứng dụng web đều có danh sách thả xuống làm cho người dùng dễ dàng lựa chọn tiểu bang, tháng sinh của họ, vv... Giả sử một ứng dụng Quản lý dự án cho phép người dùng đăng nhập và tùy thuộc vào đặc quyền của họ trình bày với họ một danh sách thả xuống các dự án họ có quyền truy cập đến. Điều gì xảy ra nếu kẻ tấn công tìm thấy tên của một dự án khác mà họ không nên có quyền truy cập và gửi thông tin qua proxy. Ứng dụng sẽ cho phép truy cập vào dự án? Họ không nên có quyền truy cập ngay cả khi họ bỏ qua kiểm tra logic nghiệp vụ ủy quyền. Ví dụ 3. Giả sử hệ thống quản lý xe cơ giới yêu cầu một nhân viên ban đầu kiểm tra từng tài liệu và thông tin của công dân khi họ cấp giấy chứng nhận hoặc giấy phép lái xe. Tại thời điểm này quá trình kinh doanh đã tạo ra dữ liệu với mức độ toàn vẹn cao khi tính toàn vẹn của dữ liệu được gửi đi được kiểm tra bởi ứng dụng. Bây giờ giả sử ứng dụng được chuyển đến Internet để nhân viên có thể đăng nhập vào dịch vụ đầy đủ hoặc công dân có thể đăng nhập vào ứng dụng tự phục vụ để cập nhật thông tin nhất định. Tại thời điểm này kẻ tấn công có thể sử dụng một proxy chặn để thêm hoặc cập nhật dữ liệu mà họ không nên có quyền truy cập và họ có thể phá hủy tính toàn vẹn của dữ liệu bằng cách tuyên bố rằng công dân đã không kết hôn nhưng cung cấp dữ liệu cho tên của vợ hoặc chồng. Loại chèn hoặc cập nhật dữ liệu chưa được kiểm tra này sẽ phá hủy tính toàn vẹn của dữ liệu và có thể đã bị ngăn cản nếu tuân theo logic quy trình nghiệp vụ. Ví dụ 4. Nhiều hệ thống bao gồm ghi chép cho mục đích kiểm tra và xử lý sự cố. Tuy nhiên, như thế nào là tốt hoặc hợp lệ cho thông tin trong các bản ghi? Chúng có thể bị những kẻ tấn công thao túng, cố tình hoặc vô tình bị hủy hoại toàn bộ hay không? 3. Cách kiểm thử Phương pháp chung • Xem lại tài liệu dự án và sử dụng các kiểm thử tìm kiếm để tìm các phần của ứng dụng hoặc hệ thống (các thành phần, ví dụ: các trường đầu vào, cơ sở dữ liệu hoặc nhật ký) di chuyển, lưu trữ hoặc xử lý dữ liệu hoặc thông tin. • Đối với mỗi thành phần xác định loại dữ liệu hoặc thông tin nào được chấp nhận về mặt logic và loại ứng dụng hoặc hệ thống cần phải bảo vệ. Ngoài ra, xem xét ai theo logic nghiệp vụ được phép chèn, cập nhật và xóa dữ liệu hoặc thông tin và trong mỗi thành phần. • Cố gắng chèn, cập nhật hoặc chỉnh sửa xóa các giá trị dữ liệu hoặc thông tin với dữ liệu hoặc thông tin không hợp lệ vào mỗi thành phần (nghĩa là đầu vào, cơ sở dữ liệu, hoặc đăng nhập) bởi người dùng. Không nên cho phép theo quy trình làm việc logic nghiệp vụ. Phương pháp riêng 1 • Sử dụng chức năng chụp proxy và lưu lượng HTTP tìm kiếm các trường ẩn. • Nếu một trường ẩn được tìm thấy như thế nào trường này so sánh với ứng dụng GUI và bắt đầu tra cứu giá trị này thông qua proxy bằng cách gửi các giá trị dữ liệu khác nhau cố gắng để phá vỡ quy trình kinh doanh và thao tác các giá trị mà bạn không có ý định truy cập. Phương pháp riêng 2 • Sử dụng chụp proxy và lưu lượng HTTP tìm kiếm nơi chèn thông tin vào các khu vực của ứng dụng không thể chỉnh sửa. • Nếu phát hiện thấy các trường này so sánh với các ứng dụng GUI và bắt đầu tra cứu giá trị này thông qua proxy bằng cách gửi các giá trị dữ liệu khác nhau cố gắng phá vỡ quy trình kinh doanh và thao tác các giá trị mà bạn không có ý định truy cập. Phương pháp riêng 3 • Liệt kê các thành phần của ứng dụng hoặc hệ thống có thể được chỉnh sửa, ví dụ như nhật ký hoặc cơ sở dữ liệu. • Cho mỗi thành phần được xác định, hãy thử đọc, chỉnh sửa hoặc xóa thông tin của nó. Ví dụ các tệp nhật ký cần được xác định và Người kiểm tra nên cố gắng thao tác trên dữ liệu hoặc thông tin được thu thập. 4. Các trường hợp kiểm thử liên quan Tất cả các trường hợp kiểm thử đầu vào hợp lệ. 5. Các công cụ sử dụng Nhiều công cụ hệ thống hoặc ứng dụng như trình biên tập và công cụ thao tác trên tập tin. OWASP Zed Attack Proxy (ZAP) 6. Tài liệu tham khảo • Implementing Referential Integrity and Shared Business Logic in a RDB http:hoặchoặcwww.agiledata.orghoặcessayreferentialIntegrity.html • On Rules and Integrity Constraints in Database Systems http:hoặchoặcwww.comp.nus.edu.sghoặc~lingtwhoặcpapershoặcIST92.teopk.pdf • Use referential integrity to enforce basic business rules in Oracle http:hoặchoặcwww.techrepublic.comhoặcarticlehoặcusereferentialintegritytoenforcebasicbusinessrulesinoraclehoặc • Maximizing Business Logic Reuse with Reactive Logic http:hoặc architects.dzone.comhoặcarticleshoặcmaximizingbusinesslogic • Tamper Evidence Logging http:hoặchoặctamperevident.cs.rice.edu Logging.html 7. Cách khắc phục Ứng dụng phải đủ thông minh để kiểm tra các chỉnh sửa quan trọng và không cho phép người dùng gửi thông tin trực tiếp tới máy chủ không hợp lệ, không đáng tin cậy bởi vì nó đến từ các điều khiển không thể chỉnh sửa hoặc người dùng không được phép gửi thông qua giao diện người dùng. Ngoài ra, bất kỳ thành phần nào có thể được chỉnh sửa phải có các cơ chế để ngăn chặn việc viết hoặc cập nhật không cố ý hoặc cố ý.   CHƯƠNG IV: KIỂM THỬ THỜI GIAN XỬ LÝ 1. Tóm lược Những kẻ tấn công có thể thu thập thông tin về một ứng dụng bằng cách theo dõi thời gian cần để hoàn thành nhiệm vụ hoặc trả lời. Ngoài ra, kẻ tấn công có thể thao túng và phá vỡ các luồng quy trình nghiệp vụ được thiết kế bằng cách giữ các phiên hoạt động mở và không gửi giao dịch của họ trong khung thời gian dự kiến. Các lỗ hổng logic thời gian xử lý là duy nhất trong các trường hợp lạm dụng sử dụng nên được tạo ra khi xem xét việc thực hiện và thời gian giao dịch. Thời gian xử lý có thể cho hoặc làm rò rỉ thông tin về những gì đang được thực hiện trong các tiến trình ứng dụng hoặc hệ thống nền. Nếu một ứng dụng cho phép người dùng đoán được kết quả tiếp theo bằng cách thay đổi thời gian xử lý, người dùng sẽ có thể điều chỉnh phù hợp và thay đổi hành vi dựa trên kỳ vọng và chơi hệ thống. 2. Ví dụ Ví dụ 1. Các máy đánh bạc hoặc đánh bài video có thể mất nhiều thời gian hơn để xử lý giao dịch ngay trước khi thanh toán lớn. Điều này sẽ cho phép những người cờ bạc khôn ngoan đánh cược số tiền tối thiểu cho đến khi họ nhìn thấy thời gian quá trình dài mà sau đó sẽ khiến họ đặt cược số tiền tối đa. Ví dụ 2. Có nhiều tiến trình hệ thống đăng nhập hỏi tên người dùng và mật khẩu. Nếu bạn nhìn kỹ, bạn có thể thấy rằng nhập tên người dùng không hợp lệ và mật khẩu người dùng không hợp lệ sẽ mất nhiều thời gian để trả lại lỗi hơn là nhập tên người dùng hợp lệ và mật khẩu người dùng không hợp lệ. Điều này có thể cho phép kẻ tấn công biết nếu họ có tên người dùng hợp lệ và không cần dựa vào thông điệp GUI. Ví dụ 3. Hầu hết các Arenas hoặc các cơ quan du lịch đều có ứng dụng bán vé cho phép người dùng mua vé và đặt chỗ. Khi người dùng yêu cầu, chỗ đặt vé bị khóa hoặc đang chờ thanh toán. Nếu một kẻ tấn công tiếp tục giữ chỗ nhưng không bị kiểm tra thì sao? Các ghế sẽ được phát hành, hoặc sẽ không bán vé? Một số nhà cung cấp vé bây giờ chỉ cho phép người dùng 5 phút để hoàn thành một giao dịch hoặc giao dịch bị vô hiệu. Ví dụ 4. Giả sử một trang web thương mại điện tử kim loại quý cho phép người dùng mua hàng với giá dựa trên giá thị trường tại thời gian họ đăng nhập. Điều gì sẽ xảy ra nếu kẻ tấn công đăng nhập và đặt hàng nhưng không hoàn thành giao dịch cho đến ngày sau chỉ có giá của kim loại tăng lên? Liệu kẻ tấn công có được giá thấp hơn ban đầu? 3. Cách kiểm thử • Xem lại tài liệu của dự án và sử dụng các kiểm tra thăm dò tìm kiếm ứng dụng hoặc chức năng hệ thống có thể bị ảnh hưởng bởi thời gian. Chẳng hạn như thời gian thực hiện hoặc hành động giúp người dùng dự đoán kết quả trong tương lai hoặc cho phép một người để phá vỡ bất kỳ phần nào của logic nghiệp vụ hoặc luồng công việc. Ví dụ: không hoàn thành giao dịch trong thời gian dự kiến. • Phát triển và thực hiện các trường hợp sử dụng sai nhằm đảm bảo kẻ tấn công không thể có được lợi thế dựa trên bất kỳ thời điểm nào. 4. Các kiểm thử liên quan • Thử nghiệm các thuộc tính Cookie • Kiểm tra thời gian chờ của phiên 5. Cách khắc phục Phát triển các ứng dụng với thời gian xử lý trong tâm trí. Nếu kẻ tấn công có thể đạt được một số lợi thế từ việc biết thời gian xử lý khác nhau và các kết quả thêm các bước bổ sung hoặc chế biến để cho dù kết quả họ được cung cấp trong cùng một khung thời gian. Ngoài ra, ứng dụng hoặc hệ thống phải có cơ chế tại chỗ để không cho phép kẻ tấn công mở rộng giao dịch trong một khoảng thời gian chấp nhận được. Điều này có thể được thực hiện bằng cách hủy bỏ hoặc đặt lại các giao dịch sau một thời gian nhất định đã trôi qua như một số nhà cung cấp vé đang sử dụng.   CHƯƠNG V: KIỂM THỬ SỐ LẦN MỘT HÀM ĐƯỢC SỬ DỤNG 1. Tóm lược Nhiều vấn đề mà các ứng dụng đang giải quyết yêu cầu giới hạn số lần một chức năng có thể được sử dụng hoặc hành động có thể được thực hiện. Các ứng dụng phải đủ thông minh để không cho phép người sử dụng vượt quá giới hạn về việc sử dụng các chức năng này vì trong nhiều trường hợp mỗi lần sử dụng chức năng người dùng có thể đạt được một số lợi ích cần phải được tính để đền bù đúng cho chủ sở hữu . Ví dụ: trang Thương mại Điện tử chỉ có thể cho phép người dùng áp dụng mức chiết khấu mỗi lần giao dịch hoặc một số ứng dụng có thể nằm trong kế hoạch đăng ký và chỉ cho phép người dùng tải xuống ba tài liệu hoàn chỉnh hàng tháng. Các lỗ hổng liên quan đến việc kiểm tra các giới hạn chức năng là các trường hợp cụ thể và trường hợp sử dụng sai phải được tạo ra, cố gắng thực hiện các phần của ứng dụng, chức năng hoặc hành động nhiều hơn số lần cho phép. Những kẻ tấn công có thể phá vỡ logic kinh doanh và thực hiện một chức năng nhiều lần hơn cho phép khai thác ứng dụng vì lợi ích cá nhân. 2. Ví dụ Giả sử một trang Thương mại điện tử cho phép người dùng tận dụng lợi thế của một trong nhiều giảm giá trên tổng số mua của họ và sau đó tiến hành kiểm tra và đấu thầu. Điều gì xảy ra khi kẻ tấn công điều hướng trở lại trang Giảm giá sau khi lấy và áp dụng một mức chiết khấu cho phép? Họ có thể tận dụng ưu đãi giảm giá khác không? Họ có thể tận dụng được sự giảm giá như vậy nhiều lần? 3. Cách kiểm thử • Xem lại tài liệu dự án và sử dụng các kiểm tra thăm dò tìm kiếm các chức năng hoặc tính năng trong ứng dụng hoặc hệ thống không nên được thực hiện nhiều hơn mà chỉ một lần hoặc một số thời gian nhất định trong suốt quá trình làm việc của logic nghiệp vụ. • Đối với mỗi chức năng và các tính năng được tìm thấy chỉ được thực hiện một thời gian hoặc một số lần nhất định trong suốt quá trình làm việc của logic nghiệp vụ, phát triển các trường hợp lạm dụng hoặc lạm dụng mà có thể cho phép người dùng thực hiện nhiều hơn số lần cho phép. Ví dụ: người dùng có thể điều hướng qua lại giữa các trang nhiều lần thực hiện một chức năng chỉ nên thực hiện một lần không? Hoặc người dùng có thể tải và dỡ bỏ giỏ hàng để cho phép giảm giá thêm. 4. Các kiểm thử liên quan • Kiểm thử đối với Kiểm toán Tài khoản và Tài khoản Người dùng Cố định • Kiểm thử cho Cơ chế khóa yếu 5. Tài liệu tham khảo • InfoPath Forms Services business logic exceeded the maximum limit of operations Rule http:hoặchoặcmpwiki.viacode.comhoặcdefault.aspx?g=postst=115678 • Gold Trading Was Temporarily Halted On The CME This Morning http:hoặchoặcwww.businessinsider.comhoặcgoldhaltedoncmeforstoplogicevent201310 6. Cách khắc phục Ứng dụng cần phải có kiểm tra để đảm bảo rằng logic nghiệp vụ đang được theo sau và nếu một hàm hoặc hành động chỉ có thể được thực hiện một số lần nhất định, khi đạt đến giới hạn người dùng không còn có thể thực hiện chức năng. Để ngăn người dùng sử dụng một chức năng qua số lần thích hợp ứng dụng có thể sử dụng các cơ chế như cookie để giữ số lượng hoặc thông qua các phiên không cho phép người dùng truy cập để thực hiện các chức năng bổ sung lần.   CHƯƠNG VI: KIỂM THỬ SỰ TẮC NGHẼN TRONG QUY TRÌNH LÀM VIỆC 1. Tổng quan Các lỗ hổng về quy trình làm việc cho phép những kẻ tấn công lạm dụng một ứng dụng hay hệ thống theo một cách nào đó để phá vỡ luồng công việc được thiết kế. Ứng dụng logic nghiệp vu phải yêu cầu người dùng hoàn thành đầy đủ các bước trong quy trình làm việc theo thứ tự, nếu quy trình làm việc không được hoàn thành một cách chính xác, tất cả các hành động sẽ bị thực hiện lại hoặc hủy bỏ. Những lỗ hổng liên quan đến việc gian lận hay bỏ qua trong khi thực hiện quy trình làm việc là duy nhất bởi vì chúng là ứng dụnghoặchệ thống cụ thể và các trường hợp sử dụng sai phải được phát triển bằng cách sử dụng các yêu cầu và nghiệp vụ. Việc thực thi các ứng dụng nghiệp vụ cần được kiểm tra để đảm bảo rằng những hành động hay giao dịch của người dùng đang được tiến hành theo đúng thứ tự, nếu một giao dịch kích hoạt một số tác vụ thì hành động đó sẽ bị thực hiện lại hoặc hủy bỏ nếu giao dịch không thành công. 2. Ví dụ Hầu hết chúng ta đều nhận được dạng thẻ tích điểm để mua sắm từ các cửa hàng tạp hóa hay các trạm xăng. Giả sử một người dùng có thể bắt đầu một giao dịch được liên kết đến tài khoản của họ và sau đó điểm sẽ được cộng vào thẻ tích điểm của họ, hủy bỏ giao dịch hoặc chuyển các mặt hàng từ giỏ hàng của họ và thanh toán. Trong trường hợp này hệ thống sẽ không cộng điểm vào tài khoản cho đến khi nó được thanh toán hoặc hoạt động sẽ bị thực hiện lại nếu điểm không khớp với khoản thanh toán cuối cùng. Với trường hợp này, kẻ tấn công có thể bắt đầu một giao dịch và hủy bỏ nó để thực hiện cộng điểm vào tài khoản của mình mà không phải thực hiện mua bất cứ sản phẩm nào. Một hệ thống thông tin điện tử được thiết kế để đảm bảo rằng bất kì thông tin ban đầu nào đều không chứa những từ ngữ không lành mạnh dựa trên một danh sách được so sánh. Nếu một từ ngữ nằm trong danh sách đen được tìm thấy trong phần thông tin đó thì nó sẽ không được đăng. Tuy nhiên, sau khi gửi nội dung thông tin cho người quản trị, người quản trị có quyền truy cập, chỉnh sửa, thay đổi nội dung thông tin bao gồm các từ nằm trong danh sách từ không được cho phép. Lợi dụng điều này, kẻ tấn công có thể bắt đầu một nội dung trống và thêm bất cứ thông tin nào họ muốn vào đó giống như cập nhật thông tin mới. 3. Phương thức kiểm thử Phương thức kiểm thử chung Xem xét lại tài liệu dự án và sử dụng kiểm thử thăm dò để tìm kiếm những phương thức để bỏ qua hoặc đi đến các bước trong quá trình ứng dụng theo một thứ tự khác từ luồng dữ liệu nghiệp vụ được thiết kế. Đối với mỗi phương pháp phát triển một trường hợp lạm dụng hoặc cố gắng phá hoại hay thực hiện một hành động trái phép cho mỗi luồng logic nghiệp vụ. Phương thức kiểm thử 1 Bắt đầu một giao dịch thông qua ứng dụng qua các điểm kích hoạt tín dụng đến tài khoản người dùng. Hủy bỏ giao dịch hoặc giảm giá thầu cuối cùng để các giá trị điểm phải được giảm và kiểm trai các giá trị điểmhoặc hệ thống tín dụng để chắc chắn rằng chúng đã được ghi lại. Phương thức kiểm thử 2 Trên một hệ thống quản lý nội dung hoặc bảng thông báo nhập và lưu văn bản hoặc các giá trị hợp lệ. Sau đó cố gắng thêm, sửa và xóa dữ liệu để lại những dữ liệu hiện có ở trạng thái không hợp lệ hoặc với những giá trị không hợp lệ để chắc chắn rằng người dùng không được phép lưu những thông tin không chính xác. Những dữ liệu hay thông tin không chính xác có thể là những từ cụ thể (nội dung không lành mạnh) hoặc những chủ đề cụ thể (ví dụ như các vấn đề chính trị). 4. Cách khắc phục Các ứng dụng phải được kiểm tra tại chỗ để chắc chắn rằng mọi người dùng đều hoàn thành từng bước trong quy trình làm việc theo thứ tự xác định, ngăn chặn các kẻ tấn công từ những tấn công phá vỡhoặcbỏ quahoặclặp lại bất cứ bước nào trong luồng xử lý công việc. Kiểm thử các lỗ hổng về luồng xử lý công việc liên quan đến việc phát triển các trường hợp phát triển lạm dụng logic nghiệp vụ không hoàn thành các bước chính xác theo thứ tự đúng.   CHƯƠNG VII: KIỂM THỬ CÁC BIỆN PHÁP NGĂN CHẶN VIỆC SỬ DỤNG SAI MỤC ĐÍCH 1. Tổng quan Việc lạm dụng và sử dụng các chức năng không hợp lệ có thể xác định các cuộc tấn công liệt kê các ứng dụng web, định danh yếu, các tấn công khai thác lỗ hổng. Cần tiến hành kiểm thử để xác định các cơ chế phòng thủ tầng ứng dụng đúng vị trí để bảo vệ ứng dụng. Việc thiếu sót các hệ thống phòng thủ sẽ tạo điều kiện để các kẻ tấn công phát hiện các lỗ hổng mà không cần đến bất kỳ sự hỗ trợ nào. Do đó, người quản trị sẽ không phát hiện được những ứng dụng của mình đang bị tấn công. 2. Ví dụ Người dùng hợp lệ thực hiện trình tự các hành động sau: Cố gắng truy cập vào một tệp ID mà vai trò của họ không được phép tải xuống. Thay thế một dấu nháy đơn (‘) thay vì số tệp ID. Thay đổi các request GET sang POST. Thêm một tham số phụ. Trùng lặp cặp tên hoặc giá trị tham số. Ứng dụng đang giám sát việc sử dụng sai với sự chắc chắn cao người dùng ở đây chính là kẻ tấn công. Một số ví dụ về ứng dụng: Vô hiệu hóa các chức năng quan trọng. Kích hoạt các bước xác thực bổ sung cho các chức năng còn lại. Thêm timerelays vào mỗi chu kỳ hồi đáp yêu cầu. Ghi lại các dữ liệu bổ sung về tương tác người dùng. Nếu ứng dụng không hồi đáp bằng bất kỳ cách nào và kẻ tấn công có thể tiếp tục để lạm dụng các tính năng và gửi các nội dung độc hại đến ứng dụng, trường hợp kiểm thử này được xem như thất bại. Trong thực tế, các hành động riêng lẻ trong ví dụ trên không có khả năng xảy ra. Có nhiều khả năng xảy ra hơn khi một công cụ fuzzing được sử dụng để xác định các điểm yếu của từng tham số. Đây cũng là những gì mà một nhân viên kiểm tra an ninh sẽ phải thực hiện. 3. Phương thức kiểm thử Phương thức kiểm thử này khác biệt ở chỗ kết quả có thể được đưa ra dựa trên các kiểm thử khác thực hiện ngăn chặn các ứng dụng web. Trong khi thực hiện các phương pháp kiểm thử khác, cần lưu ý các biện pháp nhận biết ứng dụng có khả năng tự bảo vệ: Thay đổi các lời hồi đáp. Chặn các truy vấn. Các hành động người dùng đăng nhập hay khóa tài khoản. Những khả năng này chỉ có thể được giới hạn. Các phương pháp bảo vệ phổ biến là: Từ chối dữ liệu đầu vào chứa một số ký tự nhất định. Khóa tạm thời một tài khoản sau một số lần xác thực thất bại nhất định. Việc kiểm soát an ninh cục bộ là không đầy đủ. Thường không có biện pháp bảo vệ chống lại việc sử dụng sai mục đích như: Truy cập trái phép. Bỏ qua bước xác nhận dữ liệu đầu vào. Các lỗi về kiểm soát đa truy cập. Bổ sung, trùng lặp hoặc thiếu các tham số tên. Xác thực dữ liệu đầu vào nhiều lần hoặc lỗi xác minh logic nghiệp vụ. Cấu trúc dữ liệu của các định dạng không hợp lệ được nhận. Tấn công XSS hoặc SQL Injection. Thay đổi tác nhân người dùng. Thay đổi vị trí địa lý của người dùng. Số lượng lớn hoặc tỉ lệ người dùng cao các chức năng ứng dụng cụ thể như gửi mã phiếu quà tặng, thanh toán thẻ tín dụng thất bại… Những biện pháp bảo vệ này hoạt động tốt nhất trong phần xác thực ứng dụng, mặc dù tỉ lệ tạo tài khoản mới hoặc truy cập nội dung có thể được sử dụng ở các khu vực công cộng. Không phải tất cả các trường hợp nói trên đều cần phải được giám sát bởi ứng dụng, tuy nhiên sẽ có vấn đề nếu không có trường hợp nào được kiểm soát. Bằng cách kiểm thử ứng dụng web, thực hiện các dạng hành động kể trên, có bất cứ hồi đáp nào chống lại người kiểm thử hay không? Nếu không, nhân viên kiểm thử nên báo cáo rằng các ứng dụng này không có biện pháp bảo vệ đối với toàn bộ ứng dụng ngăn chặn việc sử dụng sai mục đích. Lưu ý, đôi khi các lời hồi đáp để phát hiện tấn công không hiển thị đối với người dùng, ví dụ như thay đổi logging, tăng khả năng kiểm soát, thông báo đến quản trị viên… Do đó sự tin cậy trong những phát hiện này có thể không được đảm bảo. Trong thực tế, có rất ít các ứng dụng phát hiện được các dạng sử dụng sai mục đích.   CHƯƠNG VIII: KIỂM THỬ QÚA TRÌNH UPLOAD CÁC DẠNG TỆP TIN KHÔNG PHÙ HỢP 1. Tổng quan Có rất nhiều các quy trình xử lý nghiệp vụ của các ứng dụng cho phép việc tải lên và thao tác dữ liệu được gửi qua các tệp. Tuy nhiên quá trình xử lý nghiệp vụ phải kiểm tra các tệp và chỉ cho phép những dạng tệp chắc chắn được cho phép. Việc quyết định những dạng tệp hợp lệ được xác định bởi logic nghiệp vụ và là ứng dụnghoặc hệ thống cụ thể. Hiểm họa trong việc cho phép những người dùng tải lên các tệp, kẻ tấn công có thể gửi đi một dạng file không hợp lệ, nó có thể được thực thi và tác động tiêu cực đến ứng dụng hoặc hệ thống mặc dù các cuộc tấn công có thể là thay đổi giao diện trang web, thực thi các lệnh từ xa, duyệt các file hệ thống, duyệt các tài nguyên cục bộ, tấn công các server khác hoặc khai thác các lỗ hổng… Những lỗ hổng liên quan đến việc upload các file không hợp lệ được hiểu là việc tải lên một tệp tin phải bị từ chối nếu nó không có các tiện ích cụ thể. Ngoài ra, việc tải lên các file không hợp lệ cũng khác với việc tải các tệp tin độc hại bởi vì hầu hết các trường hợp, các dạng file không hợp lệ không phải bản thân chúng có chứa các nội dung độc hai nhưng có thể gây ra những ảnh hưởng xấu cho dữ liệu được lưu trữ. Ví dụ một ứng dụng chấp nhận các tệp tin Windows Excel, nếu một tệp cơ sở dữ liệu tương tự được tải lên nó có thể được đọc nhưng dữ liệu trích xuất có thể bị di chuyển không đúng vị trí. Một ứng dụng có thể chỉ cho phép một số dạng file nhất được được tải lên để xử lý, ví dụ như .CSV, .txt. Ứng dụng không thể xác thực file tải lên bằng phần mở rộng hoặc nội dung. Điều này có thể dẫn đến kết quả trong hệ thống không lường trước được hoặc kết quả dữ liệu trong ứng dụng hay hệ thống hoặc cung cấp cho những kể tấn công các phương thức bổ sung để khai thác các ứng dụng hay hệ thống. 2. Ví dụ Một ứng dụng chia sẻ hình ảnh cho phép người dùng tải lên các định dạng tệp đồ họa .gjf hoặc .jpg vào trang web. Vậy điều gì sẽ xảy ra nếu kẻ tấn công có thể tải lên một têp html với một thẻ bên trong đó hoặc một file php? Hệ thống có thể di chuyển tệp tin từ vị trí tạm thời đến vị trí cuối cùng nơi mã php có thể thực thi đối với ứng dụng hoặc hệ thống. 3. Phương thức kiểm thử Phương pháp kiểm thử chung: • Nghiên cứu các tài liệu của dự án và thực hiện việc kiểm thử tìm kiếm một số dạng tệp tin không được hỗ trợ trong các ứng dụnghoặc hệ thống. • Cố gắng tải lên các định dạng tệp tin không được hỗ trợ trong các ứng dụng hoặc hệ thống để xác minh rằng chúng đã bị từ chối. • Nếu có nhiều tệp tin cùng được tải lên cùng một thời điểm, cần phải thực hiện kiểm thử ngay lập tức để xác minh rằng mỗi tệp được đánh giá đúng đắn. Phương pháp kiểm thử cụ thể: • Nghiên cứu các yêu cầu ứng dụng phù hợp. • Chuẩn bị một thư viện trong đó bao gồm các định dạng tệp không được cho phép tải lên ví dụ như: jsp, exe, hoặc các tệp html chứa các các tập lệnh script. • Trong các ứng dụng điều hướng đến cơ chế gửi hoặc tải lên các tệp tin. • Gửi các tệp tin không được cho phép và xác minh rằng chúng đã được ngăn chặn khi tải lên. 4. Cách khắc phục Các ứng dụng cần được phát triển các cơ chế cho phép một số định dạng tệp tin nhất định mà một phần chức năng ứng dụng có thể nhận dạng và xử lý. Một ví dụ cụ thể như: danh sách các file mở rộng đen hoặc trắng, sử dụng “contenttype” từ phần tiêu đề, hoặc sử dụng một bộ nhận dạng loại tệp tin, chỉ cho phép những loại tệp cụ thể mà hệ thống chỉ định.   CHƯƠNG IX: KIỂM THỬ VIỆC TẢI LÊN CÁC TỆP TIN ĐỘC HẠI 1. Tổng quan Rất nhiều các quy trình xử lý nghiệp vụ của ứng dụng cho phép việc tải lên các dữ liệu hay thông tin. Chúng ta thường xuyên kiểm tra tính hợp lệ và tính bảo mật của văn bản nhưng việc chấp nhận các tệ tin có thể gây ra nhiều rủi ro hơn. Để giảm thiểu các rủi ro, chỉ nên chấp nhận những định dạng file nhất định, tuy nhiên những kẻ tấn công cũng có thể nhũng những đoạn mã độc vào các tập tin này. Việc kiểm thử các tệp tin độc hại xác minh rằng hệ thống hay ứng dụng có thể bảo vệ một cách an toàn ngăn chăn các kẻ tấn công tải lên những tệp tin độc hại. Các lỗ hổng liên quan đến việc tải lên các tệp độc hại là độc nhất vì các tệp độc hại này có thể dễ dàng bị từ chối thông qua bao gồm logic kinh doanh sẽ quét các tệp trong quá trình tải lên và từ chối những tệp được coi là độc hại. Ngoài ra, điều này khác với việc tải lên các tệp không mong muốn trong khi loại tệp có thể được chấp nhận tệp tin có thể vẫn độc hại cho hệ thống. Cuối cùng, độc hại có nghĩa là những thứ khác nhau cho các hệ thống khác nhau, ví dụ như các tệp độc hại có thể khai thác lỗ hổng SQL server Bilities có thể không được xem là nguy hiểm đối với một môi trường file khung chính. Ứng dụng này có thể cho phép tải lên các tệp độc hại bao gồm các khai thác hoặc trình bao mà không đưa chúng tới chức năng quét tệp độc hại. Các tệp độc hại có thể được phát hiện và dừng lại tại các điểm khác nhau của kiến trúc ứng dụng như: IPS hoặc IDS, phần mềm chống virus máy chủ ứng dụng hoặc quét virút bằng ứng dụng khi các tệp được tải lên (có thể tải quét bằng SCAP). 2. Ví dụ Giả sử một ứng dụng chia sẻ hình ảnh cho phép người dùng tải các tệp đồ hoạ .gif hoặc .jpg lên trang web. Điều gì sẽ xảy ra nếu kẻ tấn công có thể tải lên một trình bao PHP, hoặc tệp exe, hoặc virus? Kẻ tấn công sau đó có thể tải lên tệp tin có thể được lưu trên hệ thống và vi rút có thể lây lan chính nó hoặc thông qua quá trình xử lý từ xa exes hoặc shell code có thể được thực hiện. 3. Cách kiểm thử Phương pháp kiểm thử chung • Xem lại tài liệu của dự án và sử dụng các thử nghiệm thăm dò tìm kiếm ứng dụng hoặc hệ thống để xác định những gì cấu thành và tập tin độc hại trong môi trường của bạn. • Phát triển hoặc có được một tập tin độc hại được biết đến. • Cố gắng tải tệp tin độc hại lên ứng dụng hoặc hệ thống và xác minh rằng nó đã bị từ chối một cách chính xác. • Nếu nhiều tập tin có thể được tải lên cùng một lúc, phải có các bài kiểm tra tại chỗ để xác minh rằng mỗi tập tin được đánh giá đúng. Phương pháp kiểm thử riêng 1 • Sử dụng chức năng tạo payload của Metasploit tạo ra một shellcode như một file thực thi của Windows sử dụng lệnh msfpayload của Metasploit. • Gửi tệp thực thi thông qua chức năng tải lên của ứng dụng và xem nếu nó được chấp nhận hoặc bị từ chối đúng cách. Phương pháp kiểm thử riêng 2 • Phát triển hoặc tạo ra một tệp tin mà không nên quá trình phát hiện phần mềm độc hại. Có rất nhiều trên Internet như ducklin.htm hoặc ducklinhtml.htm. • Gửi tệp thực thi thông qua chức năng tải lên của ứng dụng và xem nếu nó được chấp nhận hoặc bị từ chối đúng cách. Phương pháp kiểm thử riêng 3 • Thiết lập proxy chặn lại để nắm bắt yêu cầu hợp lệ đối với một tệp được chấp nhận. • Gửi yêu cầu không hợp lệ thông qua với một phần mở rộng tệp hợp lệ hoặc chấp nhận được và xem yêu cầu có được chấp nhận hay không. 4. Các trường hợp kiểm thử liên quan • Test File Extensions Handling for Sensitive Information (OTGCONFIG003) • Test Upload of Unexpected File Types (OTGBUSLOGIC008) 5. Các công cụ • Metasploit’s payload generation functionality • Intercepting proxy 6. Tài liệu tham khảo OWASP Unrestricted File Upload https:hoặchoặcwww.owasp.org index.phphoặcUnrestricted_File_Upload • Why File Upload Forms are a Major Security Threat http:hoặc www.acunetix.comhoặcwebsitesecurityhoặcuploadformsthreathoặc • File upload security best practices: Block a malicious file upload http:hoặchoặcwww.computerweekly.comhoặcanswerhoặcFileuploadsecuritybestpracticesBlockamaliciousfileupload • Overview of Malicious File Upload Attacks http:hoặcsecuritymecca.comhoặcarticlehoặcoverviewofmaliciousfileuploadattackshoặc • Stop people uploading malicious PHP files via forms http:hoặchoặcstackoverflow.comhoặcquestionshoặc602539hoặcstoppeopleuploadingmaliciousphpfilesviaforms • How to Tell if a File is Malicious http:hoặchoặcwww.techsupportalert.comhoặccontenthoặchowtelliffilemalicious.htm • CWE434: Unrestricted Upload of File with Dangerous Type http:hoặchoặccwe.mitre.orghoặcdatahoặcdefinitionshoặc434.html • Implementing Secure File Upload http:hoặchoặcinfosecauditor.wordpress.comhoặctaghoặcmaliciousfileuploadhoặc • Watchful File Upload http:hoặchoặcpalizine.plynt.comhoặcissueshoặc2011Aprhoặcfileuploadhoặc • Matasploit Generating Payloads http:hoặchoặcwww.offensivesecurity.comhoặcmetasploitunleashedhoặc Generating_Payloads • Project Shellcode – Shellcode Tutorial 9: Generating Shellcode Using Metasploit http:hoặchoặcwww.projectshellcode. comhoặc?q=nodehoặc29 • AntiMalware Test file http:hoặchoặcwww.eicar.orghoặc860Intended use.html 7. Cách khắc phục Mặc dù các biện pháp bảo vệ như liệt kê các phần mở rộng tệp đen hoặc trắng, sử dụng ContentType từ tiêu đề hoặc sử dụng bộ nhận dạng loại tệp có thể không phải lúc nào cũng được bảo vệ chống lại loại lỗ hổng này. Mọi ứng dụng chấp nhận tệp từ người dùng phải có cơ chế xác minh rằng tệp được tải lên không chứa mã độc hại. Các tệp tải lên không bao giờ được lưu trữ ở nơi người dùng hoặc kẻ tấn công có thể trực tiếp truy cập chúng.   KẾT LUẬN Thông qua việc tìm hiểu kiểm thử logic nghiệp vụ để nắm được tầm quan trọng cũng như các trường hợp kiểm thử cũng như cách thức thực hiện kiểm thử logic nghiệp vụ. Kiểm thử logic nghiệp vụ là một hoạt động quan trọng trong việc đảm bảo hệ thống cũng như ứng dụng hoạt động an toàn, tránh được các hiểm họa có thể xảy ra. Đối với kiểm thử logic nghiệp vụ có rất nhiều các trường hợp kiểm thử khác nhau như kiểm thử dữ liệu hợp lệ, kiểm thử khả năng giả mạo các yêu cầu, kiểm thử khả năng kiểm tra tính toàn vẹn, kiểm thử thời gian xử lý, kiểm thử số lần một hàm được sử dụng, kiểm thử sự tắc nghẽn trong quá trình làm việc, kiểm thử các biện pháp ngăn chặn việc sử dụng sai mục đích, kiểm thử quá trình upload các dạng tệp tin không phù hợp, các dạng tập tin độc hại.   TÀI LIỆU THAM KHẢO 1: OWASP Testing Guide v4 Table of Contents https:www.owasp.orgindex.phpOWASP_Testing_Guide_v4_Table_of_Contents.