Luận văn Chống tấn công sql injection sử dụng các khuôn mẫu tổng quát

quan sát cẩn thận hành vi thay đổi của trang web, kẻ tấn công có thể ngoại suy không chỉ các tham số dễ bị tổn thương mà còn có thêm thông tin về các giá trị trong cơ sở dữ liệu. Các nhà nghiên cứu đã báo cáo rằng với những kỹ thuật này, họ đã có thể đạt được tốc độ trích xuất dữ liệu là 1B / s. Xem xét hai chuỗi tiêm nhiễm có thể thêm vào trường đăng nhập. Đầu tiên là “admin’ and 1 = 0 --” và “admin’ and 1 = 1 --". Điều này dẫn đến hai truy vấn sau: “SELECT * FROM user_account WHERE user_name = ’admin’ and 1=0 -- ' AND password = ’abc123’;” “SELECT * FROM user_account WHERE user_name = ’admin’ and 1=1 -- ' AND password = ’abc123’;” Trong trường hợp đầu tiên, ứng dụng được bảo mật và đầu vào để đăng nhập được xác thực chính xác. Cả hai truy vấn sẽ trả về thông báo lỗi đăng nhập và kẻ tấn công sẽ biết rằng tham số đăng nhập không dễ bị tấn công. Trong kịch bản thứ hai, ứng dụng không an toàn và tham số đăng nhập dễ bị tiêm nhiễm. Kẻ tấn công gửi chuỗi tiêm nhiễm đầu tiên và nhận được thông báo lỗi đăng nhập, vì nó luôn bị đánh giá là sai. Tuy nhiên, kẻ tấn công không biết liệu đây có phải là do ứng dụng xác thực đầu vào chính xác và ngăn chặn tấn công hay do chính cuộc tấn công gây ra lỗi đăng nhập. Kẻ tấn công sau đó gửi truy vấn thứ hai, kèm mệnh đề luôn đúng. Nếu trong trường hợp này không 18 có thông báo lỗi đăng nhập, thì kẻ tấn công biết rằng cuộc tấn công đã đi qua và tham số đăng nhập dễ bị tiêm nhiễm. Truy vấn Union: Với kỹ thuật này, kẻ tấn công lợi dụng lỗ hổng tham số để thay đổi bộ dữ liệu trả về cho một câu truy vấn. Với câu truy vấn hợp lệ bên trên, kẻ tấn công có thể tiêm nhiễm vào trường login là “’ UNION SELECT bankNumber FROM Bank WHERE ID =101--”. Lúc này câu truy vấn sẽ trở thành: “SELECT * FROM user_account WHERE user_name = ’’ UNION SELECT bankNumber FROM Bank WHERE ID = 101 - -' AND password = ’’;” Với câu truy vấn đã bị thay đổi trên, CSDL dù không tìm thấy bản ghi login nào phù hợp với “user_name = ’’”nhưng vẫn sẽ tìm thấy bản ghi bankNumber phù hợp với “ID = 101”. CSDL sẽ tiến hành hợp 2 bộ kết quả, và bankNumber vẫn sẽ được trả về cho ứng dụng. Truy vấn Piggy-Backed: Kỹ thuật tấn công này dựa vào máy chủ CSDL được cấu hình để thực thi nhiều câu truy vấn khác nhau trên cùng 1 dòng mã và được ngăn cách bởi dấu “;”. Kẻ tấn công sẽ chèn thêm các câu truy vấn trái phép vào câu truy vấn ban đầu với mục đích trích xuất dữ liệu, thay đổi dữ liệu, thực hiện từ chối dịch vụ hay thực thi lệnh từ xa. Ví dụ, kẻ tấn công có thể nhập mã độc “’; SHUTDOWN --” vào trường user_name. Câu truy vấn lúc này sẽ là “SELECT * FROM user_account WHERE user_name = ’’; SHUTDOWN -- ‘; AND password =’’;” Khi thực thi câu truy vấn trên, CSDL sẽ thực thi luôn câu lệnh “SHUTDOWN”, CSDL sẽ bị tắt, một loạt các truy vấn hợp lệ sau đó sẽ không kết nối được. 1.3. Các phương pháp ngăn chặn tấn công tiêm nhiễm SQL Các nhà nghiên cứu đã đề xuất ra rất nhiều các biện pháp phòng chống và ngăn chặn tấn công tiêm nhiễm SQL. Các biện pháp được thực thi ở các mức khác nhau từ ứng dụng web, trung gian đến CSDL. Các biện pháp ngăn chặn tấn công tiêm nhiễm SQL có thể kể đến như sau: Tham số hóa truy vấn: Sử dụng tham số hóa truy vấn là một trong những cách tốt nhất để ngăn chặn việc tiêm nhiễm SQL. Nó cũng đơn giản để viết và 19 dễ hiểu hơn các truy vấn SQL động. Phương pháp này nhắm tới việc ngăn chặn tấn công tiêm nhiễm SQL bằng cách cho phép nhà phát triển có thể xác định chính xác cấu trúc của câu truy vấn và truyền các tham số giá trị một cách tách biệt. Nếu người dung nhập “12345’ or 1=1 --“ vào trường user_name thì truy vấn tham số hóa sẽ tìm kiếm trong CSDL để khớp với toàn chuỗi “12345’ or 1=1 -- “. Điều đó sẽ ngăn ngừa cấu trúc câu truy vấn bị thay đổi bởi bất kỳ đầu vào nào. Sau đây là một số ngôn ngữ lập trình có áp dụng kỹ thuật này:  Java EE - sử dụng PreparedStatement () với các biến liên kết.  .NET - sử dụng các truy vấn được tham số hóa như SqlCommand () hoặc OleDbCommand () với các biến liên kết  PHP - sử dụng PDO với các truy vấn được tham số hóa mạnh mẽ.  Hibernate - sử dụng createQuery () với các biến liên kết (được gọi là tham số có tên trong Hibernate)  SQLite - sử dụng sqlite3_prepare () để tạo đối tượng câu lệnh Ví dụ trong PHP. $stmt = $dbh->prepare('SELECT * FROM customers WHERE ssn = :ssn'); $stmt-> bindParam(':ssn' => $ssn); Sử dụng các thủ tục lưu trữ: Các thủ tục được lưu trữ sẽ thêm một lớp bảo mật bổ sung vào CSDL bên cạnh sử dụng truy vấn tham số. Nó thực hiện giúp cho ứng dụng xử lý dữ liệu đầu vào dưới dạng thủ tục được xây dựng từ trước thay vì thực thi câu lệnh SQL trực tiếp. Các thủ tục được viết và lưu trữ trong máy chủ CSDL, sau đó được gọi từ ứng dụng web. Nếu người dùng truy cập vào CSDL chỉ được phép thông qua các thủ tục được lưu trữ thì không cần thiết phải phân quyền người dùng trên các bảng dữ liệu. Bằng cách này, tính an toàn của CSDL được nâng cao. Xác thực dữ liệu đầu vào của người dùng: Ngay cả khi sử dụng tham số trong truy vấn được áp dụng, việc thực hiện xác thực đầu vào là cần thiết để đảm bảo các thuộc tính dữ liệu phù hợp như kiểu/ loại, độ dài, định dạng,... Chỉ xử lý dữ liệu đầu vào đã qua xác thực cho CSDL. 20 Với những kiểm soát đơn giản như kiểm soát về kiểu dữ liệu cũng có thể hạn chế đáng kể các cuộc tấn công. Ví dụ, trường bankNumber được khai báo ở kiểu số. Khi nhận dữ liệu đầu vào, các ký tự không phải là số sẽ bị loại bỏ. Mã hóa dữ liệu đầu vào: Tấn công tiêm nhiễm SQL thường lợi dụng đưa các chuỗi ký tự đặc biệt hay các chuỗi được sử dụng trong ngữ pháp SQL như OR, AND, UNION, để tiêm nhiễm, đánh lừa CSDL. Trong thực tế, giải pháp hạn chế nhập những ký tự đặc biệt đã được áp dụng nhưng nó lại đi kèm với hạn chế làm giảm đi tính an toàn ở khía cạnh dữ liệu dễ bị suy đoán, dễ bị tiết lộ. Vì vậy mà ngoài kết hợp với tham số hóa truy vấn, chuỗi dữ liệu đầu vào có thể được tiến hành mã hóa thay cho dạng plain text thông thường. Việc mã hóa dữ liệu vừa hữu ích trong chống tấn công tiêm nhiễm SQL lại vừa có giá trị trong việc bảo mật thông tin. Ẩn thông tin của các thông báo: Thông báo lỗi rất hữu ích cho những kẻ tấn công tìm hiểu thêm về kiến trúc CSDL. Trong trường hợp tấn công suy đoán, kẻ tấn công có thể lợi dụng các thông báo lỗi để hoàn thiện kiến thức, phương án tấn công. Vì vậy thông báo lỗi nên chỉ hiển thị các thông tin cần thiết. Tốt hơn hết là hiển thị thông báo lỗi chung cho biết có lỗi xảy ra và khuyến khích người dùng liên hệ với nhóm hỗ trợ kỹ thuật trong trường hợp sự cố vẫn còn. Hạn chế đặc quyền: không kết nối với cơ sở dữ liệu của bằng tài khoản có quyền truy cập root trừ khi được yêu cầu vì những kẻ tấn công có thể có quyền truy cập vào toàn bộ hệ thống. Do đó, tốt nhất là sử dụng một tài khoản có các đặc quyền hạn chế để giới hạn phạm vi thiệt hại trong trường hợp bị tấn công tiêm nhiễm SQL. Ngoài ra, xác định người dùng khác nhau với các đặc quyền khác nhau và sử dụng trong quá trình phát triển có thể thực sự hữu ích trong việc giảm thiểu rủi ro của cuộc tấn công tiêm nhiễm SQL. Trên đây là một số phương pháp có thể được thực hiện ngay để giảm nguy cơ bị tấn công tiêm nhiễm SQL. Tuy nhiên những phương pháp này lại phụ thuộc nhiều vào quá trình thiết kế, phát triển ứng dụng web cũng như CSDL. Bên cạnh đó, có thêm các giải pháp hỗ trợ với mục đích phát hiện và ngăn chặn tấn công tiêm nhiễm SQL như: Phát hiện và ngăn chặn dựa trên chữ ký “signature”: Phương pháp này tập trung xây dựng tập các mẫu tấn công tiêm nhiễm SQL có thể có. Quá trình xây dựng đòi hỏi phải cập nhật thường xuyên các mẫu tấn công. Phương pháp hoạt động tương tự như các chương trình anti – virus. Khi có một truy vấn bất 21 kỳ đến CSDL, nó sẽ được so sánh với các mẫu tấn công. Nếu khớp mẫu tấn công, truy vấn sẽ bị chặn lại. Phát hiện và ngăn chặn trên bất thường: Ngược lại với phương pháp phát hiện và ngăn chặn dựa trên chữ ký, phương pháp này xây dựng tập các mẫu hợp lệ. Bất kỳ một truy vấn đến CSDL nằm ngoài tập mẫu này sẽ bị cho là tấn công và ngăn chặn lại. Phân tích mã: Phương pháp này sử dụng kiểm thử để phát hiện ra lỗ hổng của ứng dụng. Bộ kiểm thử sẽ sinh ra một loạt các dạng tấn công tiêm nhiễm SQL nhằm kiểm tra phản hồi của ứng dụng web. Dựa vào kết quả trả về của bộ kiểm thử, nhà phát triển có thể xác định các lỗ hổng trên ứng dụng và tìm cách khắc phục các lỗ hổng này. Một số bộ kiểm thử thông dụng với tấn công tiêm nhiễm SQL như SQLMap, Acunetix, Burp suite, Netsparker, 1.4. Kết chương Chương 1 đã nêu lên một cách tổng về tấn công tiêm nhiễm SQL, các loại tấn công và một số phương pháp phát hiện, ngăn chặn. Tiêm nhiễm SQL (còn gọi là SQL Injection) không còn là khái niệm quá mới, nhưng nó vẫn là một trong những kiểu tấn công mạng khá phổ biến. Tấn công tiêm nhiễm SQL là một kỹ thuật tấn công vào hệ thống cơ sở dữ liệu của ứng dụng (web, mobile hoặc desktop ) thông qua việc kẻ tấn công lợi dụng lỗ hổng để tiến hành tiêm nhiễm mã độc vào câu truy vấn SQL và thi hành các câu lệnh SQL bất hợp pháp trên cơ sở dữ liệu đằng sau ứng dụng web. Tấn công tiêm nhiễm SQL vô cùng nguy hiểm vì kẻ tấn công không chỉ có thể ăn cắp được dữ liệu chứa thông tin nhạy cảm mà chúng còn có thể thay đổi dữ liệu, thậm chí là kiểm soát cả máy chủ mà CSDL đang chạy. Tấn công tiêm nhiễm SQL xảy ra trên các hệ quản trị CSDL quan hệ như MySQL, MS SQL, DB2, Oracle Tấn công tiêm nhiễm SQL có thể phân loại thành Order Wise, Blind SQL Injection và Against Database. Order Wise gồm: Tiêm nhiễm First Order, Tiêm nhiễm Second Order, Tiêm nhiễm Lateral. Blind SQL Injection gồm: Tấn công dựa vào nội dung phản hồi, Tấn công dựa vào độ trễ thời gian phản hồi. 22 Kỹ thuật thao tác SQL gồm có: tautologies, chú thích cuối dòng, suy luận, truy vấn Union, truy vấn Piggy-Backed. Một số phương pháp phát hiện, ngăn chặn tấn công tiêm nhiễm SQL: Tham số hóa truy vấn, Sử dụng các thủ tục lưu trữ, Xác thực dữ liệu đầu vào của người dùng, Ẩn thông tin của các thông báo lỗi, Hạn chế đặc quyền, Phát hiện và ngăn chặn dựa trên chữ ký “signature”, Phát hiện và ngăn chặn dựa trên bất thường, Phân tích mã. 23 CHƯƠNG 2: MỘT SỐ PHƯƠNG PHÁP CHỐNG TẤN CÔNG TIÊM NHIỄM SQL SỬ DỤNG KHUÔN MẪU TỔNG QUÁT 2.1. Phương pháp chống tấn công tiêm nhiễm SQL sử dụng các khuôn mẫu hợp lệ theo bối cảnh, SDriver 2.1.1. Kiến trúc của SDriver SDriver được đề xuất bởi Dr. Dimitris Mitropoulos và Prof. Diomidis Spinellis. Ý tưởng của kỹ thuật này là dựa vào kiến trúc điển hình của một ứng dụng web bao gồm ít nhất một ứng dụng đang chạy trên một máy chủ web và cơ sở dữ liệu ở phía sau. Giữa hai tầng này, có một trình điều khiển kết nối dựa trên các giao thức như ODBC (Open Database Connectivity) hoặc JDBC (Java Database Connectivity). Theo đề xuất của hai nhà khoa học, SDriver được thêm vào giữa ứng dụng web và trình điều khiển kết nối tới cơ sở dữ liệu. Tất cả mọi truy vấn từ ứng dụng web đều phải đi qua SDriver trước khi đến CSDL. Sau khi nhận được truy vấn, SDriver sẽ tiến hành so sánh với tập các mẫu hợp lệ được xây dựng từ trước. Nếu truy vấn đến phù hợp với tập dữ liệu, SDriver thực hiện kết nối đến CSDL. Nếu truy vấn đến nằm ngoài tập dữ liệu này, SDriver cảnh báo tấn công, ngăn chặn ngay lập tức. Hình 2.1 [2, tr.5] là mô tả kiến trúc đề xuất của SDriver. Hình 2.1 Kiến trúc đề xuất của SDriver [2, tr.5] Trong phần nghiên cứu của hai nhà khoa học, SDriver được triển khải trên nền tảng ngôn ngữ Java, tuy nhiên SDriver cũng có thể xây dựng trên những nền 24 tảng ngôn ngư khác. Mô hình triển khai SDriver sẽ giống như hình 2.2 [2, tr.8]. Một CSDL ssql sẽ được xây dựng để chứa tập các mẫu truy vấn hợp lệ. Hình 2.2 Kiến trúc thực tế của Sdriver [2, tr.8] SDriver là trong suốt và không phụ thuộc vào ứng dụng, CSDL hay trình điều khiển kết nối của ứng dụng. Bản thân SDriver cũng không phải là một trình điều khiển kết nối mà là trung gian giữa ứng dụng web và trình điều khiển kết nối. Một điểm đặc biệt là SDriver gắn các mẫu truy vấn hợp lệ với bối cảnh. Bối cảnh ở đây chính là Stack trace. 2.1.2. Cách thức hoạt động của SDriver SDriver có 2 chế độ hoạt động: chế độ huấn luyện (training mode) và chế độ thực thi (Production mode). Tập các khuôn mẫu hợp lệ sẽ được xây dựng trong chế độ huấn luyện. Do giả thuyết toàn bộ truy vấn trong chế độ này là hợp lệ nên cần thực hiện trong môi trường không trực tuyến. Chế độ huấn luyện Khuôn mẫu hợp lệ được xây dựng trên 3 thành phần.  Thông tin về stack trace của câu truy vấn.  Các từ khóa SQL.  Các bảng và các trường có trong câu truy vấn. 25 Sau khi kết hợp các đặc trưng trên của câu truy vấn sẽ thu được khuôn mẫu hợp lệ. Tập hợp khuôn mẫu hợp lệ sẽ có dạng sau: 𝑺 = { 𝝎 ∶ 𝝎 = (𝒌, 𝒂𝟏, 𝒂𝟐, ), 𝒌 ∈ 𝑲, 𝒂𝒊 ∈ (𝑳 ∪ 𝑴 ∪ 𝑵)} Trong đó, S là tập hợp khuôn mẫu hợp lệ,  là khuôn mẫu hợp lệ, K là tập hợp stack trace của câu truy vấn, L là tập hợp các từ khóa SQL tương ứng, M là tập hợp các bảng tương ứng và N là tập hợp các trường tương ứng. Hình 2.3 Chế độ huấn luyện của SDriver 26 Khi một câu truy vấn thực thi trong chế độ huấn luyện – “traning mode”, SDriver thực hiện một số việc như sau: - Rút gọn chuỗi truy vấn, loại bỏ dữ liệu, số, chuỗi đầu vào. - Thu thập thông tin StackTrace bằng cách lần ngược lại ngăn xếp được gọi cho đến khi tìm được vị trí câu truy vấn thực thi. - Kết hợp chuỗi truy vấn rút gọn, Stack trace thành khuôn mẫu hợp lệ. - Kiểm tra khuôn mẫu thu được trong bảng signatures của CSDL ssql. - Lưu khuôn mẫu thu được vào bảng signatures của CSDL ssql nếu khuôn mẫu chưa tồn tại trong đó. Ví dụ về rút gọn chuỗi truy vấn: “Select * from USER_ACCOUNT where USER_NAME = 'admin' and PASSWORD = 'abc123'” Câu rút gọn: Select * from USER_ACCOUNT where USER_NAME = and PASSWORD = Chế độ thực thi Trong chế độ thực thi, SDriver sẽ sử dụng các khuôn mẫu hợp lệ đã được lưu trữ trong CSDL ssql trong quá trình huấn luyện để xác định một câu truy vấn là hợp lệ hay không. Các bước thực hiện chế độ thực thi được mô tả như hình 2.4. Khác biệt duy nhất giữa hai chế độ là ở chế độ thực thi, nếu khuôn mẫu tổng hợp ra được không khớp với bất kỳ một mẫu nào trong ssql thì SDriver kết luận luôn là tấn công, ngăn chặn kết nối đến CSDL thay vì thêm khuôn mẫu vào ssql như ở chế độ huấn luyện. 2.1.3. Stack trace Trong đề xuất xây dựng khuôn mẫu của SDriver, ngoài mẫu chuỗi rút gọn truy vấn hợp lệ còn kèm thêm phần Stack trace – đóng vai trò là bối cảnh. Stack Trace tạo ra sự khác biệt giữa kỹ thuật này với các kỹ thuật chống tấn công tiêm nhiễm SQL sử dụng khuôn mẫu hợp lệ khác. Stack Trace là một danh sách các 27 lệnh gọi chương trình con mà ứng dụng thực hiện trong khi thực thi, bao gồm thông tin chi tiết về tất cả phương thức, vị trí gọi (vị trí dòng lệnh). Mỗi câu truy Hình 2.4 Chế độ thực thi của SDriver vấn sẽ có thông tin về Stack Trace là không giống nhau. Vì vậy sử dụng stack trace để tạo thành đặc trưng của chuỗi truy vấn sẽ tạo ra sự khác biệt nhất định trong việc phát hiện ngăn chặn tấn công. 28 Ví dụ về vai trò của Stack Trace Hình 2.5 Ví dụ vai trò của stack trace.[1,tr.25] Ví dụ trên có hai form nhập dữ liệu: Form đăng nhập với chuỗi truy vấn 1: “Select * from USER_ACCOUNT where USER_NAME = 'admin' and PASSWORD = 'abc123'” Form quản lý user với chuỗi truy vấn 2: “Select * from USER_ACCOUNT where USER_NAME = 'admin'” Sự khác nhau của hai truy vấn này là ở phần điều kiện “and PASSWORD = 'abc123'”. Với các kỹ thuật ngăn chặn tấn công tiêm nhiễm SQL sử dụng các khuôn mẫu hợp lệ không sử dụng Stack Trace, tập dữ liệu hợp lệ chỉ chứa các mẫu truy vấn hợp lệ ( các mẫu truy vấn hợp lệ có thể được xử lý thêm trước khi thêm vào CSDL tùy theo từng kỹ thuật khác nhau. Sự kiện đặt ra có một kẻ tấn công sử dụng chuỗi “ admin’ -- “ nhập vào trường USER_NAME. Chuỗi truy vấn số 1 trở thành như sau: “Select * from USER_ACCOUNT where USER_NAME = 'admin' –- ‘and PASSWORD = 'abc123'” Do trong ngữ pháp SQL, chuỗi đằng sau “–-“ được coi là thành phần chú thích và không được thực thi. Mặc nhiên, nó sẽ biến thành truy vấn hợp lệ tương tự như chuỗi số 2. Kẻ tấn công có thể đăng nhập mà ko cần dùng mật 29 khẩu. Trong SDriver, đây là hai câu truy vấn khác nhau nên Stack Trace của 2 chuỗi truy vấn là khác nhau. Mặc dù chuỗi truy vấn hợp lệ nhưng Stack Trace không đúng, SDriver cũng có thể phát hiện ra chuỗi tấn công và ngăn chặn kết nối đến CSDL sau ứng dụng. Ví dụ về Stack Trace: SStatement.java:654)org.SStatement.manageQuery(SStatement.java:58 2)org.SStatement.executeQuery(SStatement.java:545)simplewebapp.ut ils.DBUtils.findUser(DBUtils.java:42)simplewebapp.servlet.DoLogin Servlet.doGet(DoLoginServlet.java:53)simplewebapp.servlet.DoLogin Servlet.doPost(DoLoginServlet.java:108)javax.servlet.http.HttpSer vlet.service(HttpServlet.java:648)javax.servlet.http.HttpServlet. service(HttpServlet.java:729)org.apache.catalina.core.Application FilterChain.internalDoFilter(ApplicationFilterChain.java:292)org. apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:207)org.apache.tomcat.websocket.server.WsFilter.d oFilter(WsFilter.java:52)org.apache.catalina.core.ApplicationFilt erChain.internalDoFilter(ApplicationFilterChain.java:240)org.apac he.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte rChain.java:207)simplewebapp.filter.JDBCFilter.doFilter(JDBCFilte r.java:96)org.apache.catalina.core.ApplicationFilterChain.interna lDoFilter(ApplicationFilterChain.java:240)org.apache.catalina.cor e.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207 )org.apache.catalina.core.StandardWrapperValve.invoke(StandardWra pperValve.java:212)org.apache.catalina.core.StandardContextValve. invoke(StandardContextValve.java:106)org.apache.catalina.authenti cator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)org.apa che.catalina.core.StandardHostValve.invoke(StandardHostValve.java :141)org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo rtValve.java:79)org.apache.catalina.valves.AbstractAccessLogValve .invoke(AbstractAccessLogValve.java:616)org.apache.catalina.core. StandardEngineValve.invoke(StandardEngineValve.java:88)org.apache .catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522) org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract Http11Processor.java:1095)org.apache.coyote.AbstractProtocol$Abst ractConnectionHandler.process(AbstractProtocol.java:672)org.apach e.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.j ava:1500)org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.r un(NioEndpoint.java:1456)java.util.concurrent.ThreadPoolExecutor. runWorker(ThreadPoolExecutor.java:1149)java.util.concurrent.Threa dPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)org.apache.t omcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.jav a:61)java.lang.Thread.run(Thread.java:748 30 2.2. SDriver cải tiến của luận văn Thạc sỹ Nguyễn Thanh Liêm 2.2.1. Những lỗ hổng trong SDriver Luận văn của Nguyễn Thanh Liêm đã tiến hành phân tích cơ chế hoạt động của SDrive. Một khuôn mẫu của SDriver bao gồm có 2 phần là Stack Trace và chuỗi truy vấn rút gọn. Stack Trace rất khó, thậm chí có thể nói là không thể giả mạo. Vì vậy, nếu có trường hợp kẻ tấn công có thể vượt qua được SDriver thì chỉ có thể xảy ra vấn đề trong chuỗi truy vấn rút gọn hay nói cách khác, cách thức rút gọn truy vấn tiềm tàng lỗ hổng có thể khai thác được. Về cơ chế, SDriver sử dụng Regular Expression để tiến hành rút gọn chuỗi truy vấn, loại bỏ những phần được coi là không cần thiết . Định nghĩa Regular Expression trong SDriver. “//Initializing patterns trivia = Pattern.compile("\\+|-|\\."); escapeChar = Pattern.compile("\\'(?:.|[\\n\\r])*?\\'"); numbers = Pattern.compile("([,\\(]+\\s*)(?:[0-9A-Fa-f])+"); comments = Pattern.compile("/\\*(?:.|[\\n\\r])*?\\*/");” Các bước tiến hành xóa bỏ: 1. Xóa bỏ các ký tự được cho là thông thường: “+”, “-” và “.”. 2. Xóa bỏ các chữ số đằng sau các phép toán “”. 3. Xóa bỏ thành phần chú thích “/* */”. 4. Xóa bỏ chuỗi nhập liệu nằm giữa cặp dấu ngoặc đơn “'”. “public String strippedDownQuery(String sql){ Matcher tmpMatcher = this.trivia.matcher(sql); sql = tmpMatcher.replaceAll(""); tmpMatcher = this.numbers.matcher(sql); sql = tmpMatcher.replaceAll("$1"); tmpMatcher = this.comments.matcher(sql); sql = tmpMatcher.replaceAll(""); tmpMatcher = this.escapeChar.matcher(sql); 31 sql = tmpMatcher.replaceAll(""); System.out.println("SDriver: The stripped query: " +sql); return sql; }” Bước một và ba chủ yếu là loại bỏ các ký tự, chuỗi được cho là “thừa”, không phải là đặc trưng của câu truy vấn. Trong khi bước hai và bốn là loại bỏ các ký tự số, chuỗi nhập liệu của người dùng. Ví dụ: đầu vào là câu truy vấn “Select a.Code, a.Name, a.Price, a.Vendor from Product a where a.Vendor like '%HP%' and a.Price >=1000.0 and a.Price <=1500.0 /* Truy van Product HP */” Thì câu truy vấn rút bỏ dữ liệu sẽ là “SELECT aCode, aName, aPrice, aVendor from Product a WHERE where a.Vendor like and aPrice >=and aPrice <=” Lần ngược quá trình rút gọn một câu truy vấn của SDriver để tìm ra điểm yếu. Ví dụ với trường hợp truy vấn sử dụng đăng nhập cơ sở dữ liệu. Câu đã rút gọn cuối cùng: “Select * from USER_ACCOUNT where USER_NAME = and PASSWORD = ” Câu truy vấn ở bước 4 : “Select * from USER_ACCOUNT where USER_NAME = '?' and PASSWORD = '?' ” Câu truy vấn rút gọn ở bước 3: “Select * from USER_ACCOUNT where USER_NAME = '?'/* */ and PASSWORD = '/* */' ” Ở bước rút gọn số 3, SDriver tiến hành rút gọn chú thích. Trong câu truy vấn chú thích được phân tách bằng “/**/” và có thể đặt ở bất kỳ nơi nào trong câu. Ở vị trí đầu tiên, chú thích thật sự hoạt động đúng chức năng nhưng ở vị trí số 2. Cụm chú thích nằm trong cặp ngoặc đơn. Bản thân các dấu chú thích này 32 nếu nằm trong cặp ngoặc đơn thì chúng sẽ được giải mã như những ký tự thông thường chứ không phải là dấu chú thích. Vậy nên nếu lồng ghép dấu “/*” và “*/” vào các cặp ngoặc đơn, ví dụ như “’/*’ OR ‘*/’” thì chuỗi “OR” sẽ không được tính như một thành phần chú thích mà là một toán tử của SQL. Trong khi đó SDriver lại tiến hành xóa bỏ chuỗi chú thích trước khi xóa bỏ chuỗi dữ liệu trong cặp nháy đơn. Do vậy ở bước ba, SDriver có thể sẽ loại bỏ nhầm những chuỗi mã độc hại. Ở bước thứ bốn, SDriver chỉ chú tâm vào việc loại bỏ các chuỗi nằm trong cặp dấu ngoặc đơn mà không quan tâm đến việc có bao nhiêu chuỗi đã bị loại bỏ. Trong một số ví dụ, chuỗi truy vấn có đến 3 chuỗi trong cặp ngoặc đơn nhưng khi SDriver thực hiện rút gọn thì lại chỉ có 2 do 1 cặp ngoặc đơn nằm trong phần chú thích nên đã bị loại bỏ tại bước trước. Một số ví dụ kiểm chứng: Kỹ thuật tautologies: Nhập “/*admin' or 1=1 -- */” vào trường Username, Password bất kỳ. Kết quả kiểm tra tại SDriver như hình 2.6. SDriver: This is the query the application sent: Select * from USER_ACCOUNT where USER_NAME = '/*admin' or 1=1 -- */' and PASSWORD = 'dsdsd' SDriver: The stripped query: Select * from USER_ACCOUNT where USER_NAME = and PASSWORD = SDriver: NO NEED TO WORRY Hình 2.6 Ví dụ tấn công tautologies thành công 33 Kỹ thuật truy vấn Union: Nhập chuỗi “/*' union select * from USER_ACCOUNT -- */” vào Username, Password bất kỳ. Kết quả kiểm tra tại SDriver như hình 2.7. SDriver: This is the query the application sent: Select * from USER_ACCOUNT where USER_NAME = '/*' union select * from USER_ACCOUNT -- */' and PASSWORD = 'dsds' SDriver: The stripped query: Select * from USER_ACCOUNT where USER_NAME = and PASSWORD = SDriver: NO NEED TO WORRY Hình 2.7 Ví dụ tấn công UNION thành công Kỹ thuật truy vấn Piggy-Backed: Nhập chuỗi “admin” vào Username và chuỗi “/*'; shutdown -- */” vào Password. Kết quả kiểm tra tại SDriver như hình 2.8. SDriver: This is the query the application sent: Select * from USER_ACCOUNT where USER_NAME = 'admin' and PASSWORD = '/*'; shutdown -- */' SDriver: The stripped query: Select * from USER_ACCOUNT where USER_NAME = and PASSWORD = SDriver: NO NEED TO WORRY 34 Kẻ tấn công đã vượt qua được SDriver, tuy vậy lệnh “SHUTDOWN” sẽ không được thực thi là do phương thức gọi lệnh thực thi truy vấn trong trường hợp trên là excuteQuery, phương thức này chỉ truy vấn để lấy dữ liệu chứ không thực hiện bất kỳ thay đổi nào trên CSDL. Qua một số trường hợp trên, kẻ tấn công có thể lợi dùng lỗ hổng SDriver để thực hiện tấn công tiêm nhiễm SDriver, Hình 2.8 Ví dụ tấn công Piggy-Backed thành công 2.2.2. SDriver cải tiến của luận văn Nguyễn Thanh Liêm N