WEB APPLICATION SECURITY

Hình 3-1: Tấn công Brute-force thành côngTiết lộ thông tin tài khoản trên đường truyền Nếu một ứng dụng sử dụng một kết nối HTTP không được mã hóa để truyềntải các thông tin đăng nhập, h

KHÓA LUẬN TỐT NGHIỆP

WEB APPLICATION SECURITY

Niên khóa : 2006 - 2010

Sinh viên thực hiện : Lâm Thế Diễn

Hứa Văn HiếuTrịnh Thái LongNguyễn Minh Thành

TP HỒ CHÍ MINH, tháng 10 năm 2010

KHÓA LUẬN TỐT NGHIỆP

WEB APPLICATION SECURITY

Giáo viên hướng dẫn: Sinh viên thực hiện:

Hứa Văn HiếuTrịnh Thái LongNguyễn Minh Thành

TP HỒ CHÍ MINH, tháng 10 năm 2010

security test” đã phần nào hoàn thành Ngoài sự cố gắng hết mình của bản thân,chúng em đã nhận được sự khích lệ rất nhiều từ phía nhà trường, thầy cô, gia đình

Chúng em xin chân thành cám ơn thầy cô trường Đại học Nông Lâm TP.HCM

đã tận tình giảng dạy, trang bị và truyền đạt những kiến thức quý báu, đã truyềnthụ cho chúng em những kiến thức, kinh nghiệm, đã quan tâm dìu dắt và giúp đỡchúng em trong suốt quá trình học tập cũng như trong lúc thực hiện luận văn này.Đặt biệt, chúng em xin bày tỏ lòng chân thành sâu sắc đến thầy Phạm Văn Tính,người đã tận tình hướng dẫn và giúp đỡ chúng em trong quá trình làm luận văn tốtnghiệp

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

Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phépnhưng chắc chắn sẽ không tránh khỏi những thiếu sót, kính mong nhân được sựtận tình chỉ bảo của quý thầy cô và bạn bè

Một lần nữa, chúng em xin chân thành cám ơn và luôn mong được những tìnhcảm chân thành của tất cả mọi người

Giới thiệu tổng quan về sự phát triển công nghệ thông tin trên thế giới Tìnhhình an ninh mạng trên thế giới và việt nam Các lỗ hổng mạng dễ bị tấn côngnhất, cũng như đánh giá của các tổ chức quốc tế và việt nam về mức độ nguyhiểm và tính phổ biến của các lỗ hổng đó Và cuối cùng hướng tìm hiểu, đánh giá

và mục đích cuối cùng của đề tài chúng em

Chương 2: Tổng Quan

Giới thiệu thực trạng ứng dụng web xưa và nay từ đó rút ra các khái niệm vềweb security, khái niệm ứng dụng web, mô hình và hoạt động của ứng dụng web

và các vấn đề có liên quan đến bảo mật ứng dụng web

Chương 3: Cơ Sở Lý Thuyết.

3.1: Phần này mô tả chi tiết các vấn đề liên quan đến quá trình xác thực đang

phổ biến rộng rãi Khả năng khai thác thông tin và tấn công dựa vào nhứng lỗhổng trong xác thực và đưa ra những biện pháp phòng ngừa để khắc phục những

lỗ hổng này trong thiết kế ứng dụng

3.2: Chương này trình bày khái niệm về session token, các kỹ thuật khai thác

session, các vị trí có thể khai thác điểm yếu của session token Cuối cùng là đưa

ra những biện pháp phòng thủ để hạn chế điểm yếu này

3.3: Trình bày khái quát về lỗi kiểm soát truy cập trong ứng dụng, chỉ ra các

rủi ro thường gặp trong lỗi kiểm soát truy cập Đồng thời, chúng tôi cũng đưa racác phương pháp để giúp chúng ta tránh được các lỗi kiểm soát truy cập trongứng dụng

3.4: Trình bày các loại tấn công bằng phương pháp inject code bao gồm : kỹ

thuật tiêm code vào ngôn ngữ thông dịch, tiêm code vào SQL, tiêm vào hệ điềuhành, tiêm vào ngôn ngữ Scripting web, tiêm vào SOAP, tiêm vào Xpath, và tiêmvào LDAP Đặc biệt trong phần này sẽ giới thiệu nhiều kỹ thuật khai thác và tấncông lỗi SQL injection, giới thiệu các lỗi thường gặp của ba HQTCSDL MySQL,MS-SQL và Oracle bị hacker khai thác lỗi SQL injection

3.5: Phần này mô tả khái niệm về lỗi path traversal, cách thực hiện tấn công,

những kỹ thuật dùng để vượt qua những trở ngại khi thực hiện tấn công pathtraversal và những biện pháp để khắc phục lỗ hổng này trong quá trình thiết kếứng dụng

3.7: Trình bày khái quát về lỗi XSS Phân loại các loại lỗi XSS Các kỹ thuật

dùng để phát hiện, khai thác và tấn công ứng dụng khi xảy ra lỗi XSS Đồng thời,chúng tôi cũng đưa ra các phương pháp để phòng chống việc tấn công vào lỗiXSS

3.8: Phần này trình bày về các khái niệm, kỹ thuật tấn công và đưa ra những

lời khuyên để ngăn chặn những lỗi thông dụng: Redirection, HTTP HeaderInjection, Frame Injection, Request Forgery, JSON Hijacking, Session Fixation,ActiveX Controls

3.9: Phần này mô tả về các lỗ hổng có thể xảy ra trong kiến trúc tầng của ứng

dụng Khả năng khai thác các lỗ hổng đó, mức độ nguy hiểm và đưa ra lời khuyênngăn ngừa khả năng xuất hiện các lỗ hổng đó

3.10: Trình bày khái quát về tấn công từ chối dịch vụ Chỉ ra cho người dùng

biết những khả năng có thể bị tấn công bằng từ chối dịch vụ Các kiểu tấn công từchối dịch vụ thường gặp hiện nay và đưa ra một số phương pháp để khắc phục vàphòng chống kỹ thuật tấn công từ chối dịch vụ

3.11: Trình bày khái quát về lỗi file inclusion Đưa ra các kỹ thuật tìm kiếm,

khai thác khi ứng dụng xảy ra lỗi file inclusion Đồng thời, chúng tôi cũng đưa racác phương pháp để phòng chống việc tấn công vào lỗi file inclusion

3.12: Trình bày khái quát về hệ quản trị cơ sở dữ liệu MySQL Trong chương

này các cơ chế bảo mật của MySQL sẽ được trình bày cụ thể Thứ nhất là cơ chếbảo mật trong môi trường mạng, chúng ta sẽ tìm hiểu cơ chế bảo mật của SSL,cách cài đặt và triển khai của nó Thứ hai cơ chế bảo mật trong cơ sở dữ liệu sẽtìm hiểu các bản và các cột chứa thông tin đăng nhập cơ sơ dữ liệu cũng như quátrình xác thực password

3.13: Trình bày về các lỗi xảy thường xảy ra trên client Đánh giá mức độ rủi

ro và sự đe dọa trong các ứng dụng web Đồng thời đưa ra lời khuyên cụ thể chotừng loại lỗi

3.14: Phần này đưa ra những biện pháp xây dựng hệ thống mạng an toàn và

đưa ra những lỗ hổng mạng thường xuyên bị tấn công

3.15: Trình bày khái quát về các loại web server Đưa ra một số lỗi thường xảy

ra trên các loại web server và cách khắc phục cho từng trường hợp cụ thể

Chương 5: Kết Quả Đạt Được Và Hướng Phát Triển

Phần này đưa ra các bảng mô tả khái quát và đánh giá mức độ nguy hiểm củacác lỗi Đồng thời đưa ra bảng thống kê các công cụ hỗ trợ phát hiện, khai thác vàtấn công các loại lỗi Đưa ra hướng phát triển của luân văn

TÓM TẮT BÁO CÁO ii

MỤC LỤC v

DANH SÁCH CHỮ VIẾT TẮT ix

DANH SÁCH CÁC HÌNH xi

DANH SÁCH CÁC BẢNG xi

Chương 1: MỞ ĐẦU 1

Chương 2: TỔNG QUAN 3

2.1 Khái niệm về Web Security 3

2.2.Tổng quan về web server 3

2.3 Khái niệm về ứng dụng web 4

2.4 Mô hình và hoạt động của ứng dụng web 6

2.5 Các vấn đề liên quan đến bảo mật ứng dụng web 7

Chương 3: CƠ SỞ LÝ THUYẾT 8

3.1 Lỗi xác thực trên web 8

