mrro wrote:

Đương nhiên xây dựng một hệ thống như thế đòi hỏi tiền bạc, thời gian, nhân lực và rõ ràng là không thể áp dụng cho HVAOnline.

- đối với một hệ thống như HVAOnline, chúng ta có thể điều chỉnh bằng các rule, chẳng hạn như:

+ ủy thác thực hiện các chức năng quan trọng vào một lớp IP nhất định.

+ trước khi thực hiện bất kỳ chức năng nào, phải verify lại mật khẩu.

+ tách bạch giữa account quản lý và account sinh hoạt trên diễn đàn (chẳng hạn như "quanlytruong")

+ ...
 

Điểm thứ 1 ok, đã áp dụng (như điểm thứ 3).
Điểm thứ 2 hơi kẹt .
Điểm thứ 3 gần giống điểm thứ 1.

Hầu hết các chức năng quan trọng đều nằm trong administrator account và nó được "quản chế" khá chặt. Các account moderators có thể làm được một số công tác quan trọng khác nhưng không thể làm hàng loạt được . Đây là nguyên tắc bảo mật căn bản. 

boom_jt wrote:

hì hì, bồ cứ đưa đoạn mã bị sql inj, mình đảm bảo fix đc á

xss như đoạn bồ vừa nói là 1 trường hợp rất hay, (cũng filter đc chớ giả dụ ko cho thực hiện câu javascript tiếp theo bằng dấu ; - js mà ko có ; thì có thực hiện tiếp đc ko nhỉ )
@mR.Bi: lọc hết js thì mất hết hay của web rùi còn gì  

hehe, XSS mà bồ đi lọc dấu chấm phẩy àh? Hay là thấy trường hợp của tui rồi mới nảy ra ý lọc dấu chấm phẩy (j/k).
Còn đoạn code bị SQL injection là thế này đây
Tui có một website về 1 giải bóng đá (WC 2010) chẳng hạn:
giải đấu được chia ra làm 10000 bảng:
muốn xem thông tin các đội trong 1 bảng, ví dụ bảng A đi: thì truy cập URL:
http://football.com/info.php?table=A
trong source-code
$sql="select * from $_GET[table]";
.......
hehe, lúc đó hacker tấn công SQL injection ở mức cơ bản
http://football.com/info.php?table=Admin
hoặc
http://football.com/info.php?table=Infomation_schema.tables
.....
thì bồ xây dựng bộ lọc SQL injection trong trường hợp này thế nào ??
@vivashadow: Bồ làm một bài về httpOnly đi, tui có nhiều thắc mắc về nó  

p/s: Theo mình thì khó mà chống mất cookie, mình chơi nghệ sĩ hơn là có lấy được nhưng không xài được

......

Sao lại không lọc được, chỉ cần tạo mảng chứa các table nhạy cảm hoặc có thể đặt tên table như: _A, _B
$sql="select * from _".$_GET[table];

Trong PHP có hỗ trợ session_ regenerate_ id, có thể sau 3 request thì tạo lại session_id. Mod vào xem bài viết (1), thực hiện xóa bài (2), trở về lại(3). Tuy nhiên cách này lại xung đột với token nếu thao tác kiểu inline mod. session_id đã đổi nhưng giá trị token của trang hiện tại vẫn còn vì chưa load lại trang.
 

HVA còn lờ đi phần Ghi nhớ, chứ nếu có nữa thì còn nhiều vấn đề phải bàn. Không có tính năng này thì ít ra cũng nên đặt Login box bên ngoài để login cho nhanh, chứ cứ mỗi lần phải vào Đăng nhập thì rất mất cảm tình.
 

p/s: Theo mình thì khó mà chống mất cookie, mình chơi nghệ sĩ hơn là có lấy được nhưng không xài được  

Biết chết liền
Đợi 3 lần thì quá lâu, cái class này làm luôn 1 lần.
www.phpclasses.org/browse/package/2794.html

Cần có ví dụ cụ thể về cuộc tấn công của member kia, chứ vầy thì lẫn lộn giữa XSS và session hijacking + XSS
Cố tình lờ đi cái Ghi nhớ chắc là sợ bị flood hoặc gì gì đó

p/s: Cái editor của forum này chuối thật, không nhận biết được con trỏ đang ở đâu, lúc nào nó cũng chèn vào cuối bài viết. 

Biết chết liền
Đợi 3 lần thì quá lâu, cái class này làm luôn 1 lần.
www.phpclasses.org/browse/package/2794.html

