Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán

Còn đối với cácứng dụng đã được thực hiện và triển khai thì có phương pháp phát hiện tĩnh và động.Các phương pháp có thể được áp dụng cho các phần khác nhau của quá trình giao tiếpgiữa n

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

1 Thông tin về sinh viên

Họ và tên sinh viên: Nguyễn Văn Bảo

Điện thoại liên lạc: 0977728940 Email: anpha2010@gmail.com

Lớp: Công nghệ phần mềm Hệ đào tạo: Đại học

Đồ án tốt nghiệp được thực hiện tại: Trường Đại học Bách Khoa Hà Nội

Thời gian làm ĐATN: Từ ngày / /2010 đến / /2010

2 Mục đích nội dung của ĐATN

Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán

3 Các nhiệm vụ cụ thể của ĐATN

- Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting

- Tìm hiểu các phương pháp phòng tránh và phát hiện Cross-Site Scripting

- Tìm hiểu về Cross-Site Scripting worm

- Xây dựng chương trình phát hiện sâu mã độc phát tán

4 Lời cam đoan của sinh viên:

Tôi – Nguyễn Văn Bảo - cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của Tiến sĩ Nguyễn Khanh Văn

Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công trình nào khác

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

Tác giả ĐATN

5 Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ:

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

Giáo viên hướng dẫn

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP

Ngày nay với sự phát triển sâu rộng của internet, nó đã xâm nhập vào hầu hết các lĩnhvực của đời sống xã hội Con người ngày càng có nhu cầu kinh doanh buôn bán, trao đổi vàlưu trữ thông tin trên mạng Vì thế vấn đề bảo mật, an toàn thông tin ngày càng trở nên cấpthiết và cần có sự đầu tư thích đáng Trong những năm gần đây có rất nhiều lỗ hổng bảo mậttrên ứng dụng web được phát hiện Một trong số đó là lỗ hổng bảo mật cross-site-scripting, cái

mà đã gây nhiều tổn thất và có có những mối nguy hại tiềm tàng Luận văn này được đưa ra đểtìm hiểu về lỗ hổng bảo mật này, cùng với đó là nghiên cứu các biện pháp phòng tránh vàngăn chặn chúng Phân tích và xem xét các biện pháp đó xem nó có những điểm mạnh điểmyếu gì, áp dụng trong hoàn cảnh nào là phù hợp Ngoài ra luận văn còn tìm hiểu một dạng đặtbiệt của lỗ hổng cross-site-scripting đó là cross-site-scripting worm, một loại worm có khảnăng đặc biệt là lây lan một cách nhanh chóng mà không gây nên tắc ngẽn mạng Cuối cùng làxây dựng chương trình phát hiện sự phát tán của worm trên

to analyze the advantages and disadvantages of those methods and the condition to use them.Furthermore, a special types of the cross-site-scripting gap is researched It’s the cross-site-scripting worm (a worm with special strength of spreading rapidly without making networkjammed) Finally, the essay gives the program to detect the propagation of that worm.

Xin cám ơn tất cả bạn bè đã và đang động viên giúp đỡ mình trong quá trình học tập vàhoàn thành đồ án tốt nghiệp này.

MỤC LỤC

LỜI GIỚI THIỆU 1

Mục tiêu của luận văn 2

Tổ chức của luận văn 3

CHƯƠNG 1: TỔNG QUAN VỀ CROSS SITE SCRIPTING 4

1.1 Định nghĩa XSS 4

1.2 Phân loại XSS 5

1.2.1 Stored XSS 5

1.2.2 Refleted XSS 7

CHƯƠNG 2: CÁC CÁCH NGĂN CHẶN XSS 10

2.1 Ngăn chặn XSS trong giai đoạn phát triển 10

2.2 Ngăn chặn XSS bằng phần mềm 12

2.3 Ngăn chặn XSS bằng việc phân tích việc truyền dữ liệu 13

2.4 Ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm 14

2.5 Ngăn chặn XSS trên phía máy khách 14

CHƯƠNG 3: PHƯƠNG PHÁP NGĂN CHẶN XSS SỬ DỤNG 16

“DYNAMIC DATA TAINTING” 16

3.1 Dynamic data tainting 16

3.1.1 Khởi tạo dữ liệu đánh dấu 17

3.1.2 Theo dõi dữ liệu đánh dấu 19

3.2 Data transmission 27

CHƯƠNG 4: XSS WORM 33

4.1 Khái niệm XSS worm 33

4.2 Phương pháp lây lan 33

4.3 Tác hại của XSS worm 34

4.3.1 XSS Worm đầu tiên: Samy worm 34

4.3.2 24 giờ lan truyền đầu tiên: Samy xác lập một kỷ lục 35

4.3.3 Phân tích và so sánh 36

4.4 Chương trình phát hiện XSS worm 38

4.4.1 Phương pháp tiếp cận 39

4.4.2 Thiết kế chương trình 40

4.4.2.1 Lấy các giá trị tham số và URI link từ HTTP request 43

4.4.2.2 DOM script và các file script bên ngoài của trang web 43

4.4.2.3 Bộ giải mã tự động 44

4.4.2.4 Phát hiện chuỗi tương tự 44

4.4.3 Cài đặt chương trình 45

4.4.4 Đánh giá 56

CHƯƠNG 5: KẾT LUẬN 57

PHỤ LỤC 58

TÀI LIỆU THAM KHẢO 63

DANH MỤC HÌNH

Hình 1: Các lỗ hổng trong ứng dụng web 2

Hình 2: Ví dụ về một tin nhắn cho tấn công “Stored XSS” mà lấy cắp cookie 5

Hình 3: Các bước tấn công stored XSS 6

Hình 4:Ví dụ về tấn công “Refleted XSS” 7

Hình 5: Các bước của tấn công Refleted XSS 8

Hình 6: Các nguồn bị đánh dấu ban đầu 18

Hình 7: Ví dụ về phép gán 20

Hình 8: Ví dụ về các phép toán học và logic 21

Hình 9: Ví dụ về vòng lặp for với điều kiện bị đánh dấu 22

Hình 10: Ví dụ cho một điều khiển phụ thuộc 23

Hình 11: Phạm vi bị đánh dấu của khối if 24

Hình 12: Opcode của ví dụ trong hình 11 24

Hình 13: Các vị dụ về cấu trúc điều khiển và lặp 25

Hình 14: Các tham số hàm 27

Hình 15: Ví dụ về hàm 27

Hình 16: Sử dụng của eval với thông tin bị đánh dấu 28

Hình 17: Ví dụ cho lưu trữ tạm thời dữ liệu bị đánh dấu vào DomTree 28

Hình 18: Ví dụ của việc truyền cookie bằng cách thay đổi nguồn của một ảnh bằng Javascript 30

Hình 19: Log file của một Get request thành công 30

Hình 20: Ví dụ truyền dữ liệu bằng submit một form 31

Hình 21: Hộp thoại hỏi cho việc truyền dữ liệu 32

Hình 22: Tấn công dùng vòng lặp do-while 33

Hình 23: 24 giờ đầu lan truyền của các worm 37

Hình 24: Lây nhiễm peer-to-peer 38

