NGHIÊN CỨU LỰA CHỌN MỘT SỐ CÔNG CỤ ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CHO ỨNG DỤNG WEB

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA TOÁN – CƠ – TIN HỌC

Trần Thị Luyến

NGHIÊN CỨU LỰA CHỌN MỘT SỐ CÔNG
CỤ ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CHO
ỨNG DỤNG WEB

Khóa luận tốt nghiệp đại học hệ chính quy
Ngành: Toán - Tin ứng dụng

Hà Nội – 2014


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA TOÁN – CƠ – TIN HỌC

Trần Thị Luyến

NGHIÊN CỨU LỰA CHỌN MỘT SỐ CÔNG
CỤ ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CHO
ỨNG DỤNG WEB

Khóa luận tốt nghiệp đại học hệ chính quy
Ngành: Toán - Tin ứng dụng

Cán bộ hướng dẫn: TS. Hồ Văn Hương

Hà Nội - 2014


MỤC LỤC
LỜI MỞ ĐẦU ..........................................................Error: Reference source not found
CHƯƠNG 1: TỔNG QUAN VỀ AN NINH AN TOÀN ỨNG DỤNG WEB........ Error:
Reference source not found
1.1 Khái niệm ứng dụng Web ..................................Error: Reference source not found
1.2 Các công nghệ dùng trong ứng dụng Web ..........Error: Reference source not found
1.2.1 Giao thức HTTP ...............................................Error: Reference source not found
1.2.2 Công nghệ được sử dụng trong chức năng của ứng dụng Web .....Error: Reference
source not found
1.3 Cơ chế phòng thủ trong ứng dụng Web ..............Error: Reference source not found
1.4 Các rủi ra thường gặp trong ứng dụng Web .........Error: Reference source not found
CHƯƠNG 2: TÌM HIỂU MỘT SỐ LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB . .Error:
Reference source not found
2.1 SQL Injection ......................................................Error: Reference source not found
2.1.1 Khái niệm lỗi SQL Injection ..............................Error: Reference source not found
2.1.2 SQL Injection do không lọc các ký tự “escape”. . Error: Reference source not found
2.1.3 SQL Injection do không kiểm soát tốt kiểu của biến. . . .Error: Reference source not
found
2.1.4 SQL Injection do các hàm của hệ quản trị cơ sở dữ liệu. ....Error: Reference source
not found
2.2 Cross Site Scripting (XSS) ..................................Error: Reference source not found
2.2.1 Khái niệm lỗi XSS ............................................Error: Reference source not found
2.2.2 Nguyên nhân gây lỗi XSS .................................Error: Reference source not found
2.2.3 Phân loại lỗi XSS ..............................................Error: Reference source not found
2.2.4 Kịch bản khai thác lỗi XSS ...............................Error: Reference source not found
2.3 Session ID Management (Chiếm hữu phiên làm việc) . .Error: Reference source not

found
2.3.1 Tấn công kiểu “Ấn định phiên làm việc”........... Error: Reference source not found
2.3.2 Tấn công kiểu “Đánh cắp phiên làm việc” .........Error: Reference source not found
CHƯƠNG 3: SỬ DỤNG CÔNG CỤ ĐỂ QUÉT LỖ HỔNG BẢO MẬT ỨNG DỤNG
WEB ........................................................................Error: Reference source not found
3.1 AppScan Standard ...............................................Error: Reference source not found
3.1.2 Yêu cầu khi cài đặt hệ thống ..............................Error: Reference source not found
3.1.2.1 Yêu cầu về phần cứng ....................................Error: Reference source not found
3.1.2.2 Yêu cầu về phần mềm ....................................Error: Reference source not found


3.1.2.3 Đánh giá điểm yếu an ninh ứng dụng Web bằng AppScan .........Error: Reference
source not found
3.2 Acunetix Web Vulnerability Scanner .....................Error: Reference source not found
3.3 So sánh hai công cụ..............................................Error: Reference source not found
3.5 Ứng dụng dùng Acunetix Web Vulnerability Scanner quét website ..Error: Reference
source not found
KẾT LUẬN ............................................................Error: Reference source not found
TÀI LIỆU THAM KHẢO
CHƯƠNG 2: TÌM HIỂU MỘT SỐ LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB
14
2.1.4 SQL Injection do các hàm của hệ quản trị cơ sở dữ liệu. 16
2.2.2 Nguyên nhân gây lỗi XSS 20
2.2.3 Phân loại lỗi XSS 21
2.2.4 Kịch bản khai thác lỗi XSS 21
2.3 Session ID Management (Chiếm hữu phiên làm việc) 22
2.3.1 Tấn công kiểu “Ấn định phiên làm việc” 23
CHƯƠNG 3: SỬ DỤNG CÔNG CỤ ĐỂ QUÉT LỖ HỔNG BẢO MẬT ỨNG
DỤNG WEB 25
3.1.2.1 Yêu cầu về phần cứng 26

3.1.2.2 Yêu cầu về phần mềm 26
3.1.2.3 Đánh giá điểm yếu an ninh ứng dụng Web bằng AppScan 27


LỜI CẢM ƠN
Trước tiên em xin được bày tỏ lòng biết ơn tới các thầy cô giáo đã và đang
công tác tại khoa Toán – Cơ - Tin trường Đại học Khoa học Tự Nhiên Hà Nội,
những người đã giảng dạy và cung cấp những kiến thức khoa học quý báu trong
suốt những năm học vừa qua để em có nền tảng kiến thức thực hiện khóa luận này.
Đặc biệt, em xin bày tỏ lòng biết ơn sâu sắc đến TS. Hồ Văn Hương, người
đã tận tình chỉ bảo, giúp đỡ và tạo điều kiện về nhiều mặt để em có thể hoàn thành
khóa luận này.
Em cũng xin gửi lời cảm ơn tới tập thể lớp K55A3, trường Đại học Khoa
học Tự Nhiên đã giúp đỡ, nhiệt tình chia sẻ đóng góp những kinh nghiệm quý
báu cho em.
Cuối cùng em xin cảm ơn gia đình, bạn bè đã giúp đỡ, tạo điều kiện và đóng
góp cho em nhiều ý kiến quý báu trong cuộc sống, công việc và học tập nói chung
cũng như trong quá trình thực hiện khóa luận này.
Mặc dù đã có nhiều cố gắng nhưng do hạn hẹp về kiến thức, kinh nghiệm,
thời gian tìm hiểu và thực hiện nên khóa luận không tránh khỏi những thiếu sót. Em
rất mong nhận được sự góp ý của thầy cô, bạn bè để em có thể hoàn thành tốt khóa
luận của mình.
Hà Nội, tháng 05 năm 2014
Sinh viên
Trần Thị Luyến


