P/S: Thực ra, Y360 cũng đã có một bước anti CSRF ở link xóa comment và recent comment bằng việc check IP khi login và IP khi ra lệnh xóa. Có lẽ vì lý do đó nên khi tôi gửi msg thông báo lỗi cho Y360 Team chẳng thấy họ phản ứng gì. Có điều, cách anti như vậy không có tác dụng tốt lắm với blogger Việt Nam, vì IP là giống nhau do đi qua proxy. Điều đó cũng có nghĩa là nếu bạn sử dụng ADSL của FPT thì không thể attack được vào blog của người đang xài ADSL VDC hay Viettel. 

Cảm ơn Conmale đã check giúp.
1. Server này gần như dedicated vì hầu như chỉ có site này chạy.
2. Brute force dưới bất kì hình thức nào đều bị block IP.
3. DNS thì đang kiểm tra lại.
4. FTP đã fix manual
5. Forum dùng IBF 2.0.4 (chưa update bao giờ)
6. Site thường xuyên bị DoS. Tháng nào cũng bị bắn nên anh truy cập vào thấy chậm là phải.
7. Blind SQL injection ---> Pls check again  

Thú vị ở đó khi đọc dữ liệu bằng HexEditor tôi cũng nhận ra như vậy.
Vậy nên một câu hỏi đặt ra là : hàm include của php lỗi ở đâu mà nó lại read các lệnh ( chỉ read có mỗi lệnh php ) được comment trong têp binary này mà không bị lỗi linh tinh ( như sai biến thiếu ";" vân vân và vân vân ) ) rất thú vị, ngoài ra tuyệt nhiên ko thấy dấu vết của vụ NULL code trong đoạn cuối của script được chèn.
Một dấu chấm hỏi thiệt là to :?  

Điều gây khúc mắc là: Cấu trúc của tệp JPG là một tệp Binary ( theo tôi biết ) chứa thông tin về dữ liệu hình ảnh được nén, cấu trúc của nó không rõ là lỗi ở đâu mà kiến các comment có thể được thực thi. Trong khi thằng PHP include là load cái tệp tin vô quá trình thông dịch script là đọc và load tệp bằng chế độ đọc text chứ không phải chế độ đọc binary !?  

<?php
include(“/home/$file”);
?> 

hic gamma95 à, CSRF là lợi dụng truy vấn GET và Session của Moderator để truyền lệnh phá dữ liệu ( mượn tay giết gà đó mà ), chứ nó có phải là XSS đâu mà lấy cắp cái session về cất tủ . Việc lấy cái Session thật ra là theo ý của anh conmale là bypass cái vụ check session mà chúng ta đã đề cập từ đầu bài thảo luận.
Tôi đề cập tới hidden field ở đây là nó có thể chứa chuỗi hash nên tôi tìm cách lấy nó theo câu hỏi "khó" của anh conmale mừ 

Hì xin được giải thích thêm ( gamma95 biết rồi còn giả chưa biết )
Đầu tiên là đọc cookie:
vì dụ các phiên bản cũ của IE cho phép chạy activeX FileSystemObject là một trong các activeX cho phép truy cập file, còn tiếp theo cậu hiểu ý tớ rồi chứ.

Và đọc input hidden field:
document.all.field.value;


Còn các lỗ hổng khác thì ..... nhìu nhìu.  

Và đọc input hidden field:
document.all.field.value; 

Vậy xin cho mình hỏi tiếp mấy câu. Nếu hỏi ngố quá thì mong mọi người đừng cười nha.
Nếu người ta đã scan được thì sao ko giữ lại để dùng cho riêng mình thì sẽ lâu bị die hơn. Mục đích của việc share này những proxy này là gì hay chỉ là lòng tốt? 

Việc lấy hash trong 2 trường hợp này là có thể.

Với version cũ của 1 số browse ( trình duyệt ) có lỗi có thể thực hiện Cross-Site-Cookies-Read.
Việc đọc input hidden field còn dễ hơn qua các hàm cơ bản của Javascript.  

1. Đối với kiểu "lừa" admin/mod sang trang khác rồi GET trở lại thì sẽ có Referer từ bên ngoài, như vậy chỉ cần check Referer là chặn được.