Phát triển giải pháp và ông ụ đảm bảo an ninh ho á dịh vụ trự tuyến

oss-Site Scripting là một trong các lỗi chính mà k tẻ ấn công khai thác để ấ t n công vào nhiều dịch vụ Web.. ủ- Phát triển một công cụ được gọi là XSS Detection nhằm kiểm tra và phát hi

1

- Đinh Thái Sơn

Trang ph bìa ụ

Chuyên ngành : Công nghệ thông tin

LUẬN VĂN THẠC SĨ KĨ THUẬT CÔNG NGH THÔNG TINỆ

NGƯỜI HƯỚNG D N KHOA H C Ẫ Ọ :

TS Nguyễn Khanh Văn

Hà N i – ộ Năm 2013

LỜI CAM ĐOAN

Tôi xin cam đoan: L ận văn thạu c s Công ngh thông tin “Phát triển giải ĩ ệ

pháp và công cụ đả m bả o an ninh cho các d ch v tr c tuy n” này là công trình ị ụ ự ế

nghiên c u thứ ực sự ủa cá nhân, đượ c c thực hiện trên cơ sở nghiên c u lý thuy t vứ ế à dướ ự hưới s ng d n khoa h c c a Tiẫ ọ ủ ến sĩ: Nguy ễn Khanh Văn

Tôi xin ch u trách nhi m v lị ệ ề ời cam đoan này

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

Tác gi ả

Đinh Thái Sơn

LỜI CẢM ƠN

Để n th nh chương tr nh cao học v ết luận văn n y, tôi xin chân th

cảm ơn đến quí thầy cô trong Viện Công nghệ thông tin và Truyền Thông, trường

Đạ ọi h c Bách Khoa Hà Nội đ ậã t n tình d y b o tôi trong th i gian h c ạ ả ờ ọ

Tôi xin g i l i biử ờ ết ơn sâu sắc đến Tiến Sĩ Nguyễn Khanh Văn đã dành rất nhi u th i gian và nhi t huyề ờ ệ ết để hướng d n tôi hoàn thành luẫ ận văn này

áNhân đây, tôi cũng xin cảm ơn Ban gi m hiệu trường Đại học Hùng Vương

và cá thc ầy cô trong khoa Toán công nghệ đ ạo điều kiện cho lớp cao học Công ã tngh thông tin 2010B tệ ại Hùng Vương ch ng tôi đượú c học tập thuận lợi

Mặc d tôi đ ố ắng hết sức ho n thiện luận văn, tuy nhiên chắc chắn vẫn ù ã c g àcòn nhi u thi u sót, r t mong s góp ý quý báề ế ấ ự u của quí th y cô và cáầ c bạn

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

Tác gi ả

Đinh Thái Sơn

MỤC LỤC

Trang ph bìa 1 ụ

MỤC LỤC 4 DANH M C CÁC THU T NGỤ Ậ Ữ, TỪ VIẾT TẮT 6 DANH M C CÁC HÌNH V 7 Ụ ẼPHẦN M Ở ĐẦU 9

1 Lý do chọn đề tài 9

2 Mục đích nghiên c u luứ ận văn, đối tượng, phạm vi nghiên c u 10 ứ

3 C u trúấ c luận văn 10 Chương 1 11

T NG QUAN V AN NINH TR C TUY N 11 Ổ Ề Ự Ế1.1 An ninh tr c tuy n 11 ự ế1.2 Th ng kê an ninh 11 ố1.3 Đánh giá 13 Chương 2 14 PHƯƠNG PHÁP PHÁT HIỆN VÀ NGĂN CHẶN CROSS-SITE SCRIPTING 14 2.1 Tìm hi u v Cross-site scripting 14 ể ề2.2 Các mối đe dọa từ Cross-site Scripting : 14 2.3 Phân lo i Cross-site Scripting 16 ạ2.4 Các cách ngăn chặn XSS: 20 2.4.1 Ngăn chặn XSS trong giai đoạn phát tri n web 21 ể2.4.2 Ngăn chặn XSS b ng ph n m m 22 ằ ầ ề2.4.3 Ngăn chặn XSS b ng vi c phân tích vi c truy n d li u 23 ằ ệ ệ ề ữ ệ2.4.4 Ngăn chặn XSS b ng vi c theo dõi d li u nh y c m 25 ằ ệ ữ ệ ạ ả2.4.5 Mã hóa an toàn (Secure Coding) 25 2.4.6 Tường l a ng d ng Web (Web Application Firewalls - ử ứ ụ WAF): 26 2.4.7 Phương pháp phòng chống phía máy khách (client-side) 28 2.5 Các cách phát hiện lỗ ải b o m t chung 29 ậ

2.5.1 Phương pháp t n công 29 ấ 2.5.2 Penetration Testing th công 30 ủ 2.5.3 Phân tích mã 32 2.5.4 Máy quét l h ng Web t ng 33 ỗ ổ ự độ 2.6 Mô hình hoạt động của WVS 35 2.6.1 S th c thi n i tuy n (inline) tronự ự ộ ế g iStar 37 2.6.2 Th c thi hoàn ch nh trong iStar 38 ự ỉ 2.6.3 Hạn chế ủ c a máy quét l h ng Web hi n nay 40 ỗ ổ ệ 2.6.4 M t máy ghi trình t n hình 42 ộ ự điể 2.6.5 Phát hiện các lỗ ổ h ng bảo mật trên lớp mạng 43 2.6.6 S ựphát hiệ ự động các lỗ ổn t h ng b o m t XSS lo i 2 (th h th 2) 43 ả ậ ạ ế ệ ứ Chương 3 46 PHƯƠNG PHÁP PHÁT HIỆN VÀ PHÒNG TRÁNH XSS WORM 46 3.1 Khái ni m XSS Worm 46 ệ 3.2 Phương pháp lan truy n c a sâu 46 ề ủ 3.3 Phương pháp phát hiện XSS worm 48 3.4 Chương trình XSS Detection : 54 3.5 Đánh giá chương trình 59

K T LU N 61 Ế Ậ TÀI LIỆU THAM KHẢO 63

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

STT Thuậ t ng ữ Di gi i ễn ả

1 XSS Cross- Site Scripting

2 CERT Computer Emergency Response Team

3 OWASP Open Web Application Security Project

4 DOM Document Object Model

5 PHP Hypertext Preprocessor

6 ASP Active Server Page

7 CGI Common Gateway Interface

8 HTML Hypertext Markup Language

9 HTTP Hypertext Transfer Protocol

10 URL Uniform Resource Locator

11 WVS Web Vulnerability Scanner

12 IDS Intrusion detection system

13 CAPTCHA Completely Automated PublicTuring test to

tell Computers and Humans Apart

14 CSRF Cross-site Request Forgery

15 IDE Integrated Development Environement

16 API Application Programming Interface

DANH M C C C H NH V Ụ Á Ì Ẽ