DANH SÁCH CÁC CHỮ VIẾT TẮT
Ký hiệu
ASP

CGI
CSS
DHTML
DOM
HTML
HTTP
HTTPS
IIS
IBM
JSP
MIME
OS
OWASP
PHP
RAM
SOAP
SQL
TCP/IP
SSL
URL
VBScript
XML
XSS

Tiếng Anh
Active Server Pages
Common Gateway Interface
Cascading Style Sheet
Dynamic HTML
Document Object Model

Hypertext Markup Language
Hypertext Transfer Protocol
HTTP + SSL
Internet Information Services
International Business Machines Corporation
Java Server Pages
Multipurpose Internet Mail Extensions
Operating System
Open Web Application Security Project
Hypertext Preprocessor
Random Access Memory
Simple Object Access Protocol
Structured Query Language
Internet protocol suite
Secure Socket Layer
Uniform Resource Locator
Visual Basic Script
eXtensible Markup Language
Cross-Site Scripting


DANH SÁCH CÁC BẢNG
CHƯƠNG 2: TÌM HIỂU MỘT SỐ LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB
14
Trên thực tế có rất nhiều loại lỗ hổng an ninh mà một ứng dụng Web có thể mắc
phải, tương ứng với nó là các kiểu tấn công khác nhau. Chương này sẽ phân tích
cụ thể một số lỗ hổng nguy hiểm và phổ biến mà ứng dụng Web có thể mắc phải
hiện nay. 14
2.1.4 SQL Injection do các hàm của hệ quản trị cơ sở dữ liệu. 16
2.2.2 Nguyên nhân gây lỗi XSS 20

2.2.3 Phân loại lỗi XSS 21
2.2.4 Kịch bản khai thác lỗi XSS 21
2.3 Session ID Management (Chiếm hữu phiên làm việc) 22
2.3.1 Tấn công kiểu “Ấn định phiên làm việc” 23
CHƯƠNG 3: SỬ DỤNG CÔNG CỤ ĐỂ QUÉT LỖ HỔNG BẢO MẬT ỨNG
DỤNG WEB 25
3.1.2.1 Yêu cầu về phần cứng 26
3.1.2.2 Yêu cầu về phần mềm 26
3.1.2.3 Đánh giá điểm yếu an ninh ứng dụng Web bằng AppScan 27

DANH SÁCH CÁC HÌNH
CHƯƠNG 2: TÌM HIỂU MỘT SỐ LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB
14
Trên thực tế có rất nhiều loại lỗ hổng an ninh mà một ứng dụng Web có thể mắc
phải, tương ứng với nó là các kiểu tấn công khác nhau. Chương này sẽ phân tích
cụ thể một số lỗ hổng nguy hiểm và phổ biến mà ứng dụng Web có thể mắc phải
hiện nay. 14
2.1.4 SQL Injection do các hàm của hệ quản trị cơ sở dữ liệu. 16
2.2.2 Nguyên nhân gây lỗi XSS 20
2.2.3 Phân loại lỗi XSS 21
2.2.4 Kịch bản khai thác lỗi XSS 21
2.3 Session ID Management (Chiếm hữu phiên làm việc) 22
2.3.1 Tấn công kiểu “Ấn định phiên làm việc” 23


CHƯƠNG 3: SỬ DỤNG CÔNG CỤ ĐỂ QUÉT LỖ HỔNG BẢO MẬT ỨNG
DỤNG WEB 25
3.1.2.1 Yêu cầu về phần cứng 26
3.1.2.2 Yêu cầu về phần mềm 26
3.1.2.3 Đánh giá điểm yếu an ninh ứng dụng Web bằng AppScan 27

LỜI MỞ ĐẦU
Ngày nay, ứng dụng Web đã có mặt trong hầu hết mọi lĩnh vực của cuộc
sống hiện đại từ các nhu cầu cơ bản như tìm kiếm sản phẩm, mua sắm đến các nhu
cầu hiện đại, đặc trưng của thời đại như trao đổi tâm sự, chia sẻ thông tin trên mạng
xã hội. Đặc biệt trong lĩnh vực thương mại điện tử hiện nay, rất nhiều doanh nghiệp
đang sử dụng ứng dụng Web để quảng bá hình ảnh, kết nối với khách hàng, đối tác
và cung cấp dịch vụ thương mại trực tuyến. Cùng với sự phát triển nhanh chóng của
ứng dụng Web thì vấn đề bảo mật ứng dụng Web đang là lĩnh vực vô cùng nóng hổi
nhằm đảm bảo an toàn cho tất cả người dùng ứng dụng. Vậy nếu có một lỗi bảo mật
xảy ra trong ứng dụng Web thì điều này có thể ảnh hướng tới tất cả người dùng, ảnh
hưởng tới uy tín của công ty, tổ chức đó, gây mất mát về mặt tài chính và các ràng
buộc về pháp lý,…
Theo thống kê của tổ chức OWASP (Open Web Application Security Project)
trong những năm gần đây thì lỗ hổng bảo mật của ứng dụng Web ngày càng tăng mà
nguyên nhân chính đó là sự lơi lỏng trong việc lập trình Web, sự đa dạng của các
phần mềm ứng dụng và một số hạn chế trong việc kiểm tra tính bảo mật của ứng
dụng đó.
Vì vậy khóa luận “Nghiên cứu lựa chọn một số công cụ đánh giá độ an toàn
và bảo mật cho ứng dụng Web” sẽ đáp ứng phần nào nhu cầu cấp thiết về an ninh
bảo mật hiện nay. Trên cơ sở nghiên cứu và lựa chọn hệ thống hỗ trợ mã nguồn mở,
có khả năng tự động quét toàn bộ cấu trúc Website từ bên ngoài, từ đó đưa ra báo
cáo đánh giá về an toàn thông tin cho Website nhằm nâng cao tính chính xác và
giảm thiểu chi phí trong việc kiểm tra và chứng thực tính an ninh của một
Website…
Nội dung chính của bài khóa luận gồm ba chương và phần kết luận:
•

