An toàn bảo mật thông tin Tấn công XSS và SQL Injection
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (820.19 KB, 22 trang )
1
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
Viện Công Nghệ Thông Tin & Truyền Thông
o0o
BÁO CÁO TIỂU LUẬN
Môn học: An toàn bảo mật thông tin
Lớp: 12BCNTT2 - Nhóm 4
Đề tài: Tấn công XSS và SQL Injection
Giảng viên: TS. Trần Đức Khánh
Nhóm học viên thực hiện:
Ngô Hoàng Thành
Phạm Tất Thành
Nguyễn Xuân Thịnh
Trần Văn Nậm
Luyện Thanh Tuấn
Trần Hữu Thảo
Hà Nội 06-2013
MỤC LỤC
1.1. Khái niệm 4
1.2. Phân loại 5
!"
#$ % &'!(
$ $ ) *+,-
Thao tác 1 : Dò m lỗ hổng XSS của trang web 8
.$ / 01
5.1. Đối với người phát triển web 9
5.2. Đối với người dùng 10
23 4+,5678
2 $*9
:;<= $
2.1 Thông qua “user input” 11
2.2 Thông qua Cookies 11
2.3 Thông qua các biến server 12
2.4 Second-order Injec?on 13
#$=> 4= $#
3.1 Union Query Based 13
3.2 Batched Query 14
3.3 Order by clause 14
$?;<= $ ,8.
4.1. Phát hiện 15
4.2 Thu thập thông ?n về hệ quản trị cơ sở dữ liệu 16
4.3. Xác định số lượng cột trong mệnh đề Select 16
4.4. Xác định thông ?n 17
.'0@= $1
"$ / 01
(A9@ B
7.1. Kịch bản xâm nhập 20
7.2 Mô tả tool 21
-2C@4
2
1D@* 9= E
3
I. XSS – Cross Site Script
1. Tổng quan về XSS
1.1. Khái niệm
XSS (Cross-site script) là một kỹ thuật tấn công bằng cách chèn vào các trang web
động (PHP, ASP, JSP…) những thẻ HTML hoặc những đoạn script (những đoạn mã
lệnh thực thi trực tiếp trên trình duyệt) nhằm mục đích thiết lập hoặc đánh cắp những
thông tin quan trọng trên máy người dùng.
Kỹ thuật này được viết tắt là XSS để tránh nhầm lẫn với CSS - Cascading Style
Sheet – (những file định dạng hiển thị cho HTML).
XSS là kỹ thuật tấn công nhằm vào phía người dùng (client side), lợi dụng sự
“ngây thơ” của những người sử dụng web chủ yếu là để đánh cắp các thông tin quan
trọng từ họ và sử dụng những thông tin đó vào mục đich xấu. Các đoạn script được
chạy trong khi người dùng không hề ý thức được việc mình đang thực hiện các thao
tác này.
4
1.2. Phân loại
Stored XSS
Phương pháp này giống như tên gọi tức là XSS được lưu trữ lại trên server. Với
phương pháp này, attacker sẽ gửi một đoạn script độc hại vào trang web của server
(qua nhiều hình thức như comment, viết bài, …) và những đoạn script này sẽ được lưu
trữ vào server. Khi người dùng xem trang web này, trình duyệt sẽ nhận về cả trang
web lẫn script độc hại và chạy đoạn script này, thực hiện các thao tác mà người dùng
không hề biết (chuyển thông tin cho attacker, thực hiện các thao tác giao dịch …)
Reflected XSS
Về cơ bản reflectd XSS được sử dụng thông qua các URL chứa đoạn script độc hại mà
người dùng không để ý vẫn click vào. Attacker gửi cho người dùng URL chứa script
độc hại (thông qua email, chat, …) và thông thường URL này được ẩn dưới dạng mà
người dùng tin tưởng (URL của các trang mà người dùng có tài khoản, những trang
5
hay truy cập). Khi người dùng click vào những đường link này thì một request mang
theo script độc hại sẽ được gửi lên server, server sẽ trả lại trang HTML có chứa script
và trình duyệt sẽ thực hiện script đó với tư cách là user đang đăng nhập, dễ dàng thực
hiện các thao tác và thao tác đơn giản nhất là gửi thông tin người dùng (chứa trong
cookie) cho attacker.
2. Mục đích chính của XSS
Mục đích chính của XSS là đánh cắp thông tin quan trọng của người dùng để
thực hiện các thao tác bất hợp pháp. XSS là phương pháp tấn công phía client do đối
tượng tấn công của nó là những người dùng “ngây thơ”, bản thân kỹ thuật này không
nhằm đến việc tấn công hủy hoại server hay chiếm quyền điều khiển trên server. Ta có
thể liệt kê ra đây một số mục đích chính của XSS:
• Truy cập thông tin nhạy cảm hoặc bị hạn chế.
• Ăn cắp tiền của người dùng (thông qua giao dịch ngân hàng, giao dịch mua bán
…).
• Theo dõi thói quen lướt web của người dùng.
• Hủy hoại ứng dụng web.
• Tấn công DDoS (Sử dụng trình duyệt của người dùng như một công cụ tấn
công).
6
• …
3. Cách thức hoạt động của XSS
Về cơ bản XSS cũng giống như SQL injection, nó cũng là kỹ thuật chèn vào
các request từ client lên server những đoạn mã độc hại. Việc chèn các đoạn mã này có
thể được thực hiện thông qua các form HTML cho phép input dữ liệu hoặc trực tiếp
thông qua các URL.
Một URL bị tiêm mã độc có thể có dạng như sau :
http::/Trang_web/file_name?query=<script>Mã độc</script>
Phần in đậm chính là đoạn mã độc được tiêm vào URL trong thẻ <script>. Với đoạn
URL này thì web server có lỗ hổng XSS sẽ trả về trình duyệt một trang HTML có thẻ
<script> chứa mã độc này và trình duyệt sẽ thực hiện nó với tư cách là người dùng đã
truy cập vào web server.
Đây là cách thông dụng nhất để đánh lừa người dùng. Người dùng tưởng rằng
mình truy cập trang web đó một cách bình thường như mọi lần, thực hiện các thao tác
bình thường mà không hề biết rằng trình duyệt của mình đang thực thi một số thao tác
nằm ngoài tầm kiểm soát.
Nội dung trong thẻ <script> không bị hạn chế. Nó có thể là một đoạn code sẵn
có hoặc thậm chí là một đường link đến một file script được viết sẵn từ trước, và chính
vì vậy mà ta không thể lường trước hết được những gì mà XSS có thể làm được. Tuy
nhiên do những script này được chạy trên trình duyệt của người dùng nên mục tiêu của
nó chính là những người dùng. Nó không có tác dụng thay đổi dữ liệu nguồn của web
server. Tất nhiên có những trường hợp attacker sử dụng người dùng để tấn công server
nhưng điều đó chỉ là tấn công bề ngoài của server mà thôi (do người dùng cũng chỉ có
quyền hạn nhất định trên web server).
Trên thực tế XSS không dễ nhận ra theo cách thức nhìn thấy thẻ script trên
URL mà URL có thể được encode lại dưới dạng mã Hexa. Ở dạng này trình duyệt vẫn
hiểu được URL đó là gì nhưng người dùng lại khó nhận ra được URL này chứa XSS.
Ví dụ :
7
http::/Trang_web/file_name?query=%3C%73%63%72%69%70%74%3E
%61%6C%65%72%74%28%27%58%53%53%20%61%74%74%61%63%6B
%65%64%21%27%29%3B%3C%2F%73%63%72%69%70%74%3E
thực chất là URL :
http::/Trang_web/file_name?query= <script>alert('XSS attacked!');</script>
đã được mã hóa dưới dạng Hexa. Người dùng sẽ không nhận ra URL này thực chất là
gì mà sẽ chỉ nghĩ rằng đây là các tham số của trang web mình thường sử dụng và sẽ
click vào đó.
Các đoạn script trong XSS rất đa dạng. Nó có thể đơn giản chỉ là những script
lấy thông tin cookie (thông tin về session của người dùng) gửi về cho attacker cho đến
những thao tác phức tạp như thực thi các giao dịch mua bán, giao dịch chuyển tiền…
Trong thực tế có nhiều cách tấn công XSS “tinh vi” hơn thông qua các file được
upload lên server. Điển hình là cách tấn công XSS thông qua các file flash.
Macromedia Flash cho phép thêm vào file flash những script có cú pháp đơn giản và
tương tự như Java script. Những đoạn script này có thể thực thi việc gọi đến một trang
web hay đơn giản là gọi đến một đoạn Java script khác. Attacker sẽ gửi lên trang web
những file flash có chứa mã độc trong script (những đoạn mã này người dùng hoàn
toàn không thấy được), khi người dùng xem những file flash đó thì các đoạn script sẽ
được thực thi và thực hiện những thao tác mà attacker mong muốn.
4. Các thao tác thực hiện tấn công XSS
Thao tác 1 : Dò tìm lỗ hổng XSS của trang web
Ta có 2 cách để thực hiện thao tác này.
Cách 1 : Sử dụng các tool có sẵn (ví dụ : chương trình Web Vulnerability Scanner) để
dò quét lỗi XSS của trang web.
Cách 2 : Thực hiện thủ công
• Bước 1 : Thao tác 2 : Thao tác tấn công
8
Tùy thuộc vào lỗ hổng ta tìm ra được ở thao tác 1 mà ta sẽ đưa ra được chiến
lược tấn công khác nhau. Chiến lược phổ biến như sau (reflected xss):
• Bước 1 : Tạo một email giả đến người dùng, trong mail có URL ẩn giấu
trong text (tức là URL và nội dung hiển thị không giống nhau, nội dung sẽ
là những gì mà người dùng tin tưởng). URL này có thể là URL trực tiếp đến
thành phần có lổ hổng XSS và thêm script vào request hoặc là một URL đến
trang web khác. Trang web này làm nhiệm vụ thêm mã độc vào request và
chuyển đến server, server sẽ trả về cho người dùng trang HTML có chứa mã
độc.
• Bước 2 : Người dùng đọc email sẽ tin tưởng và click vào URL mà ta đã
chuẩn bị sẵn. Server sẽ gửi lại trang HTML có mã độc, trình duyệt sẽ chạy
đoạn có mã độc này và attacker có thể lấy được thông tin của người dùng.
• Bước 3 : Attacker lấy được thông tin của người dùng và sử dụng nó vào
mục đích của mình, kết thúc thao tác tấn công XSS
5. Cách phòng chống XSS
Tấn công XSS chỉ thực hiện được khi người dùng nhận được trang web chứa
mã độc của attacker, mà việc gửi những trang web này là lổ hổng của các webserver.
Tuy vậy mục tiêu của XSS là tấn công vào người dùng “ngây thơ”, lợi dụng sự lơ là
của họ để tiêm mã độc gửi lên server, vì vậy cách phòng chống XSS sẽ là công việc từ
cả hai phía, người dùng và webserver.
5.1. Đối với người phát triển web
Lọc dữ liệu
Khi nhận dữ liệu từ người dùng ta phải thực hiện việc lọc dữ liệu này hay nói
cách khác là ta phải xác minh tính hợp lệ của dữ liệu. Dữ liệu không được chứa các ký
tự đặc biệt, không được chứa các đoạn script… Tuy nhiên việc xác minh tính hợp lệ
của dữ liệu một cách liên tục sẽ ảnh hưởng đến hiệu năng của hệ thống. Thêm vào đó
các attacker có thể vượt qua bước này bằng cách mã hóa lại các script nhập vào (lưu ý
rằng phần dữ liệu này sẽ được đưa vào trang HTML bên máy người dùng nên việc mã
hóa chỉ cần sao cho trình duyệt của người dùng vẫn có thể hiểu được).
9
Mã hóa dữ liệu
Đây cũng có thể coi là một cách loại bỏ những ký tự đặc biệt, không hợp lệ.
Thông thường việc mã hóa dữ liệu sẽ là mã hóa dưới dạng các mã HTML cho các ký
tự đặc biệt. Các mã này giúp trình duyệt khi dịch trang HTML sẽ hiểu và hiển thị
chúng chứ không coi chúng như một tag của mình và thực thi chúng. Tuy nhiên việc
mã hóa dữ liệu liên tục và có khối lượng lớn cũng ảnh hưởng đến hiệu năng của hệ
thống. Do đó ta cần phải lưu ý vấn đề này để đưa ra được phương án mã hóa hợp lý.
5.2. Đối với người dùng
Cảnh giác đối với các đường link lạ
Như đã trình bày ở trên, cách tấn công thường gặp là attacker gửi cho người
dùng URL có chứa mã độc (reflected xss) và người dùng không để ý mà click vào. Do
đó người dùng cần cảnh giác với những URL lạ, nhất là những URL quá dài và có
những dấu hiệu của các thẻ HTML. Người dùng cần để ý những URL quan trọng liên
quan đến thông tin nhạy cảm của mình để tránh nhầm lẫn giữa URL bình thường và
URL đã bị tiêm mã độc.
Ngăn chặn việc chạy mã độc
Trong thực tế nhiều trường hợp mã độc không ẩn giấu dưới dạng URL mà được
tiêm trực tiếp vào nội dung mà người dùng nhận được (tiêm và các thẻ HTML của
email chẳng hạn), do đó người dùng cần cài đặt các chế độ ngăn chặn việc chạy các
mã độc trên hệ thống của mình (trình duyệt web hoặc phần mềm check email) để đảm
bảo không có đoạn mã được thực thi nằm ngoài kiểm soát của bản thân.
Kết luận :
XSS là một kỹ thuật tấn công nguy hiểm và ta không lường trước được những
gì mà XSS có thể làm được. Đây là kỹ thuật tấn công nhắm vào người dùng và gây
nguy hại trực tiếp đến người dùng. Tuy nhiên khi chúng ta hiểu kỹ về nó thì chúng ta
hoàn toàn có thể tránh được việc gặp phải những lỗi tấn công XSS và người dùng hoàn
toàn có thể tự mình phòng tránh những lỗi này.
10
II. Kĩ Thuật Tấn Công SQL Injection
1.Khái niệm
Sql Injection (SQLi) là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ
hổng của việc kiểm tra dữ liệu đầu vào 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 trả về để inject (tiêm vào) và thi hành các câu lệnh SQL
bất hợp pháp, Sql Injection có thể cho phép những kẻ tấn công thực hiện các thao tác,
thêm, sửa, xóa,… trên cơ sở dữ liệu của ứng dụng. 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…
2.Hướng khai thác
2.1 Thông qua “user input”
User input điển hình thường đến từ các form nhập liệu, form search hay link…
Những dữ liệu này được web browser gửi đến server thông qua phương thức HTTP
GET hay POST và trở thành các tham số cho ứng dụng web truy cập tới cơ sở dữ liệu.
Ví dụ như trong một form search, khi người dùng điền vào “Sql Injection”, đơn giản
ứng dựng web sẽ truy cập cơ sở dữ liệu và tìm ra các bản ghi mà nội dung của nó chứa
từ khóa “Sql Injection” để trả lại kết quả cho người dùng.
2.2 Thông qua Cookies
Cookies là những tệp tin lưu trữ thông tin trạng thái của người dùng khi truy cập
các ứng dụng web. Những thông tin này do người lập trình quyết định, được tạo ra ở
server và lưu trữ tại client. Khi người dùng truy cập lại ứng dụng web, cookies được
browser gửi lên server giúp phục hồi lại những trạng thái của người dùng trong lần
truy cập trước đó. Ở một số ứng dụng web thương mại, cookies còn được lưu trữ
11
những sở thích của người dùng, khi đó ứng dụng web sẽ sử dụng cookies để đưa ra
những gợi ý tốt nhất cho người dùng khi mua sản phẩm. Do được lưu trữ ở client nên
người dùng có thể chỉnh sửa tùy ý, vì vậy nếu ứng dụng web sử dụng những thông tin
lưu trong cookies để xây dựng các truy vấn tới cơ sở dữ liệu thì hacker hoàn toàn có
thể chèn vào cookies những script sql để thực hiện một cuộc tấn công Sql Injection.
2.3 Thông qua các biến server
Biến server có thể là một khái niệm tương đối lạ lẫm nhưng nó không hề mới.
Một số ví dụ của biến server là Http header, Network header… Không phổ biến lắm
nhưng các giá trị được lưu trong biến server có thể được ứng dụng web sử dụng như
trong việc logging truy cập hay thống kê truy cập theo user agent… Những công việc
này đều có sự tương tác với cơ sở dữ liệu nên các hacker hoàn toàn có thể sử dụng các
biến server trong việc khai thác Sql Injection
12
2.4 Second-order Injection
Đây là kỹ thuật ít được sử dụng vì rất khó để nhận biết một ứng dụng web có bị
mặc lỗi này hay không. Kỹ thuật này được mô tả như sau : Trước hết, hacker “inject”
vào cơ sở dữ liệu một đoạn mã. Đoạn mã này chưa hề gây nguy hiểm cho hệ thống
nhưng nó sẽ được sử dụng làm bàn đạp cho lần inject tiếp theo của hacker. Chúng ta
hãy xem một ví dụ cụ thể để hiểu hơn về kỹ thuật này.
Một hacker truy cập vào một ứng dụng web và cố gắng đăng ký một tài khoản có
username là “administrator’ ”. Sau đó hacker này thực hiện thao tác thay đổi mật
khẩu. Thao tác thay đổi mật khẩu được ứng dựng web xử lý như sau :
Với username đăng ký như trên, câu truy vấn sẽ trở thành
Như vậy, hacker đã thay đổi được password của tài khoản administrator và hoàn toàn
có thể đăng nhập dưới tên tài khoản administrator.
3. Các kỹ thuật khai thác
3.1 Union Query Based
Đây là phương pháp phổ biến khi khai thác Sql Injection. Cơ sở của nó là sử dụng
từ khóa union để gộp các kết quả của các mệnh đề select, qua đó lấy được thông tin từ
cơ sở dữ liệu.
13
3.2 Batched Query
Đây là phương pháp áp dụng khả năng thực thi cùng lúc nhiều câu lệnh Sql của
một số hệ quản trị cơ sở dữ liệu và khả năng hỗ trợ của ngôn ngữ lập trình. Phương
pháp này rất mạnh mẽ và gây nguy hiểm ngay với hệ thống. Bằng cách thêm vào một
dòng lệnh Update, Insert hay Delete, dữ liệu trong cơ sở dữ liệu của ứng dụng web
không còn toàn vẹn nữa.
3.3 Order by clause
Không giống như các phương pháp trên, nội dung inject nằm trong mệnh đề điều
kiện where. Trong phương pháp này, chúng ta sẽ cố gắng tiêm mã script vào mệnh đề
order. Chúng ta hãy xem đến một kịch bản sau:
Người lập trình muốn liệt kế sản phẩm của công ty bao gồm các thông tin : Mã sản
phẩm, Tên sản phầm, Ngày tháng… và có chức năng cho pháp người dùng tủy chỉnh
xem họ muốn sắp xếp theo thứ tự ngày tháng, theo tên hay mã của sản phẩm.
Câu truy vấn được xây dựng như sau :
14
Trong trường hợp này chúng ta không thể thêm trực tiếp một mệnh đề sub select thông
qua từ khóa union như mọi khi được. Một cách khai thác đó là sử dụng BATCHED
QUERY hoặc có thể tham khảo cách sau
Trong phương pháp trên, chúng ta đã inject được một sub select nhưng rõ ràng cách
thực hiện này giờ đây phải kết hợp cả với kỹ thuật BOOLEAN BASED BLIND SQLI.
4. Các bước khai thác thông tin
4.1. Phát hiện
Một cách thông thường, để phát hiện một ứng dụng web có dính lỗi Sql Injection
hay không là thêm vào câu truy vấn các meta character trong các hệ quản trị cơ sở dữ
liệu, chẳng hạn như dấu nháy đơn (single quote), dấu nháy kép (double quote), dấu
chấm phẩy (semi colon) và các ký tự comment ( , ##, /**/)… và chờ xem ứng dụng
web sẽ xứ lý câu truy vấn đó như thế nào.
Ví dụ khi muốn xem item có id=2 ta request tới liên kết http://site/item.php?id=2. Để
xem liên kết này có dính lỗi Sql Injection hay không ta thêm vào cuối liên kết một
15
trong các meta character đã nói ở trên, chẳng hạn ta thêm vào dấu nháy đơn
http://site/item.php?id=2’. Nếu như ứng dụng web vẫn trả về cho chúng ta nội dung
của item có id=2 hoặc đưa ra một thông báo về việc không tìm được item hoặc đưa
chúng ta tới một trang khác (một trang thông báo lỗi mặc định hay trang chủ chẳng
hạn), như vậy ta có thể kết luận rằng ứng dụng đã xứ lý tốt tham số đầu vào trước khi
thao tác cơ sở dữ liệu. Ngược lại, nếu thấy xuất hiện một thông báo lỗi (exception) từ
mysql, mssql… thì ứng dụng web đã dính lỗi Sql Injection.
4.2 Thu thập thông tin về hệ quản trị cơ sở dữ liệu
Khi phát hiện ứng dụng bị dính lỗi Sql Injection, công việc cần làm tiếp theo là
thu thập thông tin về hệ quản trị cơ sở dữ liệu mà ứng dụng đang dùng, thông tin này
bao gồm loại cơ sở dữ liệu (mysql, mssql, oracle…) và phiên bản của nó. Tùy vào ứng
dụng sử dụng phiên bản hay loại hệ quản trị sơ sở dữ liệu nào mà chúng ta có những
kỹ thuật khai thác khác nhau. Một ví dụ đơn giản cho thấy sự khác nhau giữa các loại
hệ quản trị cơ sở dữ liệu đó là, trong khi mssql sử dụng ký tự comment là ‘ ’ thì
mysql lại sử dụng ‘##’…
Để xác định hệ loại quản trị mà ứng dụng đang sử dụng, chúng ta có thể đánh giá theo
nhiều tiêu chí. Có thể đánh giá qua thông báo lỗi :
4.3. Xác định số lượng cột trong mệnh đề Select
Khi khai thác Sql Injection, chúng ta thường sử dụng một hay nhiều mệnh đề
select phụ (subselect), điều này được thực hiện thông qua từ khóa union. Union là từ
khóa dùng để gộp kết quả của nhiều mệnh đề select do đó trong mỗi mệnh đề select
đòi hỏi số lượng các trường đều phải bằng nhau và đều bằng số lượng các trường được
select trong mệnh đề select ban đầu. Xét một ví dụ cụ thể :
16
Ở đây, trong mệnh đề select ban đầu chọn ra 3 trường là id, content và author. Do đó
mệnh đề select sau từ khóa union cũng cần phải có đúng 3 trường. Nếu số trường
select ở mệnh đề select sau union không bằng số lượng các trường được select trong
mệnh đề select đầu tiên, chúng ta sẽ nhận được thông báo lỗi. Vậy làm sao để biết để
biết được chính xác mệnh đề select đầu tiền chọn ra bao nhiêu trường. Chúng ta có thể
thực hiện thử dần bằng cách tăng dần số lượng cột trong mệnh đề select sau union (bắt
đầu từ 1). Khi nào không thấy thông báo lỗi xuất hiện thì đó chính là số lượng cột cần
tìm.
Một cách khác để làm điều này, nhanh chóng hơn đó là sử dụng ‘order by’. Trong các
hệ quản trị cơ sở dữ liệu từ khóa ‘order by’ được sử dụng để sắp xếp thứ tự cho các
bản ghi thu được trong mệnh để select. Sau order by có thể là tên một cột để xác định
rằng kết quả thu về sẽ được sắp xếp theo giá trị của cột đó (có thể tăng dần hay giảm
dần). Sau order by cũng có thể là số thứ tự vị trí của cột đó. Nếu giá trị sau order lớn
hơn số cột được select thì chúng ta sẽ thấy thông báo lỗi.
4.4. Xác định thông tin
Để khai thác được Sql Injection, chúng ta cần biết một số thông tin về cơ sở dữ
liệu như tên bảng, tên cột, các kiểu dữ liệu của từng cột… Giai đoạn này đòi hỏi khá
nhiều thời gian.
17
Tên bảng và cột
Chúng ta có nhiều cách để làm được công việc này, một trong những cách đó là
“đoán” vì nó nhanh chóng và trong những trường hợp cụ thể, đây là cách rất hữu ích.
Ví dụ khi tên bảng là một tên quen thuộc như : user, users, admin, administrator, staff,
account… (chú ý tiền tố tbl_ rất hay được các lập trình viên sử dụng để đặt cho tên
bảng).
Ở đây chúng ta không quan trọng mệnh đề select phía sau trả giá trị là bao nhiêu bản
ghi. Cái mà ta quan tâm là ‘tablename’ có đúng là một tên bảng hay không. Cũng theo
cách này chúng ta cũng có thể đoán biết được tên cột, username hay password…
Một cách chính qui hơn để biết được tên bảng, tên cột là sử dụng đối tượng
information_schema. Đối tượng này cung cấp các thông tin về tables, columns, views
và procedures… của cơ sở dữ liệu. Để đọc được những thông tin chứa trong
information_schema chúng ta cũng cần một mệnh đề subselect :
Kiểu dữ liệu
Khi khai thác Sql Injection với hệ quản trị Microsoft SQL Server thường gặp phải
những bó buộc với kiểu dữ liệu của các trường. Trong các mệnh đề select trước và sau
union, kiểu dữ liệu của các trường tương ứng phải thống nhất với nhau.
18
5. Một số tools khai thác
Hiện nay đã có rất nhiều công cụ quét lỗ hổng bảo mật (bao gồm SQL Injection).
Những công cụ này chủ yếu cho công việc phát hiện và đánh giá mức độ nguy hiểm
của các loại lỗ hổng chứ chưa có khả năng khai thác được xem có thể làm được gì từ
lỗ hổng đó. Một số công cụ khai thác tự động hay được sử dụng đó là :
The Mole
Sqlmap
Havij
6. Cách phòng chống
Ngay từ khái niệm, chúng ta đã có thể biết được cách phòng chống hiệu quả Sql
Injection chính là việc kiểm tra kỹ càng tham số đầu vào. Những tham số mà từ đó
người lập trình website sử dụng để build lên câu truy vấn tới cơ sở dữ liệu.
Công việc kiểm tra tham số đầu vào (áp dụng phòng tránh lỗi Sql Injection) nên
được tiến hành theo nhiều tầng :
Client: javascript (có thể bypass bằng các phần mềm tamper)
Server: C#, PHP, JSP…
Kiểm tra kiểu của dữ liệu : đối với dữ liệu kiểu số, kiểu chuỗi … chúng ta phải có
những hàm validate tương ứng:
Nếu là kiểu int
ASP.NET: Int32.Parse(/*Param*/);
PHP: is_numeric($var), is_int($var), is_integer($var)
Nếu là kiểu chuỗi
Thiết lập độ dài cần thiết
Lọc bỏ các kí tự nguy hiểm
Kiểm tra định dạng chuỗi: email, username, password, website…
Sử dụng các thư viện hỗ trợ
Phân quyền SQL
19
7. Demo Tool
7.1. Kịch bản xâm nhập
Chúng ta sẽ xây dựng một web server đơn giản để hỗ trợ thực hiện kịch bản
kiểm thử. Tool do nhóm xây dựng sẽ có chức năng xâm nhập trái phép vào web server
qua trang Login. Sau đây là bảng chức thông tin user account trong Database và màn
hình login:
Bảng thông tin Account trong CSDL
Màn hình Login Page
20
7.2 Mô tả tool
Tool sẽ xâm nhập trang Login bằng cách lấy các biến trên server, các biến này sẽ
được phân tích trên trình duyệt Chrome. Bằng phương thức Get ta sẽ thấy khi gửi
request đăng nhập qua trang login sẽ có 4 biến server như sau: UserName, Password,
ControlName, Viewstate, EventValidation.
Bên trên là màn hình phân tích biến server bằng trình duyệt Chrome. Khi đã có đầy
đủ các biến server, chúng ta sẽ gửi các đoạn SQL vào 2 input là username và
password. Kết quả thu được là trang login bị vượt qua mà không cần quyền user.
8. Kết luận
SQL Injection luôn được đánh giá là một trong những lỗ hổng bảo mật web
nguy hiểm nhất trong nhiều năm qua. Do đó, đối với những người lập trình web cần
hiểu rõ nguyên nhân và cách khắc phục sao cho hiệu quả. Những người quản trị cần có
21
những cấu hình cần thiết để trách nguy cơ và giảm thiểu tác hại trong trường hợp ứng
dụng web có lỗi có thể khai thác SQL Injection.
Các kỹ thuật tấn công, bypass trên đây, tùy vào những trường hợp cụ thể mà có
những cách áp dụng khác nhau. Do tính chất đặc thù trong mỗi trường hợp như thế nên
bài viết không thể bao quát hết được tất cả các kỹ thuật. Với sự phát triển của các ứng
dụng firewall (WAF) có thể những cách bypass nêu trên sẽ không còn có thể áp dụng
được trong tương lai.
9. Tài liệu tham khảo
/> />http://diendancnt
22