1.1 Th ng kê 10 lố ỗi website thường gặp phải 12 1.2 Th ng kê th i gian vá l i ố ờ ỗ 12 1.3 Mức độ nghiêm tr ng do các l h ng bọ ỗ ổ ảo mật gây ra 13 2.1 Th ng kê các l hố ỗ ổng thường b tị ấn công năm 2009 15 2.2 Ví d v m t tin nhụ ề ộ ắn, tấn công Stored XSS để ấ ắ l y c p

2.3 Các bướ ấc t n công Stored XSS 18 2.4 Ví d v t n công “ Reflected XSS” ụ ề ấ 19 2.5 Các bướ ấc t n công Reflected XSS 19 2.6 Đoạn hex đượ ử ục s d ng trong l i XSS ỗ 21 2.7 Ví d v m t b l c ụ ề ộ ộ ọ 27 2.8 M t d ng t n công XSS d a vào mô hình Black-box ộ ạ ấ ự 33 2.9 K thu t White-box th c hi n trong quá trình x lý d li u ỹ ậ ự ệ ử ữ ệ 33 2.10 M t ki n trúc Web Vulnerability Scanner chu n ộ ế ẩ 34 2.11 M t workflow-base WVS ộ 36 2.12 Th hi n kiực ệ ểu nội tuy n ế 37 2.13 Th c thi Inline trong Istar ự 38 2.14 Th c thi complete trong iStar ự 39 2.15 Các mẫu tiêm độc hại 44

3.1 Đoạn mã XSS Worm vi t b ng Javascript ế ằ 48

3.2 Mô hình ki n trúc ki m soát các gói tin t phía trình duyế ể ừ ệt

chống l i s phát tán c a XSS worm ạ ự ủ 49 3.3 S ự tương đồng giữa mã ngu n g c và mã nguồ ố ồn đã được

3.4 Mô hình hoạt động c a XSS Detection ủ 55 3.5 Một đoạn mã c a hàm list_url ủ 55 3.6 Mô t ảcác thuộc tính c a th HTML ủ ẻ 56 3.7 Một đoạn chương trình của hàm Handle_starttag 57 3.8 Một đoạn chương trình mô t hàm scan_web ả 57 3.9 Chương trình scan với các trang xss.progphp.com 59 3.10 K t qu tìm ki m lế ả ế ỗi các dựa vào các payload cho trước 59 3.11 Đánh giá xem website có khả năng dính lỗi XSS hay không 59

PHẦ N M Ở ĐẦ U

1 Lý do chọ n đ ề tài

S ự phát triển nhanh chóng của Internet đem lại cho người dùng rất nhiều

dịch vụ ữu ích đặc biệt là các dịch vụ thanh toán hoặc giải trí trực tuyến Tuy hnhiên hầu hết các ứng dụng này đều tiề ẩn nguy cơ chứm a các lỗ ải b o m t mà tin ậ

tặc có thể khai thác và ấn công Crt oss-Site Scripting là một trong các lỗi chính mà

k tẻ ấn công khai thác để ấ t n công vào nhiều dịch vụ Web Kể ừ khi trình duyệt t Web hỗ ợ tr việc thực hi n các script, các k ch bệ ị ản được nhúng trong n i dung, k ộ ẻ

tấn công có thể ử ụng lỗi bảo mật này để truy nhập thông tin người dùng một s dcách bất hợp pháp Vi c phát hiệ ện các mã script độc hại là r t c n thi t đấ ầ ế ối với ngườ ử ụi s d ng d ch v và vi c phát hi n này có th ị ụ ệ ệ ể được th c hi n b ng cách s ự ệ ằ ử

dụng các công cụ có sẵn do các công ty bảo mật uy tín cung cấp.Tuy nhiên ở Vi t ệNam vi c phòng ch ng tác hệ ố ại các lỗi do XSS gây ra chưa được nghiên c u cứ ụ ể th

và chi ti t.Vì vế ậy dướ ự hưới s ng dẫn của TS Nguyễn Khanh Văn, em đã chọn đề

tài “Phát tri n gi i pháp và công c ể ả ụ đả m bả o an ninh cho các d ị ch vụ ực tuyế ” tr n

nhằm mô tả ổng quan các dịch vụ ực tuyến và đi sâu tìm hiểu cách thức tấn công t tr

và các tác h i do cách tạ ấn công Cross Site Scripting gây ra, kh- ả năng giải quy t ế

nhằm giảm bớt sự nguy hiểm của các cuộc tấn công bằng cách thức này mang lại

Đồng th i trong luờ ận văn này, tác giả cũng nghiên cứu v XSS worm, nghiên c u ề ứphương pháp lan truyền và đưa ra mô hình ngăn chặn s d ng thu t toán tri-grams, ử ụ ậtác giả cũng phát triển m t công cộ ụ mới được xây d ng b ng ngôn ng python, ự ằ ữđược tác gi t tên là XSS Detection.Công c này nh m phát hi n m t s l i XSS ả đặ ụ ằ ệ ộ ố ỗthường g p trên website, và s ặ ẽ được đánh giá dựa trên hai y u t : hi u suế ố ệ ất và độchính xác Kết quả so sánh với chương trình Web Vulnerability Scanner của hãng Acunetix K t qu cho th y tính chính xác c a công c XSS Detection là có thế ả ấ ủ ụ ểchấp nhận được, đủ để đáp ứ ng cho s an toàn cự ủa người dùng mà không c n so ầsánh v i các công c ớ ụkhác

2 M ục đ í ch nghiên cứu luận văn, đối tượ ng, ph ạm vi nghiên cứ u

-Theo đánh giá của tác giả, đây l đề i tuy không mới trên thế ới nhưng ởà tà gi

Việt Nam đây là đề tài tương đối mới và khó với nhiều vấn đề ỹ thuật mới Trong k

phạm vi đ ềi u kiện v khả năng nghiên cứ , mục đ ch, đối tượng và u í à phạm vi nghiên

cứu được x c địá nh như sau:

- Nghiên c u t ng quan chung v ứ ổ ềan ninh các dịch v tr c tuy n ụ ự ế

- Nghiên c u Cross Site Scripting: ứ

• T ng quan v Cross Site Scripting ổ ề

• Các cách thức tấn công Cross Site Scripting

• Phương pháp ngăn chặn và phòng tránh

- Nghiên c u v ứ ềXSS Worm

- Thuật toán ngăn chặn sự lây lan c a XSS Worm ủ

- Phát triển một công cụ được gọi là XSS Detection nhằm kiểm tra và phát

hiện lỗi XSS trong các website và so sánh với công cụ WVS (Web Vulnerability Scanner )

3 C ấ u tr úc lu ận văn

Phầ ộn n i dung chính c a luủ ận văn được chia thành 3 chương, trong đó:

Chương 1 - T ng quan v an ninh tr c tuy n : Th ổ ề ự ế ống kê và đánh giá mức đ ủộ r i

ro của một số ỗ ả l i b o m t hay b m c ph i ậ ị ắ ả