Chương 1: tổng quan về an ninh, an toàn ứng dụng Web. Chương này

sẽ trình bày kiến thức tổng quan về ứng dụng Web như kiến trúc, phương thức hoạt
động, cơ chế bảo mật của nó cũng như các rủi ro thường gặp nhất trong ứng dụng
Web, từ đó làm cơ sở cho việc kiểm tra, đánh giá bảo mật ứng dụng Web.

1


•

Chương 2: tìm hiểu một số lỗ hổng ứng dụng Web. Chương này phân

tích một số tấn công vào 3 lỗ hổng chiếm tỷ lệ cao nhất hiện nay đối với ứng dụng
Web của Việt Nam và thế giới là: SQL Injection, Cross Site Scripting và Chiếm hữu
phiên làm việc.
•

Chương 3: sử dụng công cụ để quét lỗ hổng bảo mật ứng dụng Web.

Trên cơ sở lý thuyết phân tích các lỗ hổng, chương này giới thiệu hai công cụ được
dùng trong việc quét các lỗ hổng nhằm phát hiện, đánh giá các lỗ hổng bảo mật của
ứng dụng Web. Qua đó so sánh, lựa chọn một công cụ có giải pháp tối ưu về kiểm
định, đánh giá các lỗ hổng ứng dụng Web.
•

Kết luận: tổng kết khóa luận và hướng phát triển nghiên cứu.

2

CHƯƠNG 1: TỔNG QUAN VỀ AN NINH AN TOÀN ỨNG
DỤNG WEB
Phần này sẽ trình bày kiến thức tổng quan về ứng dụng Web như kiến trúc,
phương thức hoạt động, hay cơ chế bảo mật của nó, từ đó làm cơ sở cho việc kiểm
tra, đánh giá bảo mật ứng dụng Web.
Những khái niệm cơ bản của chương một chủ yếu dựa vào tài liệu [1,4].
1.1
Khái niệm ứng dụng Web
Trong những ngày đầu của Internet, World Wide Web là tập hợp những site
chứa các trang Web là các tài liệu tĩnh. Ngày nay, hình thức của nó đã thay đổi rất
nhiều. Đa số các trang Web trên Website là các ứng dụng thực tế. Các ứng dụng này
hỗ trợ việc đăng ký, đăng nhập, giao dịch tài chính, tìm kiếm…, các nội dung được
trình bày cho người sử dụng được tạo ra tự động và thường được thiết kế cho mỗi
người dùng cụ thể. Ứng dụng Web được tạo ra để thực hiện tất cả các chức năng
hữu ích mà có thể thực hiện trực tuyến. Có rất nhiều cách hiểu khác nhau về ứng
dụng Web, dưới góc độ kỹ thuật, dưới góc độ chức năng…
Dưới góc độ chức năng, ứng dụng Web là các chương trình máy tính cho
phép người dùng website đăng nhập, truy vấn vào ra dữ liệu qua mạng Internet trên
trình duyệt Web của người dùng. Dữ liệu sẽ được gửi tới người dùng trong trình
duyệt theo kiểu thông tin động (trong một định dạng cụ thể, như với HTML thì
dùng CSS) từ ứng dụng Web qua một Web Server.
Để hiểu hết được ý nghĩa của khái niệm này chúng ta cùng đi sâu tìm hiểu
mô hình cấu trúc chức năng của ứng dụng Web.

Hình 1: Mô hình hoạt động của ứng dụng Web

3


Hình 1 mô hình hóa hoạt động của một ứng dụng Web điển hình trong đó:

Trình khách (Web client): là trình duyệt Web. Nó thông qua giao thức
HTTP (hay một số giao thức khác) và hoàn lại HTML (hay một số ngôn ngữ khác
như Dynamic HTML, XML,…). Web client được dùng để biểu diễn dữ liệu được
xử lý bởi máy chủ Web và nhận dữ liệu từ người dùng.
Tường lửa (Firewall): là một kỹ thuật được tích hợp vào hệ thống mạng để
chống sự truy cập trái phép nhằm bảo vệ các nguồn thông tin nội bộ cũng như hạn
chế sự xâm nhập vào hệ thống của một số thông tin khác không mong muốn.
Trình chủ (Web Server): được mô tả đơn giản nhất như một deamon HTTP
(dịch vụ) nhận các yêu cầu từ client, thực hiện một số phân tích cơ bản theo yêu cầu
sau đó đưa nó tới ứng dụng Web để xử lý. Khi ứng dụng Web trả về một phản hồi,
HTTP deamon trả nó về cho client. Một số phần mềm máy chủ Web phổ biến hiện
nay như Microsoft IIS, Apache HTTP Server…
Ứng dụng Web (Web Application): là một chương trình phần mềm ứng
dụng thực hiện chức năng nào đó. Để hiểu hơn về Web Application cần hiểu về “ntier”. “n-tier” là một kiến trúc mở rộng tạo ra sự liền mạch cho ứng dụng mà người
dùng có thể tương tác trong thời gian thực. Một “n-tier” điển hình là kiến trúc gồm
ba lớp: lớp trình bày, lớp ứng dụng và lớp dữ liệu.

Hình 2: Kiến trúc của ứng dụng web
Lớp trình bày có nhiệm vụ tương tác với người dùng, nhận lệnh từ trình
duyệt gửi lên server, chờ xử lý, nhận các dữ liệu, bố cục trình bày và hiển thị kết
quả tại trình duyệt người dùng. Lớp ứng dụng là nơi xử lý các yêu cầu gửi lên từ
trình duyệt. Nó sẽ phân tích các thông tin, đưa ra quyết định, xử lý kết quả và gửi
đến lớp trình bày. Lớp này thường được cài đặt bằng các kỹ thuật lập trình như:

4


Java, .Net, PHP… được triển khai trên các trình chủ như IIS, Apache… Cuối cùng,
lớp dữ liệu chịu trách nhiệm quản lý các file dữ liệu và quyền sử dụng.
Nhiều công nghệ được sử dụng để xây dựng các ứng dụng tích hợp chức

năng của một hay nhiều tầng này, vì vậy thật khó để phân biệt chúng trong một ứng
dụng thực tế.
Cơ sở dữ liệu (Database): chịu trách nhiệm lưu trữ dữ liệu, cho phép tìm
kiếm, trích xuất, cập nhật dữ liệu. Đây là môi trường trung gian cho phục hồi thông
tin và thương mại điện tử. Các nhà cung cập và các platform trong lớp dữ liệu
chiếm ưu thế nhất hiện nay là SQL và Oracle.
Tóm lại, quá trình hoạt động bắt đầu với yêu cầu được tạo ra từ người dùng
trên trình duyệt, gửi tới máy chủ Web (Web server) rồi từ máy chủ Web gửi tới trình
chủ ứng dụng Web. Máy chủ ứng dụng Web truy cập máy chủ cơ sở dữ liệu
(Database server) để thực hiện nhiệm vụ được yêu cầu cập nhật, truy vấn thông tin
đang nằm trong cơ sở dữ liệu. Sau đó máy chủ ứng dụng Web tự động sinh ra một
trang Web và gửi nó tới Web Server và từ Web server sẽ gửi thông tin lại cho người
dùng qua trình duyệt.
1.2
Các công nghệ dùng trong ứng dụng Web
Các ứng dụng Web sử dụng nhiều loại công nghệ để thực hiện chức năng của
nó. Ở đây sẽ đề cập một số công nghệ quan trọng, phổ biến mà có khả năng gặp
phải khi kiểm thử các ứng dụng Web.
1.2.1 Giao thức HTTP
Giao thức HTTP (Hypertex Transfer Protocol) là giao thức truyền thông cốt
lõi được sử dụng để truy nhập World Wide Web và tất cả các ứng dụng Web. Giao
thức này hoạt động theo cơ chế request/response mà trong đó client gửi message
request hay yêu cầu và server gửi lại message response hay hồi đáp. HTTP đã được
mở rộng, phát triển theo nhiều hướng khác nhau để hỗ trợ cho các ứng dụng phân
tán phức tạp phổ biến hiện nay.
a. Http Request
Http Request là gói tin yêu cầu mà client gửi lên server. Cấu trúc nó bao gồm
những thành phần sau:

Dòng yêu cầu (request line): chỉ ra phương thức yêu cầu, tài nguyên

yêu cầu và phiên bản http đang sử dụng. Ví dụ: GET/images/logo.gif HTTP/1.1

Các trường thông tin yêu cầu (request header):cho phép máy trạm gửi
kèm các dữ liệu về bản thân nó về yêu cầu đến máy chủ. Trong phạm vi đồ án ta
quan tâm tới một số request header thông dụng sau:
5


Bảng 1: Http Request Headers
Header
Accept
AcceptEncoding
Connectio
n

Host
Referer

UserAgent
CacheControl



Ý nghĩa
Dạng nội dung trả về sẽ được chấp nhận
Dạng mã hóa trả về sẽ được chấp nhận

Ví dụ
Accept: text/plain
Accept-Encoding:

compress, gzip
Xác định dạng của kết nối mà client Connection: close
mong muốn: tiếp tục mở kết nối sau khi
request thành công hay đóng kết nối đó
lại.
Domain name của Server
Host: en.wikipedia.org
Địa chỉ của trang trước đó mà liên kết Referer:
hiện tại được bấm vào.
/>iki/Main_page
Dạng trình duyệt mà client sử dụng, đây User-Agent: Mozilla/5.0
cũng có thể dùng để đánh dấu chương (Linux; X11)
trình nào đang truy vấn trang Web
Được sử dụng để xác định chỉ thị rằng tất Cache-Control: private
cả các cơ chế trong bộ nhớ đệm PHẢI
tuân theo giá trị trong yêu cầu này.

Nội dung message body.

Dưới đây là một ví dụ cho một Http Request.
Get/tintuc/homnay.php HTTP/1.1
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer: http://localhost/lienket.php
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5;
Windows NT 5.0)
Accept-Encoding: gzip, deflate

Mỗi http request luôn được bắt đầu bằng một từ chỉ “phương thức” (method)
yêu cầu (GET, POST, HEAD…). Đây là thành phần xác định các hành động mong
muốn được thực hiện đối với các tài nguyên trên Server.
6


b. Http Response
Http Response là gói tin mà server trả lời cho client. Nó bao gồm mã trả về
(status code), các trường tiêu đề (Headers) và có hoặc không có message body.
HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
Date: Thu, 21 Jun 2013 08:46:34 GTM
Content-Length: 2291
Content-Type: text/html
Set-Cookie: a=17;path=/
Cache-control: private
Có rất nhiều trường khác nhau trong http response: tuy nhiên trong phạm vi
đồ án ta cần tập trung vào các trường sau:
Bảng 2: Http Response Headers
Headers
Allow
ContentEncoding
ContentLength
Server
Set-Cookie
Content-Type

Ý nghĩa
Chỉ định ra các phương thức được
sử dụng đối với tài nguyên này.

Định dạng mã hóa được sử dụng
đối với dữ liệu.
Độ dài của response body tính
theo kiểu số nguyên 8 bit.
Tên, phiên bản… của Web server
đang sử dụng.
Yêu cầu tạo ra các cookie với các
giá trị xác định.
Dạng mime của dữ liệu trả về

Ví dụ
Allow: GET, HEAD
Content-Encoding: gzip
Content-Length: 348
Server:
Apache/1.3.27
(Unix) (Red-Hat/Linux)
Set-Cookie:
a=17;path=/
Content-Type:
text/html;
charset=utf-8