Hình 25: Lây nhiễm từ máy chủ web tới trình duyệt web 39

Hình 26: Ví dụ DOM tree của một văn bản 41

Hình 27: Quá trình gửi HTTP request và nhận HTTP response 42

Hình 28: Kiến trúc client cho phát hiện XSS 43

Hình 29: Package diagram 47

Hình 30: Class diagram 48

Hình 31: Mã đăng kí các sự kiện 49

Hình 32: Quá trình lấy các script trong document 50

Hình 33: Quá trình sử lý sự kiện có một yêu cầu gửi đi 51

Hình 34: Quá trình lấy dữ liệu trong tham số gửi đi 52

Hình 35: Cài đặt thuật toán trigram 54

Hình 36: Cài đặt chương trình 55

Hình 37: Hình ảnh chương trình khi cài đặt xong 56

Hình 38: Hình ảnh cảnh báo khi người dùng vào trang web có lỗi XSS worm 56

Hình 39: Cấu trúc trong một file xpi 59

Hình 40: Nội dung của một file install.rdf 60

Hình 41: Khai báo thanh trạng thái(statusbar) trong file browser.xul 61

Hình 42: Đoạn mã để thêm một statusbarpanel vào thanh trạng thái 61

Hình 43: Định dạng của file chrome.manifest 63

Hình 44: Ví dụ để ghép overlay trong extension vào trong cửa sổ trình duyệt 63

DANH MỤC TỪ VIẾT TẮT, THUẬT NGỮ

CNTT Công nghệ thông tin

CSDL Cơ sở dữ liệu

UTF-7 Một chuẩn mã hóa

HTTP Hypertext Transfer Protocol

HTTP request Yêu cầu HTTP gửi đi

URI Uniform Resource Identifier

URL Uniform Resource Locator

URN Uniform Resource Name

DOM Mô hình đối tượng tài liệu

Byte-code Mã trung gian giữa mã viết và mã máy

DNS Domain name system

XMLHttpRequest Một giao diện lập trình để truyền dữ liệu giữa máy

khách và máy chủLog-file Tập tin lưu trữ dấu vết truy cập trên máy chủ

TFTP Một giao thức truyền file

API Giao diện lập trình

XML eXtensible Markup Language: ngôn ngữ đánh dấu

mở rộng

LỜI GIỚI THIỆU

Với xu thế phát triển và xâm nhập nhanh chóng của mạng Internet vào mọi mặt đờisống xã hội, các ứng dụng và dịch vụ web trở nên ngày càng đa dạng, phục vụ mọi nhucầu phong phú của người dùng: từ các nhu cầu cơ bản như tìm kiếm sản phẩm, muasắ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ôngtin trên các mạng xã hội Đặc biệt trong địa hạt thương mại điện tử hiện nay, rất nhiềudoanh nghiệp hiện đang sử dụng ứng dụng web để quảng bá hình ảnh, kết nối vớikhách hàng và đối tác, và cung cấp dịch vụ thương mại trực tuyến Tuy nhiên, ứngdụng web cũng đem đến những rủi ro mới ảnh hưởng đáng kể đến an toàn của hệ thống

và dữ liệu Đa số ứng dụng web có thể bị những lỗi mà các phương cách phòng chốngmạng thông thường không phát huy tác dụng Các lỗi phát triển ứng dụng có thể gây racác lỗ hổng trong mã nguồn của ứng dụng web, mà có thể bị kẻ xấu khai thác gây ranhững hậu quả nghiêm trọng Ví dụ như làm lộ dữ liệu nhạy cảm, gây tổn thương đếntoàn hệ thống hạ tầng CNTT Sự cố bảo mật trong ứng dụng web có thể ảnh hưởng đếndanh tiếng của công ty, mất mát về mặt tài chính, ảnh hưởng đến uy tín với khách hàng

và các vấn đề liên quan đến ràng buộc pháp lý

Ngày nay các ứng dụng web thường sử dụng công nghệ web động để tạo ra nhữngtrang web có tính thẩm mỹ cao, thông tin được cập nhật thường xuyên, và có khả năngtương tác với người dùng Thông thường, các thông tin trong trang web động được thuthập từ nhiều nguồn khác nhau Một trong những nguồn quan trọng nhất là các dữ liệuđược cung cấp bởi người dùng Dữ liệu này rất đa dạng và phong phú nên các ứngdụng web rất khó để có thể kiểm soát được các dữ liệu này Một nguồn khác của nộidung trong một trang web có thể là được cung cấp bởi một dịch vụ web từ xa của mộtnguồn cung cấp thông tin Kẻ xấu thường tấn công nhờ lợi dụng khả năng kiểm soátkém của các ứng dụng web đối với dữ liệu nhập vào bởi người dùng Theo thống kêtrong những năm gần đây các lỗ hổng được tìm thấy trong ứng dụng web tăng lên rấtnhanh và chủ yếu là các lỗ hổng khai thác vấn đề trên

Hình 1: Các lỗ hổng trong ứng dụng web

Trong luận văn này, người viết tập trung tìm hiểu và nghiên cứu về cross site

scripting (XSS), một dạng lỗ hổng phổ biến và được quan tâm nhiều nhất trong số các

lỗ hổng web mà ta vừa nêu trên Trong kiểu tấn công này kẻ tấn công lợi dụng việc dữliệu gửi lên bởi người dùng không được kiểm tra, làm sạch để gửi thông tin mà có chènthêm các đoạn mã độc lên ứng dụng web Sau đó khi một người dùng khác tải thông tin

đó về thì đoạn mã độc được thực hiện trên trình duyệt của người dùng Lỗ hổng nàyngày càng được chú ý khi mà những trang web phát hiện có lỗ hổng này ngày càngtăng, mục đích của kẻ tấn công nhằm vào lĩnh vực thương mại điện tử và các mạng xãhội có rất nhiều thành viên tham gia

Mục tiêu của luận văn

Luận văn được thực hiện với mục đích tìm hiểu và nghiên cứu lỗ hổng bảo mật

sross site scripting.Những phân tích về các lỗi thường gặp trong quá trình phát triển sẽ

giúp ích cho những người phát triển có những biện pháp để phòng ngừa và ngăn chặn

lỗ hổng Các biện pháp để phát hiện XSS được nêu ra để thảo luận xem các điểm mạnh

và các điểm yếu của chúng, từ đó chọn ra biện pháp phù hợp và hiệu quả nhất Ngoài raluận văn còn nghiên cứu về XSS worm, một loại đặc biệt của XSS Người viết chỉ ramức độ tác hại của loại worm này và xây dựng một giải pháp phát hiện chúng phía máykhách

Tổ chức của luận văn

Chương 1 Tổng quan về sross site scripting: chương này sẽ nêu ra định nghĩa thế

nào là XSS, nguyên nhân gây ra lỗi XSS, và chỉ ra các loại tấn công XSS cơ bản

Chương 2 Các cách ngăn chặn XSS: Trong chương này người viết chỉ ra các

