Chương 7: Chiếm hữu phiên làm việc (Session Management)…………………………
I. TỔNG QUAN VỀ SESSION ID……………………………………………………..
II. ẤN ĐỊNH PHIÊN LÀM VIỆC……………………………………………………...
II.1. Tấn công Session ID trên tham số URL…………………………………………
II.2. Tấn công Session ID trong biến ẩn form………………………………………...
II.3. Tấn công Session ID trong cookie……………………………………………….
II.4. Cách phòng chống……………………………………………………………….
III. ĐÁNH CẮP PHIÊN LÀM VIỆC…………………………………………………..
III.1. Tấn công kiểu dự đoán phiên làm việc (Prediction sessionID)…………………
III.2. Tấn công kiểu vét cạn phiên làm việc (Brute force ID)………………………...
III.3. Tấn công kiểu dùng đoạn mã để đánh cấp phiên làm việc……………………...
III.4. Cách phòng chống……………………………………………………………….
III.5. Sự khác biệt giữa đánh cắp phiên làm việc (session hijacking) và ấn định phiên
làm việc (session fixation)……………………………………………………………...

 

Các bạn cho mình hỏi. Đọc tài liện luận văn tốt nghiệp "Nghiên Cứu Một Số Vấn Đề Về Bảo Mật Ứng Dụng Web Trên Internet" của sinh viên trương ĐH Khoa Học Tự Nhiên nói về Chương 7

Chương 7: Chiếm hữu phiên làm việc (Session Management)…………………………
I. TỔNG QUAN VỀ SESSION ID……………………………………………………..
II. ẤN ĐỊNH PHIÊN LÀM VIỆC……………………………………………………...
II.1. Tấn công Session ID trên tham số URL…………………………………………
II.2. Tấn công Session ID trong biến ẩn form………………………………………...
II.3. Tấn công Session ID trong cookie……………………………………………….
II.4. Cách phòng chống……………………………………………………………….
III. ĐÁNH CẮP PHIÊN LÀM VIỆC…………………………………………………..
III.1. Tấn công kiểu dự đoán phiên làm việc (Prediction sessionID)…………………
III.2. Tấn công kiểu vét cạn phiên làm việc (Brute force ID)………………………...
III.3. Tấn công kiểu dùng đoạn mã để đánh cấp phiên làm việc……………………...
III.4. Cách phòng chống……………………………………………………………….
III.5. Sự khác biệt giữa đánh cắp phiên làm việc (session hijacking) và ấn định phiên
làm việc (session fixation)……………………………………………………………...

 

Cho mình hỏi là nếu phân chia ra như vậy thì có hợp lý và thiếu sót phần nào nữa ko?
 

Ví dụ CSRFcó thể được thêm vào đây hay ko?
 

Về Ấn Định Phiên Làm Việc mình có thắc mắc là trong thực tế có website nào thiết kế kiểu như vậy ko?
Nghĩa là: Hacker send 1 url chứa session được ấn định sẵn cho victim. Victim chạy URL đó và đăng nhập vào hệ thống.
Hacker sẽ vào được phiên làm việc đó với sesssion đã được ấn định.

Thanks 

Về Ấn Định Phiên Làm Việc mình có thắc mắc là trong thực tế có website nào thiết kế kiểu như vậy ko?
Nghĩa là: Hacker send 1 url chứa session được ấn định sẵn cho victim. Victim chạy URL đó và đăng nhập vào hệ thống.
Hacker sẽ vào được phiên làm việc đó với sesssion đã được ấn định.
 

CSRF có lẽ không thể thêm vào đây được. EM thấy trong forum dịch là "Mượn Đao giết người" và nó không liên quan đến SESSION.
Nhưng em vẫn chưa rõ phần

Về Ấn Định Phiên Làm Việc mình có thắc mắc là trong thực tế có website nào thiết kế kiểu như vậy ko?
Nghĩa là: Hacker send 1 url chứa session được ấn định sẵn cho victim. Victim chạy URL đó và đăng nhập vào hệ thống.
Hacker sẽ vào được phiên làm việc đó với sesssion đã được ấn định.
 

Trong báo cáo của họ nói có mô hình " Mô tả chi tiết quá trình thực hiện tấn công người dùng
bằng kĩ thuật ấn định phiên làm việc." như sau
http://img248.imageshack.us/my.php?image=demonp9.jpg
Và em thắc mắc về phần Tấn công Session ID trên tham số URL
http://img134.imageshack.us/my.php?image=demo1lq4.jpg
Sao em thấy nó không hề thực tế tí nào. Vì thường em thấy chỉ lúc chứng thực thành công mới tạo session mà thôi. Còn đằng này lại ấn định trước thì chưa hề thấy bào giờ. Vậy thực tế có trường hợp nào như trường hợp này không vậy, hay chỉ là trên lý thuyết mà thôi.
Bác conmale nói không đơn giản và không tổng quát hóa như thế được thì phải chi tiết chút như thế nào nhỉ. Có thể gơi ý thêm tý nữa không?
Còn đây là toàn bộ tài liệu:
http://www.ebook.edu.vn/?page=1.1&view=3966
Thanks

 

Tóm tắt quá trình hack athena.com.vn
(Local attack)

Bỏ qua mấy giai đoạn lặt vặt bây giờ làm việc với trường hợp đã có sẵn con webshell //http://12a6dh.info/forum/cache/skin_cache/cacheid_2/skin_public.php