Với status code, đây là một trường rất cần thiết phải quan tâm. Nó là một mã
số gồm 3 chữ số, mô tả kết quả server trả về cho 1 request xác định. Các dạng
Status-code bao gồm:
•
1xx là message thông tin
•

2xx là request thành công và tài nguyên được request sẽ được trả về

trong message body.
•
3xx tự động chuyển đến client đang request một số tài nguyên khác
•

4xx là lỗi phía client
7


•

5xx là lỗi phía server

1.2.2 Công nghệ được sử dụng trong chức năng của ứng dụng Web
Ngoài các giao thức chính được sử dụng để truyền thông giữa server và client,
các ứng dụng Web sử dụng nhiều công nghệ để thực hiện chức năng của mình. Có rất
nhiều công nghệ khác nhau được sử dụng bên phía server và client vì vậy cần phải có
kiến thức cơ bản về những công nghệ này để việc kiểm tra đạt hiệu quả.
a.
Công nghệ sử dụng phía Server
Các thành phần được sử dụng để cung cấp chức năng cho ứng dụng Web bên
phía server gồm có:
+ Ngôn ngữ script như là PHP, VBScript và Perl
+ Platform ứng dụng Web như ASP.NET và Java
+ Các máy chủ Web như Apache, IIS và Netscape Enterprise
+ Cơ sở dữ liệu như MS-SQL, Oracle và MySQL
+ Các thành phần phụ trợ như hệ thống tập tin, các dịch vụ Web dựa trên
SOAP và dịch vụ thư mục.

b.
Công nghệ sử dụng phía client
Đối với các ứng dụng phía server để nhận được đầu vào người dùng và đưa
ra kết quả trở lại cho người dùng thì nó cần phải cung cấp một giao diện người dùng
phía client. Bởi vì tất cả các ứng dụng Web được truy cập thông qua một trình
duyệt Web, nên tất cả những giao diện này chia sẻ một lõi chung các công nghệ.
Tuy nhiên, những giao diện này được xậy dựng dựa trên nhiều cách khác nhau. Một
số công nghệ sử dụng phía client điển hình như là:
+ HTML
+ Ajax
+ Hyperlinks
+ HTML5
+ Forms
+ ”Web 2.0”
+JavaScript
+…
Các công nghệ phía client vẫn tiếp tục phát triển nhanh chóng trong những
năm gần đây.
c.
Trạng thái và các phiên
Các công nghệ được mô tả ở trên cho phép các thành phần máy chủ và máy
khách của một ứng dụng Web trao đổi và xử lý dữ liệu theo nhiều cách. Tuy nhiên,
để thực hiện được hầu hết các chức năng hữu ích, ứng dụng cần phải theo dõi trạng
thái tương tác của người dùng với ứng dụng qua nhiều yêu cầu. Ví dụ, một ứng
dụng mua sắm có thể cho phép người dùng duyệt một danh mục sản phẩm, thêm

8


các sản phẩm vào giỏ hàng, xem và cập nhật nội dung giỏ hàng, tiến hành kiểm tra,

cung cấp các chi tiết cá nhân và thanh toán.
Để thực hiện các yêu cầu của người dùng một cách chính xác, ứng dụng phải
duy trì một bộ trạng thái dữ liệu thông qua các yêu cầu của người dùng gửi đến
server. Dữ liệu này thường được lưu trong cấu trúc phía server được gọi là phiên
(session). Khi người dùng thực hiện một hành động như thêm một mục vào giỏ
hàng, ứng dụng phía server cập nhật các chi tiết liên quan trong phiên của người
dùng. Sau đó khi người dùng xem nội dung giỏ hàng thì dữ liệu từ phiên được sử
dụng để trả về thông tin chính xác cho người dùng.
Trong một số ứng dụng, thông tin trạng thái được lưu trữ trên thành phần
máy khách chứ không phải trên máy chủ. Tập dữ liệu hiện thời được chuyển đến
máy khách trong mỗi hồi đáp của máy chủ và được gửi lại cho máy chủ trong từng
yêu cầu của máy khách. Bởi vì người dùng có thể thay đổi bất kỳ dữ liệu nào được
truyền qua thành phần máy khách, cho nên các ứng dụng cần phải có các biện pháp
bảo vệ phù hợp để những kẻ tấn công không thể thay đổi thông tin trạng thái nhằm
can thiệp vào ứng dụng.
1.3
Cơ chế phòng thủ trong ứng dụng Web
Để người dùng có thể truy cập vào một ứng dụng, vành đai tường lửa phải
cho phép các kết nối gửi đến máy chủ qua HTTP hoặc HTTPS. Và đối với các ứng
dụng chức năng, máy chủ phải được phép kết nối tới hệ thống Database. Những hệ
thống này thường là cốt lõi của mọi hoạt động của tổ chức và cư trú đằng sau nhiều
lớp phòng thủ cấp mạng. Nếu một lỗ hổng tồn tại trong một ứng dụng Web, một kẻ
tấn công trên Internet có thể thỏa hiệp hệ thống Database bằng cách gửi dữ liệu độc
từ trình duyệt Web của mình. Dữ liệu này vượt qua tất cả các lớp phòng vệ mạng
của tổ chức một cách bình thường tới ứng dụng Web và kẻ tấn công sẽ chiếm được
dữ liệu nhạy cảm trên hệ thống Database. Đây là vấn đề tiềm năng cho một loạt các
cuộc tấn công và phòng thủ chống lại các cuộc tấn công phải được thực hiện trong
các ứng dụng.
Vấn đề an ninh cơ bản với các ứng dụng Web – đó là tất cả đầu vào người
dùng là không đáng tin cậy – làm phát sinh một số cơ chế bảo mật mà các ứng dụng

sử dụng để bảo vệ mình chống lại các cuộc tấn công. Phần này mô tả các cơ chế bảo
mật chính mà ứng dụng Web sử dụng để giải quyết vấn đề cơ bản này. Các cơ chế
phòng thủ được sử dụng trong các ứng dụng Web như sau:
+ Xử lý truy cập người dùng
+ Xử lý đầu vào người dùng
9


