Đăng Kí Hoặc đăng nhập để hưởng quyền lợi đặc biệt!!
cám ơn đã ghé thăm Forums..
Bạn nên Sử dụng chức năng tìm kiếm để tìm nhanh thông tin.
Quảng cáo thì chờ 5s nhấn
(SKIP AD)

Nhập email của bạn:


You are not connected. Please login or register

View previous topic View next topic Go down Message [Page 1 of 1]

Nohlevel

Thượng Uý
Thượng Uý
3.6. TẤN CÔNG DIRECTORY TRAVERSAL



Thông thường, web server sẽ từ chối client truy cập vào các tài nguyên không nằm trong thư mục gốc của web server.



Ví dụ: Nếu thư mục gốc của web server là /home/www, client yêu cầu truy cập vào tài nguyên /etc/passwd thì sẽ bị web server từ chối vì tài nguyên trên không nằm trong /home/www.
Tuy nhiên, có một hình thức tấn công có thể truy cập vào tài nguyên này
mà không cần sử dụng một công cụ nào, chỉ đơn thuần thao tác với các
biến với ../ (dot-dot-slash) để thực hiện
liên kết mềm (symbolic) truy cập đến các file nằm trong thư mục cha của
thư mục hiện hành. Đó là tấn công Directory Traversal.



Dưới đây là một ví dụ cụ thể về loại hình tấn công này.



Code:


http://example.com/getpage.php?page=../../../etc/passwd





Như ta thấy trên URI, thực hiện chèn biến ../ ba lần để liên kết mềm về thư mục gốc /
. Sau đó thêm vào etc/passwd để tạo thành request đến thư mục
/etc/passwd. Nếu không cấu hình cản lọc để request này, nội dung của
file /etc/passwd sẽ được hiển thị trên trình duyệt của hacker.

Hacker có thể không chèn trực tiếp biến ../ mà thực hiện chèn các biến đã được mã hoá như %2e%2e%2f, khi giải mã thì nội dung vẫn là ../



Dưới dây là danh sách các chuỗi chúng ta cần chặn:



- ../

- ..%2f

- %2e%2e/

- %2e%2e%2f

- %2e./



Với ModSecurity, chỉ cần sử dụng chức năng chuyển đổi t:urlDecode để chuyển tất cả chuỗi được mã hoá thành giá trị nguyên thuỷ của nó. Dưới đây là rule để chặn hình thức tấn công này:



Code:


SecRule REQUEST_URI "../" "t:urlDecode,deny"





3.7. TẤN CÔNG SQL INJECTION

3.7.1. Giới thiệu



Các cuộc tấn công SQL injection có thể xảy ra nếu hacker cung cấp
dữ liệu cho ứng dụng web mà các dữ liệu này không được cản lọc, làm sai
lệch các câu lệnh SQL khi thực thi. Điển hình là nhập vào các chuỗi đặc
biệt để bỏ qua bước kiểm tra mật khẩu của người dùng và làm cho đăng
nhập hợp lệ:



Ví dụ, chúng ta xét câu lệnh truy vấn khi thực hiện đăng nhập dưới đây:



Code:


SELECT * FROM user WHERE username = '%s' AND password = '%s';





Với truy vấn trên, nếu hacker muốn đăng nhập vào với tài khoản
admin mà chưa biết mật khẩu, hacker sẽ thực hiện nhập tên đăng nhập là
admin và mật khẩu là ‘ OR ‘1’ = ‘1 -- Khi thực hiện truy vấn, thông tin đăng nhập được đưa vào sẽ trở thành:



Code:


SELECT * FROM user WHERE username = 'admin' AND password = '’ OR ‘1’ = ‘1’;





Câu lệnh trên có nghĩa: Truy vấn lấy thông tin tất cả các trường từ
bảng user với điều kiện trường username có giá trị là admin và mật khẩu
là trống ‘’ hoặc 1 = 1.1 = 1
luôn đúng nên mặc dù mật khẩu không đúng, câu lệnh trên vẫn được thực
thi và truy vấn lấy thông tin user admin thành công. Đăng nhập sẽ được
chấp nhận.



3.7.2. Các hình thức tấn công SQL injection thông thường

3.7.2.1. Lấy dữ liệu từ nhiều bảng với UNION



Câu lệnh SQL UNION có thể được sử dụng để lấy dữ liệu từ hai bảng
khác nhau. Ví dụ: Nếu có một bảng có tên cooking_recipes và bảng khác có
tên ser_credentials, lệnh SQL sau sẽ lấy dữ liệu từ cả hai bảng:



Code:


SELECT dish_name FROM cooking_recipe UNION SELECT username, password FROM user_credentials;





Một câu lệnh SQL tương tự là UNION ALL, hoạt động gần giống như UNION. Sự khác biệt duy nhất là UNION ALL sẽ không loại bỏ các dòng bị trùng lặp trong kết quả trả về.



3.7.2.2. Nhiều truy vấn trong một lời gọi



Nếu SQL engine cho phép nhiều câu lệnh SQL trong một truy vấn SQL
đơn, ta sẽ thấy nguy cơ bảo mật xuất hiện. Ví dụ sau có thể giải thích
nguy cơ này.



Code:


SELECT * FROM products WHERE id = %d;





Nếu hacker cung cấp ID bằng một đoạn lệnh 1;DROP TABLE products; câu lệnh SQL sẽ trở thành:



Code:


SELECT * FROM products WHERE id = 1; DROP TABLE products;





Khi câu lệnh này được thực hiện, đầu tiên nó sẽ truy vấn tất cả các
trường trong bảng products có id bằng 1, sau đó bảng products sẽ bị
xoá.



3.7.2.3. Đọc nội dung của một file



MySQL có thể được sử dụng để đọc nội dung của một file trên hệ thống bằng cách sử dụng hàm LOAD_FILE(). Ví dụ:



Code:


SELECT LOAD_FILE(“/etc/passwd”);





Lệnh sẽ trả về nội dung của file /etc/passwd nếu tiến trình MySQL có quyền truy cập.



3.7.2.4. Ghi dữ liệu vào tập tin



MySQL cũng hỗ trợ lệnh ghi dữ liệu vào tập tin với OUTFILE.
Rất nguy hiểm nếu hacker lợi dụng và khai thác được lệnh này, bởi thực
thi OUTFILE không những ảnh hưởng đến cơ sở dữ liệu mà còn ảnh gây hưởng
đến tập tin hệ thống.



Dưới đây là một ví dụ đơn giản sử dụng MySQL để ghi dữ liệu vào file text.txt



Code:


SELECT "vi du ghi du lieu" INTO OUTFILE "test.txt";





3.7.3. Ngăn chặn tấn công SQL injection



Có ba bước quan trọng để ngăn chặn tấn công SQL injection:



1. Làm “trong sáng” câu lệnh SQL trong ứng dụng web.

2. Lọc dữ liệu người dùng đưa lên.

3. Sử dụng ModSecurity để chặn mã SQL injection khi hacker khai thác lỗi ứng dụng web.



Trong ba bước trên, quan trọng nhất vẫn là bước đầu tiên. Sử dụng
các câu lệnh SQL “trong sáng” nghĩa là sử dụng các câu lệnh chuẩn, không
không gây ra lỗ hổng SQL injection cho ứng dụng web.

Bước thứ hai là đảm bảo tất cả dữ liệu người dùng cung cấp cho truy
vấn SQL đểu được cản lọc, tránh bị chèn vào các đoạn mã nguy hiểm như
dấu ngoặc đơn, dấu nháy đơn… Nếu ứng dụng web viết bằng PHP, có thể sử
dụng các mysql_real_escape_string() để cản lọc.



Và cuối cùng, sử dụng ModSecurity để ngăn chặn triệt để tấn công SQL injection.



Dưới đây là bảng liệt kê danh sách các lệnh thường được sử dụng
trong tấn công SQL injection cùng với các biểu thức chính quy dùng để
ngăn chặn.







Bảng 3.3 Các lệnh thường được sử dụng trong tấn công SQL injection



Ví dụ về rule để chặn tấn công SQL injection ghi dữ liệu vào tập tin.



Code:


SecRule ARGS "into\s+outfile" "t:lowercase,deny,msg:'SQL Injection'"





Cú pháp \s+ cho phép phát hiện tất các hình thức nhập vào của ký tự trắng (space) ví dụ như INTO%20%20OUTFILE.



3.8. TẤN CÔNG BRUTE FORCE



Với tấn công Brute Force, hacker thực hiện đoán các thông tin đăng
nhập như tên người dùng, mật khẩu, email… và thực hiện đăng nhập liên
tục đến khi nào thông tin đăng nhập là đúng. Hầu hết người dùng đều sử
dụng thông tin đăng nhập giống nhau trên tất cả các website mà họ thường
đăng nhập, dẫn đến tài khoản của họ bị xâm nhập trên hàng loạt các
website khi thông tin đăng nhập bị lộ bởi một website khác.



