Với dạng tấn công này, tin tặc có thể vượt qua các trang đăng nhập, nhờ
vào lỗi khi dùng các câu lệnh SQL, thao tác trên CSDL của ứng dụng web. Xét ví dụ điển hình, thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống có trang đăng nhập để người dùng nhập tên đăng nhập và mật khẩu. Hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp. Có thể dùng hai trang, một trang HTML để hiển thị form nhập liệu và một trang ASP dùng
để xử lí thông tin nhập từ phía người dùng.
Ví dụ 11:
login.htm
<form action="execlogin.asp" method="post"> Username: <input type="text" name="fUSRNAME"> <br>
Password: <input type="password" name="fPASSWORD"> <br>
<input type="submit"> </form>
execlogin.asp
<% Dim vUsrName, vPassword, objRS, strSQL vUsrName = Request.Form("fUSRNAME") vPassword = Request.Form("fPASSWORD")
strSQL= "SELECT * FROM T_USERS WHERE USR_NAME=' " & vUsrName & " ' and USR_PASSWORD=' " & vPassword & " ' "
Set objRS = Server.CreateObject("ADODB.Recordset") objRS.Open strSQL, "DSN=..."
If (objRS.EOF) Then
Response.Write "Invalid login." Else
Response.Write "You are logged in as " & objRS("USR_NAME") End If
Đoạn mã “execlogin.asp” dường như không chứa một lỗ hổng về an toàn. Người dùng không thểđăng nhập mà không có tên đăng nhập và mật khẩu hợp lệ. Tuy nhiên, đoạn mã này thực sự không an toàn và là tiền đề cho một lỗi SQL injection. Sơ hở nằm ở dữ liệu nhập vào từ người dùng được dùng để xây dựng trực tiếp câu lệnh SQL. Chính điều này cho phép những kẻ tấn công có thểđiều khiển câu truy vấn sẽđược thực hiện.
Nếu người dùng nhập chuỗi sau vào trong cả 2 ô nhập liệu username và password của trang “login.htm” là: ' OR ' ' = ' '
Lúc này, câu truy vấn sẽđược gọi thực hiện là:
SELECT * FROM T_USERS WHERE USR_NAME ='' OR ''='' and USR_PASSWORD= '' OR ''=''
Câu truy vấn này là hợp lệ, và sẽ trả về tất cả các bản ghi của T_USERS, câu lệnh so sánh luôn luôn đúng (vì‘’luôn bằng‘’), nên câu điều kiện trong mệnh
đề WHERE luôn đúng, và thực hiện phép logic “OR” giữa giá trị bất kì với dữ
liệu trong T_USERS, giá trị tên người sử dụng của dòng đầu tiên trong bảng sẽ được chọn, xử lí người dùng đăng nhập bất hợp pháp này như là người dùng
2.3.2. Tấn công sử dụng câu lệnh SELECT
Dạng tấn công này phức tạp hơn. Để thực hiện được kiểu tấn công này, kẻ
tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ
hệ thống, để dò tìm các điểm yếu khởi đầu cho việc tấn công.
Xét ví dụ thường gặp trong các website về tin tức. Có một trang nhận ID của tin cần hiển thị, sau đó truy vấn nội dung của tin có ID này.
Ví dụ 12:
http://www.myhost.com/shownews.asp?ID=123
Mã nguồn cho chức năng này thường được viết theo dạng:
<%
Dim vNewsID, objRS, strSQL
vNewsID = Request("ID")
strSQL = "SELECT * FROM T_NEWS WHERE NEWS_ID =" & vNewsID&"
Set objRS = Server.CreateObject("ADODB.Recordset") objRS.Open strSQL, "DSN=..."
Set objRS = Nothing %>
Trong tình huống thông thường, đoạn mã này hiển thị nội dung của tin có ID trùng với ID đã chỉđịnh, và hầu như không thấy có lỗi. Tuy nhiên, giống như
ví dụ 11, đoạn mã này để lộ sơ hở cho một lỗi SQL injection khác. Kẻ tấn công có thể thay thế ID hợp lệ bằng cách gán ID cho một giá trị khác, và khởi đầu cho cuộc tấn công bất hợp pháp.
Ví dụ 13:
0 OR 1=1(nghĩa là, http://www.myhost.com/shownews.asp?ID=0 or 1=1).
Câu truy vấn SQL lúc này sẽ trả về tất cả các article từ bảng dữ liệu vì nó sẽ thực hiện câu lệnh:
SELECT * FROM T_NEWS WHERE NEWS_ID=0 or 1=1
Ví dụ về trang tìm kiếm. Trang này cho phép người dùng nhập vào các thông tin tìm kiếm như Họ, Tên, … Đoạn mã thường gặp là:
<% Dim vAuthorName, objRS, strSQL
vAuthorName = Request("fAUTHOR_NAME")
strSQL="SELECT * FROM T_AUTHORS
WHERE AUTHOR_NAME =' " vAuthorName & " ' "
Set objRS = Server.CreateObject("ADODB.Recordset") objRS.Open strSQL, "DSN=..."
…
Set objRS = Nothing %>
Tương tự như trên, tin tặc có thể lợi dụng sơ hở trong câu truy vấn SQL
để nhập vào trường tên tác giả bằng chuỗi giá trị:
' UNION SELECT ALL SELECT OtherField FROM OtherTable WHERE ' '='
Lúc này, ngoài câu truy vấn đầu thành công, chương trình sẽ thực hiện thêm lệnh tiếp theo sau từ khóa UNION nữa.
Có thắc mắc là làm thế nào có thể biết được tên của bảng dữ liệu để thực hiện các thao tác phá hoại khi ứng dụng web bị lỗi SQL injection. Đơn giản vì trong SQL Server, có hai đối tượng là sysobjects và syscolumns cho phép liệt kê tất cả các tên bảng và cột có trong hệ thống.
Ta chỉ cần chỉnh lại câu lệnh SELECT:
' UNION SELECT name FROM sysobjects WHERE xtype = 'U'
2.3.3. Tấn công sử dụng câu lệnh INSERT
Thông thường các ứng dụng web cho phép người dùng đăng kí một tài khoản để tham gia. Sau khi đăng kí thành công, người dùng có thể xem và hiệu chỉnh thông tin của mình. SQL injection có thể được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào.
Ví dụ 14: câu lệnh INSERT có cú pháp dạng:
INSERT INTO TableName VALUES('Value One',
'Value Two', 'Value Three').
Nếu đoạn mã xây dựng câu lệnh SQL có dạng:
<% strSQL = "INSERT INTO TableName VALUES(' " & strValueOne & " ', ' " & strValueTwo & " ', ' " & strValueThree & " ') "
Set objRS = Server.CreateObject("ADODB.Recordset") objRS.Open strSQL, "DSN=..."
…
Set objRS = Nothing %>
thì chắc chắn sẽ bị lỗi SQL injection, khi ta nhập:
' + (SELECT TOP 1 FieldName FROM TableName) + '
Lúc này câu truy vấn sẽ là:
INSERT INTO TableName
VALUES(' ' + (SELECT TOP 1 FieldName FROM TableName) + ' ', 'abc', 'def')
Khi đó, lúc thực hiện lệnh xem thông tin, thì xem nhưđã yêu cầu thực hiện thêm một lệnh nữa, đó là:
SELECT TOP 1
2.3.4. Dạng tấn công sử dụng Stored-Procedures
“Stored Procedure” được dùng trong lập trình Web với mục đích giảm sự
phức tạp trong ứng dụng và tránh bị tấn công bằng kĩ thuật SQL Injection. Tuy nhiên hacker vẫn có thể lợi dụng “Stored Procedure” để tấn công vào hệ thống.
Việc tấn công bằng “stored-procedures” sẽ gây tác hại lớn, nếu ứng dụng
được thực thi với quyền quản trị hệ thống 'sa'.
Ví dụ 15: nếu ta thay đoạn mã dạng:
'; EXEC xp_cmdshell ‘cmd.exe dir C:'.
Hệ thống sẽ thực hiện lệnh liệt kê thư mục trên ổ đĩa C:\ cài đặt server. Việc phá hoại kiểu nào tuỳ thuộc vào câu lệnh đằng sau cmd.exe.
Ví dụ 16:
Stored procedure sp_login gồm hai tham số là username và password. Nếu nhập:
Username: nhimmap
Password: ‘;shutdown--
Lệnh gọi stored procedure như sau:
exec sp_login ‘nhimmap’,‘’;shutdown--’
Dấu chấm phẩy (;) kết thúc truy vấn SQL và cho phép thi hành lệnh SQL mới. Lúc này, “Shutdown” không còn là password, nó trở thành lệnh thực thi dừng SQL, dấu “--” thông báo không làm gì tiếp theo.
2.3.5. Biện pháp phòng tránh:
Lỗi SQL injection khai thác những bất cẩn của lập trình viên phát triển
ứng dụng web, khi xử lí các dữ liệu nhập vào để xây dựng câu lệnh SQL. Tác
hại từ lỗi SQL injection tùy thuộc vào môi trường và cách cấu hình hệ thống.
Nếu ứng dụng sử dụng quyền “dbo” (quyền của người sở hữu CSDL) khi thao tác dữ liệu, nó có thể xóa toàn bộ các bảng dữ liệu, tạo các bảng dữ liệu mới, … Nếu ứng dụng sử dụng quyền “sa” nó có thểđiều khiển toàn bộ hệ quản trị CSDL, và với quyền hạn rộng như vậy, nó có thể tạo ra các tài khoản người dùng bất hợp pháp đểđiều khiển hệ thống.
Để phòng tránh, ta có thể thực hiện ở hai mức:
1/ Kiểm soát chặt chẽ dữ liệu nhập vào
Để phòng tránh các nguy cơ có thể xảy ra, hãy bảo vệ các câu lệnh SQL bằng cách kiểm soát chặt chẽ tất cả các dữ liệu nhập nhận được từ đối tượng Request (Request, Request.QueryString, Request.Form, Request.Cookies, and Request.ServerVariables).
Ví dụ 17:
có thể giới hạn chiều dài của chuỗi nhập liệu, hoặc xây dựng hàm EscapeQuotes để thay thế các dấu nháy đơn bằng 2 dấu nháy đơn
<% Function EscapeQuotes(sInput) sInput = replace(sInput, " ' ", " ' ' ") EscapeQuotes = sInput End Function %>
Trong trường hợp dữ liệu nhập vào là số, lỗi xuất phát từ việc thay thế
một giá trị được tiên đoán là dữ liệu số bằng chuỗi chứa câu lệnh SQL bất hợp pháp. Để tránh điều này, đơn giản hãy kiểm tra dữ liệu có đúng kiểu hay không bằng hàm IsNumeric().
Ngoài ra có thể xây dựng hàm loại bỏ một số kí tự và từ khóa nguy hiểm như:
;, --, select, insert,xp_, …
ra khỏi chuỗi dữ liệu nhập từ phía người dùng để hạn chế các tấn công dạng này:
<%
Function KillChars(sInput) dim badChars
dim newChars
badChars = array("select", "drop", ";", "--", "insert", "delete", "xp_") newChars = strInput
for i = 0 to uBound(badChars)
newChars = replace(newChars, badChars(i), "") next
KillChars = newChars End Function
%>
2/ Thiết lập cấu hình an toàn cho hệ quản trị CSDL
Cần có cơ chế kiểm soát chặt chẽ và giới hạn quyền xử lí dữ liệu đến tài khoản người dùng mà ứng dụng web đang sử dụng. Các ứng dụng thông thường nên tránh dùng đến các quyền như dbo hay sa. Quyền càng bị hạn chế, thiệt hại càng ít. Ngoài ra để tránh các nguy cơ từ SQL Injection attack, nên chú ý loại bỏ
bất kì thông tin kĩ thuật nào chứa trong thông điệp chuyển xuống cho người dùng khi ứng dụng có lỗi. Các thông báo lỗi thông thường tiết lộ các chi tiết kĩ
2.4. TẤN CÔNG DỰA VÀO “KIỂU QUẢN LÝ PHIÊN LÀM VIỆC” (SessionID Management) (SessionID Management)
HTTP là giao thức hướng đối tượng tổng quát, phi trạng thái, nghĩa là HTTP không lưu trữ trạng thái làm việc giữa trình duyệt với trình chủ. Thiếu sót này gây khó khăn cho một số ứng dụng Web, bởi vì trình chủ không biết được trước đó trình duyệt đã có những trạng thái nào. Vì thế, để
giải quyết vấn đề này, ứng dụng Web đưa ra một khái niệm phiên làm việc (Session). Còn SessionID là một chuỗi để chứng thực phiên làm việc. Một số
trình chủ sẽ cung cấp một SessionID cho người dùng khi họ xem trang web trên trình chủ.
Để duy trì phiên làm việc thì sessionID thường được lưu vào :
9 Biến trên URL
9 Trường ẩn form
9 Cookie
Phiên làm việc chỉ tồn tại trong khoảng thời gian cho phép, thời gian này
được cấu hình qui định tại trình chủ hoặc bởi ứng dụng thực thi. Trình chủ sẽ tự động giải phóng phiên làm việc để khôi phục lại tài nguyên của hệ thống.
Sau khi người dùng được xác thực dựa trên thông tin cá nhân như
tên/mật khẩu, session ID được xem như mật khẩu tĩnh tạm thời cho những lần yêu cầu tiếp theo. Điều này đã khiến cho Session ID là mục tiêu lớn cho những hacker. Nhiều trường hợp, hacker giành được session ID hợp lệ của người dùng, để từđó đột nhập vào phiên làm việc của họ.
Tấn công vào một phiên làm việc thường được thực hiện theo 2 kiểu chính sau:
+ Ấn định phiên làm việc (Session Fixation).
2.4.1. Tấn công kiểu “Ấn định phiên làm việc”
Trong kiểu tấn công “ấn định phiên làm việc”, hacker ấn định sẵn session ID cho nạn nhân, trước khi họđăng nhập vào hệ thống. Sau đó, hacker sử dụng session ID này để buớc vào phiên làm việc của nạn nhân đó.
Quá trình tấn công như sau:
Bước 1: Thiết lập session ID.
Hệ thống quản lí session theo 2 hướng:
+ Hướng tự do: chấp nhận bất kì một session ID, nếu chưa tồn tại session thì tạo mới một session ID.
+ Hướng giới hạn: chỉ chấp nhận session ID nào đã đăng kí trước đó. Với hệ thống hướng tự do, hacker chỉ cần thiết lập một session ID bất kì, nhớ và sau đó sử dụng lại session ID này. Ở hướng giới hạn, hacker phải đăng kí một session ID với ứng dụng.
Phụ thuộc vào qui trình quản lí phiên làm việc, hacker lưu trữ “thời gian sống” (Time To Live) của phiên làm việc cho đến khi nạn nhân đăng nhập vào hệ thống. Thông thường một phiên làm việc không tồn tại vô hạn. Hệ thống sẽ
tự động hủy bỏ phiên làm việc, nếu nó không thực hiện một thao tác nào (thời gian nhàn rỗi) hoặc hết hạn định.
Bước 2: Gửi ID này đến trình duyệt nạn nhân.
Hacker gửi session ID vừa tạo đến người dùng, việc trao đổi ID session còn tùy vào ứng dụng, có thể qua parameter URL, trường ẩn form hay cookie.
Các cách tấn công thông dụng gồm có:
1 Tấn công sessionID trên tham số URL (SessionID parameter URL). 2 Tấn công sessionID trên trường ẩn form (SessionID hidden Form Field). 3 Tấn công sessionID trong cookie.
a/ Tấn công sessionID trên tham số URL (SessionID parameter URL) Hacker gửi một liên kết yêu cầu người dùng đăng nhập vào hệ thống máy đích với sessionID đã được ấn định sẵn trên URL.
1) Hacker mở dịch vụ trực tuyến của ngân hàng thông qua địa chỉ
online.worldbank.com
2) Nhận được một session ID từ trình chủ, để xác định phiên làm việc của hacker. Ví dụ session ID có giá trị là 1234.
3) Hacker tìm cách gửi liên kết đến một người dùng nào đó, có tài khoản trong ngân hàng này. Liên kết đó thường dẫn đến trang đăng nhập vào tài khoản trong ngân hàng ví dụ liên kết là
http://online.workbank.com/login.jsp?sessionid=1234. Người dùng có thể bị lừa làm việc trong phiên làm việc của hacker, khi người dùng nhận được liên kết này.
4) Người dùng bị mắc lừa và mở ứng dụng Web tói ngân hàng bằng liên kết của hacker. Do đã có session ID=1234 (của hacker), nên trình chủ không tạo session ID mới.
5) Người dùng tiếp tục đăng nhập với thông tin của mình để quản lí tài khoản trong ngân hàng
6) Khi đó hacker vào tài khoản của người dùng mà không cần phải đăng nhập vì có cùng phiên làm việc.
b/ Tấn công Session ID trong biến ẩn Form
Cách tấn công này tương tự như “Thao tác trên trường ẩn Form”
(phần 2.1.2), sau khi hacker xem mã HTML của trang Web, nhận thấy session ID được đặt trong biến ẩn form, hacker sẽ gửi một sessionID cũng trên URL đến người dùng hoặc một trang Web giống trang đích nhưng với biến
c/ Tấn công Session ID trong cookie
Lợi dụng cookie, hacker có hai cách để đưa một session ID đến trình duyệt của nạn nhân:
1). Thiết lập một cookie trên trình duyệt bằng ngôn ngữ kịch bản:
Hầu hết trình duyệt đều hỗ trợ các ngôn ngữ kịch bản thực thi trên trình duyệt như Javascript, VBScript. Cả hai ngôn ngữ này có thể thiết lập một cookie cho trình duyệt bằng cách thiết lập giá trị “ document.cookie”.
Ví dụ 19:
http://online.workbank.com/<script>document.cookie=“sessionid=1234; domain= .workbank.com”;</script>
Bên cạnh đó, hacker có thể thiết lập thời gian sống cho cookie, domain cookie…và cách này phù hợp với những hệ thống hướng “tự do”. Ví dụ domain nào thuộc.workbank.com đều có thểđọc được giá trị cookie này.
2). Dùng thẻ <META> với thuộc tính Set-Cookie:
Ứng dụng cũng có thể thiết lập cookie cho trình duyệt bằng thẻ <META> trong HTML.
Ví dụ 20: < meta http-equiv= Set-Cookie content=”sessionid=1234”>
Bước 3: Đột nhập vào phiên làm việc của nạn nhân.
Sau khi nạn nhân đăng nhập vào hệ thống qua session ID đã được chỉ định sẵn và chưa thoát khỏi ứng dụng, hacker dùng session ID đó để bước vào phiên làm việc của nạn nhân.
2.4.2.Tấn công kiểu “Đánh cắp phiên làm việc”
Khác với kiểu tấn công ấn định phiên làm việc, hacker đánh cắp một session ID của người dùng khi họ đang trong phiên làm việc của mình. Và để có thể đánh cắp session ID của người dùng, hacker có thể dùng những phương pháp sau:
1 Dựđoán phiên làm việc 2 Vét cạn phiên làm việc.
3 Dùng đoạn mã đánh cắp phiên làm việc
a.) Tấn công kiểu dựđoán phiên làm việc (Prediction sessionID)
Hacker phải là người dùng hợp lệ của hệ thống, sau vài lần đăng nhập vào hệ thống, hacker xem xét các giá trị session ID nhận được, tìm ra qui luật phát sinh và từ đó có thể đoán được giá trị của một phiên làm việc của người dùng kế tiếp.
b). Tấn công kiểu vét cạn phiên làm việc (Brute force ID)