+ Xử lý kẻ tấn công
+ Quản lý ứng dụng
a.
Xử lý truy cập người dùng
Có các loại người dùng khác nhau chẳng hạn như người dùng vô danh, người
dùng được xác thực thông thường, và người dùng quản trị. Mỗi loại người dùng
khác nhau được phép truy cập một tập dữ liệu khác nhau. Vì vậy hầu như bất kỳ
ứng dụng nào đều cần phải đáp ứng được việc kiểm soát người dùng truy cập vào
dữ liệu và chức năng của nó. Các ứng dụng Web xử lý truy cập bằng cách sử dụng
ba cơ chế bảo mật liên quan đến nhau:
+ Xác thực
+ Quản lý phiên
+ Kiểm soát truy cập
Mỗi cơ chế này là nền tảng cho thế trận an ninh tổng thể của một ứng dụng.
Vì sự phụ thuộc lẫn nhau của chúng, một khiếm khuyết trong bất kỳ thành phần đơn
lẻ nào đều có thể cho phép kẻ tấn công truy cập không hạn chế tới các chức năng và
dữ liệu của ứng dụng. Xử lý truy cập người dùng tới dữ liệu của ứng dụng nhằm
ngăn chặn người dùng khác truy cập trái phép.
b.
Xử lý đầu vào người dùng
Lỗ hổng dựa trên đầu vào có thể phát sinh bất cứ nơi nào trong chức năng
của một ứng dụng. Tuy nhiên, không có cơ chế đơn lẻ nào có thể được sử dụng. Xử

lý đầu vào người dùng nhằm ngăn chặn đầu vào bị thay đổi gây ra hành vi không
mong muốn.
c.
Xử lý kẻ tấn công
Một chức năng quan trọng trong cơ chế bảo mật ứng dụng là có thể xử lý và
phản ứng lại với các tấn công theo một cách có kiểm soát. Những cơ chế này
thường kết hợp một biện pháp phòng thủ và tấn công được thiết kế để làm thất bại
một kẻ tấn công càng nhiều càng tốt và cung cấp cho chủ sở hữu của ứng dụng
thông báo và bằng chứng thích hợp về những gì đã diễn ra. Thực hiện các biện pháp
để xử lý những kẻ tấn công thường bao gồm các nhiệm vụ sau:
+ Xử lý thông báo lỗi
+ Duy trì kiểm toán nhật ký
+ Tạo cảnh báo tới quản trị
+ Phản ứng lại kẻ tấn công

10


Xử lý kẻ tấn công để đảm bảo rằng các ứng dụng cư xử thích hợp khi là mục
tiêu trực tiếp, lấy phòng thủ và các biện pháp tấn công thích hợp để chống lại những
kẻ tấn công.
d.
Quản lý ứng dụng
Bất kỳ ứng dụng hữu ích nào đều cần phải được quản lý, điều hành. Khả
năng này tạo thành một phần quan trọng của cơ chế bảo mật ứng dụng, cung cấp
cho các quản trị viên cách quản lý tài khoản người dùng và các vai trò, các chức
năng giám sát truy cập và kiểm toán, thực hiện các nhiệm vụ chẩn đoán, và cấu hình
các mặt chức năng của ứng dụng.
Các cơ chế phòng thủ trong ứng dụng Web có vai trò trung tâm trong việc
giải quyết vấn đề an ninh cốt lõi, các cơ chế này cũng chiếm phần lớn bề mặt tấn

công một ứng dụng điển hình. Tìm hiểu thấu đáo những cơ chế này là phần không
thể thiếu trong việc xác định điểm yếu ứng dụng.
1.4
Các rủi ra thường gặp trong ứng dụng Web
Phát hiện ra lỗ hổng bảo mật thì quan trọng, nhưng quan trọng hơn là việc có
thể để ước tính rủi ro liên quan đến công việc của tổ chức, doanh nghiệp. Kẻ tấn
công có thể lợi dụng nhiều con đường khác nhau thông qua ứng dụng để làm tổn hại
doanh nghiệp hay tổ chức. Mỗi con đường thể hiện một rủi ro khác nhau mà có thể
có hoặc không gây ra sự chú ý. Những mỗi rủi ro có thể đi từ không có gì đến việc
khiến cho tổ chức, doanh nghiệp phá sản. Để có thể xác định được những rủi ro cho
tổ chức, doanh nghiệp thì cần phải tính toán khả năng hiện hữu của mỗi nguy hiểm,
những yếu tố tấn công và những điểm yếu bảo mật. Tập hợp chúng lại với một sự
cân nhắc về sự ảnh hưởng của chúng cả về kỹ thuật lẫn kinh doanh đối với tổ chức
hình thành nên tập hợp rủi ro. Theo thống kê mới nhất năm 2013, tổ chức OWASP
đưa ra các rủi ro thường gặp nhất trong ứng dụng Web như sau:
•
Lỗi nhúng mã: xảy ra trong các ứng dụng như SQL, OS khi những dữ
liệu không xác thực được gửi tới hệ thống biên dịch như một phần của mã lệnh.
Những dữ liệu này của kẻ tấn công có thể lừa hệ thống biên dịch thực hiện những
mã lệnh độc hại hoặc giúp kẻ tấn công xâm nhập đến những dữ liệu quan trọng một
cách trái phép.
•
Hư hỏng cơ chế chứng thực và quản lý phiên làm việc: các chức năng
ứng dụng liên quan đến thẩm định và quản lý phiên thường không được thực hiện
một cách chính xác. Điều này cho phép kẻ tấn công có thể ăn cắp mật khẩu, mã của
phiên làm việc (session tocken) hoặc tận dụng những lỗi khác để giả mạo danh tính
của người dùng khác.
11

•

Thực thi mã script xấu: xảy ra khi một ứng dụng tiếp nhận những dữ

