Kỹ thuật lập trình an toàn nghiên cứu biểu thức chính quy trong xác nhận đầu vào trong phát hiện, ngăn chặn tấn công XSS

Khi phát hiện ra một cuộc tấn công, những chi tiết về vụ tấn công sẽ được lưu vào log file hoặc một email có thể được gửi tới người quản trị viên để báo hiệu có một cuộc tấn công xảy ra

HỌC VIỆN KỸ THUẬT MẬT MÃ

Kỹ Thuật Lập Trình An Toàn Nghiên Cứu Biểu Thức Chính Quy Trong Xác Nhận Đầu Vào Trong Phát Hiện, Ngăn Chặn Tấn Công XSS

Thành viên

Trần Minh Hòa

Phạm Thị Thảo Hiền

GVHD : Phạm Duy Trung Khoa An Toàn Thông Tin

Hồ Chí Minh, 2019

Mục lục

Chương 1 Giới thiệu về Mod Sercurity 1

1 Mod Sercurity 1

2 Khả năng của mod sercurity 2

1.3 Hoạt động của mod security 3

Chương 2 Cài đặt mod sercurity 5

2.1 Yêu cầu: 5

2.2 Các bước cài đặt 5

2.3 Cấu trúc Rule 7

2.4 Các loại log 10

Chương 3 XSS và DVWA 11

3.1 XSS 11

3.1.1 Giới thiệu XSS 11

3.1.2 Hình thức tồn tại của XSS 12

3.2 DVWA 14

3.2.1.Giới thiệu 14

3.2.2 Cài đặt 14

Chương 4 Kết quả thực nghiệm 16

4.1 Khi không bật mod sercurity 16

4.2 Khi bật modsecurity 16

1

Chương 1 Giới thiệu về Mod Sercurity

1 Mod Sercurity

- ModSecurity là một web application firewall(WAF) được Ivan Ristic phát triển dành cho Apache Web Server Giống như những firewall thông thường khác,

nó lọc những lưu lượng dữ liệu vào và ra để có thể quyết định chặn lại những lưu lượng mà nó nghi ngờ là độc hại dựa theo tập lệnh nó định nghĩa Nó còn có nhiều tính năng vượt trội khác như : HTTP transaction logging và content injection…

- Các luật được tạo và chỉnh sửa sử dụng một định dạng văn bản đơn giản, nó làm cho việc viết rules trở nên đơn giản hơn Một khi đã quen với cú pháp của ModSecurity, chúng ta có thể nhanh chóng viết được những rules để block một exploit mới hoặc ngăn chặn một lỗ hổng

- Có thể hình dung ModSecurity như là một trạm trung gian giữa HTTP request và httpd (dịch vụ web server) Khi phát hiện ra một cuộc tấn công, những chi tiết về vụ tấn công sẽ được lưu vào log file hoặc một email có thể được gửi tới người quản trị viên để báo hiệu có một cuộc tấn công xảy ra trên hệ thống

- ModSecurity cho phép bạn bảo vệ server của mình thông qua việc viết các luật nhằm bao phủ một dải các viễn cảnh tấn công có thể Do đó, ModSecurity là một lớp bổ sung có thể giúp bạn bảo vệ theo một cách không cần bản vá

- ModSecurity giải quyết các vấn đề tầm nhìn : nó giúp bạn nhìn thấy lưu lượng web của mình Đó là chìa khóa trong security : mỗi khi bạn có thế nhìn thấy HTTP traffic, bạn có thể phân tích nó trong thời gian thực, record nó khi cần thiết

và phàn ứng lại với các sự kiện Điểm nổi bật ở đây là bạn có thể làm tất cả mà không tác động gì tới các ứng dụng web Thậm chí tốt hơn, nó còn có thể áp dụng với bất

kì ứng dụng nào, ngay cả khi bạn không thể truy được vào source code

2

2 Khả năng của mod sercurity

Như các bạn thấy, Mod Security đứng trước Web Server, làm nhiệm vụ như

một firewall để kiểm soát truy cập vào ra Web Server Các thông tin đi từ bên ngoài

vào và bên trong ra sẽ được kiểm soát chặt chẽ để tránh những thông tin có thể gây

hại cho Web Server hay là việc rò rỉ các thông tin đặc biệt từ Web Server đến Client

Mod Security có thể thực hiện các chức năng cụ thể sau:

 Request filtering : tất cả các request gửi đến web server đều được phân tích và

càn lọc (filter) trước khi chúng được đưa đến các modules khác để xử lý

 Anti-evasion techniques : paths và parameters được chuẩn hóa trước khi phân