3.1.1 Kỹ thuật xác thực 8

3.1.2 Thiết kế gây lỗi trong cơ chế xác thực 8

3.1.3 Lỗi trong khi hiện thực quá trình xác thực 11

3.1.4 Đảm bảo an toàn trong xác thực 13

3.2 Lỗi quản lý Session 14

3.2.1 Yếu điểm trong Session Token Generation 14

3.2.2 Yếu điểm trong xử lý Session Token 19

3.3 Lỗi trong kiểm soát truy cập 20

3.3.1 Các lỗi thường gặp trong kiểm soát truy cập 21

3.3.2 Khai thác lỗi kiểm soát truy cập 22

3.3.3 Đảm bảo kiểm soát truy cập 24

3.4 Inject code 25

3.4.1 Inject vào ngôn ngữ thông dịch 26

3.4.2 Inject vào SQL 27

3.4.3 Inject vào hệ điều hành 32

3.4.4 Inject vào ngôn ngữ Scripting web 36

3.4.8 Inject vào LDAP 41

3.5 Lỗ hổng Path Traversal 42

3.5.1 Lỗ hổng thường gặp 42

3.5.2 Tìm và khai thác lỗ hổng Traversal Path 43

3.5.3 Ngăn chặn lỗ hổng Traversal Path 49

3.6 Yếu điểm trong logic của ứng dụng 50

3.6.1 Bản chất của lỗi Logic 50

3.6.2 Các ví dụ thực tế 50

3.6.3 Hạn chế lỗi Logic 54

3.7 Cross Site Scripting 54

3.7.1 Lỗ hổng Reflected XSS 55

3.7.2 Lỗ hổng Stored XSS 57

3.7.3.Tìm kiếm lỗi XSS 58

3.7.4 Khai thác lỗi XSS 59

3.7.5 Cách phòng chống 60

3.8 Một số lỗi thông thường 60

3.8.1 Lỗi Redirection 60

3.8.2 Giả mạo yêu cầu 64

3.8.3 Session Fixation 69

3.8.4 ActiveX Controls 72

3.8.5 Lỗ hổng Buffer overflow 75

3.9 Kiến trúc của ứng dụng 77

3.9.1 Kiến trúc đa tầng 77

3.9.2 Shared Hosting và cung cấp dịch vụ web 80

3.10 Tấn công từ chối dịch vụ 83

3.10.1 Các kỹ thuật tấn công 83

3.10.2 Cách phòng chống 89

3.11 File Inclusion 90

3.11.1 Tìm kiếm lỗi 90

3.12.1 MySQL 97

3.12.2 SQL Server 102

3.12.3 Oracle 102

3.13 Các lỗi xảy ra trên client 104

3.13.1 HTML input field 105

3.13.2 Cookies and HTTP headers 105

3.13.3 Java applet 106

3.13.4 Javascript 106

3.13.5 Flash 107

3.13.6 Ajax 108

3.14 Các lỗi xảy ra trên network 108

3.14.1 Những phương pháp nâng cao tính bảo mật mạng 109

3.14.2 Những điểm yếu mạng thường bị tấn công 110

3.14.3 Kết luận 111

3.15 Các lỗi xảy ra trên web server 112

3.15.1 Apache tomcat 112

3.15.2 Microsoft Internet Information Service 115

Chương 4: NGHIÊN CỨU THỰC NGHIỆM 118

4.1 Lỗi SQL Injecton 118

4.1.1 Cách phát hiện 118

4.1.2 Cách khai thác 120

4.2 Lỗi Path Traversal 120

4.2.1 Cách phát hiện 121

4.2.2 Cách khai thác 121

4.3 Lỗi Cross Site Scripting 122

4.3.1 Cách phát hiện 122

4.3.2 Cách khai thác 124

4.4 Lỗi trong quá trình chứng thực 125

4.4.1 Cách phát hiện 125

5.2 Hướng phát triển 138 TÀI LIỆU THAM KHẢO 139

Cơ Sở Dữ LiệuCascading Style SheetsDynamic HyperText Markup LanguageDocument Object Model

Denial of ServiceExtensible Binary Meta LanguageFinish

Greenwich Mean TimeGlobally Unique IdentifierHyperText Markup LanguageHypertext Transfer ProtocolHypertext Transfer Protocol SecureInternet Explorer

Internet ProtocolInternational Standard Book NumberJavaScript Object Notation

Linux, Apache, MySQL, PHPRandom Access MemoryStructured Query LanguageSecure Sockets LayerSynchoronize

Transmission Control ProtocolTransmission Control Protocol / Internet ProtocolUniform Resource Locator

Extensible HyperText Markup LanguageExtensible Markup Language

Cross Site Cripting

Hệ quản trị cơ sở dữ liệu

Hình 2-1: Mô hình ứng dụng Web ba tầng 6

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

Hình 3-1: Tấn công Brute-force thành công 9

Hình 3-2: Kết quả của quá trình bắt session 20

Hình 3-3: Kết quả khi sử dụng tham số thư mục 33

Hình 3-4: Kết quả inject thành công câu lệnh trên PERL 34

Hình 3-5: Hiển thị nội dung của file log 35

Hình 3-6: Kết quả tiêm thành công câu lệnh trên ASP 35

Hình 3-7: Một cuộc tấn công thành công với lỗi path traversal .45

Hình 3-8: Thông báo lỗi tự động tạo ra 56

Hình 3-9: Pop-up thông báo lỗi XSS 57

Hình 3-10: Các bước tấn công lỗ hổng Stored XSS 57

Hình 3-11: Các bước khai thác lỗi XSS 59

Hình 3-12: Mô hình các khai thác session fixation 70

Hình 3-13: Mô tả cấu trúc Registry 74

Hình 3-14: Một cuộc tấn công vào tầng cơ sở dữ liệu để lấy dữ liệu 79

Hình 3-15: Tổ chức cung cấp dịch vụ ứng dụng 81

Hình 3-16: Quá trình thiết lập kết nối 84

Hình 3-17: Tấn công DoS truyền thống 85

Hình 3-18: Kiểu tấn công vào băng thông 85

Hình 3-19: Tấn công kiểu DDoS 86

Hình 3-20: Tấn công kiểu DRDoS 87

Hình 3-21: Quá trình tấn công kiểu Smurf 88

Hình 3-22: Mô hình mạng 109

Hình 3-23: Quy trình kiểm tra mạng lưới an ninh 112

Hình 4-1: Custome search engine 118

Hình 4-2: Kết quả tìm được của Custome search engine 119

Hình 4-3: Xác định lỗi dựa vào phần tìm kiếm 123

Hình 4-4: Thông báo trả về của phần tìm kiếm 123

Hình 4-5: Pop-up thông báo lỗi XSS .124

Hình 4-6: Script được chèn vào code của ứng dụng 124

Hình 4-7: Tạo tài khoản với mật khẩu yếu có 3 ký tự 126

Hình 4-8: Thông tin về tài khoản của trang web được phổ biến 126

Hình 4-9: Cửa sổ nhận vào 2 file chứa username và password 127

Hình 4-10: Quá trình Brutefore mật khẩu thành 128

Hình 5-1: Biểu đồ đánh giá mức độ bảo mật 136

Bảng 5-2: Tiêu chí đánh giá lỗi 134

Chương 1: MỞ ĐẦU

Ngày nay, khi khoa học công nghệ bùng nổ phát triển và trở thành động lựcphát triển của thế giới đặc biệt là lĩnh vực công nghệ thông tin Internet trở nênphổ biến rộng rãi, quen thuộc và trở thành phương tiện để các tổ chức, cá nhângiới thiệu thông tin cũng như thực hiện các phiên giao dịch trực tuyến Vấn đề nảysinh khi phạm vi ứng dụng ngày càng mở rộng thì khả năng xuất hiện lỗi cũng nhưkhả năng bị tấn công ngày càng cao và trở thành đối tượng cho nhiều người tấncông Nếu những cuộc tấn công khi xưa mang mục đích đơn giản chỉ là để thử tài

và chứng minh bản thân thì bây giờ những cuộc tấn công còn mang bản chất chínhtrị, cạnh tranh trong kinh tế và kiếm tiền bất chính