liệu không đáng tin cậy và gửi chúng đến cho trình duyệt Web mà không qua xử lý
và kiểm duyệt. XSS cho phép kẻ tấn công thực hiện mã độc trên trình duyệt của
người bị tấn công và lợi dụng ăn cắp phiên truy cập để mạo danh hoặc lừa người sử
dụng đến những trang Web chứa mã độc khác.
•
Đối tượng tham chiếu thiếu an toàn: đối tượng tham chiếu xảy ra khi
người phát triển để lộ một tham chiếu đến những đối tượng trong hệ thống như các
tập tin, thư mục… Nếu không có một hệ thống kiểm tra truy cập, kẻ tấn công có thể
lợi dụng những tham chiếu này để truy cập dữ liệu một cách trái phép.
•
Sai sót trong cấu hình bảo mật: một cơ chế an ninh tốt cần phải có một
cấu hình bảo mật được xác định và triển khai cho các ứng dụng, các framework,
máy chủ ứng dụng, máy chủ Web, máy chủ dữ liệu và các ứng dụng platform. Tất
cả những thiết lập này nên được xác định, thực thi và bảo trì bởi vì rất nhiều thứ
không được triển khai với thiết lập an toàn mặc định. Cấu hình bảo mật cũng bao
gồm cập nhật phần mềm và những thư viện được sử dụng bởi ứng dụng.
•
Phơi bày dữ liệu nhạy cảm: nhiều ứng dụng Web không bảo vệ dữ liệu
nhạy cảm đúng cách, chẳng hạn như thẻ tín dụng, mã số thuế, và các thông tin xác
thực. Kẻ tấn công có thể ăn cắp hoặc sửa đổi dữ liệu được bảo vệ một cách yếu ớt
như vậy để thực hiện hành vi trộm cắp danh tính, gian lận thẻ tín dụng, và các hành
vi xấu khác. Dữ liệu nhạy cảm cần phải được bảo vệ hơn nữa chẳng hạn như mã
hóa ở phần còn lại hoặc trong truyền dẫn, cũng như các biện pháp phòng ngừa đặc
biệt khi trao đổi với các trình duyệt.
•
Thiếu chức năng điều khiển mức truy cập: hầu hết các ứng dụng Web

kiểm tra cấp độ quyền truy cập trước khi thể hiện cho người dùng thấy trong giao
diện người dùng. Tuy nhiên, các ứng dụng cần phải thực hiện điều khiển truy cập
trên cùng máy chủ mỗi khi được truy cập. Nếu yêu cầu không được kiểm tra xác
nhận, kẻ tấn công có thể giả mạo yêu cầu để truy cập trái phép.
•
Giảo mạo yêu cầu (Cross Site Request Forgery): kiểu tấn công này ép
buộc trình duyệt Web của một người dùng đã đăng nhập gửi những yêu cầu HTTP
giả mạo tới một ứng dụng Web bị lỗi, bao gồm cookie của phiên truy cập và những
thông tin tự động khác như thông tin đăng nhập. Cách thức này cho phép kẻ tấn
công buộc trình duyệt Web của người dùng tạo ra những yêu cầu cho ứng dụng lỗi
mà ứng dụng này không thể biết đây là những yêu cầu giả mạo của kẻ tấn công.
•
Sử dụng các thành phần dễ bị tổn thương đã biết: các thành phần dễ bị
tổn thương chẳng hạn như: các thư viện, các framework, và các môđun phần mềm
12


khác hầu như luôn chạy với đầy đủ đặc quyền. Vì vậy, nếu bị khai thác, chúng có
thể gây mất dữ liệu nghiêm trọng hoặc máy chủ bị xâm chiếm. Các ứng dụng sử
dụng các thành phần dễ bị tổn thương này có thể làm suy yếu phòng thủ và cho
phép một loạt các cuộc tấn công có thể thực hiện.
•
Chuyển hướng và chuyển tiếp thiếu thẩm tra: các ứng dụng Web
thường xuyện đưa người dùng đến những liên kết qua các Website khác, và sử dụng
những thông tin thiếu tin cậy để xác định đích đến. Nếu không được kiểm tra một
cách cẩn thận, kẻ tấn công có thể lợi dụng để chuyển nạn nhân đến các trang Web
lừa đảo (phishing) hay phần mềm độc hại, hoặc chuyển tiếp để truy cập các trang
trái phép.
Chúng ta cần phải hiểu rằng rủi ro không phải điểm yếu. Các rủi ro được
thiết lập dựa trên việc xem xét những khă năng xảy ra và hậu quả của mỗi điểm yếu

gây ra cho ứng dụng. Ngoài những rủi ro phổ biến trên còn rất nhiều những vấn đề
có thể ảnh hưởng tới toàn bộ sự an toàn của các ứng dụng Web. Do sự tiến bộ của
kẻ tấn công, sự ra đời của những công nghệ mới, và sự thiết lập của những hệ thống
ngày càng phức tạp, những rủi ro về ứng dụng Web theo đó thay đổi liên tục.
Nắm bắt được các rủi ro trong ứng dụng Web, sẽ có thể ước tính mức độ
nghiêm trọng của tất cả các rủi ro đối với tổ chức, doanh nghiệp, và đưa ra quyết
định về những gì cần làm với chúng.

13