Chương 2 Phương pháp phát hi n và ngăn ch - ệ ặ n Cross Site Scripting: Nghiên

c u v Cứ ề ross site Scripting, phân loại Cross site Scripting, cách thức phát hiện và ngăn chặ ỗn l i XSS

Chương 3 Phương pháp phát hi - ệ n và phòng tránh XSS worm: Chương này

giới thiệu các phương pháp phát hiện từ phía người xây dựng ứng dụng và từ phía người người dùng Mô t thuả ật toán ngăn chặn XSS worm, đồng th i xây d ng m t ờ ự ộ

ứng dụng được tác gi t tên là XSS Detection nh m quét và phát hi n l h ng ả đặ ằ ệ ỗ ổXSS

Chương 1

T NG QUAN V AN NINH TR Ổ Ề Ự C TUYẾ N 1.1 An ninh tr c ự tuyến

tiNgày nay, khi Internet ngày càng phát triển, việc ếp cận đến các dịch vụ

trực tuyến ngày càng dễ dàng hơn.Cùng với sự phát triển đó là sự xuất hiện của hàng loạt các website thương mại điện tử, thanh toán tr c tuy n, các m ng xã hự ế ạ ội, các trò chơi trực tuy n, vv….Vi c đ m b o an ninh, an toàn thông tin cho các giao ế ệ ả ả

dịch này là hết sức quan trọng Thống kê an ninh cho thấy sự quan tâm của tin tặc

đố ới v i các hình th c giao d ch tr c tuy n này C th là cùng v i s ứ ị ự ế ụ ể ớ ự tăng lên củ ốa s lượng các d ch v thanh toán tr c tuy n, thì s l i b o m t đ c phát hi n trên các ị ụ ự ế ố ỗ ả ậ ượ ệwebsite đó ngày càng tăng Đặc biệt, người qu n tr ả ị website cũng không nhận th y ấcác lỗ ải b o mật này Đến khi phát hiện được, thì tác h i là không nh ạ ỏ

trCác lỗi bảo mật liên quan đến các dịch vụ ực tuyến thường liên quan đến các ứng d ng web, công c ụ ụ dùng để triển khai thanh toán điệ ửn t Lý do là nh ng ữ

l p trình viên thi t k ậ ế ếcác ứng dụng web này chưa quan tâm đúng mức đến việc đảm

bảo an ninh cho các giao dịch điện tử, hoặc có thể ọ chưa đượ ầu tư, đào tạ h c đ o bài

bản cho những vấ đề này Chính vì thế, mặc dù có quan tâm, rà soát các chương n trình, tuy nhiên v n không th tránh khẫ ể ỏi mộ ứt ng d ng web dính các l i b o m t ụ ỗ ả ậ

Theo thống kê của BKAV (bkav.com.vn) trong năm 2012 có khoảng hơn

2203 website của các doanh nghiệp và cơ quan V ệi t Nam bị ấ t n công, l i phỗ ổ ế bi n

là khai thác lỗ ổ h ng trên các hệ ố th ng mạng Cũng theo thống kê này thì số lượng website b l i hị ỗ ầu như không giảm mà đang có chiều hướng tăng lên

Thực trạng cho thấy, an ninh mạng, an ninh trực tuyến vẫn chưa được quantâm đúng mứ ại các cơ quan, doanh nghiệc t p, h u hầ ết các cơ quan này cũng chưa bốtrí được nhân s ph trách an ninh m ng, ho c đự ụ ạ ặ ội ngũ chưa đáp ứng được v i tình ớhình thực tế

1.2 Th ố ng kê an ninh

Theo th ng kê an ninh t ố ừ t ổ chức whitehat (www.whitehatsec.com) s ố lượng các

lỗi liên quan đến việc đánh cắp thông tin người dùng, hay truy xuất vào cơ sở ữ d

liệu ngày càng tăng Cụ thể, tổ chức này thống kê 10 lỗi website thường gặp phải trong năm 2011 như sau :

Hình 1.1 : Th ố ng kê 10 lỗi website thườ ng g ặ p phả i

S lố ỗi liên quan đến Cross site Scripting tăng dần theo từng năm.Mặc dù các nhà phát triể ứn ng dụng web có quan tâm đế ỗ ản l i b o m t này, tuy nhiên sậ ố lượng website bị ỗ l i này không hề gi m.Theo t ch c này, năm 2010 lỗả ổ ứ i “Information Leakage” chiếm 64%, thì năm 2011 lại có xu hướng gi m ch còn 53% ả ỉ

-Việc vá lỗi cũng không hề đơn giản, vì nó liên quan đến cấu trúc của cả ứ ng

dụng web đang được triển khai Trong ngành công nghiệp CNTT, tổ chức whitehat

vẫn đánh giá thời gian sửa lỗi XSS là lâu nh t Trung bình là kho ng 35 ngày ấ ả

Hình 1.2 : Th i gian vá l i

ti b t n Cũng theo tổchức này, họ ến hành thống kê đánh giá các website dễ ị ổthương do các lỗ ổ h ng này mang l i Và m t l n n a lạ ộ ầ ữ ỗi XSS được đánh giá là nghiêm trọng hơn cả

Hình 1.3 : M ức độ nghiêm trọ ng do các l h ỗ ổ ng bả o m t gây ra ậ

1.3 Đánh giá

Tình hình an ninh m ng, an ninh tr c tuy n mạ ự ế ặc dù có được quan tâm nhưng không

h ề được cải thiện.S lố ỗi, website bị khai thác vẫn đang có chiều hướng tăng lên.Vì

vậy cần phải có các nghiên cứu sâu hơn, đánh giá chi tiết hơn về các lỗi bảo mật này

Đặc bi t đ i v i l i Cross site Scripting ngày càng phát triệ ố ớ ỗ - ển m nh và không có ạchiều hướng giảm.Chính vì thế ệc nghiên cứu nhằm phát hiện và ngăn chặn từ vi ng bướ ỗc l i XSS là h t s c quan trế ứ ọng.Trong chương 2, và chương 3 chúng tôi sẽ đề

cập chi tiết hơn về ấn đề này.Chúng tôi sẽ ến hành tìm hiểu lỗi XSS, phân loại v tichúng, đánh giá mức độ nguy hiểm, đưa ra các giải pháp phát hiện và ngăn chặn XSS.Đồng th i trong ờ chương 3, chúng tôi sẽ nghiên c u sâu hơn về XSS worm, ứmột dạng sâu, virus, tìm hiểu phương pháp lây lan, và đưa ra thuật toán ngăn chặn

và phòng tránh

Chương 2 PHƯƠNG PHÁP PHÁT HIỆN VÀ NGĂN CHẶ N CROSS- SITE SCRIPTING 2.1 Tìm hi ể u về Cross-site scripting