Theo thống kê của các tổ chức an ninh mạng quốc tế cùng với sự phát triển củaInternet thì số lượng của các vụ tấn công cũng tăng theo cấp số nhân và mức độngày càng nghiêm trọng Đi đôi với quá trình đó, các tài liệu chuyên môn đề cậpđến vấn đề an ninh và bảo mật cho ứng dụng web cũng ngày càng nhiều hơn.Theo thống kê của Bộ Thông Tin Và Truyền Thông trong năm 2009, nước ta cóhơn 1000 website bị hacker tấn công, tăng hơn gấp đôi so với năm 2008 (461website) và gấp ba lần so với năm 2007 (342 website) Mạng Internet Việt Namcòn tiềm ẩn rất nhiều rủi ro về mặt an ninh

Trong ba tháng đầu năm nay, đã có hơn 300 website của các cá nhân và tổ chức

có tên miền.vn bị các hacker nước ngoài thăm dò, tấn công Các website bị tấncông chủ yếu là các website kinh doanh trực tuyến, ngân hàng, các tổ chức cungcấp dịch vụ…

Theo số liệu của CERT (Computer Emegency Response Team), số lượng các

vụ tấn công Internet trên thế giới những năm đầu thập niên 90 chỉ ở mức vài trăm.Năm năm đầu của thế kỷ 21 ở mức độ vài ngàn và đến thời điểm hiện tại (2010) làmức độ vài chục ngàn

Những vụ tấn công này nhằm vào các tập đoàn lớn, các công ty, nhà băng vàcác tổ chức chính trị cũng như quân sự: google, Microsoft, bộ an ninh quốc phòng

Mỹ, các mạng xã hội như facebook cũng không tránh khỏi… Một số vụ tấn công

có quy mô lớn và kéo dài (có tới 100.000 máy tính) Những con số này chỉ lànhững cuộc tấn công được công bố, số lượng thực tế có lẽ còn lớn hơn nhiều.Theo các cuộc kiểm tra vào năm 2006-2007 thì danh mục các điểm dễ bị tổnthương của ứng dụng web là Broken Authentication (67%), Broken Access

Controls (78%), SQL Injection (36%), Cross-site scripting (91%), Informationleakage (81%).

Hình 1-1: Bảng Thống kê đánh giá các loại lỗi

Với sự phát triển của công cụ tự động tìm lỗ hổng giúp các nhà lập trình webphát hiện và ngăn chặn rất nhiều lỗi nhưng vẫn không thể ngăn chặn hoàn toàn vìcông nghệ web đang phát triển rất nhanh Ngoài ra còn những vấn đề về hệ thốngmạng của ứng dụng web Sự tấn công không nằm trong khuôn khổ một ứng dụngnhất định mà linh động và tăng lên tùy vào những sai sót của nhà quản trị hệ thốngcũng như những người lập trình ứng dụng

Xuất phát từ thực trạng nói trên, luận văn được thực hiện với mục đích tìmhiểu, phân tích, đánh giá mức độ nguy hiểm của các lỗ hổng bảo mật Từ đó đưa

ra những lời khuyên, nguyên tắc để xây dựng hệ thống trở nên an toàn hơn Songsong đó luận văn còn đưa ra từng công cụ thích hợp nhất để tìm ra một lỗi xácđịnh, giúp cho các nhà lập trình web có tầm nhìn tổng quan và logic hơn về vấn đềbảo mật trên ứng dụng web

Chương 2: TỔNG QUAN

2.1 Khái niệm về Web Security

Trong những ngày đầu, World Wide Web chỉ bao gồm các trang web Đây lànhững kho thông tin chủ yếu có chứa các văn bản tĩnh và trình duyệt web đã đượcphát minh như một phương tiện thu hồi và hiển thị những tài liệu Những dòngthông tin đi một chiều từ server tới trình duyệt Hầu hết các trang web đã khôngxác thực người dùng vì không cần thiết Khi xâm nhập một web server, hackerkhông thể có bất kỳ thông tin nhạy cảm nào bởi vì các thông tin được tổ chức trênserver đã được mở để xem công cộng Thay vào đó, hacker sẽ sửa đổi các tập tintrên server để hủy hoại nội dung trang web

Ngày nay, World Wide Web gần như không thể nhận ra từ các phiên bản trước

đó của nó Chúng được tổ chức lại rất cao, và có sự trao đổi thông tin hai chiềugiữa server và trình duyệt Những website đã hỗ trợ đăng ký, đăng nhập, giao dịchtài chính, tìm kiếm, và thay đổi nội dung động theo từng người sử dụng Phần lớncác thông tin xử lý là cá nhân và rất nhạy cảm Do đó, bảo mật là một vấn đề lớn:không ai muốn sử dụng một ứng dụng web nếu họ tin rằng thông tin của họ sẽđược tiết lộ cho bên thứ ba một cách trái phép cũng như môi trường web động làmphát sinh thêm nhiều lỗ hổng ứng dụng web Môi trường phát triển web hiện naycũng tạo cơ hội cho nhiều lỗ hổng được phát sinh như: các ứng dụng được pháttriển in-house, một số ứng dụng Web được phát triển bởi người có quá ít kinhnghiệm về an ninh và bảo mật, và nếu một trang web bị lỗi thì những trang web cóđặc điểm chung cũng sẽ có lỗi tương tự Khái niệm web security ra đời cho mọingười cái nhìn chung và thấy được sự quan trọng của vấn đề an ninh và bảo mậttrên ứng dụng web

Web security là tập hợp những tiêu chuẩn, những nguyên tắc về bảo mật và lậptrình nhằm giúp những ứng dụng web trở nên an toàn hơn Từ đó đưa ra tiêuchuẩn để đánh giá mức độ an toàn của trang web

2.2.Tổng quan về web server

Web Server là server có dung lượng lớn, tốc độ cao, được dùng để lưu trữthông tin như một ngân hàng dữ liệu, chứa những website được thiết kế cùng vớinhững thông tin liên quan khác (các mã Script, các chương trình, các fileMultimedia)

Web Server có khả năng gửi đến client những trang web thông qua môi trườnginternet (intranet) qua giao thức HTTP (giao thức được thiết kế để gửi các file đếntrình duyệt web) Nó cho phép nhiều client khác nhau kết nối với các server cungcấp mà không gặp bất kì một trở ngại nào trong vấn đề tương thích.

Hầu hết các dữ liệu request hoặc response đều phải được định dạng bằng ngônngữ HTML HTML là một ngôn ngữ đánh dấu đơn giản được sử dụng để địnhdạng văn bản Trình duyệt thông dịch các thông tin đánh dấu và hiển thị các thôngtin cần đáp ứng này với khả năng tốt nhất Quan trọng hơn nữa, HTML cho phépliên kết các tài liệu và tài nguyên khác nhau Thể hiện tính siêu văn bản của web.Tất cả các Web Server đều có một địa chỉ IP hoặc cũng có thể có một DomainName

Bất kì một máy tính nào cũng có thể trở thành một Web Server, ta chỉ việc càiđặt lên nó một chương trình phần mềm Server và sau đó kết nối vào internet.Tất cả các Web Server đều hiểu và chạy được các file *.htm và *.html Tuynhiên, mỗi Web Server lại phục vụ một số kiểu file chuyên biệt chẳng hạn nhưIIS của Microsoft: *.asp, *.aspx ; Apache: *.php ; Sun Java System Web Servercủa SUN: *.jsp

Khi máy tính của bạn kết nối đến một Web Server và gửi các thông tin yêu cầutruy cập từ một trang web nào đó, phần mềm Web Server sẽ nhận yêu cầu và gửilại cho bạn những thông tin mà bạn mong muốn

Giống như những phần mềm khác mà bạn đã từng cài đặt trên máy tính củamình Phần mềm Web Server cũng chỉ là một phần mềm ứng dụng Nó được càiđặt và chạy trên máy tính dùng làm Web Server, nhờ có chương trình này màngười sử dụng có thể truy cập đến các thông tin của trang web từ một máy tínhkhác ở trên mạng (Internet, Intranet)

Phần mềm Web Server còn có thể được tích hợp với CSDL (Database) hayđiều khiển việc kết nối vào CSDL để có thể truy cập và kết xuất thông tin từCSDL lên các trang web và truyền tải chúng đến người dùng

2.3 Khái niệm về ứng dụng web

Dưới góc độ kỹ thuật, Web được định nghĩa là môi trường có khả năng thực thichương trình cao, cho phép tạo vô số tùy biến trên triển khai trực tiếp của mộtlượng lớn các ứng dụng tới hàng triệu người dùng trên thế giới Hai thành phầnquan trọng nhất của website hiện là trình duyệt Web và các ứng dụng Web Tất cả

mọi người đều có thể sử dụng hai thành phần mà không phải trả bất cứ khoản phínào.

