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ừ 

Tôi đã kiểm tra rất kỹ trước khi công bố vul này.

Thứ nhất,

Y360 bị lỗi CSRF dẫn đến việc có thể xóa comment bằng đường dẫn sau:

http://blog.360.yahoo.com/blog-thAecTcofrMD7CKmJsgcIoMq?p=9&dc=10

Đoạn bôi đỏ thay đổi khác nhau với từng blog, nhưng có thể dễ dàng lấy được bằng cách nhấn chuột vào một entry bất kỳ. Đồng thời khi đó cũng lấy được tham số p=... (ID của entry)

Tham số dc=... (ID của comment) có thể lấy được dựa trên cách... suy đoán gần đúng như sau: ID của comment sẽ bằng số thứ tự của comment trong entry + ID của entry.

Tức là, giả sử bạn có một entry ID = 10 thì comment đầu tiên (bóc tem) entry đó sẽ là 11, comment tiếp theo là 12.... ect

Tuy nhiên, con số ở đây chỉ là gần đúng bởi vì, nếu có người comment lệch entry (đang có người comment entry mới nhất lại có người comment vào entry cũ hơn) thì số thứ tự của các comment tiếp theo sẽ bị lệch đi.

Thứ hai,

Y360 không chỉ bị lỗi trong phần xóa comment mà còn bị cả ở trong phần xóa comment thông qua giao diện recent comment (trang này được liệt kê khi bạn bấm vào My Blog và bấm vào Blog Comments) như sau:

http://blog.360.yahoo.com/blog/recent_comments.html?d=10

Và ở link này thì việc xóa trở nên dễ dàng hơn rất nhiều.

Mặt khác, qua phân tích ở phần trên, chúng ta cũng dễ dàng thấy rằng Y360 coi entry và comment đều là các bài post (tăng ID) nên đường link xóa recent comment ở trên có thể xóa cả entry lẫn comment. Tức là bạn chỉ cần biết được ID của entry hoặc comment mới nhất, sau đó chạy vòng lặp downto về 0 là... xóa toàn blog.

Trước khi phát hiện ra lỗi ở Recent Comment tôi có thử xem link xóa entry thì đúng như bạn phân tích, nó đã có chuỗi hash để anti CSRF. Tương tự, link xóa quick comment ngoài top page cũng có chuỗi hash này. Nhưng Recent Comment thì KHÔNG!

Có lẽ khi phóng viên "hỏi lại" bên BKIS để confirm thì bên BKIS chỉ nghĩ tới việc attack qua link delete entry nên đã phát biểu khúc cuối sai lệch hoàn toàn vấn đề (BKIS đã nói: Tuy nhiên lỗi này không nguy hiểm vì phải chuẩn bị mỗi blog một link khác nhau etc...)

Câu nói đó đúng khi xem xét ở phần thứ nhất, nhưng nếu sử dụng cách thứ 2 thì chỉ cần 1 link "dùng chung" cho tất cả các blog của những blogger khác nhau.

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. 

http://blog.360.yahoo.com/blog/delete.html?msgid=maYlD49p 

2. Đối với kiểu tạo request từ các thành phần ngay trong diễn đàn, mà cụ thể là lợi dùng việc chèn ảnh thì có thể thắt chặt việc parse thẻ [img], chỉ cho phép URL thẳng đến các file jpg hay gif thôi  

Dẫu biết là attaker vẫn có thể trick user send request POST nhưng em nghĩ bước đầu tiên cần phải làm vẫn là hạn chế tối đa các request GET(không sử dụng càng tốt)  

Có vẻ như hackernohat chưa đọc kỹ bài của tôi. Tôi không delete blog bằng link của bạn mà delete bằng link http://blog.360.yahoo.com/blog/recent_comments.html?d=...  

Trong IPB thì để del 1 bài post thì ta dùng link sau :

Code:

http://site.com/forum/index.php?act=Mod&CODE=04&f=a&t=b&p=c&st=0&auth_key=1_day_so

Trong đó a = forumid
b = topicid
c = postid

Nhũng cái này có thể dễ dàng tìm thấy , tuy nhiên làm sao để biết đc auth_key của admin hoặc mod 

nora wrote:

Theo mình nghĩ ban quản trị dường như đã fix lỗi này, vì như vậy conmale mới công bố lên đây.
vậy câu hỏi:
Cách của ban quản trị là gì?
 

Cách của BQT có 2 phần:
- phase 1: ứng dụng random token. Token này dựa trên giá trị valid session ID của thành viên có chủ quyền là moderator + một số thông tin cá biệt khác. Ví dụ, IP của session, user-agent của session và vị trí (đang ở trên diễn đàn).... Phase 1 đã ứng dụng.
 

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. 

conmale wrote:

nora wrote:

Theo mình nghĩ ban quản trị dường như đã fix lỗi này, vì như vậy conmale mới công bố lên đây.
vậy câu hỏi:
Cách của ban quản trị là gì?
 

Cách của BQT có 2 phần:
- phase 1: ứng dụng random token. Token này dựa trên giá trị valid session ID của thành viên có chủ quyền là moderator + một số thông tin cá biệt khác. Ví dụ, IP của session, user-agent của session và vị trí (đang ở trên diễn đàn).... Phase 1 đã ứng dụng.
 

Cho em hỏi,
1)cái token này sẽ nằm trong đoạn URL để delete post (nói chung là mọi URL nhạy cảm), đúng ko? Vậy nếu như attacker dùng XSS để đọc cái token này, rồi dùng token để construct cái URL cho XSRF thì vẫn có khả năng thành công đúng ko? Vấn đề là HVA ko bị XSS nên tạm thời chưa sao?
 