CHƯƠNG 2: TÌM HIỂU MỘT SỐ LỖ HỔNG BẢO MẬT ỨNG
DỤNG WEB
Trên thực tế có rất nhiều loại lỗ hổng an ninh mà một ứng dụng Web có thể
mắc phải, tương ứng với nó là các kiểu tấn công khác nhau. Chương này sẽ phân
tích cụ thể một số lỗ hổng nguy hiểm và phổ biến mà ứng dụng Web có thể mắc
phải hiện nay.
Những khái niệm cơ bản của chương hai dựa chủ yếu vào tài liệu [2].
2.1 SQL Injection
Khi triển khai các ứng dụng Web trên Internet, nhiều người vẫn nghĩ rằ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 vấn đề như chọn hệ điều hành, hệ quản trị cơ
sở dữ liệu,…mà quên mất rằng ngay cả bản thân ứng dụng Web chạy trên đó cũng
tiềm ẩn một lỗ hổng bảo mật rất lớn đó là SQL Injection. Vậy SQL Injection là gì?
2.1.1 Khái niệm lỗi SQL Injection
SQL Injection (chèn câu truy vấn SQL) 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). 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 [3].
SQL Injection có thể được phân chia thành nhiều loại khác nhau, nhưng bản
chất gây ra lỗi thì chỉ có 3 dạng:
- Không lọc các ký tự “escape” – những ký tự có thể gây ngắt câu truy vấn SQL.
- Kiểm soát không tốt “kiểu” của biến, ví dụ: một biến định kiểu số nhưng
nếú người dùng nhập 1 xâu thì vẫn được chấp nhận.
- Lỗi do các hàm của hệ quản trị cơ sở dữ liệu.
2.1.2 SQL Injection do không lọc các ký tự “escape”.
Trong kỹ thuật lập trình, ký tự thoát (escape character) là một dạng ký tự đặc
biệt, như các mã điều khiển, ký tự bắt đầu các biến, các xâu…
Nếu như các ký tự này không được lọc bỏ mà được đưa trực tiếp vào câu
truy vấn SQL thì nó có thể gây ra việc ngắt câu truy vấn, từ đó gây lỗi hoặc thay đổi
cấu trúc câu SQL.
14


Xét ví dụ sau:
statement = "SELECT * FROM users WHERE name = '" +
userName + "';"
Câu SQL trên được thiết kế nhằm chọn ra tất cả các bản ghi của một
username xác định trong bảng users. Tuy nhiên, nếu biến “userName” bị thay đổi
theo một cách phù hợp thì câu truy vấn kia có thể thực hiện khác đi so với thiết kế
ban đầu của nó. Chẳng hạn, người ta có thể nhập giá trị cho biến “userName” là:
a' or 't'='t
Khi đó câu truy vấn SQL trở thành:
SELECT *
't'='t';

FROM

users

WHERE

name

=

'a'

OR

Nếu đoạn mã này được sử dụng trong một thủ tục xác nhận đăng nhập thì ví
dụ trên sẽ buộc ứng dụng chọn ra một username hợp pháp trong cơ sở dữ liệu, bởi
vì mệnh đề ‘t’=’t’ luôn luôn cho ra kết quả “true”.
Một số hệ quản trị cơ sở dữ liệu, như SQL Server còn cho phép thực hiện
nhiều câu truy vấn cùng lúc trong mệnh đề SQL, điều này khiến cho hacker có thể
thực hiện thêm nhiều câu truy vấn nguy hiểm nếu như ứng dụng bị mắc lỗi SQL
Injection:
Ví dụ, cũng với đoạn mã trên, nếu biến username được nhập vào giá trị sau:
a';DROP TABLE users; SELECT * FROM data WHERE name
LIKE '%
Thì câu truy vấn SQL được tạo ra sẽ là:
SELECT * FROM users WHERE name = 'a';DROP TABLE
users; SELECT * FROM DATA WHERE name LIKE '%';
Khi câu truy vấn trên được thực thi, toàn bộ bảng users sẽ bị xóa khỏi cơ sở
dữ liệu.

2.1.3 SQL Injection do không kiểm soát tốt kiểu của biến.
Dạng thứ hai gây ra lỗi SQL Injection là không kiểm soát tốt kiểu của biến.
Như ta thấy ở trên, thông thường nếu muốn ngắt 1 câu truy vấn SQL thì hacker cần
chèn được các ký tự đặc biệt vào câu truy vấn đó. Hacker thường thực hiện điều này
bằng cách chèn các dấu nháy đơn, nháy kép vào trong giá trị của biến. Tuy nhiên,
SQL Injection còn có thể xảy ra ở 1 trường hợp khác, đó là khi một trường dạng số
15


được sử dụng trong truy vấn SQL nhưng lại không kiểm tra kỹ xem dữ liệu nhập lên
từ người dùng có đúng là số không. Ta xét ví dụ sau:
statement := "SELECT
a_variable + ";"

*

FROM

data

WHERE

id

=

"

+

Biến id trong ví dụ trên là một trường kiểu số. Câu truy vấn được thiết kế với
mục đích chọn ra tất cả các bản ghi dữ liệu tại bảng Data mà có id bằng với giá trị
người dùng cung cấp.
Tuy nhiên, trong thực tế hacker có thể cung cấp lên 1 xâu thay cho 1 số:
1;DROP TABLE users

Lúc đó câu truy vấn trở thành:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;
Khi thực hiện nó sẽ xóa toàn bộ bảng user – đây là điều mà người lập trình
không bao giờ tính tới trong lúc thiết kế câu truy vấn này.

2.1.4 SQL Injection do các hàm của hệ quản trị cơ sở dữ liệu.
Đôi khi, lỗi SQL xảy ra không phải do lỗi người lập trình mà xuất phát từ
bản thân các hàm built-in của hệ quản trị cơ sở dữ liệu. Ví dụ, trong 1 số phiên bản
cũ của MySQL Server, hàm builtinmysql_real_escape_string() được viết không tốt,
do đó nếu lập trình viên sử dụng hàm này, hacker có thể chèn thêm truy vấn vào câu
SQL ngay cả khi các ký tự đặc biệt đã được lọc bỏ, bằng cách sử dụng một số ký tự
Unicode nguy hiểm.
Để thực hiện tìm và khai thác lỗi SQL Injection từ bên ngoài, hacker thường
sử dụng 2 kiểu chính sau đây:

Kiểu 1: Tìm lỗi SQL Injection dựa vào thông báo lỗi của hệ quản
trị cơ sở dữ liệu.
Đây là kiểu tấn công phổ biến và dễ thực hiện. Nếu ứng dụng web mắc lỗi
SQL Injection, khi người dùng cung cấp các giá trị đặc biệt, có khả năng ngắt/thay
đổi câu truy vấn SQL thì nó có thể gây ra một câu truy vấn sai và hệ quản trị cơ sở
dữ liệu sẽ trả về 1 thông báo lỗi thay việc thực hiện câu truy vấn đó.
Ta xét một ví dụ
Giả sử truy cập 1 trang web có địa chỉ:
/>

16