tích để chống evasion techniques

 Understanding of the HTTP protocol : ModSecurity là web application

firewall nên nó có khả năng hiểu được HTTP protocol ModSecurity có khả

năng càn lọc dựa trên các thông tin ở HTTP header hay có thể xem xét đến

từng parameters hay cookies của các requests…

 POST payload analysis : ngoài việc càn lọc dựa trên HTTP header,

ModSecurity có thể dựa trên nội dung (payload) của POST request

 Audit logging : mọi request đều có thể được ghi lại (bao gồm cả POST) để

người quản trị có thể theo dõi nếu cần

 HTTPS filtering : ModSecurity có thể phân tích HTTPS

3

 Compressed content filtering : ModSecurity sẽ phân tích sau khi đã decompress các request data

Có một điều đáng chú ý là ModSecurity có khả năng phân tích https Nhiều bạn sẽ rất thắc mắc là tại sao ModSecurity có thể đọc được thông tin khi đã bị mã hoá với ssl(secure sockets layer) Thực ra thì theo như các mô hình đều mô tả ModSecurity đứng trước Web Server, nhưng trên thực tế thì ModSecurity là một module của Web Server Tất cả các thông tin được mã hoá với ssl thì đều được Web Server giải mã trước, sau đó mới chuyển tới ModSecurity để xử lý

1.3 Hoạt động của mod security

Quá trình xử lý các request của Apache và ModSecurity :

Trong ModSecurity, mỗi phiên phân tích sẽ được thực hiện lần lượt qua 5 bước (phase), tại mỗi bước ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phòng chống các khai thác

4

ModSecurity cho phép bạn đặt rule tại một trong năm thời điểm trong chu kỳ

xử lý của Apache như sau :

- Phase Request Header : rule được đặt tại đây sẽ được thực hiện ngay sau khi Apache đọc request header, lúc này phần request body vẫn chưa được đọc Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin Mục đích của bước này nhằm cho phép người viết rule tương tác với các request trước khi thực hiện các yêu cầu trong phần HTTP body Phần này khá quan trọng để phân tích các khai thác dựa vào HTTP method cũng như dựa vào URL như SQL Injection, Reflect XSS, Local file include …

- Phase Request Body : đây là thời điểm các thông tin chức năng chung đưa vào được phân tích và xem xét, các rule mang tính application-oriented thường được đặt ở đây Bước này là quá trình kiểm tra chính trong quá trình client gởi request đến server, phần này sẽ có hiệu quả khi người dùng cố sử dụng phương thức POST hoặc PUT để upload tập tin lên phía server Việc kiểm tra này bảo đảm dữ liệu đưa lên server là an toàn, tránh tình trạng upload mã độc hoặc các dạng tấn công như Stored XSS, Ajax Injection ModSecurity hỗ trợ ba loại mã hóa request body :

 Application/x-www-form-urlencoded dùng để truyền form dữ liệu

 Multipart/form-data dùng để truyền file

 Text/xml : dùng để phân tích dữ liệu XML

- Phase Response Header : Những request đã được xử lý tại server sẽ được trả về cho ModSecurity kiểm tra trạng thái trong phần respone header Trước khi phần respone body được đọc thì ModSecurity sẽ dựa vào tập rule để xác định có cần kiểm tra nội dung dữ liệu trong phần body hay không

Ví dụ: mã trạng thái trả về là 404 (Not found) thì lúc này sẽ không cần kiểm tra nội dung gói tin trả về

5

- Phase Response Body : Sau khi ModSecurity đã hoàn thành việc kiểm tra tại respone header thì nội dung trong phần body sẽ được kiểm tra so trùng với mẫu trong tập lệnh Việc này là khá hiệu quả để phát hiện và phòng chống xâm nhập trong trường hợp ở phase request header và phase request body không phát hiện được tấn công

Ví dụ: trong khai thác SQL injection, nếu hacker cố gắng sử dụng một số công nghệ evasion thì việc phát hiện khi request là khó khăn Khi khai thác thành công, ModSecurity sẽ phân tích kết quả trong gói tin trả về để phát hiện nếu như câu truy vấn thành công

- Phase Logging : đây là thời điểm các hoạt động log được thực hiện các rules đặt ở đây sẽ định rõ việc log sẽ như thế nào, nó sẽ kiểm tra các error message log của Apache Đây cũng là thời điểm cuối cùng để bạn chặn các connection không mong muốn, kiểm tra các response header mà bạn không thể kiểm tra ở phase response header và phase response b