Web browser (trình duyệt web) là phần mềm ứng dụng cho phép người dùngtruy vấn dữ liệu và tương tác với nội dung nằm trong website Các trang Web hiệnđại cho phép người dùng lấy xuống nội dung động và tham chiếu riêng Hơn nữa,chúng cũng có thể chạy các script trên client, có thể “thay đổi” trình duyệt Internetthành giao diện cho các ứng dụng như thư điện tử, phần mềm ánh xạ tương tác(Yahoo Mail, Google Maps)

Quan trọng nhất là website hiện đại cho phép đóng gói, xử lý, lưu trữ và truyềntải dữ liệu nhạy cảm của người dùng (như thông tin cá nhân, mã số thẻ tín dụng,thông tin bảo mật xã hội…) có thể dùng ngay hoặc dùng định kỳ về sau Và điềunày được thực hiện qua các ứng dụng Web

Dưới góc độ chức năng, ứng dụng Web là các chương trình máy tính cho phépngười dùng website đăng nhập, truy vấn dữ liệu qua mạng Internet trên trình duyệtWeb yêu thích của họ Dữ liệu sẽ được gửi tới người dùng trong trình duyệt theokiểu thông tin động (trong một định dạng cụ thể, như với HTML thì dùng CSS) từứng dụng Web qua một Web Server

Mang tính kỹ thuật nhiều hơn có thể giải thích là: các ứng dụng Web truy vấnserver chứa nội dung và tạo tài liệu Web động để phục vụ yêu cầu của client Tàiliệu được tạo trong kiểu định dạng tiêu chuẩn hỗ trợ trên tất cả mọi trình duyệt(như HTML, XHTML) JavaScript là một dạng script client-side cho phép yếu tốđộng có ở trên từng trang (như thay đổi ảnh mỗi lần người dùng di chuột tới).Trình duyệt Web chính là chìa khóa Nó dịch và chạy tất cả script, lệnh… khi hiểnthị trang web và nội dung được yêu cầu

Một cải tiến đáng kể khác trong quá trình xây dựng và duy trì các ứng dụngWeb là chúng có thể hoạt dộng mà không cần quan tâm đến hệ điều hành hay trìnhduyệt chạy trên các máy client Ứng dụng Web được triển khai ở bất cứ nơi nào cóInternet, không tốn phí và hầu hết không đòi hỏi yêu cầu cài đặt cho người dùngcuối

Con số doanh nghiệp thu được lợi nhuận từ kinh doanh qua Web ngày càngtăng Do đó, việc sử dụng ứng dụng Web và các công nghệ liên quan khác sẽ tiếptục phát triển Hơn nữa, khi các mạng Intranet và Extranet được thông qua, ứngdụng Web trở thành “cứ điểm” lớn trong bất kỳ cơ sở hạ tầng truyền thông nàocủa các tổ chức, doanh nghiệp Phạm vi và khả năng kỹ thuật được mở rộng

2.4 Mô hình và hoạt động của ứng dụng web

Hình bên dưới minh họa chi tiết mô hình ứng dụng Web ba tầng Tầng đầu tiênthông thường là trình duyệt Web hoặc giao diện người dùng Tầng thứ hai là côngnghệ kỹ thuật tạo nội dung động như Java servlet (JSP) hay Active Server Pages(ASP), Tầng thứ ba là cơ sở dữ liệu chứa nội dung và dữ liệu người dùng( nhưusername, password, mã số bảo mật xã hội, chi tiết thẻ tín dụng)

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

2.5 Các vấn đề liên quan đến bảo mật ứng dụng web

Trong thực tế, phần lớn các ứng dụng web là không an toàn, dù có hoặc không

sử dụng SSL Theo kết quả thử nghiệm hàng trăm trang web của các chuyên giabảo mật trong những năm gần đây cho thấy tỷ lệ của những ứng dụng web thửnghiệm trong năm 2006 và 2007 bị ảnh hưởng bởi một số loại tổn thương phổbiến Dưới đây những giải thích ngắn gọn:

Broken authentication (67%): lỗi này dễ bị tổn thương bao gồm các yếu điểmkhác nhau trong cơ chế đăng nhập của ứng dụng, cho phép hacker đoán mật khẩuyếu, khởi động một cuộc tấn công brute-force hoặc bỏ qua hoàn toàn các thông tinđăng nhập

Broken access controls (78%): liên quan đến trường hợp ứng dụng có cách bảo

vệ truy cập dữ liệu và chức năng của nó không đúng, cho phép hacker xem dữ liệunhạy cảm của người dùng khác được tổ chức trên server, hoặc thực hiện hànhđộng đặc quyền

SQL injection (36%): lỗ hổng này cho phép hacker dùng câu lệnh SQL để canthiệp vào sự tương tác của ứng dụng với cơ sở dữ liệu Một hacker có thể lấy dữliệu tùy tiện từ các ứng dụng, can thiệp vào logic của nó, hoặc thực hiện lệnh trênmáy chủ cơ sở dữ liệu

Cross-site scripting (91%): lỗ hổng này cho phép hacker tiếp cận dữ liệu củangười dùng khác, thực hiện hành động thay họ mà lẽ ra không được phép, hoặcthực hiện các cuộc tấn công chống lại họ

SSL là một công nghệ tuyệt vời để bảo vệ tính bí mật và tính toàn vẹn của dữliệu trong quá trình truyền dữ liệu giữa client và server Vì thế mà nó bảo đảmkhông cho hacker nhận dạng được server để tấn công Nhưng hacker không ngừnglại ở các cuộc tấn công trực tiếp vào server, như hầu hết các cuộc tấn công đã xảy

ra, hacker có thể tận dụng các lỗ hổng được liệt kê bên trên để tấn công một ứngdụng hoặc những người dùng khác của ứng dụng đó Vì vậy dù có sử dụng SSLhay không, các ứng dụng web vẫn còn chứa các lỗ hổng bảo mật

Chương 3: CƠ SỞ LÝ THUYẾT

3.1 Lỗi xác thực trên web

Trong một ứng dụng web, chứng thực là khái niệm đơn giản nhất của tất cả các

cơ chế bảo mật ứng dụng web Khi người dùng cung cấp tên và mật khẩu củamình thì ứng dụng phải xác minh rằng thông tin này là chính xác Nếu không, nó

sẽ chặn người dùng truy cập vào hệ thống

3.1.1 Kỹ thuật xác thực

Trong ứng dụng web, có rất nhiều công nghệ có sẵn khác nhau cho phép hiệnthực cơ chế xác thực:

 Dựa trên các hình thức xác thực HTML

 Cơ chế Multi-factor là sự kết hợp mật khẩu và thẻ vật lý

 Client SSL certificates và smartcards

 HTTP basic và digest authentication

 Chứng thực Windows-integrated sử dụng NTLM hoặc Kerberos

 Dịch vụ chứng thực của bên thứ ba

Hầu hết các lỗ hổng và khả năng tấn công liên quan đến chứng thực có thểđược áp dụng cho bất kỳ công nghệ nào được đề cập

3.1.2 Thiết kế gây lỗi trong cơ chế xác thực

Sự an toàn trong quá trình xác thực tùy thuộc vào thiết kế, thiếu sót trong việcthiết kế mô hình này có thể đưa ra những ứng dụng rất dễ bị truy cập trái phép

Tình trạng mật khẩu yếu

Nhiều ứng dụng web không sử dụng hoặc kiểm soát không tốt mật khẩu ngườidùng Các yếu điểm khi đặt mật khẩu:

 Rất ngắn hoặc trống

 Các từ thường gặp trong từ điển

 Đặt giống tên người dùng

 Vẫn còn thiết lập một giá trị mặc định

Các bước khai thác

 Xem lại tất cả các quy tắc đặt mật khẩu

 Cố gắng đăng ký tài khoản với một số mật khẩu yếu để xác định quy tắcđặt mật khẩu

 Xác định các yếu điểm trong quá trình thay đổi mật khẩu

Hình 3-1: Tấn công Brute-force thành công

Tiết lộ thông tin tài khoản trên đường truyền

Nếu một ứng dụng sử dụng một kết nối HTTP không được mã hóa để truyềntải các thông tin đăng nhập, hacker có thể chờ ở một vị trí thích hợp trên mạng để

có thể bắt dữ liệu:

 Trên mạng nội bộ của người dùng

 Trong phạm vi ISP(Internet Service Provider) của người dùng

 Trên đường trục Internet

 Trong phạm vi các ISP lưu trữ các ứng dụng

 Trong bộ phận quản lý ứng dụng

 Chú ý:

Một số vị trí này có thể được kiểm soát bởi người có thẩm quyền nhưng cũng

có khả năng bởi hacker từ bên ngoài đã xâm nhập

Chức năng thay đổi mật khẩu

Nhiều ứng dụng web không cung cấp chức năng thay đổi mật khẩu Mặc dùchức năng này là cần thiết cho một cơ chế xác thực

Có rất nhiều ứng dụng web có chức năng thay đổi mật khẩu có thể truy cập màkhông cần xác thực:

 Cho phép không hạn chế số lần đoán mật khẩu hiện tại

 Chỉ kiểm tra mật khẩu mới và xác nhận mật khẩu mới ứng với cáctrường có cùng giá trị sau khi xác nhận mật khẩu hiện có

Các bước khai thác

 Xác định bất kỳ chức năng thay đổi mật khẩu trong ứng dụng

 Thực hiện các yêu cầu khác nhau cho chức năng thay đổi mật khẩu, sửdụng tên người dùng không hợp lệ, mật khẩu không hợp lệ, và "mật khẩumới" và "xác nhận mật khẩu mới" không phù hợp

Tên tài khoản có thể dự đoán

Một số ứng dụng tự động tạo ra tên người dùng heo một số quy luật dự đoánđược (ví dụ, cust5331, cust5332, vv) Nếu vậy hacker có thể phân biệt các quyluật và nhanh chóng tạo một danh sách đầy đủ tất cả các tên người dùng hợp lệ

Mật khẩu ban đầu có thể dự đoán

Trong một số ứng dụng, người dùng được tạo ra cùng một lúc và được tự độnggán mật khẩu ban đầu Các phương tiện tạo ra mật khẩu có thể cho phép hacker

để dự đoán các mật khẩu của người dùng khác

Phân bố thông tin tài khoản không an toàn

Nhiều ứng dụng phân phối các thông tin tài khoản mới tạo đến người dùngtrong nhóm, quá trình này có thể trình bày một nguy cơ bảo mật Ví dụ, nếu cácURL gửi cho người dùng kế tiếp theo trình tự nào đó, hacker có thể suy ra cácURL kích hoạt gửi cho người dùng gần đây và sắp tới

Các bước khai thác

 Nếu không bắt buộc phải khai báo các thông tin quan trọng trong quátrình đăng ký, xác định cách thức mà ứng dụng phân phối chứng chỉ chongười dùng mới

 Nếu một URL kích hoạt tài khoản được sử dụng, hãy thử đăng ký mớimột số tài khoản và xác định những quy luật trong các URL bạn nhậnđược

 Hãy thử để tái sử dụng một URL kích hoạt nhiều lần, và xem liệu ứngdụng cho phép điều này hay không

3.1.3 Lỗi trong khi hiện thực quá trình xác thực

Ngay cả một cơ chế xác thực được thiết kế tốt có thể được đánh giá không antoàn do những sai lầm được thực hiện trong quá trình xử lý Lỗ hổng này có xuhướng khó bị phát hiện hơn so với mật khẩu kém chất lượng

Cơ chế đăng nhập Fail-Open

Fail-open logic là một loại lỗ hổng logic và có hậu quả đặc biệt nghiêm trọngtrong các cơ chế xác thực

Ví dụ: nếu phương thức db.getUser() phát sinh một ngoại lệ (ví dụ, ngoại lệNullPointerException phát sinh do yêu cầu của người dùng không chứa tham số

tê tài khoản và mật khẩu), nhưng vẫn đăng nhập thành công Session sẽ khôngchứa danh tính người dùng, do đó có thể không thực hiện được đầy đủ chức năngnhưng hacker vẫn có thể truy cập một số dữ liệu nhạy cảm hoặc chức năng