Cách tốt nhất để ngăn chặn hình thức tấn công này là giới hạn số
lần đăng nhập không đúng. Ví dụ nếu người sử dụng đăng nhập không đúng
quá 3 lần, thực hiện khoá đăng nhập của người này trong 5 phút.



Dưới đây là các rule của ModSecurity cho phép chúng ta thực hiện điều này



Code:


# Khoa dang nhap sau 3 lan dang nhap khong thanh cong

#



# Khoi tao collection ip

SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"

# Phat hien dang nhap khong thanh cong

SecRule RESPONSE_BODY "Username does not exist" "phase:4,pass,setvar:

ip.failed_logins=+1,expirevar:ip.failed_logins=300"

# Khoa dang nhap khi so lan dang nhap khong thanh cong bang 3

SecRule IP:FAILED_LOGINS "@gt 3" deny







Các rule trên dựa vào đặt điểm trả về của website khi người truy cập đăng nhập không thành công: Username does not exist



Các rule trên sẽ khởi tạo collection IP và tăng giá trị biến ip.failed_login lên một đơn vị sau mỗi lần đăng nhập không thành công. Action expirevar sẽ thiết lập biến ip.failed_login về 0 sau 5 phút. Vì vậy, khi biến ip.failed lớn hơn hoặc bằng 3, rule cuối sẽ khoá đăng nhập của người dùng trong 5 phút.



Hoặc chúng ta có thể thực hiện trì hoãn (hay dừng) request của
người dùng khi số lần đăng nhập sai vượt quá quy định. Do đó, không cần
phải từ chối truy cập như các rule được nêu ở trên. Sau đây là rule thực
hiện điều trên:



Code:



# tri hoan request 3 giay sau 3 lan dang nhap khong thanh cong



SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"

SecRule RESPONSE_BODY "Username does not exist" "phase:4,pass,setvar:

ip.failed_logins=+1,expirevar:ip.failed_logins=10"

SecRule IP:FAILED_LOGINS "@gt 3" "phase:4,allow,pause:3000"







Thời gian trì hoãn được tính bằng mili giây, các rule trên sẽ trì
hoãn response trong 3 giây khi số lần truy cập không thành công lớn hơn
hoặc bằng 3.



3.9. DIRECTORY INDEXING



Khi người sử dụng request đến URL như http://example.com, URL này không request cụ thể đến một tập tin nào trên web server (ví dụ http://example.com/page.html request cụ thể đến page.html),
vì vậy Apache sẽ tìm đọc tập tin theo cấu hình DirectoryIndex (thường
là index.html, index.php …). Nếu không có tập tin nào có trong danh sách
tập tin đã được cấu hình trong DirectoryIndex., Apache xem xét tuỳ chọn
Indexes có được kích hoạt hay không. Tuỳ chọn này có thể được kích hoạt
theo cách sau



Code:





Options +Indexes







Nếu cấu hình tuỳ chọn Indexes cũng không được tìm thấy hoặc không
kích hoạt. Apache sẽ liệt kê ra tất cả các thư mục và tập tin hiển thị
cho người dùng.







Hình 3.4 Liệt kê thư mục và tập tin với Indexes



Với việc liệt kê ra danh sách các thư mục, tập tin sẽ làm cho người
dùng có thể xem được cấu trúc của mã nguồn website, có thể tải về các
tập tin không được phép…Vì vậy, chúng ta có thể tắt indexes bằng cách
khai báo trong httpd.conf:



Code:




Options -Indexes







Hoặc cũng có thể tắt indexes bằng cách cấu hình không cho chạy module mod_autoindex.so



Code:


# Disable directory indexing

# LoadModule autoindex_module modules/mod_autoindex.so





Lưu ý: Một số module của Apache yêu cầu mod_autoindex.so hoạt động,
vì vây nếu tắt module này có thể dẫn đến Apache không khởi động được.



Để đảm bảo chắc chắc rằng người dùng không thể liệt kê được các
file và thư mục. Chúng ta có thể sử dụng ModSecurity với rule:



Code:


SecRule REQUEST_URI "/$" "phase:4,deny,chain,log, msg:'Directory index returned'"

SecRule RESPONSE_BODY "

Index of /"





Khi người dùng thực hiện liệt kê file, thư mục. Apache sẽ trả về response body có chứa

Index of /, vì vậy rule trên sẽ chặn lại và ghi log với nội dung Directory index returned



Kết thúc chủ đề Bào mật web server Apache với ModSecurity



Cảm ơn đã quan tâm theo dõi..

View user profile http://zinghack.123.st

View previous topic View next topic Back to top Message [Page 1 of 1]

Permissions in this forum:
You cannot reply to topics in this forum