XSS là một kiểu khai thác lỗ ổng an ninh mạng mà ở đó cho phép kẻ ấcông chèn mã độc vào m t website Mã này có th có th ch a JavaScript hay ch là ộ ể ể ứ ỉHTML n m trên máy ch web hoằ ủ ặc được chèn vào khi người dùng duyệt đến một trang web Khi đoạn mã được kích ho t, k t n công có th chi m quy n s d ng ạ ẻ ấ ể ế ề ử ụcác trang web của bên th ba hoứ ặc sử ụ d ng tài nguyên của máy ch Các cuủ ộc tấn công XSS thường chèn mã JavaScript vào m t d ch v ộ ị ụ web độc h i th c hi n trên ạ ự ệtrình duy t web cệ ủa người dùng

biXSS là một trong các ứng dụng tấn công web phổ ến nhất mà các tin tặc sử

dụng để ử g i các mã độc hại cho người sử ụng Nó cũng được sử ụng để thay đổi d dnội dung hoặc chiếm quyền điều khiển trang web hay thực hiện các cuộc tấn công

để ấ l y thông tin và d liữ ệu người dùng

Bằng việc khai thác lỗ ổng XSS cross site scripting, kẻ ấn công có thể h - t xây

dựng một cuộc tấn công Kỹ thuật này thường được sử ụng bởi những kẻ ấn công d tvới mục đích là tiêm đoạn mã JavaScript, VBScript, ActiveX, HTML, hoặc Flash

để ự th c hi n trên h th ng c a n n nhân v i quy n c a n n nhân Khi m t cu c t n ệ ệ ố ủ ạ ớ ề ủ ạ ộ ộ ấcông được kích ho t, t t c m i th t l y tài khoạ ấ ả ọ ứ ừ ấ ản, thay đổi các thi t l p cế ậ ủa người

s d ng, l y cookie ho c qu ng cáo có th ử ụ ấ ặ ả ểsai lệch

2.2 Các m ối đe dọ ừ a t Cross-site Scripting :

- Theo thống kê về các lỗ ổng bảo mật thường bị ấn công nhất vào năm 2009, ta h t

có k t qu ế ả như dưới đây:

Hình 2.1 : Th ố ng kê các lỗ ổng thường bị ấn công năm 2009 h t

Microsoft http://www.microsoft.com

/

http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target

=<script>alert(document.cookie)</script>

Chase https://www.chase.com/ https://www.chase.com/chase/gx.cgi/F

Tcs?pagename=<script>alert(document.cookie)</script>&urlname=smallbusiness/direct

Ebay https://scgi.ebay.co.uk

https://scgi.ebay.co.uk/saw-cgi/eBayISAPI.dll?SSLRegisterShow

&countryid=3&siteId=3&co_partnerId

=0&UsingSS L=1&aolemail=<script>alert(document.cookie) </script>

Oracle

Japan

http://www.oracle.co.jp http://www.oracle.co.jp/mts_sem_owa/

MTS_SEM/im_search_exe?search_text=<script>alert(document.cookie)

</script>

Cross-Site Scripting (XSS) ch ếi m m t t l r t cao so v i cộ ỉ ệ ấ ớ ác phương pháp t n ấcông khác Hầu hết các tác hạ ềi ti m ẩ ủa kĩ thuật này đã đượn c c biết đến Tuy nhiên, chúng t ma ới ch kh c ph c ỉ ắ ụ được m t ph n c a nó ộ ầ ủ

T lừ ỗi Cross site scripting, kẻ ấn công có thể gây ra những rủi ro nghiêm - t

tr ng: ọ

• Đánh cắp thông tin ngườ ử ụi s d ng: ch ng hẳ ạn như hacker thêm JavaScript để

ăn cắp cookie, m t khậ ẩu người dùng,…

• T o ra nh ng thông tin sai l ch, bôi nh ạ ữ ệ ọdanh tiếng c a cá nhân, t ủ ổchức…

• Tạo các cuộc tấn công lừa đảo tr c tuy n ự ế

• Chiếm quyền sử ụ d ng của nạn nhân: chẳng hạn như thêm mã JavaScript đểchuyển hướng người dùng

• Đoạn mã độc h i có th làm cho trang web c a b n không th truy cạ ể ủ ạ ể ập, cũng như có thể làm cho trình duy t l i ho c tr nên không th hoệ ỗ ặ ở ể ạt động

• Thông qua đoạn mã k t n công có th theo dõi l ch s truy c p các trang ẻ ấ ể ị ử ậweb, theo dõi thông tin bạn đăng lên một trang web và truy cập vào dữ ệ li u cá nhân như (thẻ tín d ng, tài kho n ngân hàng,…) ụ ả

2.3 Phân loạ i Cross-site Scripting

Có ba lo i t n công XSS khác nhau là : Stored XSS, Reflected XSS và DOMạ ấ -base XSS C th ụ ể như sau:

- Stored XSS :

Còn được g i là ki u t n công liên t c (Persistent) là lo i mà các mã đư c ọ ể ấ ụ ạ ợchèn vào website thông qua m t chộ ức năng nào đó, chẳng hạn như: gửi m t l i bình ộ ờluận hay tin nhắn, gửi bài trên các diễn đàn, để ừ đó khi t các thành viên khác truy

c p website s b ậ ẽ ị dính mã độc từ ẻ ấ công này k t n

Với tấn công kiểu tấn công Stored XSS, kẻ ấn công sẽ lưu trữ đoạn mã độc ttrên ứng dụng web (ví dụ trong cơ sở ữ ệ d li u - Database) Vì vậy, nó được gọi là Stored XSS… Sau đó, khi một người dùng g i yêu cử ầu đến trang web mà có chứa đoạn mã độc đó thì đoạn mã độc s ẽ được kích ho t và th c hiạ ự ện mưu đồ ủ c a k t n ẻ ấcông

Ví dụ như một web site là một diễn đàn, nơi mọi người có thể đưa các bài

viết lên hiển thị cho tất cả ọi người Trang web này có thể được sử ụng để ực m d th

hiện loại tấn công này Kẻ ấn công viết một mẩu tin như hình 1 mà trong đó có tchứa một đoạn mã độ ể ăn cắp cookie, sau đó mẩu tin được lưu trữc đ trong CSDL Khi một người dùng muốn đọc bài vi t trên thì ế phả ả ả đoạn mã đội t i c c xu ng trình ốduyệt của mình Đoạn mã độc được chạy trên trình duyệt web của người dùng, nó

s gẽ ửi cookie của người dùng cho một máy chủ web mà được kiểm soát bởi kẻ ấn tcông

Hình 2.2 : Ví d v m t tin nh t ụ ề ộ ắ n, ấn công Stored XSS để ấ ắ l y c p cookie

Trước tiên, k tẻ ấn công lưu bài viết ch a mã XSS trên diứ ễn đàn Đầu tiên, người dùng đăng nhập vào diễn đàn và sẽ được xác định b i mở ột cookie được thi t ế