Chạy con backdoor trên kết nối vào mysql của 12a6 sau đó tiến hành lấy sources của athena. Trong trường hợp này xác định link của trang quản trị là /admin nên chỉ chú trọng vào việc lấy code của các file liên quan đến cái này thui (khi nào có con backdoor trên host của nó rùi lấy tiếp). Lấy code bằng mấy câu query sau:

CREATE TABLE test(text LONGTEXT);

load data local infile 'path/file' into table test FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\'' LINES TERMINATED BY '\n';

Có code rùi thì ngồi đọc nó, trước hết là thằng index.php

session_start(); // quản lý bằng session chứ ko phải bằng cookie, có nghĩa là khi ta vào link admin nó sẽ tạo cho ta một phiên làm việc, phiên làm việc này sẽ được server tạo ra và lưu vào file sess_...... (VD: sess_2d193503319fefd5a48b208d48b69d36) nằm trên server, mặc định của phiên làm việc này là ko hợp lệ nhưng nếu ta đăng nhập thành công thì server sẽ chỉnh sửa file sess_ kia thành hợp lệ (hack được athena phải cảm ơn thằng này nhiều ). Tiếp tục nào case 'login' : include "_login.php"; break; thằng index sơ sơ như vậy là được rùi bây giờ chuyển sang thằng _login.php

if (isset($_POST['txtUsername'])) $admin_user=$_POST['txtUsername']; else $admin_user='';
if (isset($_POST['txtPassword'])) $admin_pass=$_POST['txtPassword']; else $admin_pass='';
if (isset($_POST['txtPassSec'])) $admin_sec=$_POST['txtPassSec']; else $admin_sec='';

hô hô user, pass1, pass2.

$admin_sec = md5(base64_encode($admin_sec));

if ($admin_sec == "53f8797e875fb1b667c86e4ae15cee24") {
if ( (!empty($admin_user)) && (!empty($admin_pass)) )
{
$admin_pass = md5($admin_pass);
$query = "select * from admin WHERE username='$admin_user' AND password='$admin_pass'";

ặc ặc cái pass2 của nó vừa base64_encode vừa md5, nó mà đặt pass dài xíu là ngồi decode đù người luôn mà chưa chắc gì có kết quả, còn cái pass1 cũng bị md5 luôn.

Có 2 cách giải quyết được đặt ra, thứ nhất là dò 2 cái pass của nó, thứ 2 là fake cookie. Cách thứ nhất ko chơi, ngu gì mà ngồi dò pass trong khi cách thứ 2 có vẻ dễ ăn hơn và khả năng thành công cũng cao hơn. Hồi nãy coi file index thấy nó quản lý phiên làm việc bằng session coi bộ ngon ăn. Vậy là quyết định chọn cách 2.

Có 2 hướng giải quyết cho cách 2:
+ Thứ nhất là khi ta mở trang index.php ra nó sẽ tạo cho ta một session trên server, công việc của ta là tìm cách edit cái phiên làm việc sao cho nó trở thành hợp lệ. Coi cái phpinfo() của nó xem nào session.save_path=/tmp. Ok rùi mở cái thư mục /tmp coi thử có gì trong đó. Ặc ặc …. bị access denied rùi coi bộ hướng đi này ko ổn, chuyển hướng đi thui.
+ Thứ hai nếu ta edit cái file session ko được thì tại sao ta ko tạo ra một cái file session mới hợp lệ với cái source đã có kia rùi fake cookie của web browser với cái session mới đó. Vậy là đã xác định được chính xác hướng đi và những cái cần phải làm, công việc tiếp theo là up sources của athena lên host 12a6, edit lại cái pass2 trong file _login.php, edit cái pass1 trong db của nó, xong rùi login nào … vừng ơi mở ra…. bùm vào được admin control panel rùi (cái này là đồ giả nằm trên host của 12a6) vào phần quản lý cookie của web browsers (opera) coi thử cái session của nó là gì nào, copy nó lại bây giờ chuyển qua thằng athena fake bằng cái session đó, refresh lại nào …. bùm …. he he heeeeee vào được admin control panel của athena rùi (hàng thật chất lượng cao ), tìm chỗ up con shell…..


GAME OVER

Author: longnhi(HCE)  

@phitiger: ấn định phiên làm việc có phải là "session fixation" ko nhi? Bồ google keyword đó thử coi đúng yêu cầu ko. Bồ cho tui cái list tất cả các chương của luận án tốt nghiệp đó thử (ngày xưa tui cũng học trường này và cũng làm về đề tài này ) 

<?php
session_start();
$_SESSION['user']=$_GET['uid'];
?> 

Vấn đề cần phải phân biệt :

SessionID là 1 chuỗi NGẪU NHIÊN được sinh ra bởi WEBSERVER chứ không phải là 1 giá trị nào đó mà ứng dụng web có thể quyết định. Vì vậy, mỗi lần user đăng nhập (hoặc bắt đầu từ 1 hành động nào đó khiến cho ứng dụng web sử dụng tới session), user được cấp 1 SessionID ngẫu nhiên, KHÔNG THỂ ĐOÁN TRƯỚC bởi ứng dụng web cũng như người dùng web.
Câu trả lời cho câu hỏi cuối là "không"