2)Có phải vì token này không thể thay thế cho sessionid nên có thể đặt nó vào URL mà không sợ vi phạm cái nguyên tắc bảo mật đã nói ở trên?
 

Việc dùng GET và pass những giá trị "nhạy cảm" như auth_key vào URI là việc cực kỳ nguy hiểm và nên tránh bằng mọi giá. auth_key chỉ nên được tạo ra một lần khi xác thực tài khoản và lưu trên memory của trình duyệt (và gắn liền + có giá trị với sessionid nào đó). Việc đưa những thông tin nhạy cảm này vào cookie và lưu trên máy của client cũng là việc nên tránh xa.

Nếu dùng POST, các giá trị nhạy cảm được đưa vào hidden field của FORM và việc này cũng nên tránh bởi vì nếu bị xss, các giá trị của hidden field vẫn có thể bị đọc được. Bởi thế, những thông tin thuộc về chủ quyền của user (như mods, admins.... ) không nên đưa vào GET hoặc POST mỗi lần một request xảy mà gắn liền chúng với một sesion có giá trị và điều tối quan trọng là sessionid phải do web application server cung cấp và xác thực. Web application không bao giờ tiếp nhận một sessionid đã cũ (và được chèn vào bất cứ lúc nào trong request).
 

@ sư phụ nohat: nhưng anh ấy (conmale) nói:
-"dùng GET... nên tránh bằng mọi giá"
-"cookie ... cũng là việc nên tránh xa"
-"POST ... cũng nên tránh"

Vậy thì còn dùng phương thức gì nữa để truyền tham số giữa client và server ?! 

những thứ nhạy cảm sẽ được lưu tại session và được check bằng token mà ( session_id hash ), chứ nãy giờ bạn không theo giỏi àh?
 

- với GET, các biến sẽ được đưa đến server xuyên qua "query string" (những gì nằm sau ? là query string, những gì nằm sau = là giá trị biến). Ví dụ:
/hvaonline/moderation.php?action=del&by=conmale&post=123&token=7bbde36b2fg6d521b654ef2652593ab3

- với POST, các biến sẽ được đưa đến server xuyên qua các "hidden fields" trên HTML FORM. Ví dụ:

<input type="hidden" name="action" value="del" />
<input type="hidden" name="module" value="moderation" />
<input type="hidden" name="by" value="conmale" />
<input type="hidden" name="post" value="123" />
<input type="hidden" name="token" value="7bbde36b2fg6d521b654ef2652593ab3" />
 

@ sư phụ nohat: nhưng anh ấy (conmale) nói:
-"dùng GET... nên tránh bằng mọi giá"
-"cookie ... cũng là việc nên tránh xa"
-"POST ... cũng nên tránh"

Vậy thì còn dùng phương thức gì nữa để truyền tham số giữa client và server ?! 

Anh conmale cho em hỏi: giá trị "nhạy cảm" lưu trên memory của trình duyệt là như thế nào ạ ? 

Giả sử một moderator vào trang abc.php chẳng hạn. Lúc đó,

- server sẽ kiểm tra và chấp nhận moderator đó hiện đang ở trong một session có giá trị (bằng cách kiểm tra giá trị cookie sessionid trong cookie khi trình duyệt gởi request đi). Trong khi xây dựng trang abc.php để trả lời cho request ở trên, server sẽ tạo một token có giá trị nào đó rồi kèm theo và gởi ngược lại cho client.

- client nhận được trang abc.php và nó hiển thị trên trình duyệt. Trong nội dung trang này có chứa giá trị token (ở dạng giá trị biến trên query string nếu dùng GET, ở dạng hidden fields nếu dùng POST như đã dẫn giải ở bài trước).

- trang abc.php này có đường dẫn để thực thi việc gì đó và việc thực thi có xảy ra hay không thì đã dẫn giải trước đây.

Các bước trên có thể dùng GET hay POST giữa client và server. GET và POST chỉ là phương pháp chuyển gởi thông tin. Trong giai đoạn này, ngoài các thông tin tĩnh (như pic, css, js...) được ấn định là "tĩnh" theo sự trả lời của server sẽ có thể được cache (cache trên proxy, cache ngay chính trên trình duyệt), các thông tin "động" khác như chính trang abc.php và các giá trị thuộc trang này hoàn toàn nằm trên bộ nhớ của trình duyệt. Nếu tắt trình duyệt ngay lúc này và vào thư mục chứa cache của trình duyệt thì chỉ thấy dăm ba bức hình và vài cái css, js (nếu có dùng) mà thôi. Trang abc.php sẽ không có trong thư mục chứa cache này. Đây chính là cái gọi là "lưu trên memory của trình duyệt".

Thân mến. 

Xin lỗi vì đã đào bài này lên, nhưng đây đúng là vấn đề em đang thắc mắc, mong các anh giúp đỡ

Theo như anh conmale thì server sẽ tạo token và gửi trả lại client dưới dạng Hidden fields. Nhưng liệu token này có thể bị đọc bởi một trang thứ 3 như sau không?
(Giả sử người dùng bị lừa vào một trang nào đó, và dính Javascript thực hiện như sau)
- Dùng AJAX gửi một yêu cầu đến trang abc.php. Khi đó (như trên), server sẽ trả về mã HTML, trong đó có chứa token nằm trong Hidden Field.
- Dùng Javascript lấy token trong mớ HTML này, rồi cứ thế dùng AJAX gửi các yêu cầu POST đến trang abc.php để xoá các thứ.
Liệu kịch bản này có xảy ra không ạ ?