l p trên trình duyậ ệt Sau đó, người dùng có th c bài viể đọ ết của kẻ ấn công đã đăng, tcác mã độc được gử ả ại như mội tr l t ph n c a bài viầ ủ ết và sau đó nó sẽ được dịch và chạy trên trình duy t cệ ủa người dùng Đoạn mã XSS s g i cookie cẽ ử ủa người dùng

cho kẻ ấ t n công V i thông tin này cớ ủ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ác quyề ủa nạn c n nhân

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

- Reflected XSS :

- Còn được gọi là kiểu tấn công XSS không liên tục (Non Persistent) Đây là

-loại tấn công phổ ến Trong loại này, mã độc được gửi trở ại ngườ dùng với sự bi l i giúp đỡ ủ ứ c a ng dụng web Chúng dưới d ng m t tin nh n thông báo l i, k t qu ạ ộ ắ ỗ ế ảtìm ki m… gế ửi đến người dùng Để làm điều này, kẻ ấ t n công g i m t liên k t cho ử ộ ếngười dùng có th bể ằng email (đoạn mã hình 2 ) Trong liên k.4 ết là mã HTML có chứa mộ script để ất t n công các máy client nhận được email này Nếu người dùng

nhấp chuột vào liên kết thì sẽ ển thị các trang web được yêu cầu trong liên kết này hi

Trên trang web có thể ch a mã đ c hạứ ộ i, chúng sẽ được gử ới t i trình duy t cệ ủa người dùng và nó được th c thi ự

Hình 2.4: Ví d v t n công “Reflec ụ ề ấ ted XSS”.

của người dùng như “ Kiểm tra tài khoản”, “Một phần thưởng hấp dẫn đang chờ

• Bước 5: Sau khi nhận được thông tin c n thi t, hacker có th s dầ ế ể ử ụng để thâm

nh p vào tài khoậ ản của người dùng

Hình 2.5 : Các bước tấ n công XSS Reflected

- Dom- based Xss :

Đây là loại th ba c a ki u t n công XSS gây hứ ủ ể ấ ại đến trình duy t cệ ủa người dùng Trong trường h p này, k tợ ẻ ấn công đặt m t tộ ập tin Flash độc trên m t trang web mà ộngười dùng ghé thăm Khi trình duyệ ủa ngườt c i dùng t i v các video, t p tin kích ả ề ậ

hoạt một script trong trình duyệt, kẻ ấn công có thể ểm soát các yếu tố ủa các t ki ctrang web bên trong trình duy t cệ ủa ngườ ử ụi s d ng

Một XSS DOM base hoạt động hoàn toàn trong phạm vi của trình duyệt

-của nạn nhân và thậm chí một số cuộc tấn công còn có thể không được phát hiện

th y trên máy ch ấ ủ

2.4 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 source

Origination Policy” Mô hình này được sử ụng rộng rãi trong vấn đề đảm bảo an dninh 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 truy c p các thành ph n cể ậ ầ ủa một document được tả ừ ội t m t website khác Tuy nhiên, trong m 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ế ẻ ấn công nhúng mã độ t c vào liên

kết tương tự như hình 2.3, mô hình bảo mật đó có thể không còn tác dụng bởi vì đoạn script đó được ch y tronạ g chính trang web đó chứ không ph i là m t trang ả ộweb khác Nó có th l y tài nguyên trong trang 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 c ệ ệ