Cần có ví dụ cụ thể về cuộc tấn công của member kia, chứ vầy thì lẫn lộn giữa XSS và session hijacking + XSS
Cố tình lờ đi cái Ghi nhớ chắc là sợ bị flood hoặc gì gì đó

p/s: Cái editor của forum này chuối thật, không nhận biết được con trỏ đang ở đâu, lúc nào nó cũng chèn vào cuối bài viết. 

...
p/s: @prof: mình chưa hiểu rõ lắm ý tưởng timestamp của bồ, có thể nói rõ thêm cho mình hiểu chút đc ko, sozy  

hì, mình chưa rõ là cụ thể () cái timestamp đó đc implement thế nào nội dung truyền giữa client và server là tn? 

Mình đoán ý bạn thế này: mình sẽ sử dụng 1 khái niệm gọi là timeout, cookie sẽ chỉ hợp lệ trong 1 khoảng thời gian nhất định đúng ko? Sau khoảng thời gian đó, cookie ko còn hợp lệ, và như vậy kẻ tấn công không thể làm gì đc với cookie ko còn hợp lệ đó? 

Vậy thì khi quá thời gian đó, phải chăng người dùng sẽ lại phải nhập username/password để có 1 cookie hợp lệ mới (có bất tiện cho người dùng quá ko? ), hay bạn sẽ thực thi cơ chế nào đó ? Mình nghĩ nên đi chi tiết vào vấn đề này để làm rõ khả năng ngăn ngừa session hijacking của phương pháp.

Cơ chế timeout này cũng đã đc áp dụng (yahoo! mail chẳng hạn), tuy nhiên thời gian timeout có thể là 1 ngày (khá dài), đủ để kẻ tấn công làm đc điều hắn muốn ... 

Em nghĩ có thể kết hợp thêm yếu tố Timestamp (chẳng hạn, khoảng 30 giây) cho securityHash/token (có tính duy nhất cho 1 session) hiện tại của diễn đàn. Theo đó, phía server sẽ lưu giữ một table các securityHash này và sẽ không chấp nhận một request nào đó nếu giá trị securityHash đã và đang được dùng trước đó. Table này sẽ chỉ lưu các securityHash trong khoảng thời gian của Timestamp sau đó sẽ được giải phóng mà không chiếm tài nguyên.

Trong trường hợp nhận được 2 requests với 2 securityHash giống nhau (bị session hijack), khi đó server-side nên cân nhắc trường hợp reject cả hai request này (vì khi đó không rõ request nào là hợp lệ) hoặc tiến hành verify lại password. 

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.  

Bàn về cách này của bác Mai ví dụ như kẻ tấn công đã có chủ ý và lỗi đó bị khai thác trong phần chữ ký chẳng hạn thì kẻ đó hoàn toàn có thể gởi một PM trực tiếp đến tài khoản có quyền quản trị cao nhất (chẳng hạn như quanlytruong) chẳng hạn thì khi (quanlytruong) đọc tin nhắn có kèm theo chữ ký thì hoàn toàn đã bị hacker cướp được. và lúc đó Hacker đang vẫn có thể khai thác với quyền tối cao.  

Để "sống chung với XSS" (nếu ta muốn như vậy hay bắt buộc phải như vậy), thì tôi sẽ theo một giải pháp khác, xuất phát từ việc phân tích nguyên lý khai thác lỗi XSS của hacker. Tôi sẽ tìm cách để thành phần thứ 3 (tức là hacker với công cụ webserver của hacker) trong quá trình exploit scenarios, không thể phát huy bất cứ một tác dụng gì. Nghĩa là làm cho nó vô dụng.
Để làm việc này tôi đã đề cập một số giải pháp (không cho insert hình ảnh upload trên các webserver khác vào HVA forum, không cho đặt link trên forum để chỉ cần click vào link là có thể kết nối đến các webserver khác, trừ các link nội bô ...vân vân).
Chúng ta để ý sẽ thấy rằng các trang chủ của các công ty kinh doanh tên miền nổi tiếng thường thiết kế rất đơn giản (không hề có animation pic. hay flash gì cả), không hề hiện diện một link "sống" nào, trừ các link nội bộ. Vì các trang chủ này thường có nơi Login vào "Domain control panel", mà trong trừong hợp này thì nickname và pass của một user là tối quan trọng.
Cũng như đã có một số website của chính phủ Mỹ, khi user chỉ chuột vào một link liên kết với một webserver bên ngoài, thì lập tức có một cửa sổ popup hiện ra, với cảnh báo đại thể là: "Bạn đang rời website của chúng tôi để truy cập đến một website-webserver bên ngoài. Chúng tôi cảnh báo việc này và không chịu trách nhiệm nếu như việc này có thể gây tổn thất, rắc rối... cho bạn". Các website này chắc đã thấy rõ tầm quan trọng của lỗi XSS cũng như việc khó loại bỏ hết lỗi XSS trong website của mình.
Một số website khác cho phép user post các link tham khảo, nhưng không được dưới dạng "Hyperlink" mà dưới dạng text. Ngừoi đọc phải copy và dán lên một cửa sổ trình duyệt mới mở ra.
Ngoài ra nếu tạo điều kiện cho user được insert hình ảnh lên HVA forum thuận tiện, dễ dàng thì có lẽ sau này HVA nên có một "file uploading server" riêng. Tạo cái này thưc ra không khó.
 