cách để phòng ngừa và ngăn chặn XSS Kiến thức đạt được có thể được sử dụng thựchiện các biện pháp phòng ngừa khi phát triển ứng dụng web, bởi vì ngay cả các phươngpháp lọc đơn giản có thể thực hiện được các vấn đề bảo mật cơ bản Còn đối với cácứng dụng đã được thực hiện và triển khai thì có phương pháp phát hiện tĩnh và động.Các phương pháp có thể được áp dụng cho các phần khác nhau của quá trình giao tiếpgiữa người sử dụng và ứng dụng web khi một vấn đề bảo mật được phát hiện Những

lý luận sẽ giúp hiểu hơn về các vấn đề này

Chương 3 Phương pháp ngăn chặn XSS sử dụng “Dynamic data tainting”: Trong

chương này người viết tìm hiểu một giải pháp để ngăn chặn tấn công XSS và thảo luận

về những khác biệt của nó với các phương pháp hiện có Phương pháp này là “dynamicdata tainting” “dynamic data tainting” nghĩa là gì và các khái niệm ẩn chứa trong nó sẽđược trình bày trong chương 3

Chương 4 XSS worm: Chương này sẽ đưa ra định nghĩa XSS worm, phương pháp

lây lan và mức ảnh hưởng của nó như thế nào Cuối cùng người viết tìm hiểu và cài đặtmột giải pháp để phát hiện XSS worm phía máy khách Ngoài ra còn có các đánh giá

về điểm mạnh và yếu của giải pháp này

Chương 5 Kết luận: Tóm tắt lại các vấn đề đã tìm hiểu được nêu ra các hướng phát

triển trong tương lai

CHƯƠNG 1: TỔNG QUAN VỀ CROSS SITE SCRIPTING

1.1 Định nghĩa XSS

Một trang web có thể vô tình chứa các thẻ HTML hoặc script độc hại vì trang đóđược tạo ra tự động mà không kiểm tra đầu vào được nhập từ các nguồn không tin cậy.Điều này sẽ gây ra lỗ hổng nếu máy chủ web không chắc chắn rằng các trang tạo rađược mã hóa để ngăn chặn các script thực hiện các lệnh ngoài ý muốn Vấn đề đó đượcgọi là “code injection” Ứng dụng web sẽ xử lý luôn đầu vào mà không kiểm tra chúng

có bị nhúng mã độc hay không Bởi vì thế mà đoạn mã mà được xuất ra cho một ngườidùng thì có thể là được tạo ra bởi một người dùng khác, lỗ hổng như vậy có thể dẫnđến các cuộc tấn công Nếu mã nhúng là scripting code (ví dụ Javascript) thì ta gọi đó

là cross site scripting (XSS)

Tổng quát hơn ta có khái nệm XSS như sau:

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránhnhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằngcách chèn vào các website động (ASP, PHP, CGI, JSP ) những thẻ HTML hay nhữngđoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác Trong

đó, những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng các Client-SiteScript như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML

Nếu các thông tin nhập vào bởi người dùng mà sau đó khi ứng dụng web xử lýthông tin đó, nó không kiểm tra chúng có chứa mã HTML hay script hay không Cuốicùng thông tin này được xuất ra trang web của người bị tấn công Trình duyệt web (ví

dụ FireFox) khi hiển thị nội dung của trang web đó, nó hiểu đoạn mã độc là script bìnhthường và sẽ chạy đoạn script đó Và như thế chính sách “Same origin policy” củatrình duyệt web bị phá vỡ Chính sách này chống lại kiểu tấn công mà trong đó mộtdocument được tải từ một trang web cố gắng truy cập hoặc thay đổi dữ liệu trong mộtdocument được tải từ một trang web khác Tuy nhiên trong tấn công XSS, document

mà chứa script độc thì script đó sẽ được chạy trong bối cảnh của document này Vì thếchương trình độc hại này có thể truy cập dữ liệu nhậy cảm được lưu trữ trong trìnhduyệt của người dùng (ví dụ như cookie), và chuyển dữ liệu đó cho bên thứ ba (ví dụtrang web của kẻ tấn công) Những kẻ tấn công đó sẽ thu thập được các thông tin doscript đó lấy được.

1.2 Phân loại XSS

Có hai phương pháp để chèn mã vào trang web mà hiển thị cho người sử dụng

đó là phải lưu trữ nó trước (stored XSS) và sử dụng ứng dụng web để gây ra các mãđộc hại (Reflected XSS)

Hình 2: Ví dụ về một tin nhắn cho tấn công “Stored XSS” mà lấy cắp cookieCác bước cho một cuộc tấn công được thực hiện như hình 3 sau:

Hình 3: Các bước tấn công stored XSSTrước tiên kẻ tấn công lưu bài viết chứa mã XSS trên diễn đàn Nạn nhân đầutiên đăng nhập vào diễn đàn và sẽ được xác định bởi một cookie mà được thiết lập trêntrình duyệt Nạn nhân sau đó có thể đọc bài viết của kẻ tấn công đã đăng các mã độcđược gửi trả lại như một phần của bài viết và sau đó nó sẽ được dịch và chạy trên trìnhduyệt Đoạn mã XSS sẽ gửi cookie của nạn nhân cho kể tấn công Với Session Cookiecủa nạn nhân kẻ tấn công có thể giả danh nạn nhân trong diễn đàn này và có tất cả cácquyền của nạn nhân.

1.2.2 Refleted XSS

Với tấn công “Refleted XSS” thì nó sẽ gửi mã độc trở lại người dùng với sựgiúp đỡ của ứng dụng web Để làm điều đó kẻ tấn công sẽ gửi một liên kết tới nạn nhân( chẳng hạn qua email … ) như trong hình sau:

Hình 4:Ví dụ về tấn công “Refleted XSS”

Liên kết trên chứa mã HTML mà có một script để tấn công kẻ nhận email Nếunạn nhân click vào liên kết đó, lỗ hổng trên ứng dụng web sẽ hiển thị trang web vừa