thực thi các ngôn ngữ script trên trình duyệt của mình Về ơ bản điểu này là đúng cnhư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 hay ị ỗ ổkhô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 JavaScript (là m t sự ộ ự ế k t h p các công nghợ ệ để ả c i

tiến tính tươ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ộ ựa chọt l n khác là ch vào nh ng trang web tin cỉ ữ ậy Điều này có thể ất khó khăn nế r u m t công c tìm kiộ ụ ếm được sử ụng để d tìm kiếm một

th ứ gì đó trên trang web Các trang web được trả ề ởi công cụ tìm kiếm mà chưa v b

không Sau đây, là 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.4.1 Ngăn chặn XSS trong giai đoạn phát triển web.

Hai biện pháp chính để phòng ch ng XSS phía máy ch là: l d li u u vào ố ở ủ ọc ữ ệ đầ

và kh u ra Chúng có th ử đầ ể được th c hiự ện trong giai đoạn phát tri n ph n m m : ể ầ ề

Lọc đầu vào là quá trình xác nh n t t c ậ ấ ảcác dữ ệ li u vào.Cách ả ệ b o v này thực

hi n bệ ởi các bộ ọc dự l a vào vi c lo i b ệ ạ ỏcác từ khóa được xác định trước, chẳng hạn như “<”, “script”, “JavaScript”, hoặc “document”,

Kh u ra s d ng m t s ký t , ch ng hử đầ ử ụ ộ ố ự ẳ ạn như “ <”, ” " “, đã được mã hóa khi người dùng cung c p d liấ ữ ệu để ửi đi g

Như vậy, 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 M i dọ ữ ệu đầ li 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” 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ử ụng mã hóa ký tự d ISO 8859 1 thì ký t c bi- ự đặ ệt đó có thểđược mã hóa thà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ử ụng trong đầ d u ra có th làm tể ốn tài nguyên nhưng lạ ấi r t hi u qu ệ ả

Phương pháp này được thưc hiện khi phát tri n ng d ng web mang l i hi u ể ứ ụ ạ ệ

qu ả cao 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 cả các tcuộc tấn công đã có và có thể có, và ph i bi t làm th ả ế ế nào để tránh chúng Đồng thời, phương pháp này tốn rất nhiều tài nguyên cho việc lọc và mã hóa mỗi đầu vào

và đầu ra 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ên rất cao Tuy nhiên, nếu tất cả các dữ ệu không đáng litin c y b ậ ị " tước vũ khí " theo cách này thì XSS có thể hoàn toàn được ngăn chặn

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

Phần m m ki m tra các l h ng XSS có th ề ể ỗ ổ ể được th c hiự ện theo hai cách tĩ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ác tác giả G.A Di Lucca, A.R Fasolino, M Mastroianni, and P Tramontana m t ộphương phá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ởi máy chủ Đồ ị bao gồm các nút đầu vào và đầu ra Mỗi nút đầ vào có th u

CSDL, cookie, dữ ệ li u từ ộ m t t p tin Mậ ột nút đầu ra là liên quan đến câu truy 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ể ị ỗ ổng nếu một phần củ ồ b l h a đ th luị ồng điều khiển tồn

tại kết nối một nút đầu ra với một nút đầu vào Tuy nhiên, trong trường hợp dữ ệu li

t mừ ột trang gửi đến một trang khác thì ứng dụng web có thể không bị ỗ ổng đối l h

với kiểu tấn công này nếu chỉ ột trang có lỗi bảo mật Ví dụ ột trang có thể đọc m mđầ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ỗ ổng tiềm tàng Nhưng nếu trang khác mà đọc dữ ệu từ h litrường này mà mã hóa m i th ọ ứ 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ứ ụng web 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á

ứng dụ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ích tĩ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ỗ ổng đó Các trình thu thập tiến hành kiểm thử ộp đen với một CSDL h hđượ ạo ra Nó phân tích các trang đượ ạc t 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ả ới mã nguồ v n nhưng nó chỉ ểm tra để ế ki bi t có l h ng hay không ch không kh c phỗ ổ ứ ắ ục đượ ỗc l

hổng Kiểm thử ộp đen có thể thấy hết các vị trí của ô nhập mà được sử ụng để h d

thực hiện trong các cuộc tấn công Nhưng đó cũng c ỉ là những cuộc tấn công đã h

bi t, và vì th ế ếchỉ ngăn chặn được các lỗ ổng đó h

2 4.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ử ụng để ngăn chặn tấn công XSS Proxy phải giám dsát các yêu c u (request) HTTP gầ ửi đi và các kết qu (response) tr v cả ả ề ủa người dùng đang lướt web Có hai ch ế độ được g i là “Response change mode” và ọ

“Request change mode” Trong “Response change mode”, proxy lưu trữ thông tin

v ề yêu cầu mà chứa những thẻ đặc biệt (ví dụ script) Nếu tiếp theo các thẻ đó lại

xuất hiện trong response gửi về ở ứng dụng web thì mặ ị b i 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êm mộ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ố ủa yêu cầu gửi đi được cthê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 ng web 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 response thì ứ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ả ại đượ l 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ẻ ữa các máy chủ giproxy Hệ ố th ng này không có thông tin về ấ c u trúc và ngữ nghĩa của trang web vừa truy c p, nó ch có thậ ỉ ể ể ki m tra tham số được xử lý bở ứi ng d ng wụ eb mà được sử

d ng trong yêu c u http Nụ ầ ếu mã hóa được sử ụ d ng thì proxy không th theo dõi các ểrequest và các response

Ngoài ra trong cu n sách “10ố th ACM Conferenceon Computerand Communication 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ấn cô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ích cho 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 đọc và giai đoạn phát hiện Trong giai đoạn đọ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 truy vố ỗ ấn được tính toán b ng cách s dằ ử ụng mô hình đào tạo mà

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.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 p ằ ệ ữ ệ ạ ả ả ợtrong 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ữ ệu ra bên ngoài chương trình thì nó sẽ li

b ị ngăn chặn Việc đánh dấu và theo dõi các dữ ệu nhạy cảm như vậy gọi là li

“tainting” Các dữ ệu nhạy cảm phải được quy định cụ ể Ví dụ như là biế li th 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õi các dữ ệu nhạy cảm đó Ví dụ, khi chúng được truyền litrong các hàm, được gán cho các biế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ỉ ần chỉnh sửa trình biên dịch Khi c

đã tích hợp gi i pháp này vào trình biê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 ng m i thì l i ph i xây d ng l i trình biên d ch ả ệ ỗ ổ ớ ạ ả ự ạ ị

2.4.5 Mã hóa an toàn (Secure Coding)

hCách tốt nhất để ngăn chặn các lỗ ổng bảo mật trong các ứng dụng là viết

mã an toàn Quá trình phát tri n ph n mể ầ ềm đã dần dần được c i thi n theo th i gian ả ệ ờ

và có nhiều phương pháp tiếp cận khác nhau Tùy thuộc vào quy mô nhóm, quy mô

d ự án, thời gian và ngân sách tiền tệ hoặc chỉ đơn giản là sở thích cá nhân, nhóm nhà phát tri n ph n m m có thể ầ ề ể ự l a chọ ừ ận t t p h p các mô hình phát tri n phợ ể ần

mềm khác nhau hay từ các mô hình cũ như mô hình thác nước, mô hình V, hoặc là

một trong các phương pháp nhanh như Extreme Programming, SCRUM và vv… Tuy nhiên, trong số những phương pháp này không có phương pháp nào tập trung chủ ế y u vào cách mã hóa an toàn

Michael Howard và Steve Lipner từ Microsoft đã phát triển và công bố cuốn sách có tên "Security Development Lifecycle" (SDL) SDL được hoàn thành và được gi i thi u trong tháng 7 năm 2004 tớ ệ ại Microsoft và các tác gi cho rả ằng sau đó

chất lượng t ng th v an ninh c a các sổ ể ề ủ ản phẩm của Microsoft sẽ ải thiện đáng kể cTrong bất cứ ột nhóm phương pháp phát triể m n phần mềm nào, phần quan tr ng ọ

nhất nằm trong sự ểu biết của tất cả các nhà phát triển, đó là quá trình xây dự hi ng

và cung cấp các tính năng SDL ch là m t ví d , trỉ ộ ụ ong đó kiến th c an ninh, an ứtoàn thông tin và học vấn được kế ợt h p trong việc viết tài liệu chứng minh, t o ra ạcác mô hình…

Có nhiều cách mã hóa an toàn Tuy nhiên, điều quan trọng là phải hiểu rằng,

mục tiêu của quá trình quét lỗ ổng là tìm ra lỗ ổ h h ng bảo mật để các nhà phát triển

có th ể theo dõi và đưa ra các cơ chế ả b o m t ậ.

2 4.6 Tường lửa ứng dụng Web (Web Application Firewalls - WAF):

Tường lửa ứng dụng Web kiểm tra sự an toàn của các ứng dụng trong trình duyệt của các khách hàng WAF điều tra lưu lượng truy cập đến các mẫu xác định trước và các b l c s l c gói tin v i nộ ọ ẽ ọ ớ ội dung độc h i giạ ống như mộ ệ ốt h th ng phát

hiện xâm nhập (IDS) Ví dụ, WAF có thể ọc các yêu cầu đầu ra của HTTP và tìm lcác thông s không h p lố ợ ệ hoặc các thông số có ch a dữ ệứ li u có thể ẽ s gây ra lỗ

hổng bảo mật Lợi thế chính là ứng dụng bảo vệ không thay đổi trong bằng bất kỳtrường h p nào ợ

Danh sách đầu vào phù hợp cho các mẫu độc hại được gọi là danh sách đen(blacklisting), lọc đầu vào với nội dung được chấp nhận gọi là danh sách trắng (whitelisting)

Để làm cho danh sách đen rõ ràng hơn, xét cấu hình một WAF phát hiện vectơ tấn công <script>arlert(something)</script>, ví d phù h p v i bi u th c là: ụ ợ ớ ể ứ

<script>arlert \ (* \) </ script> Biểu th c này có th ứ ể được gi u b i các ấ ở vectơ tấn công <script> prompt (1) </ script>, các vectơ này về cơ bản giống như các vectơ

tấn công đầu tiên Bảng 2.7 cho thấy những ví dụ ủa các biểu thức chính quy và ccác mẫu tiêm gi u chúng ấ

Hình 2.7: Ví d v m t b l c ụ ề ộ ộ ọ

Rõ ràng r ng hằ ầu như không ể ế th vi t một bộ ọ danh sách đen l c mà có thể tìm

ra tất cả đầu vào độ ạ c h i Mặt khác, bộ ọ danh sách trắ l c ng c n phầ ải được thiết kế

một cách cẩn thận để không giới hạ các chức năng củn a m t ộ ứng dụng Web Vì ự s

phức tạ ủp c a nó, nhiệm vụ này gần như là không th th c hi n ể ự ệ

Rõ ràng, m t ộ WAF không giải quyết được tận gốc các lỗ ổng bảo mật mà h

chỉ ả gi i quyết được các trường h p nó phát hi n ra d u hi u ợ ệ ấ ệ Các ứng d ng ụ Web cơ

b n v n ả ẫ không an toàn v ếì n u m t k tộ ẻ ấn công tìm ra ột cách để ắ m t t WAF, ng ứ

dụng Web ẽ để ộ s l ra tất cả các điểm yếu của nó Một bất lợi là nếu một tường lửa (WAF) không được c u hình ho c b ấ ặ ị vượt qua, thì h th ng r t d b v ệ ố ấ ễ ị đổ ỡ

M t ộ điểm yếu nữa là kh ả năng tương thích, ở ộm r ng của tường lử Nếu một a

ứng dụng Web được sao chép s d ng trên m t vài máy ch ử ụ ộ ủ ở các nơi khác nhau,

vậy nên cài đặt WAF ở đâu?

x ử lý đầu vào, bằng cách thêm vào các thuật toán phân tích đầu ra của mộ ứt ng dụng Web, hoặc bằng cách theo dõi các mã script được phép và không được phép

Nh ng cách tiữ ếp cận này khá thú v , tuy có chiị ến lược làm gi m s t n công vào các ả ự ấ

ứng d ng web ụ nhưng không giải quyết được các vấn đề ả b o m t c a mã ngu n ng ậ ủ ồ ứ

Trong một báo cáo khác người ta phát triể, n một công cụ có tên là Noxes,

hoạt động như là một tường lửa cá nhân phía máy khách cho các ứng d ng Web Nó ụ

là m t proxy ộ cơ bản, chặn yêu cầu đầu ra và chạy các bộ ọ l c khác nhau trên các yêu

cầu để xác định xem chúng là độc hại hay không Các tác giả ải thích Noxes như gisau: “Trong một tường l a truy n th ng, khi m t kử ề ố ộ ết nối (connection) được mở thông qua một port nào đó từ ộ ứ m t ng dụng không được xác định, thì rõ ràng ứng

dụng đó tiềm ẩn nhiều nguy cơ Tuy nhiên, trên web, các trang được liên kết với nhau vì vậy nó có thể liên k t đ n các trang web mà ngưế ế ời dùng không biết đến Do

đó, một tường l a web cá nhân nên có ích trong th c t ph i h tr m t s liên k t ử ự ế ả ỗ ợ ộ ố ế

tối ưu để giảm sự ần thiết phải tạo ra các quy tắ c c bắt buộc như trên Đồng thời, tường lửa có để đả m b o r ng an ninh không suy y u " ả ằ ế

Nhận xét này cho thấy rõ ràng có nhiề ấ ều v n đ trong các phương pháp phòng chống phía client Phương pháp này vô cùng quan tâm đến vi c phân bi t gi a mã ệ ệ ữJavaScript độc hại và không độc h i, th , và các liên kạ ẻ ết Sau đó, một gi nh quan ả đị

trọng cơ bản được thực hiện: “Tất cả các liên kết tĩnh được nhúng trong một trang web có thể được coi là an toàn đối với các cuộc tấn công XSS Nh ng kữ ẻ ấ t n công không thể ự tr c ti p sế ử ụ d ng các liên kết tĩnh để mã hóa dữ ệu ngườ li i dùng nhạy

c m.” ả

Gi ả định này là đúng đối với các nỗ ự ể l c đ ăn cắp thông tin đăng nhập hoặc

hiểm khi các ứng dụng web bị nhiễm sâu XSS (xem chương 3) ,dựa trên các liên

kết tĩnh và không có ý định ăn cắp thông tin nhạy cảm thông qua JavaScript Tin tặc

s dử ụng các cuộc tấn công XSS để ải phần mềm độc hại vào máy tính của nạn tnhân

2.5 Các cách phát hi ện lỗ ả i b o m t ậ chung

hCác lỗ ổng của ứng dụng web có thể được khám phá theo nhiều phương pháp Hai phương pháp tiếp c n thông dậ ụng là phương pháp kỹ thu t h p đen ậ ộ(black-box) và phương pháp ỹ k thuật hộp trắng (whit box) Trong phương pháp e-Black-Box, các ứng dụng Web được ểm tra, xử lý mặc dù không truy cập mã kingu n, ồ không nghiên cứu mã nguồn và thậm chí không biết loạ ứng dụng nào đangi chạy trên máy ch Web T t c thông tin v ng d ng Web phủ ấ ả ề ứ ụ ải được thu th p ậthông qua các các công cụ như Web Vulnerability Scanners ( một công cụ quét lỗ

hổng web rất hữu ích ), hay bằng thủ công kiểm tra các phản h i ồ HTTP hoặc ằb n cách th các giá trử ị đầ u vào khác nhau Qua đó, tạo ra t p các hành đ ng c a ứng ậ ộ ủ

d ng web ụ

Phương pháp White-Box thì ngượ ạc l i, các Pentester ( những người đánh giá

độ an toàn website thông qua cách t n công chúng) có t t c các thông tin c n thi t ấ ấ ả ầ ế

và th m chí có th truy c p vào mã nguậ ể ậ ồn để tìm các lỗ ổ h ng Hoạt động của các

ứng d ng Web có th ụ ể được theo dõi b ng cách s d ng công c g l i, máy ch ằ ử ụ ụ ỡ ỗ ủWeb và các phiên bản cơ sở ữ ệu đượ d li c biết đến

m t ộ ứng dụng Web không thông qua cách nhìn của kẻ ấn công, chúng ta có khả tnăng bỏ ỡ l các l h ng b o m t, b i vì chúng ta t p trung nghiên c u quá nhi u vào ỗ ổ ả ậ ở ậ ứ ềtác động hơn là v các cách thề ức để phát hi n các loạệ i khác nhau c a các lỗ ổủ h ng XSS

2.5.2 Penetration Testing thủ công

Thu t ng “Penetration Testing” ( hay Pentest) có th hiậ ữ ể ểu một cách đơn giản chính

là đánh giá độ an toàn b ng cách tằ ấn công( đánh trận gi ) M t ph n trong công tác ả ộ ầđánh giá hệ ố th ng Nói m t cách chính xác ta ph i th c hi n m t s công vi c chính ộ ả ự ệ ộ ố ệsau đây:

- Xác định khả năng bị ấ t n công

- Kh ả năng kế ợp các nguy cơ nhỏt h thành mối nguy cơ lớn

- Xác định các nguy cơ mà các công cụ ự độ t ng không phát hiện được

- Đánh giá khả năng tác động đến hoạt động của tổ chức nếu Pentest thành công

- Kh ả năng của hệ ố th ng trong việc ngăn chặn các loại hình t n công ấ

- Lượng hoá các vấn đề ần đầu tư cho bả c o m t ậ

Pentest một cách ủ công là cách mang lại kết quả ốt nhất vì một lý do th tđơn giản: M i ng dỗ ứ ụng Web là khác nhau và có tương tác với ngườ ử ụi s d ng Nhiều trường nhập dữ liệu yêu cầu thông tin hợp lệ như: một ID khách hàng hợp lệ,

s th ố ẻ tín dụng hợp lệ, tên một người dùng, sau đó mới cho phép người dùng tiến hành bước ti p theo Ví dế ụ, tương tác của ngườ ử ụng là CAPTCHA, đượi s d c thi t ế

k mế ột cách rõ ràng để xác định người đó và để ngăn chặn các hệ ống tự độ th ng truy c p vào các lậ ớp sâu hơn của ứng d ng Web Sụ ự tương tác của con người trở nên quan trọng hơn trong các ứng d ng Web hiụ ện đại vì các thư viện JavaScript, hình ảnh động, và các yêu cầu HTTP không đồng bộ thông qua AJAX được kích

ho t b ng vi c nhạ ằ ệ ấp chuột ho c nh n phím ặ ấ

Một số ỗ ổng trong các ứng dụng Web có thể được kẻ ấn công khai thác l h t

bằng cách sử ụ d ng các cách khác thường Một số bài báo cung cấp một số ví dụ khá hay H t o ra m t ng dọ ạ ộ ứ ụng thử nghiệm được gọi là "WackoPicko", trong đó người

Khi tải lên một hình nh, WackoPicko sao chép tả ệp được đăng bởi người dùng t i ớmột thư mục con của thư mục tải lên Tên của thư mục con là th ẻ người dùng cung

cấp các hình ảnh được tải lên Tin tặc có thể thao tác trên các tham số ẻ để ực th th

hi n t n công ệ ấ

Kết quả là máy quét không thể tìm ra lỗ ổng bảo mật Nguyên nhân do các hmáy quét không th t i lên m t hình ể ả ộ ảnh Nhưng ngay cả khi các máy quét có th tể ải lên m t hình nh, v n có khộ ả ẫ ả năng máy quét sẽ không phát hiện được các lỗ

h ng Ch ổ ỉ có sự ết hợp của việc tải lên một hình ảnh và cung cấp một thẻ đặc biệt kthì s tìm ra l hẽ ỗ ổng đó

dPentesters sử ụng một cách tiếp cận lặp đi lặp lại Đầu tiên, các thông sốđầu vào đượ ửc s a đ i m t chút b ng cách chèn các vectơ t n công có ch a các kí t ổ ộ ằ ấ ứ ựquan trọng như ‘, ", <, và >

Đôi khi , các vectơ tấn công có th ể được thay th bế ằng vectơ tấn công tương tự, phá

v ỡ các bộ ọc cụ thể Giả ử, bộ ọ l s l c đầu vào lọc c ỗi con <script> Nếu bộ ọc hu lkhông tái ki m tra các chu i, các vector t n công <scr <script> ipt src = " "> </ ể ỗ ấscript> s ẽ vượt qua được bộ ọc và mã độc đượ l c th c thi ự

Một cách tiếp cận lặp đi lặp lại vào thư mục WackoPicko truyền tải lỗ ổ h ng

bảo mậ ẽ bao gồm tải lên một hình ảnh bình thường với thẻ khác nhau như test, t s

<script> alert (5) </ script>, / test, test/test2, / / test, để tìm các bất thường trong các phản h i cho mồ ỗi vectơ tấn công Ngoài ra, hình nh có th ả ể được thay th b ng ế ằ

một hì ảnh bị thay đổi hoặc bởi một tệp hoàn toàn khác chẳng hạnh n như một Shellscript (tập lệnh vỏ) hoặc một tệp script ập lệ(t nh) được viết bằng ngôn ngữ ập trình l

-của các ứng dụng Web để tiêm các mã tiêm độc hại Pentesting thủ công tìm hiểu các cách gây ra s kiự ện bất ngờ ủ c a các ứng dụng Web để ể hi u cơ chế và logic c a ủ

nó

Việc sử ụng pentesting thủ công trở nên cồng kềnh, nếu các biểu mẫu với dcác trường đầu vào là vô t n và mậ ỗi trường phải được kiểm tra m t lộ ần Hãy tưởng tượng m t bi u m u vộ ể ẫ ới 20 trường u vào mà ch có mđầ ỉ ột đầu vào là l h ng b o ỗ ổ ả

mật để ấn công Đồ t ng thời, nếu một trong những trường đầu vào khác bị ph y ủ đầ

bởi một vectơ tấn công, ứng dụng sẽ ển thị ột thông báo lỗi không rõ ràng.Cách hi mduy nhất đểtìm ra lỗ ỏ h ng b o m t là kiả ậ ểm tra đầu vào của tấ ả các trườt c ng Ta cần

m t công c t ộ ụ ự động để ự th c hi n các công việ ệc lặp đi lặp lại

Mặt khác, kiểm tra thâm nhập thủ công không phá hủy các máy chủ Web vì lượ ảt t i quá m c b i hàng ngàn yêu c u HTTP, skipfishứ ở ầ 3 gửi đến 2.000 yêu cầu mỗi giây - một con số ấn tượng Tuy nhiên, kết quả không phải lúc nào cũng như mong

2.5.3 Phân tíc h mã

thuPhân tích mã là một kỹ ật hộp trắng điển hình, bởi vì pentester có quyền truy c p mã nguậ ồ ứn ng d ng web Kụ ẻ ấn công cũng có thể ử ụng phân tích mã để t s dtìm trong ph n m m mã ngu n mầ ề ồ ở những lỗ ổ h ng b o m t Phân tích mã ngu n có ả ậ ồ

th ể được thực hiệ ằng thủ công hoặc tự động Cách tiếp cận thủ công cũng giốn b ng như bấ ỳ phương pháp tiết k p cận mã đọc khác, pentester truy tìm v trí c a d li u, ị ủ ữ ệ

d liữ ệu đó được xử lý như thế nào và nơi mà nó chuyể ớn t i

K thuỹ ật hộp đen chỉ hoạt động trên các giao diệ có thể được truy cập từn bên ngoài Tuy nhiên, các ng dứ ụng web cũng nên lọc dữ ệ li u từ cơ s d liở ữ ệu Nếu không, m t nhân viên có qu n truy cộ yề ập vào cơ sở ữ ệ d li u có thể tiêm mã độc hạ ừ i tbên trong, sau đó gửi cho t t c các khách hàng c a các ng d ng Web Trong k ấ ả ủ ứ ụ ỹthuật hộp đen là việc chuyển giao dữ ệu từ cơ sở ữ ệu tới các giao diện đầu ra li d li