BÁO CÁO BÀI TẬP LỚN
ĐỀ TÀI: KIỂM THỬ LOGIC NGHIỆP VỤ

Giảng viên hướng dẫn

Hà Nội, ngày 21 tháng 3 năm 2017


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
1


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
2


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

3


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.

4


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à
5


đ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 POST/GET
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 "hand-offs" 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 (OTG-IDENT-004)).
Kiểm thử về lược đồ quản lý các phiên bỏ qua (Testing for
Bypassing Session Management Schema (OTG-SESS-001)).
Kiểm thử về các biến phiên bị lộ (Testing for Exposed
Session Variables (OTG-SESS-004)).
5. Các công cụ sử dụng
6


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_kaTgdEC&pg=PA280&lpg=PA280&dq=business+logic
+example+valid+data+example&source=bl&ots=GOfQ7f4Hu&sig=4jOejZVligZOrvjBFRAT4jy8DI&hl=en&sa=X&ei=mydYUt6qEOX54APu7IDgCQ&ved=0CFI
Q6AEwBDgK#v=onepage&q=business%20logic%20example
%20valid%20data%20 example&f=false

7


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 front-end để gửi trực tiếp thông tin
cho back-end xử lý. Mục tiêu của kẻ tấn công là gửi các yêu cầu
HTTP POST/GET 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 POST/GET đế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

8


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 POST/GET
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 POST/GET
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.
9


 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 (OTG-SESS-004)
 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS005)
 Testing for Account Enumeration and Guessable User
Account (OTG-IDENT-004)
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ặc1

1hoặccross-siterequest-forgery-legitimazing.html
- Debugging features which remain present in the final
game
http:hoặchoặcglitchcity.infohoặcwikihoặcindex.phphoặcList
_of_video_games_
with_debugging_features#Debugging_features_which_
remain_present_in_the_final_game
- Easter egg:
http:hoặchoặcen.wikipedia.orghoặcwikihoặcEaster_egg_(m
edia)
- Top 10 Software Easter Eggs
http:hoặchoặclifehacker.comhoặc371083hoặc top-10software-easter-eggs
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.

10


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ông-thể-chỉnh-sử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ô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, 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
11


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.
12


 Đố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
13


http:hoặchoặcwww.agiledata.orghoặcessayreferentialIntegrity.h
tml
 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ặcusereferentialintegrity-to-enforce-basic-business-rules-inoraclehoặc
 Maximizing Business Logic Reuse with Reactive Logic
http:hoặc architects.dzone.comhoặcarticleshoặcmaximizingbusiness-logic
 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ố ý.

14



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
15


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.

16


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
17


 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=posts&t=115678
 Gold Trading Was Temporarily Halted On The CME This
Morning
http:hoặchoặcwww.businessinsider.comhoặcgold-halted-oncme-forstop-logic-event-2013-10
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.

18



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
19


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.

20


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 time-relays 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ệ:
21


- 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.
22


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ẻ <script> 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ử
23


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 “content-type”
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.

24