ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
BÀI TẬP LỚN
Môn Kiểm Chứng Phần Mềm
ĐỀ TÀI: Tìm hiểu một số công cụ kiểm thử, bảo mật
Ứng dụng vào KTBM trên website
Thành Viên: Nguyễn Văn Thanh
Đào Đình Thiện
Bùi Văn Công
Đỗ Mạnh Hùng
Ngô Tuấn Thịnh
1
CHƯƠNG I: TỔNG QUAN VỀ BẢO MẬT WEBSITE VÀ KIỂM THỬ BẢO
MẬT
1.1. Tổng quan về bảo mật
Bảo mật là sự thỏa hiệp giữa bảo mật và chức năng, khả năng sử dụng. Nếu
bảo mật của hệ thống quá chặt chẽ, nó sẽ trở nên rất khó sử dụng hoặc khó hoạt
động một cách hiệu quả. Nếu bảo mật quá đơn giản, hệ thống dễ bị tấn công và
xâm nhập.
Kiểm thử bảo mật Web, trong nghĩa truyền thống, là kiểm thử hiệu quả sự
bảo vệ toàn bộ hệ thống Web. Nó yêu cầu kết hợp nhiều kiến thức về các công
nghệ bảo mật, công nghệ mạng, lập trình, và kinh nghiệm thực tế về thâm nhập các
hệ thống mạng. Hầu hết các kiểm thử viên phần mềm không có loại kiến thức
này.Tuy nhiên, chúng ta nên hiểu các vấn đề về bảo mật sao cho chúng ta hiểu
được các công việc chúng ta nên làm và các công việc nên được thực hiện bởi các
chuyên gia khác.
 Mục đích của bảo mật : Đảm bảo sự an toàn dữ liệu cho hệ thống và bảo
vệ các tài nguyên trên mạng trước sự tấn công nhằm phá vỡ hệ thống hoặc
sử dụng trái phép các tài nguyên của một số người có chủ ý xấu.
1.2. Giới thiệu về kiểm thử bảo mật
- Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần

của chúng tôi không có một chuyên gia để thực hiện kiểm thử xâm nhập,
không nên để một kiểm thử viên và lập trình viên chịu trách nhiệm này.
- Những ưu điểm trong kiểm thử bảo mật
+ Kiểm thử bảo mật là kiểm thử chủ động, không bị động.
3
+ Các lỗi không được xử lý là các kho báu để chèn lỗi vào nhằm xác định
các lỗi bảo mật.
+ Các giao diện dữ liệu vào là các kho báu để chèn lỗi nhằm xác định các lỗi
bảo mật.
+ Hãy xem xét mọi dữ liệu vào không hợp lệ có thể xảy ra phái trình khách.
+ Hãy xem xét mọi dữ liệu vào không hợp lệ có thể xảy ra phía trình chủ.
+ Tập trung trên các điều kiện dữ liệu vào mà ở đó dữ liệu được chuyển từ
miền không tin cậyvào miền tin cậy.
+ Thiết kế các ca kiểm thử với sự nhấn mạnh trên các b
+ Tìm kiếm các lỗi cho phép người sử dụng thực thi chương trình trên máy
chủ. iên giữa các miền tin cậy và miền không tin cậy.
+ Tìm kiếm các lỗi cho phép người sử dụng thay đổi nâng cao quyền truy
cập.
+ Luôn ý thức rằng ứng dụng thường xử lý sai một số dữ liệu xấu đến từ phía
trình khách không tin cậy.
+ Tìm kiếm dữ liệu vào mà có thể trở nên thực thi được (ví dụ: khi dữ liệu
vào trở nên dữ liệu ra).
1.4. Đối tượng và hoạt động của Security Testing
Cần chú ý đến các đối tượng và hoạt động Test sau:
- Phân quyền (các vai trò và danh sách quyền tương ứng): chú ý vai trò của
từng đối tượng sử dụng và các quyền cùng việc phân quyền phải chính xác, nếu
không việc thông tin bị lộ một cách không phù hợp là khó tránh khỏi. Thông
thường các ứng dụng luôn có 1 function cho việc Phân quyền nên việc Test bảo
mật ở đây là test function của module Phân quyền và đảm bảo danh sách quyền đi
kèm từng vai trò và danh sách vai trò là đủ và chính xác.