Chương 2 Cài đặt mod sercurity

(Cài đặt ModSecurity trên Ubuntu 18.04 LTS) 2.1 Yêu cầu:

 Ubuntu 18.04 LTS

 APACHE2

 Cài đặt LAMP hoặc XAMPP

2.2 Các bước cài đặt

- Bước 1: Cài đặt mod security:

sudo apt-get install libapache2-mod-security2

 Khởi động lại Apache2: sudo service apache2 restart

 Kiểm tra xem thử ModSecurity đã được enable hay chưa: sudo apachectl -M | grep security

6

Bước 2: Cấu hình Mod Security

Để ModeSecurity hoạt động được, ta sẽ tiễn hành enable SecRuleEngine

trong file configure

Lưu ý: Mỗi khi thay đổi file configure, cần restart lại Apache2 service

Khi đến bước này, cơ bản ta đã hoàn thành thiết lập xong ModSecurity và có thể đưa vào sử dụng Tuy nhiên, để tăng cường khả năng bảo mật, ta cần thiết lập bộ rule cho nó

Bước 3 Thiết lập bộ rule

Github: https://github.com/SpiderLabs/owasp-modsecurity-crs

Trước hết, ta sẽ backup lại bộ rule mặc định của ModSecurity

sudo mv /usr/share/modsecurity-crs /usr/share/modsecurity-crs.bk

Sau đó, tiến hành clone source CRS từ trang github về:

7

sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

/usr/share/modsecurity-crs

Đổi tên file configure rule:

sudo cp /usr/share/modsecurity-crs/crs-setup.conf.example

/usr/share/modsecurity-crs/crs-setup.conf

Thêm các file rule này vào file configure của ModSecurity trong Apache2

sudo nano /etc/apache2/mods-enabled/security2.conf

