> How can it be fixed? Well, there are a couple of ways to stop it, but the
> easiest (in PHP at least) seems to be to have most of the variables used by
> scripts be used through $HTTP_POST_VARS. So instead of checking for $action
> in a script, $HTTP_POST_VARS['action'] would be checked. This forces the
> user to use a POST request, not a GET.

which means the attacker reverts to using Javascript, or entices the victim
to click on an image that's acting as a submit control in a <form>.
Requiring POST raises the bar, but doesn't really fix the problem.

> Alternatively, the sessionid could be
> required to come with the GET/POST request variables, rather than by cookie.

...thereby exposing an important piece of authentication information to
history files and proxy servers; I really don't like URL mangling for
authentication purposes, especially in non-SSL systems. A combination of
cookie + URL mangling might not be bad, though in the message board case, a
CSRF attacker could use an intermediate redirect (as described earlier) to
get the URL mangling (from the Referer), and redirect back to the
messageboard with the proper mangling as well as all cookies that might be
expected/needed. So in your example case, URL mangling would buy nothing.

> Finally, in the specific case of [img] tags, the use of ? or & in the img
> URL can be disabled by some regexes.

Not at all adequate. Browsers follow redirects on IMG tags, so I redirect
you to http://example.net/logo.gif which in turn redirects you to the final
URL, as described earlier.

> If the software that you run is not secure, we recommend that you disable
> HTML and/or [img] tags, until the fixes have been implemented.

It's much worse than that.

Please see the following URLs for an introduction to the dangers of CSRF,
and some discussion of countermeasure strategies.

http://www.astray.com/pipermail/acmemail/2001-June/000803.html
http://www.astray.com/pipermail/acmemail/2001-June/000808.html
http://www.astray.com/pipermail/acmemail/2001-June/000804.html 

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ó phải topic này của huynh là để mọi người bàn luận và tìm ra cách tối ưu nhất hay để các members "tập suy nghĩ"?
 

tóm lại topic rất hay, indeed

)  

-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. 

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.  

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 lệnh cơ bản của Javascript.  

bạn nohat nói cụ thể hơn được ko?? )  

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; 

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).