public Response checkLogin(Session session) {

try { String uname = session.getParameter(“username”);

String passwd = session.getParameter(“password”);

User user = db.getUser(uname, passwd);

 Thực hiện đăng nhập hợp lệ bằng một tài khoản bạn kiểm soát Ghi lại tất

cả thông tin liên lạc bằng cách sử dụng proxy

 Lặp lại quá trình đăng nhập nhiều lần, sửa đổi mẩu dữ liệu gửi đi theonhững cách đặc biệt Ví dụ: Gửi một chuỗi rỗng, hủy bỏ hoàn toàn cặpname/value, gửi giá trị rất dài và rất ngắn, gửi chuỗi thay vì con số vàngược lại, gửi một mục nhiều lần, với giá trị giống nhau và khác nhau

 Đối với mỗi yêu cầu bị thay đổi, xem xét chặt chẽ phản ứng khác nhaucủa ứng dụng

Lỗ hổng trong các cơ chế đăng nhập Multistage

Một số ứng dụng sử dụng cơ chế đăng nhập Multistage liên quan đến nhiềuvấn đề:

 Thông tin tên tài khoản và mật khẩu

 Một thách thức như con số cụ thể từ một mã PIN hoặc một từ đáng nhớ

 Sự thay đổi giá trị của token vật lý

Việc triển khai các cơ chế đăng nhập Multistage làm cho các giả định có khảnăng không an toàn ở từng giai đoạn tương tác người dùng với các giai đoạntrước đó

Các bước khai thác

Thực hiện đăng nhập hợp lệ bằng một tài khoản bạn kiểm soát Ghi lại tất cảthông tin liên lạc bằng cách sử dụng proxy Lặp lại quá trình đăng nhập nhiều lầnvới các yêu cầu khác nhau

 Thực hiện các bước đăng nhập với chuỗi khác nhau

 Thử tiến hành đăng nhập ở giai đoạn bất kỳ và tiếp tục từ đó

 Thử bỏ qua từng giai đoạn và tiếp tục với các bước kế tiếp

Nếu bất kỳ dữ liệu nào được gửi nhiều lần, thử gửi một giá trị khác nhau ở cácgiai đoạn khác nhau, và xem còn đăng nhập thành công hay không

Lưu trữ thông tin không an toàn

Nếu một ứng dụng lưu trữ các thông tin đăng nhập một cách không an toàn,làm cho cơ chế đăng nhập suy yếu mặc dù có thể không có lỗi trong quá trình xácthực riêng của mình

Trong các ứng dụng web, thông tin người dùng thường được lưu trữ ở dạngkhông mã hóa trong cơ sở dữ liệu

Các bước khai thác

 Nếu bất kỳ trường hợp chứng thực nào mà mật khẩu được truyền lại chokhách hàng, điều này chỉ ra rằng mật khẩu đang được lưu giữ một cáchkhông an toàn

 Tìm vị trí trong cơ sở dữ liệu hoặc file hệ thống nơi mà thông tin ngườidùng được lưu trữ Truy vấn để xác định xem các mật khẩu có đang đượclưu trữ ở dạng không được mã hóa hay không

3.1.4 Đảm bảo an toàn trong xác thực

Giải pháp chứng thực an toàn đáp ứng mục tiêu an ninh, đồng thời thực hiệnđúng chức năng và tiện ích cho người dùng

Sử dụng thông tin đủ an toàn

Mật khẩu phải đủ mạnh

Tên tài khoản phải là duy nhất

Bất kỳ hệ thống tạo ra tên tài khoản và mật khẩu phải có thông tin đầy đủkhông được thiết lập theo trình tự

Che dấu quá trình xử lý thông tin

Tất cả các thông tin cần được tạo ra, lưu trữ và truyền đi phải theo phươngpháp an toàn

Truyền thông client-server phải được bảo vệ bằng cách sử dụng một giao thức

mã hóa chẳng hạn như SSL

Đảm bảo rằng các đăng nhập chính được tải bằng cách sử dụng HTTPS, thay

vì chuyển sang HTTPS tại thời điểm gửi thông tin đăng nhập

POST request nên được sử dụng để truyền các thông tin đến server

Mọi thành phần ứng dụng phía server cần lưu trữ các thông tin theo cách thứckhông thể thu hồi giá trị ban đầu

Chức năng thay đổi mật khẩu phải được hiện thực

Trường hợp các thông tin các tài khoản mới được phân phối đến người dùngtrong nhóm theo cách an toàn nhất có thể

Xác nhận đúng thông tin tài khoản

Mật khẩu phải được xác nhận đầy đủ và có nghĩa, không cần lọc hoặc sửa đổibất kỳ ký tự nào, không cắt bỏ mật khẩu

Đăng nhập Multistage nên được kiểm soát chặt chẽ để ngăn chặn cuộc tấncông can thiệp vào các giai đoạn khác

Ngăn chặn tấn công Brute-Force

Sử dụng tên người dùng không thể dự đoán

Sử dụng CAPTCHA

3.2 Lỗi quản lý Session

3.2.1 Yếu điểm trong Session Token Generation

Cơ chế quản lý session thường dễ bị tấn công vì khi token được tạo ra mộtcách không an toàn thì hacker có thể xác định được giá trị token đã được cấp chongười dùng khác

Ý nghĩa của Tokens

Session token là ký hiệu nhận dạng duy nhất được phát sinh và gửi từ servertới client để nhận diện session hiện tại của họ Client luôn truyền token như mộttham số của phương thức GET hoặc POST và lưu trữ loken như một HTTPcookie

Một session token được tạo ra bằng cách biến đổi username, địa chỉ email,hoặc các thông tin khác liên quan đến người sử dụng Những thông tin này có thểđược mã hóa hoặc làm thay đổi theo một cách nào đó và có thể được kết hợp vớicác dữ liệu khác

Ví dụ, token này xuất hiện như một chuỗi ngẫu nhiên

Tuy nhiên, nếu xem xét kỹ, nó chỉ chứa các ký tự thập lục phân Ta có thể đoánchuỗi thực sự có thể là một hex-encoding của một chuỗi ký tự ASCII Chúng ta

có thể giải mã chúng thông qua một bộ giải mã:

user = daf; app = admin; date = 10/09/07

Hacker có thể khai thác ý nghĩa trong session token này để cố gắng đoán cácsession hiện tại của người sử dụng khác Bằng cách sử dụng một danh sách liệt kêcác username thông dụng, họ có thể nhanh chóng tạo ra số lượng lớn token hợp lệ

và thử chúng để xác nhận

Token chứa những dữ liệu có ý nghĩa và có cùng một cấu trúc, các thành phần

có thể được phân nhau bởi dấu cách, khi được tách ra và phân tích một cách riêngbiệt, hacker có thể hiểu được cách thức, quy luật phát sinh token Các thành phầnbên trong token có thể bao gồm:

 Username

 Mã số mà ứng dụng dùng để nhận biết các tài khoản

 Email người dùng

 Nhóm hoặc vai trò (cấp bậc) của người dùng trong ứng dụng

 Ngày hoặc thời gian

 Một con số tăng dần hoặc số có thể dự đoán được

 Địa chỉ IP của người dùng

Mỗi thành phần của token hoặc token có thể được mã hóa theo nhiều cách khácnhau: có thể là một phương pháp nhằm xáo trộn nội dung của chúng hoặc đơngiản chỉ đảm bảo sự vận chuyển an toàn dữ liệu nhị phân thông qua HTTP Cácphương pháp mã hóa thường gặp là XOR, BASE64 và thể hiện các ký tự ở dạngthập lục phân bằng cách sử dụng các ký tự ASCII Hacker có thể sẽ thử giải mãtheo những phương pháp này để lấy được dữ liệu ban đầu

Dự đoán Tokens

Một số session token không chứa bất kỳ dữ liệu nào có ý nghĩa hoặc liên quanđến người dùng cụ thể nhưng vẫn có thể dự đoán được vì chúng được phát sinhtheo một trình tự hoặc một phương pháp nào đó Điều này cho phép hacker ngoạisuy từ một mẫu token mà ứng dụng vừa cấp phát để tìm ra các token hợp lệ khác.Trong một số trường hợp, lỗ hổng cơ bản và lộ liễu nhất là ứng dụng sử dụngmột dãy số liên tục như là một session token Trong trường hợp này, hacker chỉ

cần có được hai hoặc ba token trước khi thực hiện một cuộc tấn công và sẽ lấyđược session hợp lệ tại thời điểm đó một cách nhanh chóng.

Một số trường hợp khác, token của ứng dụng chứa các trình tự phức tạp hơn sẽgây khó khăn hơn trong việc dự đoán Các cách biến đổi token theo kiểu này cóthể là kết thúc mở, có nghĩa là không thể biết trước được token tiếp theo là gì.Nhưng theo một số chuyên gia thì session token thường được phát sinh dựa vào

 lwjVJA, Ls3Ajg, xpKr+A, XleXYg, 9hyCzA, jeFuNg, JaZZoA

Không có quy luật nào mà ta có thể thấy rõ được, nhưng xem kỹ thì có lẽ đó làmột thể hiện dữ liệu của mã hóa Base64 vì ngoài các ký tự chữ và số, có một ký

tự là + Sau khi giải mã bằng Base64 ta sẽ có được:

Thời gian phụ thuộc

Một số web server và các ứng dụng sử dụng các thuật toán để tạo ra sessiontoken bằng cách sử dụng thời gian phát sinh như là một giá trị của token Mặc dùbất kỳ token nào cũng đều xuất hiện hoàn toàn ngẫu nhiên, nhưng chúng có cùngmột trình tự kết hợp với thông tin về thời gian khi token được tạo ra

Khi kiểm tra một ứng dụng web bán lẻ trực tuyến, tác giả đã gặp trình tự saucủa session token:

So sánh hai dãy token ta thấy được hai điểm khác biệt rõ ràng:

 Dãy chữ số đầu tiên vẫn tăng lần lượt nhưng có năm giá trị đã bị bỏ qua từcuối dãy thứ nhất

 Dãy chữ số thứ hai tiếp tục tăng tương tự trước đó nhưng giá trị mới củadãy thứ hai hơn giá trị cuối dãy thứ nhất là 539.578

Điều này ngay lập tức cho ta thấy vai trò của thời gian trong việc khởi tạotoken Rõ ràng, chỉ có năm token bị bỏ qua trong thời gian khoảng mười phút.Vậy con số thứ hai trong mỗi token rất có thể phụ thuộc vào thời gian và đượctính bằng mili giây

Nếu vậy thì thuật toán khởi tạo token sẽ là:

String sessId = Integer.toString(s_SessionIndex++) +“-“ +

System.currentTimeMillis();

Phân tích được cách thức mà một token được tạo ra, hacker không khó khăntrong việc tạo ra một đoạn mã để có được session token mà ứng dụng cấp chonhững người dùng khác

Số ngẫu nhiên

Trong máy tính có rất ít thứ tồn tại là do ngẫu nhiên Vì thế, sự ngẫu nhiên chỉnên được sử dụng trong một vài trường hợp Phần mềm sử dụng các kỹ thuật khácnhau để sinh ra một số ngẫu nhiên Một số thuật toán phát sinh hàng loạt nhữngcon số ngẫu nhiên nhưng vẫn có thể ngoại suy được một cách chính xác với bất

cứ ai có được một phần nhỏ của giá trị

Jetty là một web server rất nổi tiếng được viết 100% bằng Java, nó cung cấpmột kỹ thuật quản lý session cho những ứng dụng chạy trên đó Năm 2006, ChrisAnley thuộc NGSSoftware đã phát hiện ra kỹ thuật này vẫn có lỗ hổng Server sửdụng Java API java.util.Random để phát sinh token, nó hiện thực một phươngthức như sau:

synchronized protected int next(int bits) {

seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);

return (int)(seed >>> (48 - bits));

}

Thuật toán này sẽ nhận vào con số vừa phát sinh, nhân nó cho một hằng số vàcộng cho một hằng số khác sẽ có được con số ngẫu nhiên tiếp theo Con số sẽđược cắt bớt còn 48 bits, thuật toán sẽ dịch chuyển kết quả để trả về số bit mà đốitượng yêu cầu.

Biết được điều này, ta có thể dễ dàng lấy được những con số mà thuật toán sẽtạo ra tiếp theo và trong một vài trường hợp cũng có thể lấy được những số màthuật toán đã tạo ra trước đó Điều này có nghĩa là một hacker chỉ cần có đượcmột session duy nhất từ server thì họ có thể sẽ có được tất cả những token hiện tại

và những session trong tương lai

3.2.2 Yếu điểm trong xử lý Session Token

Công bố trên mạng các Tokens

Loại điểm yếu này dễ bị phát sinh khi session token được truyền trên mạng màkhông được mã hóa, hacker ở một vị trí thích hợp có thể nghe lén, lấy được token

và đăng nhập như một người dùng hợp lệ Vị trí thích hợp ở đây bao gồm mạngcục bộ của người dùng, bộ phận công nghệ thông tin của người dùng, nhà cungcấp dịch vụ internet cho người dùng, tên đường trục internet, nhà cung cấp dịch

vụ của ứng dụng, bộ phận công nghệ thông tin của tổ chức chịu trách nhiệm lưutrữ ứng dụng Trong mỗi trường hợp, còn có cả những cá nhân của những tổ chứcliên quan và những hacker đã tấn công những cá nhân đó

Trong một số trường hợp khác, một ứng dụng có thể sử dụng HTTPS để bảo vệthông tin liên lạc giữa client và server nhưng session token vẫn có thể bị bắt trênđường truyền Có rất nhiều trường hợp phát sinh ra lỗi này nhưng đa số trườnghợp là do ta sử dụng HTTP để chuyển giao session token

Công bố Tokens trong Logs

Bên cạnh việc session token không được mã hóa trên đường truyền, thì nơisession token thường được tiết lộ nữa là trong log của hệ thống Mặc dù trườnghợp này rất hiếm khi xảy ra nhưng hậu quả của nó rất nghiêm trọng vì trong log

có thể chứa những thông tin quan trọng hơn đối với một hacker chuyên nghiệp

Lý do chính khác làm tiết lộ session token là khi ứng dụng sử dụng chuỗi truyvấn URL như một phương pháp truyền token, ngược lại với cách sử dụng HTTPcookie hoặc chứa cookie trong body của những request Ví dụ:

http://www.webjunction.org/do/Navigation;jsessionid=F27ED2A6AAE4C6DA409A3 044E79B8B48?category=327

Khi ứng dụng truyền session token theo cách này, session token cũng sẽ bị lưulại trong log của hàng loạt các hệ thống và những người không có quyền hạn vẫn

có thể truy cập:

 Log trình duyệt của người sử dụng

 Log của web server

 Log của công ty hoặc ISP proxy server

 Log của bất kỳ server nào mà ứng dụng người dùng truy cập bằng off-sitelink hiện tại Xem hình 3.3.1:

Hình 3-2: Kết quả của quá trình bắt session

Chấm dứt phiên dễ bị tấn công

Việc kết thúc session rất quan trọng vì hai lý do Thứ nhất, giữ thời gian tồn tạicủa session càng ngắn càng tốt vì điều này sẽ làm giảm cơ hội cho hacker có thểbắt dữ liệu, dự đoán hoặc lợi dụng một session hợp lệ Hai là, nó sẽ tự động hủy

bỏ session của người dùng khi họ không còn cần nữa, bằng cách này sẽ giúpsession của người dùng trở nên bảo mật hơn khi họ phải chia sẽ máy tính chongười khác

3.3 Lỗi trong kiểm soát truy cập

Trong cơ chế bảo mật của ứng dụng, kiểm soát truy cập được xây dựng dựavào việc xác thực và quản lý session Kiểm soát truy cập là cơ chế bảo vệ quantrọng trong ứng dụng, bởi chúng quyết định cho phép hoặc từ chối một yêu cầuthực hiện hành động truy cập vào các nguồn tài nguyên

3.3.1 Các lỗi thường gặp trong kiểm soát truy cập

Hoàn toàn không có tính năng bảo vệ

Trong nhiều trường hợp, kiểm soát truy cập bị lỗi Các chức năng nhạy cảm vàcác nguồn tài nguyên có thể được truy cập bởi bất cứ ai biết URL có liên quan

Có rất nhiều ứng dụng mà bất cứ ai cũng có thể truy cập nếu biết URL cụ thể và

có thể sử dụng đầy đủ chức năng của người quản trị Ví dụ:

Ở đây, hacker chỉ cần xem lại những đoạn JavaScript để xác định địa chỉ URL

có chức năng quản trị hay không và thử truy cập

Chức năng truy cập Multistage

Nhiều chức năng bên trong một ứng dụng được thực hiện qua nhiều giai đoạn,liên quan đến nhiều yêu cầu được gửi từ client đến server Ví dụ, chức năng thêmngười dùng trong ứng dụng có thể có nhiều lựa chọn như: tên, mật khẩu, vai tròcủa người dùng và các thông tin khác

Ở ví dụ trên, khi người dùng vào được chức năng thêm người dùng mới thì ứngdụng xác định rằng người dùng có đủ quyền để thực hiện, và ngăn chặn nếu nhưngười dùng không có quyền Tuy nhiên, nếu hacker thu thập được thông tin ở giaiđoạn quy định vai trò của người dùng và các thông tin khác thì kiểm soát truy cập

sẽ không có hiệu quả Người viết ứng dụng vô tình giả định rằng, nếu người dùngnào đạt đến giai đoạn cuối của quá trình này thì đã được chứng thực ở các giaiđoạn trước đó Kết quả là bất kỳ người dùng nào của ứng dụng khi đạt đến giai

đoạn cuối của quá trình này đều có thể thêm tài khoản người dùng mới, kể cả tàikhoản của người quản trị và kiểm soát toàn bộ ứng dụng.

Static Files

Trong nhiều trường hợp, người dùng truy cập vào các chức năng và các nguồntài nguyên được bảo vệ, bằng cách yêu cầu phát sinh các trang động thực hiệntrên server Trách nhiệm của mỗi trang thực hiện kiểm tra kiểm soát truy cậpthích hợp, và xác định quyền của người dùng để thực hiện các hành động của họ.Tuy nhiên, trong một số trường hợp, việc truy cập các nguồn tài nguyên lại thựchiện trực tiếp trên các nguồn tài nguyên tĩnh Ví dụ, một nhà xuất bản sách trựctuyến có thể cho phép người dùng duyệt qua các thể loại sách của mình để muahoặc tải về Sau khi thanh toán được thực hiện, người dùng sẽ nhận được một địachỉ URL để tải về như sau:

Kiểm soát truy cập không an toàn

Một số ứng dụng về cơ bản sử dụng mô hình kiểm soát truy cập không an toàn,trong đó kiểm soát truy cập quyết định thực hiện trên cơ sở các thông số yêu cầuđược gửi bởi người dùng Ứng dụng xác định vai trò hay cấp truy cập của ngườidùng tại thời điểm đăng nhập và từ thời điểm này trở đi thông tin này được truyềnthông qua người dùng dưới hình thức ẩn như: cookie hoặc chuỗi các tham số truyvấn Khi yêu cầu tiếp theo được xử lý, ứng dụng đọc tham số yêu cầu này vàquyết định cấp truy cập phù hợp cho người dùng

3.3.2 Khai thác lỗi kiểm soát truy cập

Các câu hỏi cần xem xét khi kiểm tra kiểm soát truy cập của một ứng dụng:

 Các chức năng của ứng dụng có cho phép người dùng truy xuất vào mộtphần cụ thể của dữ liệu thuộc về họ hay không?

 Trong ứng dụng có nhiều cấp độ người dùng, nhiều chức năng khác nhau.Vậy ai là người được cấp quyền để truy cập vào các chức năng khác nhauđó?

 Người quản trị có sử dụng các chức năng được xây dựng trong ứng dụng

để cấu hình và giám sát hay không?

 Các chức năng và nguồn tài nguyên trong ứng dụng mà bạn có thể leothang đặc quyền là gì?

Cách đơn giản nhất và hiệu quả nhất để kiểm tra hiệu quả kiểm soát truy cậpcủa ứng dụng là truy xuất vào ứng dụng sử dụng các tài khoản khác nhau, xácđịnh nơi nào các chức năng và nguồn tài nguyên thì được truy xuất bởi những tàikhoản không có quyền

 Nếu ứng dụng phân chia người dùng truy cập theo cấp độ chức năng, cấp

độ nguồn tài nguyên thì sử dụng 2 tài khoản với cấp độ khác nhau đểkiểm tra Một tài khoản có đủ quyền để xác định tất cả chức năng có sẵn

và một tài khoản có ít quyền hơn để kiểm tra nơi nào kiểm soát truy cậpthì có hiệu quả và nơi nào thì có thể leo thang đặc quyền

Nếu chỉ có một cấp độ tài khoản để truy cập ứng dụng thì phải bổ sung cáccông việc cần thực hiện để kiểm tra hiệu quả của kiểm soát truy cập

 Trường hợp có nhiều trang ứng dụng được xác định là đại diện cho cácchức năng khác nhau hoặc các liên kết đến người dùng bình thường hay

người quản trị, thử thêm các tham số như admin = true vào chuỗi truy vấn

URL hoặc nội dung của các yêu cầu, để xác định nơi có thể truy xuất cácchức năng mở rộng mà người dùng bình thường không được phép

Trong trường hợp, ứng dụng được xem là kiểm soát truy cập có hiệu quả thìbạn cũng nên kiểm tra thêm để xác định các giả định của người lập trình cókhuyết điểm không

 Trường hợp một hành động được thực hiện theo nhiều bước, liên quanđến một số yêu cầu khác nhau gửi từ client đến server, kiểm tra từng yêucầu riêng để xác định xem các kiểm soát truy cập có được áp dụng vào nókhông

 Cố gắng tìm kiếm bất kỳ vị trí nào mà ứng dụng cho rằng kiểm soát truycập có hiệu quả Nếu bạn tìm thấy một vị trí cụ thể, hãy truy xuất vớiquyền hợp lệ để kiểm tra hiệu quả của kiểm soát truy cập Sau đó, cố gắngtruy xuất vào vị trí đó bằng cách sử dụng một tài khoản với quyền thấphơn để kiểm tra xem có thể leo thang đặc quyền không

Trong trường hợp ứng dụng bảo vệ các nguồn tài nguyên tĩnh thông qua truycập trực tiếp các URL Bạn nên kiểm tra xem ứng dụng có cho phép người dùngkhông có quyền yêu cầu các URL một cách trực tiếp.

 Sử dụng các tài khoản người dùng khác nhau để truy cập trực tiếp vào cácnguồn tài nguyên bằng việc sử dụng các URL mà bạn đã xác định được

 Nếu cuộc tấn công này thành công, cố gắng tìm hiểu cách ứng dụng đặttên để bảo vệ các nguồn tài nguyên tĩnh, để có thể truy xuất vào tất cả cácnguồn tài nguyên tĩnh

3.3.3 Đảm bảo kiểm soát truy cập

Để thực hiện có hiệu quả kiểm soát truy cập trong ứng dụng web, cần phải thựchiện các vấn đề sau:

 Đánh giá và tài liệu rõ ràng các yêu cầu kiểm soát truy cập cho các chứcnăng của ứng dụng Vấn đề này bao gồm cả những người có quyền sửdụng các chức năng và các nguồn tài nguyên

 Sử dụng cơ chế kiểm soát truy cập tập trung để kiểm tra truy cập Xử lýmọi yêu cầu của người dùng thông qua cơ chế này, để xác định rằngngười dùng đưa ra yêu cầu được phép truy cập các chức năng và cácnguồn tài nguyên được yêu cầu

 Sử dụng các kỹ thuật lập trình để bảo đảm hiệu quả của kiểm soát truycập Một cách tiếp cận hiệu quả là mỗi trang ứng dụng phải thực hiện mộtgiao diện mà được truy vấn bởi các cơ chế kiểm soát truy cập trung tâm.Bằng cách buộc các lập trình viên kiểm tra một cách rõ ràng mã kiểm soáttruy cập logic vào mỗi trang

 Đối với các chức năng đặc biệt nhạy cảm, chẳng hạn như trang quản lý,bạn có thể giới hạn truy cập theo địa chỉ IP, để đảm bảo người dùng chỉ từmột phạm vi mạng cụ thể có thể truy cập các chức năng, bất kể tình trạngđăng nhập của họ

 Nếu nội dung tĩnh cần được bảo vệ, có hai phương pháp kiểm soát truycập Trước tiên, các tập tin tĩnh có thể được truy cập gián tiếp bằng cáchgửi tên tập tin đến server có liên quan đến kiểm soát truy cập logic Thứhai, trực tiếp truy cập vào các tập tin tĩnh có thể được kiểm soát bằng cơchế chứng thực HTTP hoặc các tính năng khác của máy chủ ứng dụng đểlọc các yêu cầu đến và kiểm tra các quyền truy cập vào các nguồn tàinguyên trước khi cấp quyền truy cập

 Nhật kí các sự kiện, nơi dữ liệu nhạy cảm được truy cập hoặc hành độngnhạy cảm được thực hiện Các nhật kí có thể phát hiện và điều tra cáckiểm soát truy cập vi phạm.

Trong phát triển ứng dụng web để thực hiện cơ chế kiểm soát truy cập có hiệuquả thì chúng ta phải thêm các đoạn code giống nhau vào các trang xử lý kiểmsoát truy cập Cách tiếp cận này có nhiều rủi ro trong cơ chế kiểm soát truy cập,

vì những xử lý kiểm soát truy cập cho vị trí này thì không thể dùng để kiểm soáttruy cập cho vị trí khác

Trái ngược với cách tiếp cận trên, sử dụng cơ chế kiểm soát truy cập tập trung

để thực hiện kiểm soát truy cập thì có nhiều lợi ích:

 Nó làm tăng sự rõ ràng của các kiểm soát truy cập trong ứng dụng, chophép các lập trình viên khác nhau nhanh chóng hiểu những kiểm tra đượcthực hiện bởi những người khác

 Nó làm cho việc bảo trì có hiệu quả và đáng tin cậy hơn Hầu hết các thayđổi chỉ cần được áp dụng một lần, vào một thành phần chung duy nhất, và

sẽ không cần phải cắt và dán vào nhiều chỗ

 Nếu mã kiểm tra truy cập được thực hiện trọn vẹn trong suốt ứng dụng thìnhững sai lầm và thiếu sót sẽ được hạn chế

Mô hình ứng dụng nhiều tầng

Các vấn đề liên quan đến truy cập không chỉ áp dụng đối với ứng dụng web màcòn cả cơ sở hạ tầng nằm bên dưới nó Đặc biệt là máy chủ ứng dụng, cơ sở dữliệu, hệ điều hành Tiếp cận về chiều sâu thì bảo mật đòi hỏi phải thực hiện kiểmtra truy cập ở mỗi lớp để tạo ra một vài lớp bảo vệ Điều này cung cấp sự chắcchắn hơn để chống lại các mối đe dọa của việc truy cập trái phép, bởi vì nếuhacker xâm nhập thành công một lớp nào đó, cuộc tấn công có thể sẽ bị chặn bởicác lớp phòng thủ khác

3.4 Inject code

Code injection là một lỗ hổng rất lớn, nó có thể xảy ra trên nhiều ngôn ngữ lậptrình và có rất nhiều kiểu tấn công khác nhau Khi chúng ta tìm hiểu cách thứcphát sinh và cách khai thác các lỗ hổng, chúng ta có thể đưa ra phương pháp xâydựng web an toàn hơn

Trong Code injection thì SQL injection là lỗ hổng phổ biến, và thường xuyên

bị tấn công nhất SQL injection có thể khai thác bằng nhiều kỹ thuật khác nhaunhư: bypasses a login, inference-based attacks, và fully blind exploitation

Chúng ta cũng sẽ xem xét một loạt các lỗ hổng phổ biến khác trong codeinjection, bao gồm cả tiêm vào web scripting languages, SOAP, XPath, email,LDAP, và hệ điều hành server Trong mỗi trường hợp, chúng ta sẽ mô tả thực tiễncác bước có thể làm để khai thác các lỗi này.

3.4.1 Inject vào ngôn ngữ thông dịch

Ngôn ngữ thông dịch là dịch từng lệnh rồi chạy từng lệnh, lần sau muốn chạylại thì phải thông dịch lại Trái ngược với điều này, ngôn ngữ biên dịch là codesau khi biên dịch sẽ chứa trong một file (thường là exe) và file này có thể sửdụng lại mà không cần biên dịch nữa

Theo nguyên tắc, bất kỳ ngôn ngữ có thể được hiện thực bằng cách sử dụngmột trình thông dịch hoặc một trình biên dịch Tuy nhiên, hầu hết các ngôn ngữhiện tại thường chỉ dùng một trong hai cách, và rất nhiều các ngôn ngữ chínhđược sử dụng để phát triển ứng dụng web được thực hiện bằng cách sử dụng mộttrình thông dịch, bao gồm cả SQL, LDAP, Perl và PHP

Trong ngôn ngữ biên dịch, hacker thường inject vào những đoạn code có chứa

mã máy để tấn công Hãy xem xét ví dụ rất đơn giản sau đây HelloWorld là mộtđoạn shell script mà in ra một tin nhắn được cung cấp bởi người sử dụng:

[manicsprout@localhost ~]$ /helloworld.sh “`ls -la`”

total 28 drwxr-xr-x 2 manicsprout manicsprout 4096 Dec 4 00:22

drwxr-xr-x 3 root root 4096 Dec 4 00:19 -rw-r r 1 manicsprout

manicsprout 24 Dec 4 00:19 bash_logout -rw-r r 1 manicsprout

manicsprout 191 Dec 4 00:19 bash_profile -rw-r r 1 manicsprout

manicsprout 124 Dec 4 00:19 bashrc -rw - 1 manicsprout manicsprout

706 Dec 4 00:22 viminfo -rw-rw-r 1 manicsprout manicsprout 8 Dec 4

00:22 helloworld.sh