IncludeOptional /usr/share/modsecurity-crs/*.conf

IncludeOptional "/usr/share/modsecurity-crs/rules/*.conf

Cuối cùng là không quên restart lại Apache2 service

2.3 Cấu trúc Rule

Cấu trúc rule modsecurity bao gồm các thông tin khác nhau , các yêu cầu thiết đặt

khác nhau về nội dung

- Cấu trúc bao gồm chỉ thị, các biến, các hàm chuyểnđổi, các signature và

các action tương ứng cho phép, không cho phép, ghi log

- Yêu cầu về logic là phát hiện các cuộc tấn công

- Thiết đặt chính sách đưa ra hành động xử lý nếu phát hiện ra tấn công

- Thông tin về các cuộc tấn công

8

Cho phép xử lý tách riêng thành các thành phần khác nhau, cơ bản coreruler là dựa trên các mẫu đã được xây dựng sẳn và cũng có thể tự xây dựng thêm các core rule

Khái quát SecRule gồm 4 thành phần:

Variables: cho Modsecurity biết đâu là nơi cần tìm hay còn gọi là mục tiêu Operator: chỉ thị Modsecurity để khích hoạt một lần thực thi

Transformation: chỉ thị Modsecurity chuẩn hóa dữ liệu trên biến

Actions: Cho Modsecirity biết cần phải làm gì khi một rule trùng khớp (kiểm tra đúng với bộ lọc)

Biến: có 105 biến trong 6 loại khác nhau, ví dụ như:

 Biến Request - ARGS, REQUEST_HEADERS, REQUEST_COOKIES

 Biến Response - RESPONSE_HEADERS, RESPONSE_BODY

 Biến Server - REMOTE_ADDR, AUTH_TYPE

 Biến Time - TIME, TIME_EPOCH, TIME_HOUR

 Biến Collection - TX, IP, SESSION, GEO

 Biến Miscellaneous - HIGHEST_SEVERITY, MATCHED_VAR

Operators: có 36 chỉ thị trong 4 loại khác nhau, ví dự như:

 String Operators - rx, pm, beginsWith, contains, endsWith, streq, within

 Numerical Operators - eq, ge, gt, le, lt

 Validation Operators - validateByteRange, validateUrlEncoding,

validateSchema

 Miscellaneous Operators - rbl, geoLookup, inspectFile, verifyCC

Transformation: có 35 hàm dịch trong 6 loại khác nhau, ví dự như:

9

 Hàm chống xê dịch - lowercase, normalisePath, removeNulls,

replaceComments, compressWhitespace

 Hàm giải mã - base64Decode, hexDecode, jsDecode, urlDecodeUni

 Hàm mã hóa - base64Encode, hexEncode

 Hàm băm - sha1, md5

Actions: có 47 hành động trong 6 loại khác nhau, ví dụ như:

 Disruptive Actions - block, drop, deny, proxy

 Flow Actions - chain, skip, skipAfter

 Metadata Actions - phase, id, msg, severity, tag

 Variable Actions - capture, setvar, initcol

 Logging Actions - log, auditlog, nolog, sanitiseArg

 Miscellaneous Actions - ctl, multiMatch, exec, pause, append/prepend

Có 5 phase bao gồm: Request Headers (1), Request Body (2), Response Headers (3), Response Body (4) and Logging (5) Các rule thường thực hiện ở phase 2 – Request Body vì ở đó chứ toàn bộ thông tin của trang kết nối

 Cấu trúc rule gồm:

SecRule VARIABLES "OPERATOR" "TRANSFORMATIONS,ACTIONS"

Ví dụ:

SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES

"@contains () {"

"id:420008,phase:2,t:none,t:lowercase,deny,status:500,log,msg:'Malware expert - user-agent: Bash ENV Variable Injection Attack'"

Variables:

- REQUEST_LINE: tất cả các dòng request thành công đến server bao gồm phương thức và thông tin phiên bản HTTP

10

- REQUEST_HEADERS: tất cả header của request

- REQUEST_HEADERS_NAMES: tất cả tên của các REQUEST HEADER Operator:

- @contains () {: tìm trên tất cả cá biến yêu cầu các chuỗi “()}” nếu tìm thấy thì trả về true

Transformations:

- t:none: không chuyển bất kì giá trị nào cảu biến trước khi trùng khớp

- t:lowercase: chuyển REQUEST về dạng chữ thường

Actions:

- id:420008: id duy nhất được gán cho rule này khi nó xuất hiện

- phase:2: phase thực hiện là phase 2 REQUEST BODY

- deny: hành động là từ chối truy cập

- status:500: appache hearder gửi đến client

- Log: rule trùng khớp trên error và audit log

- msg:'Malware expert - user-agent: Bash ENV Variable Injection Attack'": thông điệp tùy chỉnh được gán cho rule khi nó xuất hiện trùng khớ

2.4 Các loại log

Trong Modsecurity có 3 loại log chính:

 1.Error log

 2.Debug log

 3.Auditlog

11

 Error log

Đây là loại nhật ký được tạo khi gặp lỗi hoặc bất kỳ nỗ lực độc hại nào gặp phải trên máy chủ Vì ModSecurity hoạt động với Apache, tất cả các nhật ký lỗi (Nhật ký lỗi Apache + Nhật ký lỗi bảo mật Mod) được tạo trong cùng một tệp Nó

có nghĩa là tất cả các nhật ký lỗi, cảnh báo, lỗi nghiêm trọng, v.v và nhật ký lỗi ModSecurity được tìm thấy trong cùng một tệp, theo mặc định nằm trong đường dẫn sau

Chương 3 XSS và DVWA

3.1 XSS

3.1.1 Giới thiệu XSS

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP…) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác Trong đó những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng Client-Site Script như javascript, Jscript, DHTML và cũng có thể là các thẻ HTML XSS là một lỗi phổ biến, có rất nhiều trang web bị mắc phải lỗi này, chính

vì thế ngày càng có nhiều người quan tâm đến lỗi này

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 trên chính máy người sử dụng Hacker sẽ lợi dụng sự kiểm tra lỏng lẻo lợi dụng vào hiểu biết hạn chế của người dung cũng như biết đánh vào sự tò mò của họ dẫn đến người dùng bị mất thông tin một cách dễ dàng

12

Thông thường hacker lợi dụng địa chỉ URL để đưa ra những liên kết là tác nhân kích hoạt đoạn chương trình được viết bằng ngôn ngữ máy khách VBScript,

JavaScript… được thực thi trên chính trình duyệt của nạn nhân

3.1.2 Hình thức tồn tại của XSS

 Stored XSS

Stored XSS là hình thức tấn công mà ở đó cho phép kẻ tấn công có thể chèn một đoạn script nguy hiểm (thường là Javascript) vào website của chúng ta thông qua một chức năng nào đó (vd: viết lwofi bình, guestbook, gởi bài…), để từ đó khi các thành viên khác truy cập website sẽ bị dính mã độc từ kẻ tấn công này, các mã độc này thườn được lưu lại trong database của website chúng ta nên gọi là Stored Stored XSS phát sinh do chúng ta không lọc dữ liệu do thành viên gởi lên một các đúng đắn, khiến cho mã độc được lưu vào Database của Website

 Reflected XSS