5
Bất kỳ hệ thống nào cũng được xây dựng từ một tập hợp các yêu cầu. Đôi
khi những yêu cầu này được viết một cách rõ rang, nhưng thường chúng là những
phát biểu mật mờ không được định nghĩa rõ ràng. Ví dụ, có thể có phát biểu “Ứng
dụng phải an toàn”. Nhưng “an toàn” nghĩa là gì và nên phải dành bao nhiêu công
sức và thời gian để làm cho sản phẩm an toàn.
1.5.2 Kiểm thử mã nguồn
Phương pháp kiểm tra độ bảo mật của ứng dụng thông qua mã nguồn của
ứng dụng. Phuong pháp kiểm thử này chủ yếu dung để xác định sự an toàn của
thuật toán được dung trong ứng dụng, xác độ nguy cơ rò rỉ thông tin, nguy cơ bị tấn
công chiếm quyền kiểm soát thông qua mã nguồn. Phương pháp này thường ứng
dụng kỹ thuật kiểm thử hộp trắng.
1.5.3 Kiểm thử các thiết lập của trình duyệt
Các thiết lập của trình duyệt có thể được cài đặt trong các trình duyệt như
Mozilla FireFox và Micrrosoft Internet Explorer cho phép giới hạn truy cập đến các
nội dung internet có thể gây hại. Người sử dụng sẽ thường có các chỉnh sửa các
thiết lập này.Hơn nữa, có một sự thay đổi lớn phía người sử dụng về khả năng làm
chủ các thiết lập này.Những người sử dụng Web ngày càng được đào tạo nhiều hơn
cách sử dụng các thiết lập để bảo vệ chính họ. Với tư cách là một đội phát triển
Website hay ứng dụng Web, chúng ta không thể bắt buộc người sử dụng chấp nhận
các thiết bị mặc định. Vì vậy, chúng ta cần phải kiểm thử nhiều sự kết hợp của các
thiết lập.
1.5.4 Kiểm thử bức tường lửa
Cần nhắc lại rằng nhóm kiểm thử phần mềm không chịu trách nhiệm kiểm
thử sự hiệu quả của các tường lửa và sự cấu hình chúng.Kiểm thử tường lửa nhằm
nhận biết các hiệu ứng về chức năng được tạo ra bởi sự chuyển đổi dữ liệu qua các
mạng khác nhau.Một số mạng riêng và một số khác công cộng.
6
1.6. Quy trình kiểm thử bảo mật Website
1.6.1 Quy trình kiểm thử thủ công

việc đảm bảo an toàn, bảo mật nhằm giảm thiểu tối đa khả năng bị tấn công
từ các tin tặc chỉ đơn thuần tập trung vào các cấn đề như chọn hệ điều hành,
hệ quản trị cơ sở dữ liệu, webserver sẽ chạy ứng dụng, …mà quên mất rằng
ngay cả bản thân ứng dụng chạy trên đó cũng tiềm ẩn một lỗ hổng bảo mật
rất lớn. Một trong số các lỗ hổng này là SQL Injection. Tại Việt Nam, đã qua
thời kì các nhà quản trị website lơ là việc quét virus, cập nhật các bản vá lỗi
từ các phần mềm hệ thống, nhưng việc chăm sóc các lỗi của các ứng dụng lại
11
rất ít được quan tâm. Đó là lí do tại sao không ít website tại VN bị tấn công
và đa số đều là lỗi SQL injection. Vậy SQL injection là gì?
 SQL injection là một kĩ thuật cho phép những kẻ tấn công lợi dụng lỗ
hổng trong việc kiểm tra dữ liệu nhập trong các ứng dụng web và các
thông báo lỗi của hệ quản trị cơ sở dữ liệu để "tiêm vào" (inject) và thi
hành các câu lệnh SQL bất hợp pháp (không được người phát triển ứng
dụng lường trước).
Dạng lỗi này có thể tìm thấy trên các trang web cho phép submit dữ liệu
ở bất kì một trình tìm kiếm nào trên mạng, chẳng hạn như các trang login, search,
feedback, url có truyền tham số
Hậu quả của nó rất tai hại vì nó cho phép những kẻ tấn công có thể thực hiện
các thao tác xóa, hiệu chỉnh, … do có toàn quyền trên cơ sở dữ liệu của ứng dụng,
thậm chí là server mà ứng dụng đó đang chạy. Lỗi này thường xảy ra trên các ứng
dụng web có dữ liệu được quản lí bằng các hệ quản trị cơ sở dữ liệu như SQL
Server, MySQL, Oracle, DB2, Sysbase.
Sql Injection được mô tả như là một trong những lỗ hổng bảo mật web nguy
hiểm nhất. Khai thác Sql Injection, ngoài việc đoạt được quyền kiểm soát về mặt
dữ liệu như đã nói ở trên, hacker còn có thể cài đặt backdoor trên server mà ứng
dụng đang chạy, qua đó kiểm soát toàn bộ hệ thống…
2.2.2 Các dạng lỗi thường gặp
• Không kiểm tra ký tự thoát truy vấn
Đây là dạng lỗi SQL injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu

định nghĩa đầu vào dữ liệu không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ
13
liệu đầu vào. Điều này có thể xảy ra khi một trường số được sử dụng trong truy vấn
SQL nhưng lập trình viên lại thiếu bước kiểm tra dữ liệu đầu vào để xác minh kiểu
của dữ liệu mà người dùng nhập vào có phải là số hay không. Ví dụ như sau:
statement := "SELECT * FROM data WHERE id = " + a_variable + ";"
Ta có thể nhận thấy một cách rõ ràng ý định của tác giả đoạn mã trên là nhập
vào một số tương ứng với trường id - trường số. Tuy nhiên, người dùng cuối, thay
vì nhập vào một số, họ có thể nhập vào một chuỗi ký tự, và do vậy có thể trở thành
một câu truy vấn SQL hoàn chỉnh mới mà bỏ qua ký tự thoát. Ví dụ, ta thiết lập giá
trị của biến a_variable là:
1; DROP TABLE users
khi đó, nó sẽ thực hiện thao tác xóa người dùng có id tương ứng khỏi cơ sở dữ
liệu, vì câu truy vấn hoàn chỉnh đã được hiểu là:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;
• Lỗi bảo mật bên trong máy chủ cơ sở dữ liệu.
Đôi khi lỗ hổng có thể tồn tại chính trong phần mềm máy chủ cơ sở dữ liệu, như
là trường hợp hàm mysql_real_escape_string() của các máy chủ MySQL. Điều
này sẽ cho phép kẻ tấn công có thể thực hiện một cuộc tấn công SQL injection
thành công dựa trên những ký tự Unicode không thông thường ngay cả khi đầu
nhập vào đang được thoát.
• Blind SQL injection.
Lỗi SQL injection dạng này là dạng lỗi tồn tại ngay trong ứng dụng web nhưng
hậu quả của chúng lại không hiển thị trực quan cho những kẻ tấn công. Nó có thể
gây ra sự sai khác khi hiển thị nội dung của một trang chứa lỗi bảo mật này, hậu
quả của sự tấn công SQL injection dạng này khiến cho lập trình viên hay người
dùng phải mất rất nhiều thời gian để phục hồi chính xác từng bit dữ liệu. Những
14
kẻ tấn công còn có thể sử dụng một số công cụ để dò tìm lỗi dạng này và tấn
công với những thông tin đã được thiết lập sẵn.

hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết
định cho phép hay từ chối thực hiện tiếp.
Ví dụ, trong trường hợp sử dụng ASP, người ta có thể dùng 2 trang: 1 trang
HTML để hiển thị Form nhập liệu và 1 trang ASP để xử lý thông tin nhập vào từ
phía người dùng như sau:
Trang đăng nhập: login.html
<form action="ExecLogin.asp" method="post">
Username: <input type="text" name="fUSRNAME"><br />
Password: <input type="password" name="fPASSWORD"><br />
<input type="submit">
</form>
Trang xử lý đăng nhập: xuly.asp
<%
Dim vUsrName, vPassword, objRS, strSQL
vUsrName = Request.Form("fUSRNAME")
vPassword = Request.Form("fPASSWORD")
strSQL = "SELECT * FROM T_USERS " & _
"WHERE USR_NAME=' " & vUsrName & _
" ' and USR_PASSWORD=' " & vPassword & " ' "
16
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN= "
If (objRS.EOF) Then
Response.Write "Invalid login."
Else
Response.Write "You are logged in as " & objRS("USR_NAME")
End If
Set objRS = Nothing %>
Chỗ sơ hở trong đoạn mã xử lý nhập liệu trên nằm ở chỗ dữ liệu nhập vào từ
người dùng được dùng để xây dựng trực tiếp câu lệnh SQL. Chính điều này

DROP TABLE T_AUTHORS –
Câu truy vấn sẽ thực hiện việc xóa bảng.
• Dạng tấn công sử dụng câu lệnh INSERT.
Thông thường các ứng dụng web cho phép người dùng đăng kí một tài khoản để
tham gia. Chức năng không thể thiếu là sau khi đăng kí thành công, người dùng có
thể xem và hiệu chỉnh thông tin của mình. SQL injection có thể được dùng khi hệ
thống không kiểm tra tính hợp lệ của thông tin nhập vào. Ví dụ, một câu lệnh
INSERT có thể có cú pháp dạng:
INSERT INTO TableName VALUES('Value One', 'Value Two', 'Value Three')
Nếu đoạn mã xây dựng câu lệnh SQL có dạng:
18
<%
strSQL = "INSERT INTO TableName VALUES(' " & strValueOne & " ', ' " _ &
strValueTwo & " ', ' " & strValueThree & " ') "
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN= "
…
Set objRS = Nothing
%>
Thì chắc chắn sẽ bị lỗi SQLi, bởi vì nếu ta nhập vào trường thứ nhất ví dụ như:
' + (SELECT TOP 1 FieldName FROM TableName) + '
Lúc này câu truy vấn sẽ là:
INSERT INTO TableName VALUES(' ' + (SELECT TOP 1 FieldName FROM
TableName) + ' ', 'abc', 'def')
Khi đó, lúc thực hiện lệnh xem thông tin, xem như bạn đã yêu cầu thực hiện thêm
một lệnh nữa đó là:
SELECT TOP 1 FieldName FROM TableName
• Dạng tấn công sử dụng stored-procedures.
Việc tấn công bằng stored-procedures sẽ gây tác hại rất lớn nếu ứng dụng được
thực thi với quyền quản trị hệ thống 'sa'. Ví dụ, nếu ta thay đoạn mã tiêm vào dạng:

+ Kiểm tra xem định dạng chuỗi: email, username, password… đều có một
định dạng nhất định, do đó có thể viết các biểu thức chính qui (Regular Expression)
cho mỗi định dạng này.
C#: System.Text.RegularExpressions;
20
PHP: preg_match();
Java: Pattern.matcher();
- Sử dụng các thư viện hỗ trợ:
+ C#: Parameters
cmd.Parameters.Add("@var", SqlDbType.Int);
cmd.Parameters["@var"].Value = input;
• Thiết lập cấu hình an toàn cho hệ quản trị cơ sở dữ liệu
- Phân quyền SQL.
Tài khoản sử dụng cho ứng dụng web trong cơ sở dữ liệu dĩ nhiên phải có quyền
đọc. Nhưng khi thực hiện thao tác thêm bài viết, thêm user thì nó phải cần thêm
quyền ghi nữa. Do đó, tùy vào mỗi trường hợp mà ta thiết lập role phù hợp cho mỗi
tài khoản web tương tác với cơ sở dữ liệu. Với những ứng dụng web thông thường,
tài khoản cho ứng dụng web trong SQL SERVER nên chỉ được thiết lập quyền đọc
(SELECT) (db_datareader) và quyền ghi (INSERT, UPDATE) (db_datawriter) như
vậy sẽ không có quyền xóa một table.
2.3. XSS Injection.
Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất
hiên nay, đồng thời nó cũng là một trong những vấn đề bảo mật quan trọng đối với
các nhà phát triển web và cả những người sử dụng web. Bất kì một website nào cho
phép người sử dụng đăng thông tin mà không có sự kiểm tra chặt chẽ các đoạn mã
nguy hiểm thì đều có thể tiềm ẩn các lỗi XSS. Trong bài viết này tôi sẽ đề cập sơ
lược tới XSS với một số kinh nghiệm của tôi qua kĩ thuật tấn công này.
2.3.1 XSS là gì?
21
Hình 2.1 Minh họa XSS


Một iframe với kích thước 0×0 được chèn vào trang web và sẽ tự động load
trang lấy cookie của hacker tại địa chỉ http://hacker.com/getcookie.php. Khi có
được cookie, hacker có thể dễ dàng đăng nhập mà không cần biết mật khẩu của
người dùng.
Kiểu tấn công này thường gây hại cho người dùng.
Reflected XSS (phản hồi XSS)
Khác với Stored-XSS, Reflected-XSS đoạn mã khai thác sẽ không được lưu trữ
trên server. Một ví dụ điển hình của Reflected-XSS là kết quả trả về của
module search:
24
Ta thấy từ khóa tìm kiếm mà ta nhập vào ô textbox được hiển thị lại trên trình
duyệt. Lợi dụng việc không kiểm soát giá trị này, Hacker thể chèn thêm đoạn mã
gây hại vào. Đường link sẽ có dạng:
http://www.example.com/search.php?q=<script>alert(“XSS”)</script>
Tuy nhiên đoạn mã độc hại này chỉ được kích hoạt khi nạn nhân click đường
link trên.
Do vậy, cách mà Hacker sử dụng lỗi này để tấn công người dùng đó là làm sao
để người đó click vào các link chứa mã độc này.
• Reflected XSS và Stored XSS có 2 sự khác biệt lớn
trong quá trình tấn công:
+ Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân truy
cập vào URL của mình. Còn Stored XSS không cần phải thực hiện việc này, sau
khi chèn được mã nguy hiểm vào CSDL của ứng dụng, hacker chỉ việc ngồi chờ
nạn nhân tự động truy cập vào. Với nạn nhân, việc này là hoàn toàn bình thường vì
họ không hề hay biết dữ liệu mình truy cập đã bị nhiễm độc.
+ Thứ 2, mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn
công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với Reflected
XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy cập đến URL
mà hắn ta cung cấp để thực thi mã độc. Nhưng Stored XSS thì khác, vì mã độc đã