PXMMRF wrote:

Để "sống chung với XSS" (nếu ta muốn như vậy hay bắt buộc phải như vậy), thì tôi sẽ theo một giải pháp khác, xuất phát từ việc phân tích nguyên lý khai thác lỗi XSS của hacker. Tôi sẽ tìm cách để thành phần thứ 3 (tức là hacker với công cụ webserver của hacker) trong quá trình exploit scenarios, không thể phát huy bất cứ một tác dụng gì. Nghĩa là làm cho nó vô dụng.
Để làm việc này tôi đã đề cập một số giải pháp (không cho insert hình ảnh upload trên các webserver khác vào HVA forum, không cho đặt link trên forum để chỉ cần click vào link là có thể kết nối đến các webserver khác, trừ các link nội bô ...vân vân).
Chúng ta để ý sẽ thấy rằng các trang chủ của các công ty kinh doanh tên miền nổi tiếng thường thiết kế rất đơn giản (không hề có animation pic. hay flash gì cả), không hề hiện diện một link "sống" nào, trừ các link nội bộ. Vì các trang chủ này thường có nơi Login vào "Domain control panel", mà trong trừong hợp này thì nickname và pass của một user là tối quan trọng.
Cũng như đã có một số website của chính phủ Mỹ, khi user chỉ chuột vào một link liên kết với một webserver bên ngoài, thì lập tức có một cửa sổ popup hiện ra, với cảnh báo đại thể là: "Bạn đang rời website của chúng tôi để truy cập đến một website-webserver bên ngoài. Chúng tôi cảnh báo việc này và không chịu trách nhiệm nếu như việc này có thể gây tổn thất, rắc rối... cho bạn". Các website này chắc đã thấy rõ tầm quan trọng của lỗi XSS cũng như việc khó loại bỏ hết lỗi XSS trong website của mình.
Một số website khác cho phép user post các link tham khảo, nhưng không được dưới dạng "Hyperlink" mà dưới dạng text. Ngừoi đọc phải copy và dán lên một cửa sổ trình duyệt mới mở ra.
Ngoài ra nếu tạo điều kiện cho user được insert hình ảnh lên HVA forum thuận tiện, dễ dàng thì có lẽ sau này HVA nên có một "file uploading server" riêng. Tạo cái này thưc ra không khó.
 

Yeah! Yeah! Yeah! Ý kiến của mình ở trên chính là muốn Admin khai triển điều này. (chỉ có điều mình chưa diễn đạt được như đồng chí PXMMRF )
Cảm ơn bạn PXMMRF. 

Theo tôi thì giải pháp này nghiên về hướng phòng chống XSS, không cho nó xảy ra. Đây là những biện pháp tốt nhưng chủ đề mình đang bàn là: giả sử mình bị XSS và chưa khắc phục thì ở phía server mình có thể làm những gì để ngăn cản hoặc giảm thiểu dung hại tình trạng session bị hijack do mất cookie.

Tất nhiên phòng cháy hơn chữa cháy. Việc ngăn ngừa XSS xảy ra và ưu tiên một nhưng cái scope để bàn luận ở đây không phải là các phương pháp ngăn ngừa XSS.  

Mình nghĩ cách dùng password thứ hai khá hay. VD ta cho nó gồm 2 chữ số và trong mỗi tao tác quản trị thì verify lại pass này. Vì pass phụ chỉ có 2 chữ số nên ko gây nhiều quá nhiều cản trở như việc nhập lại pass chính (passwd của các admin và mod trên forum thì có lẽ khá rắc rối).  

í em còn quên cái này,các anh chỉ dùm em luôn,em thấy các anh bảo là chỉ cần view sorce là có thể thấy được sessionID mà em tìm mãi mà kô thấy cái sesionID nào cả,thử mấy trang rồi.mong chỉ giúp ạ.