yêu cầu với thông tin truyền cho nó chứa trong liên kết (mycomment=<script

src=’http://evilserver/xss.js’></script> ) Thông tin này chứa đoạn mã độc và là một

phần của trang web mà được gửi lại cho trình duyệt của người sử dụng nơi mà nó đượcbiên dịch và chạy

Các bước thực hiện cuộc tấn công được hiển thị như trong hình 5 sau:

Hình 5: Các bước của tấn công Refleted XSSTrong ví dụ này giả định rằng nạn nhân đầu tiên đăng nhập vào một ứng dụngweb có lỗ hổng Kẻ tấn công sẽ gửi cho nạn nhân một email hay một tin nhắn mà trong

đó có chứa liên kết trên Khi người sử dụng nhấn vào liên kết và nếu trang web gửi lại

mà được tạo ra bởi một ứng dụng web có lỗ hổng thì trang web đó sẽ chứa đoạn mã

HTML mà được truyền vào từ liên kết trên (<script src=’http://evilserver/xss.js’>

</script>).

Script sau đó được dịch và chạy bởi trình duyệt web và cookie của người dùng

sẽ được truyền đến trang web của kẻ tấn công Một lần nữa, kẻ tấn công có thể sử dụngSession Cookie của nạn nhân để giả mạo nạn nhân trong trang web có lỗ hổng và có đủnhững quyền của nạn nhân

Thông thường để ngăn ngừa lỗi XSS thì yêu cầu nhà cung cấp ứng dụng phảiđảm bảo rằng phần mềm của họ là không có lỗ hổng Điều này có thể thực hiện trongsuốt quá trình phát triển ứng dụng web bằng cách sử dụng thiết kế phần mềm bảo mật

và sử dụng phương pháp viết mã an toàn, hoặc khi ứng dụng đã được triển khai trênmáy chủ web trong trường hợp chủ sở hữu của website sử dụng sản phẩm của bên thứ

ba, các bản vá lỗi mới nhất của nhà cung cấp phải được cập nhật thường xuyên để bảo

vệ cho người sử dụng Thật không may cần có thời gian để phát triển và thử nghiệmbản vá cho lỗ hổng vừa được tìm thấy Vì thế người dùng vẫn bị đe dọa là nạn nhâncủa của một trang web bị tấn công “cross site scripting”

CHƯƠNG 2: CÁC CÁCH NGĂN CHẶN XSS

Một số cuộc tấn công có thể được ngăn chặn bằng chính sách “Same sourceorigination Policy” mà được đưa vào trong hầu hết các mô hình an ninh Scripting.Chính sách này ngăn cản việc một document mà được tải từ một website có thể truycập các thành phần của một document được tải từ một website khác Tuy nhiên trongmột cuộc tấn công XSS các script có thể truy cập dữ liệu trong bối cảnh của document

bị tấn công Nếu kẻ tấn công nhúng mã độc vào liên kết tương tự như hình 4, mô hìnhbảo mật đó có thể không còn tác dụng bởi vì đoạn script đó được chạy trong chínhtrang web đó chứ không phải là một trang web khác Nó có thể lấy tài nguyên trongtrang web và truyền ra ngoài

Để tránh các lỗi này, cách đơn giản nhất là người dùng nên vô hiệu hóa việcthực thi các ngôn ngữ script trên trình duyệt của mình Về cơ bản điểu này là đúngnhưng giải pháp này ảnh hưởng đến tất cả các trang web dù chúng có bị lỗ hổng haykhông Và điều đó làm giảm các chức năng của một trang web Ví dụ một trang web

mà sử dụng Ajax dựa trên Java Script (là một sự kết hợp các công nghệ để cải tiến tínhtương tác của trang web) mà nếu script bị vô hiệu hóa thì việc này sẽ không thực hiệnđược Một lựa chọn khác là chỉ vào những trang web tin cậy Điều này có thể rất khókhăn nếu một công cụ tìm kiếm được sử dụng để tìm kiếm một thứ gì đó trên trangweb Các trang web được trả về bởi công cụ tìm kiếm mà chưa từng được xem trước đóthì nó không thể biết các trang web đó có tin cậy hay không Sau đây người viết sẽtrình bày các phương pháp ngăn chặn và phát hiện mà đã có những hiệu quả nhất định

2.1 Ngăn chặn XSS trong giai đoạn phát triển

Trong phần này người viết sẽ trình bày các biện pháp phòng ngừa XSS mà cácbiện pháp này có thể được thực hiện trong giai đoạn phát triển phần mềm Để giảm nhẹcác vấn đề trên ta có thể làm bằng cách cài đặt các ký tự mã hóa của mỗi trang đượctạo Ví dụ trong UTF-7 tồn tại một mã hóa thay thế ký tự đặc biệt “<”, ký tự này là

đánh dấu bắt đầu của một thẻ HTML Một kẻ tấn công có thể nhúng mã mà sử dụng

mã hóa UTF-7 của “<” và đoạn mã đó được gửi cho ứng dụng web Nếu ký tự đó làmột phần trong đầu ra của trang web mà không cài đặt ký tự mã hóa, trình duyệt nhậnđược mã ký tự trên sẽ hiểu nó là chuẩn mã hóa ASCII và dịch thành “<” Lý do là trìnhduyệt web sử dụng UTF-7 là kiểu mã hóa ký tự mặc định chuẩn HTML cho phép trìnhduyệt dịch các thẻ trong ký tự mã hóa thay thế và vì thế nếu không thiết lập mã hóa ký

tự thì sẽ cho phép kẻ tấn công nhúng các thẻ HTML vào trang web

Tất cả các ký tự đặc biệt(ví dụ “<”, “>”, “&” ) cần phải được xác định và mãhóa nếu chúng chứa trong đầu ra hoặc chúng cần phải được lọc bỏ bởi ứng dụng web.Nếu không cơ chế bảo mật trong ứng dụng có thể bị qua mặt bằng cách tiêm mãscripting Để xác định ký tự ta thực hiện với một “ White-list”, chỉ những ký tự đặc biệt

là không gây ra vấn đề gì trong khi xử lý mới được mã hóa và xuất ra Ví dụ năm sinhthì chỉ cần số để biểu diễn vì thế không ký tự đặc biệt nào là cần thiết Khi gặp phải sựviệc này, một thông báo lỗi có thể được hiện ra hoặc tất cả mọi thứ mà không phải là sốcần phải được loại bỏ Phương pháp này an toàn hơn là cố gắng chỉ loại bỏ ký tự từ ônhập mà có thể được sử dụng trong một nỗ lực tấn công XSS(ví dụ loại bỏ tất cả cácthẻ HTML như <script>) Vì rất khó để xác định các ký tự đặc biệt và sự kết hợp củacác ký tự đặc biệt

Mọi dữ liệu đầu vào mà chứa trong đầu ra thì phải được mã hóa, điều này có thểđược thực hiện với “character entity references” hoặc một giá trị số của mã hóa kí tựtrong tập các kí tự HTML mà được định nghĩa để tạo ra trang web Ví dụ ký tự “<” từ

dữ liệu vào nên được chuyển thành “character entity references” là “&lt” Nếu trangđược tạo ra sử dụng mã hóa ký tự ISO 8859-1 thì ký tự đặc biệt đó có thể được mã hóathành “&#60”, sử dụng giá trị số Mã hóa tất cả các đầu vào không tin cậy mà được sửdụng trong đầu ra có thể làm tốn tài nguyên nhưng lại rất hiệu quả

Phòng ngừa được thưc hiện trong khi phát triển ứng dụng web có thể rất hiệuquả nhưng đòi hỏi người phát triển phải là người có kiến thức tốt về tất cả các cuộc tấncông đã có và có thể có, và phải biết làm thế nào để tránh chúng Việc thực hiện cácbiện pháp đối phó đó làm tốn rất nhiều tài nguyên Nó không chỉ đòi hỏi nhiều côngsức hơn trong giai đoạn phát triển mà sau đó ứng dụng thực hiện nó sẽ sử dụng nhiềutài nguyên hơn khi nó lọc và mã hóa mỗi đầu vào và đầu ra Sự đòi hỏi xử lý các yêu

cầu trên cho một trang web phổ biến có thể làm cho chi phí thực hiện của trang web lênrất cao.

2.2 Ngăn chặn XSS bằng phần mềm

Phần mềm kiểm tra cho các lỗ hổng XSS có thể được thực hiện theo hai cáchtĩnh và động Kiểm tra tĩnh được thực hiện bằng cách phân tích thử nghiệm mã nguồn.Trong cuốn sách “Sixth IEEE International Workshop on Web Site Evolution” của cáctác giả G.A Di Lucca, A.R Fasolino, M Mastroianni, and P Tramontana một phươngpháp được mô tả là tạo ra một biểu đồ kiểm soát luồng thông tin mà được xử lý bởimáy chủ Đồ thị bao gồm các nút đầu vào và đầu ra Mội nút đầu vào có thể là quátrình nhập dữ liệu của một forn, đọc giá trị của một câu truy vấn một trường trongCSDL, cookie, dữ liệu từ một tập tin Một nút đầu ra là liên quan đến câu tru vấn màghi vào các trường trong CSDL, ghi vào file, một cookie hay đầu ra của một trang web.Máy chủ có thể bị lỗ hổng nếu một phần của đồ thị luồng điều khiển tồn tại kết nối mộtnút đầu ra với một nút đầu vào Tuy nhiên trong trường hợp dữ liệu từ một trang gửiđến một trang khác thì ứng dụng web có thể không bị lỗ hổng đối với kiểu tấn côngnày nếu chỉ một trang có lỗi bảo mật Ví dụ một trang có thể đọc đầu vào và lưu trữvào một trường trong CSDL Kết quả của phân tích này chỉ ra rằng trang này có lỗhổng tiềm tàng Nhưng nếu trang khác mà đọc dữ liệu từ trường này mà mã hóa mọithứ trong đầu ra của trang và vì thế toàn thể ứng dụng web là không bị tổn thương

Trong kiểm tra động ta cho chạy lại các cuộc tấn công đã biết trên ứng dụngweb Trong cuốn sách “Sixth IEEE International Workshop on Web Site Evolution”trên các tác giả thực hiện việc kiểm tra động như là giai đoạn thứ hai của đánh giá ứngdụng web Chính xác hơn là các trang máy chủ mà có lỗ hổng theo một bước phân tíchtĩnh trước được kiểm tra lại trong kiểm tra động với một số tấn công đặc biệt cho lỗhổng đó Các trình thu thập tiến hành kiểm thử hộp đen với một CSDL được tạo ra Nóphân tích các trang được tạo ra của ứng dụng web và sau đó chọn cách tấn công đểthực hiện

Phân tích bằng phần mềm là phương pháp mạnh mẽ phát hiện các lỗ hổng cóthể Nhưng với phương pháp phân tích tĩnh ta thấy nó hiệu quả với mã nguồn nhưng nóchỉ kiểm tra để biết có lỗ hổng hay không chứ không khắc phục được lỗ hổng Kiểmthử hộp đen có thể thấy hết các vị trí của ô nhập mà được sử dụng để thực hiện trong

các cuộc tấn công Nhưng đó cũng chỉ là những cuộc tấn công đã biết, và vì thế chỉngăn chặn được các lỗ hổng đó.

2.3 Ngăn chặn XSS bằng việc phân tích việc truyền dữ liệu

Để ngăn chặn việc truyền dữ liệu một hệ thống proxy được đề xuất Nó có thểđược cài đặt phía người sử dụng để ngăn chặn tấn công XSS Proxy phải giám sát cácyêu cầu (request) HTTP gửi đi và các kết quả (response) trả về của người dùng đanglướt web Có hai chế độ được gọi là “Response change mode” và “Request changemode” Trong “Response change mode”, proxy lưu trữ thông tin về yêu cầu mà chứanhững thẻ đặc biệt (ví dụ script) Nếu tiếp theo các thẻ đó lại xuất hiện trong responsegửi về bởi ứng dụng web thì mặc định các thẻ đó được mã hóa và trở thành an toàn.Còn trong “Request change mode” tham số trong yêu cầu gửi đi được gắn kèm thêmmột định danh là một số ngẫu nhiên nếu chúng chứa kí tự đặc biệt Tất cả các thẻHTML đặc biệt trong tham số của yêu cầu gửi đi được thêm một số ngẫu nhiên (nóhoạt động như một định danh) Ví dụ với tham số “<s>test</s>” một số ngẫu nhiên 234được tạo ra và sử dụng như một định danh Request gửi đi được chỉnh sửa và trở thành

“<234s>234test<234/s>234” Sau khi request đươc sửa đổi thì được gửi tới ứng dụngweb Và khi response trả về nó sẽ được quét để kiểm tra sự xuất hiện của các thẻ đãthay đổi Nếu không có thẻ được sửa đổi với định danh được phát hiện trong responsethì ứng dụng là không có lỗ hổng và yêu cầu bình thường được gửi đi và response trảlại được chuyển cho người sử dụng Trong chế độ này số lượng yêu cầu và response làtăng gấp đôi Thông tin về lỗ hông bảo mật tiềm năng này được gửi tới CSDL để chia

sẻ giữa các máy chủ proxy Hệ thống này không có thông tin về cấu trúc và ngữ nghĩacủa trang web vừa truy cập, nó chỉ có thể kiểm tra tham số được xử lý bởi ứng dụngweb mà được sử dụng trong yêu cầu HTTP Nếu mã hóa được sử dụng thì proxy khôngthể theo dõi các request và các response

Ngoài ra trong cuốn sách “10th ACM Conferenceon ComputerandCommunication Security” của các tác giả Christopher Kruegel và Giovanni Vigna cógiới thiệu một hệ thống phát hiện xâm nhập Hệ thống này giúp phát hiện các cuộc tấncông vào máy chủ web và ứng dụng web Các log file của máy chủ web được phân tíchcho các dị thường trong các yêu cầu HTTP Giải pháp này bao gồm giai đoạn học vàgiai đoạn phát hiện Trong giai đoạn học các chuỗi truy vấn gửi đến ứng dụng web

được sử dụng để tính điểm mà dựa trên một mô hình Mô hình và điểm số được thíchứng với từng ứng dụng web Trong giai đoạn phát hiện các điểm số cho mỗi câu truyvấn được tính toán bằng cách sử dụng mô hình đào tạo mà vượt quá một ngưỡng nhấtđịnh thì là dấu hiệu cho một cuộc tấn công Để phát hiện ra các dị thường đòi hỏi một

mô hình tốt để cung cấp các điểm số chính xác và ngưỡng phải là một số không quácao (nếu không các cuộc tấn công có thể không bị phát hiện) Nhưng ưu điểm của nó là

có thể phát hiện các cuộc tấn công mới mà không cần thay đổi ứng dụng

2.4 Ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm

Để ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm thì ta phải tích hợptrong trình dịch một chương trình để đánh dấu và theo dõi các dữ liệu nhạy cảm Bất cứkhi nào mà ứng dụng cố gắng đưa dữ liệu ra bên ngoài chương trình thì nó sẽ bị ngănchặn Việc đánh dấu và theo dõi các dữ liệu nhạy cảm như vậy gọi là “tainting” Các

dữ liệu nhạy cảm phải được quy định cụ thể ví dụ như là biến session, database results,biến trong một form, cookies, thông tin HTTP header Và phải có một luật để theo dõicác dữ liệu nhạy cảm đó, ví dụ khi chúng được truyền trong các hàm, được gán cho cácbiến khác… Đối với kiểu ngăn chặn này thì không cần phải chỉnh sửa chương trìnhứng dụng mà chỉ cần chỉnh sửa trình biên dịch Khi đã tích hợp giải pháp này vào trìnhbiên dịch thì tất cả ứng dụng mà chạy trên nó sẽ được bảo vệ Tuy nhiên khi có lỗ hổngmới thì lại phải xây dựng lại trình biên dịch

2.5 Ngăn chặn XSS trên phía máy khách

Các tác giả trong cuốn sách “10th IEEE International Conferenceon Engineering

of Complex Computer Systems” sử dụng một hệ thống kiểm tra vào trình duyệtMozilla FireFox, hệ thống này có thể phát hiện cả lỗi sử dụng bất thường và lỗi sửdụng sai Hệ thống này giám sát việc thực hiện các đoạn mã JavaScript và so sánhchúng với một chính sách cấp cao để phát hiện hành vi nguy hiểm Đối với một hoàncảnh cụ thể, các quy tắc cụ thể được thực hiện để có thể phát hiện ra lỗ hổng Các quytắc đó cho phép xác định trình tự của các phương thức Javascript tương ứng với chúng

là các tham số để xem xét sự độc hại của chúng Với thông tin đó trạng thái điều khiểncác quy tắc có thể được thực hiện Hệ thống thực hiện hầu hết các kiểm tra trongXPConect, đó là một tầng kết nối Javascript engine với các component khác củaMozilla FireFox Một số tính năng kiểm tra bổ sung được thực hiện trong

DomClassInfo, LiveConnect (giao tiếp giữa JavaScript, Java appet và các plugin khác )

và Securety Manager Xử lý nội bộ được thực hiện bởi các chương trình JavaScript thìkhông truy cập được các nguyên tắc đó Nếu có lỗ hổng mới được phát hiện thì quy tắcmới được thực hiện và trình duyệt phải được xây dựng lại

Một hệ thống an ninh được đưa ra thảo luận tiếp theo là hệ thống được sử dụng

để thay đổi hành vi của “Same Origin policy” Khi bật chế độ đánh dấu dữ liệu, chươngtrình JavaScript của một document trong một window có thể truy cập vào dữ liệu củamột document trong một window khác mà được tải từ một máy chủ khác Nhưngdocument của window khác đó phải đánh dấu các dữ liệu đó là bảo mật, riêng tư vàchúng không thể được truyền tới một máy chủ khác mà không có quyền của ngườidùng Tuy nhiên hệ thống này phải được kích hoạt bởi người dùng và cần có các địnhnghĩa về dữ liệu mà cần bảo mật trong document được truy cập

CHƯƠNG 3: PHƯƠNG PHÁP NGĂN CHẶN XSS SỬ DỤNG

“DYNAMIC DATA TAINTING”

Hầu hết các hệ thống được trình bày trong chương 2 đều cố gắng ngăn chặnXSS tấn công vào các ứng dụng web trên máy chủ web hay cố gắng loại bỏ trực tiếpcác lỗ hổng bảo mật từ các ứng dụng web Đó là những cách tốt để bảo vệ người dùngkhỏi các cuộc tấn công khi tương tác với một ứng dụng web cụ thể, nhưng người dùng

sẽ không được bảo vệ khi truy cập vào các trang web khác Biện pháp trình bày trongphần 2.1 cũng hạn chế được các lỗ hổng, nhưng nó cũng có những nhược điểm như đãtrình bày ở trên Ngoài ra có thể chuyển dùng một trình duyệt với khả năng kiểm tra vàphát hiện như trình bày trong mục 2.5 Tuy nhiên trình duyệt mà được tích hợp khảnăng kiểm tra và phát hiện chỉ bảo vệ khỏi các lỗ hổng đã biết và phải được cập nhậtmột cách thường xuyên

Phương pháp trình bày trong phần này là cho phép các mã độc hại làm mọi thứtrong bối cảnh của trình duyệt.Tuy nhiên hệ thống sẽ theo dõi các truy cập và xử lýthông tin nhạy cảm Bất cứ khi nào mã độc cố gắng truyền thông tin nhạy cảm ra bênngoài, thì người dùng sẽ quyết định là cho phép hay không điều này sảy ra Ví dụ trongcác cuộc tấn công như trong hình 3 và hình 5 khi script cố gắng để truyền cookie cho

kẻ tấn công thì người dùng được cảnh báo và có thể từ chối việc truyền này Tất cả cáctruy cập thông tin nhạy cảm thì kết quả sẽ bị đánh dấu trong chương trình JavaScript

Xử lý dữ liệu bị đánh dấu được theo dõi tương tự như các phương pháp được giới thiệutrong 2.4

3.1 Dynamic data tainting

Trong một cuộc tấn công XSS, đoạn mã độc được tiêm vào đầu ra của trangweb Thông thường kẻ tấn công sẽ có toàn quyền kiểm soát nội dung của đoạn mã tiêm

đó Nếu có hạn chế thì chỉ là chiều dài của đoạn mã nếu nó được nhúng thông qua mộtURL, vì chiều dài của một url là bị hạn chế

Mã tiêm được gửi từ ứng dụng web tới trình duyệt web, sau đó sẽ được thực thitrong trình duyệt của người dùng, khi đó nó có thể thu thập thông tin nhạy cảm, xử lý

nó (ví dụ nối nó thêm vào một chuỗi) và cuối cùng gửi cho máy chủ web mà được điềukhiển bởi kẻ tấn công Bởi vì đoạn mã được chạy trong bối cảnh của ứng dụng web,nên các hành động của nó không được phân biệt với các hành vi của ứng dụng bìnhthường Vì thế injected code có đầy đủ quyền để xử lý thông tin và truyền đi Ví dụ đểlọt qua máy quét an ninh cái mà tìm kiếm các chuỗi kí tự nhất định trong dữ liệu truyền

đi bởi trình duyệt web, injected code có thể thực hiện mã hóa thông điệp trước khi nóđược gửi đi Để theo dõi việc xử lý thông tin nhạy cảm, khái niệm “dynamic datatainting” được sử dụng “Tainting” nghĩa là dữ liệu chứa thông tin nhạy cảm quantrọng được đánh dấu lúc đầu Đối với mỗi bước thực hiện của chương trình, kết quảcủa chúng phải được đánh dấu nếu toán hạng được sử dụng là bị đánh dấu và nó có thểtruyền thông tin với bước thực hiện này “dynamic” có nghĩa là luồng thông tin đượctheo dõi khi chương trình thực thi

Các phần sau đây sẽ giải thích một cách rõ ràng hơn về các bước thực hiện.Phần 3.1.1 sẽ trình bày tất cả những nguồn có chứa thông tin nhạy cảm Trong khi ởphần 3.1.2 sẽ cung cấp chi tiết về việc theo dõi dữ liệu bị đánh dấu trong thời gian thựcthi chương trình

3.1.1 Khởi tạo dữ liệu đánh dấu.

Đối với cách tiếp cận “tainting” thì phải xác định một số nguồn dữ liệu nhấtđịnh được coi là nhạy cảm Hình 6 cho thấy các phần tử trong trình duyệt có thể chứathông tin nhạy cảm, và do đó ban đầu phải được đánh dấu Hệ thống đánh dấu các phần

tử đó trong document object model ( DOM ) Hầu hết các phần tử này nằm trong DomTree và có liên quan tới các yếu tố trong trang HTML (ví dụ: document.title) ngoài racòn có thêm một số yếu tố khác (ví dụ document.cookie)

Hình 6: Các nguồn bị đánh dấu ban đầu.

Xin lưu ý rằng document.forms và document.links là không được đánh dấu Lý

do là chúng chứa các form, các link cụ thể Dĩ nhiên các phần nhạy cảm của form haylink được bao phủ bởi nhiều thuộc tính riêng (như input của form) Và lưu ý rằng cácURL history.current, history.next và history.previous không thể bị truy cập bởi vìSecurety Manager không chấp nhận điều đó Chỉ cần thực hiện đánh dấu các dữ liệukhi dữ liệu đó được cho phép truy cập bởi Securety Manager

Không phải tất cả các nguồn đều nhạy cảm như nhau Một trong những phầnquan trọng nhất của thông tin cần được bảo vệ là cookie Cookie được thiết lập bởi ứngdụng web mà mỗi lần request tới web site, cookie được gửi kèm trong dữ liệu được gửiđibởi trình duyệt Nhiều ứng dụng web sử dụng cookie như một thẻ chứng thực chongười dùng bằng cách thiết lập một ID cho các cookie mà là duy nhất cho mỗi người

Ví dụ một người mới truy cập vào trang web thì chưa được chứng thực nhưng vẫn cómột cookie để theo dõi anh ta Sau khi người dùng chứng thực rồi, ứng dụng web sửdụng ID của cookie để chứng thực anh ta mỗi khi anh ta truy cập vào dữ liệu trong website Ví dụ một diễn đàn sử dụng cookie sau khi đăng nhập của người dùng để cho phépanh ta có thể viết bài, sửa bài

3.1.2 Theo dõi dữ liệu đánh dấu

Các chương trình Javascript là một phần của một trang web được phân tích vàbiên dịch thành byte-code Những byte-code intruction sau đó được dịch bởi JavaScriptengine

Các intruction có thể chia thành các loại sau:

- Assignment (phép gán)

- Arthmetic and logic operations (+, -, &…) (các phép toán và phép logic)

- Control structures and loops (if, while, ) (cấu trúc điều khiển và lặp)

- function calls, classes and eval (lời gọi hàm, lớp, và hàm eval)

Khi một intruction được chạy, các phần hay tất cả toán hạng của nó có thể bịđánh dấu Vì vậy đối với mỗi intruction có một luật để định nghĩa mà theo đó kết quảcủa phép toán là có bị đánh dấu hay không (hoặc những kiểu khác của thông tin bị ảnhhưởng bởi dữ liệu bị đánh dấu)

3.1.2.1 Assignment

Trong một phép toán gán, giá trị của biến bên trái được thiết lập Nếu bên phảicủa phép toán mà bị đánh dấu thì kết quả của bên trái cũng bị đánh dấu JavaScriptengine có các intruction khác nhau để gán giá trị cho một biến đơn, biến hàm, các tham

số hàm, các phần tử mảng và các thuộc tính của đối tượng Một số kiểu gán được chỉ ratrong hình 7:

Hình 7: Ví dụ về phép gán.

Trong một số trường hợp không chỉ một biến mà được gán một giá trị đánh dấumới bị đánh dấu Cho ví dụ nếu một phần tử của mảng bị đánh dấu thì sau đó toàn bộmảng đối tượng cần phải được đánh dấu Cái này là cần thiết để chắc chắn rằng kếtquả của arr.length là một giá trị bị đánh dấu Hãy xem xét từ dòng 8 tới 12 trong ví dụhình 7 Ở dòng 8 một mảng mới được khởi tạo với độ dài là 0 Một giá trị được gán chophần tử đầu tiên ở dòng 10 chỉ khi kí tự đầu tiên của cookie là “a” Nếu như vậy thì bâygiờ độ dài mảng ở dòng 12 là 1 Ở dòng 12 một biến mới được thiết lập giá trị là “a”tùy thuộc vào chiều dài của mảng Khi mở rộng phương thức này cho tất cả các trươnghợp có thể có của kí tự (‘a’-‘z’, ‘A’-‘Z’, ‘0’-‘9’) kẻ tấn công có thể sao chép được kí tựđầu tiên của cookie cho một biến mới đo đó có thể lọt ra sự đánh dấu Tuy nhiên nếu ởdòng 10 ta không chỉ đánh dấu phần tử đầu tiên của mảng mà còn đánh đấu cả đốitượng mảng thì biến y ở dòng 12 sẽ bị đánh dấu Tương tự nếu một thuộc tính của đốitượng bị đánh dấu thì toàn bộ đối tượng cần được đánh dấu, lý do là thuộc tính đó cóthể là mới và trong trường hợp này số lượng thuộc tính thay đổi điều đó cho phép kẻtấn công có thể lợi dụng lỗ hổng

3.1.2.2 Phép toán học và logic

Các phép toán trong hình 8 có thể có một hoặc nhiều toán hạng Javascripttương tự java byte-code là một ngôn ngữ dựa trên stack Đó là các instruction mà thựchiện phép toán số học hay logic thì đầu tiên lấy ra số lượng thích hợp các toán hạng từ

stack để tính toán và sau đó nhét kết quả trở lại Kết quả bị đánh dấu khi sử dụng toánhạng bị đánh dấu

Hình 8: Ví dụ về các phép toán học và logic

3.1.2.3 Cấu trúc điều khiển và lặp

Cấu trúc điều khiển và lặp được sử dụng để điều khiển dòng thực hiện củachương trình và để lặp lại một số instruction nhất định Dưới đây là các cấu trúc điềukhiển và lặp:

- Khối if (có hoặc không có else)

- Câu lệnh switch

- Câu lệnh with

- Vòng lặp (do - while, for, hay for in)

- Khối try – catch – finally

Nếu điều kiện của cấu trúc điều khiển kiểm tra một giá trị đã đánh dấu thì một

“scope” (vùng) được tạo ra cho đến cuối của cấu trúc điều khiển đó

Hình 9: Ví dụ về vòng lặp for với điều kiện bị đánh dấu.

Hình 9 trên chỉ ra một ví dụ cho khối if Điều kiện của câu lệnh if bị đánh dấu(dòng 2) vì thể một phạm vi được tạo ra đến cuối khối (dòng 4) Kết quả của tất cả cácphép toán và phép gán trong vòng lặp là bị đánh dấu vì thể kết quả của lệnh gán ở dòng

3 là bị đánh dấu Điều này được sử dụng để thực hiện kiểm soát sự phụ thuộc để ngănchặn nỗ lực rửa sạch giá trị đánh dấu bằng cách sao chép chúng vào các giá trị không

bị đánh dấu như minh họa hình 10 Bởi vì một giá trị bị đánh dấu (document.cookie)được sử dụng trong điều kiện của vòng lặp for trong dòng 4 Một phạm vi từ dòng 4đến dòng 10 được tạo ra Một phạm vi bổ xung được tạo ra từ dòng 5 tới dòng 9 bởi vìđiều kiện trong câu lệnh switch là bị đánh dấu Khi sử dụng các phép toán trong mộtphạm vi bị đánh dấu thì tất cả các kết quả đều bị đánh dấu Bất kể toán hạng có bị đánh

dấu hay không Kết quả là biến “dut” bị đánh dấu.

Hình 10: Ví dụ cho một điều khiển phụ thuộc

Để xác định một phạm vi bao phủ câu lệnh if, ta có khái niệm đường bao Xemxét trong hình 11 một câu lệnh if với điều kiện bị đánh dấu (document.cookie == ‘a’ ởdòng 1) được dùng để gán cho biến x giá trị 5 ở dòng 2:

Hình 11: Phạm vi bị đánh dấu của khối if

Hình 12: Opcode của ví dụ trong hình 11Đoạn script này được biên soạn thành byte-code với các op-code như hình 12trên Cột đầu tiên là là giá trị bộ đếm chương trình (program counter PC) của opcode.Cột thứ hai là số tương ứng với số hiệu dòng trong hình 11 Cột cuối cùng là cột chứaopcode và một số thông tin tùy chọn Opcode ifeq tại PC = 00013 kiểm tra giá trị trongstack (điều kiện của câu lệnh if) và nhẩy tới PC = 00026 nếu điều đó là sai và tiếp tụcthực hiện câu lệnh sau câu lệnh if Opcode từ PC = 00016 tới PC = 00025 là thân củacâu lệnh if Vì thế bắt đầu của phạm vi là PC = 00013 và chiều dài của nó được xácđịnh ở thông tin tùy chọn của opcode (chiều dài là 13 và opcode tiếp theo là PC =00026) Khi câu if mà có else một goto-opcode có thể được tìm thấy ở PC = 00026 màchứa độ dài của nhánh else Các câu lệnh điều khiển khác cũng tương tự Nếu đố tượngđược sử dụng trong câu lệnh with mà nó bị đánh dấu một phạm vi bị đánh dấu đến cuốikhối được tạo ra Câu lệnh if-else sẽ tạo ra phạm vi cho cả hai nhánh nếu điều kiện bịđánh dấu Vòng lặp while, for, for-in được xử lý giống như câu lệnh if và câu lệnhwith Trong vòng lặp do-while phạm vi không được tạo đến khi điều kiện bị đánh dấu

được kiểm tra Kết quả là lần đầu tiên khối được chạy và không có phạm vi được tạo

ra Nếu điều kiện kiểm tra có bị đánh dấu một phạm vi đánh dấu bao trùm cả khối đượctạo ra, và sẽ giữ nguyên cho đến hết vòng lặp Trong câu lệnh try-catch-finally phạm viđược tạo ra cho khối catch khi một đối tượng ngoại lệ bị đánh dấu

Một vài ví dụ cho cấu trúc điều khiển được thể hiện trong hình 13 dưới đây:

Hình 13: Các vị dụ về cấu trúc điều khiển và lặp

3.1.2.4 Function calls và eval

Các hàm trong Javascript có thể từ các nguồn khác nhau như: một đối tượnghàm ẩn danh, đối tượng hàm có tên, hay định nghĩa cho một lớp mới (ví dụ hình 14,hình 15) Hàm có thể bị đánh dấu nếu được định nghĩa trong vùng bị đánh dấu (vùngđược tạo từ dòng 1 tới dòng 3 bởi điểu kiện bị đánh dấu ở dòng 1) như đã thấy tronghình 14 Ở dòng 5 hàm func được gọi với tham số bị đánh dấu mà kết quả trả về củahàm chính là tham số đó (dòng 4) nên kết quả của hàm func ở dòng 5 phải được đánhdấu Từ dòng 6 đến dòng 7 trong hình 15 chỉ ra rằng argument.length là bị đánh dấu

Tham số thứ 2 trong dòng 7 là bị đánh dấu nên vì thế kết quả trả về ở dòng 6 bị đánhdấu, kết quả đó truyền cho biến x ở dòng 7 nên biến x bị đánh dấu Một ví dụ phức tạphơn được chỉ ra từ dòng 8 đến dòng 10 trong hình 14 Trong dòng 8 – 9 một chuỗi

được lắp ráp và trả về giá trị của hàm count (hàm này trả về số lượng tham số truyền vào trừ đi 1 được định nghĩa trong dòng 6) cho biến dut Tham số thứ nhất của lời gọi

hàm là không bị đánh dấu trong khi các tham số khác là bị đánh dấu (bởi vì một phạm

vi đánh dấu trong vòng lặp được tạo ra) Đoạn chú thích trong dòng ở dòng 10 cho tathấy chi tiết hơn: các tham số bị gạch chân là những cái mà được thêm bởi vòng lặp bị

đánh dấu và vì thế chúng bị đánh dấu Evaluation của chuỗi này dẫn tới biến dut bị

đánh dấu

Hình 14: Các tham số hàm

Hình 15: Ví dụ về hàmHàm eval là một hàm đặc biệt vì đối số của nó được coi như là một chương trìnhJavascript và được chạy Nếu hàm eval được gọi trong phạm vi bị đánh dấu một phạm

vi xung quanh chương trình thực hiện được tạo ra (hình 16), và tất cả các toán tử trongchuỗi evaluted là bị đánh dấu.

Hình 16: Sử dụng của eval với thông tin bị đánh dấu

3.1.2.5 Dom Tree

Một kẻ tấn công có thể cố gắng loại bỏ trạng thái bị đánh dấu của một số yếu tố

dữ liệu bằng cách tạm thời lưu trữ nó trong một node nào đó trên DomTree và sau đó

sẽ lấy nó ra (hình 17) Để ngăn chặn việc làm sạch dữ liệu qua DomTree thông tin bịđánh dấu phải được mở rộng ra ngoài Java script- engine (trong trình duyệt), cuối cùngđối tượng là một Dom node sẽ bị đánh dấu khi một chương trình Java script lưu trữ giátrị bị đánh dấu lên node đó Khi nó được truy cập ở lần sau, thì giá trị trả về sẽ bị đánhdấu

Hình 17: Ví dụ cho lưu trữ tạm thời dữ liệu bị đánh dấu vào DomTree

3.2 Data transmission

Phương pháp “Dynamic data tainting” như mô tả ở 3.1.2 chỉ theo dõi trạng tháicủa yếu tố dữ liệu trong quá trình xử lý chúng ở Java script engine Chưa có các biệnpháp để ngăn chặn việc rò rỉ thông tin nhạy cảm Vì sự biên dịch của những câu lệnhJava script không bị ngăn chặn trong trường hợp biến sử dụng là bị đánh dấu Cũngkhông phải dữ liệu bị đánh dấu hay một phần của nó bị loại bỏ trong quá trình xử lý

Ta sẽ đi tìm hiểu cách để ngăn chặn việc rò rỉ thông tin nhạy cảm trong phần này