Chào anh conmale,
Hôm nay nhân dịp em tiến hành audit cái web-app của một khách hàng nên em cũng thử apply các technique đó vào HVA. Em thấy HVA mình bị cái lỗi cross site request forgery ở chức năng delete và hide một bài viết. Ví dụ như em muốn delete một bài có id là 12345, em chỉ cần GET cái URI như sau:
Code:

http://hvaonline.net/hvaonline/jforum.html?module=posts&action=delete&post_id=12345&start=0

Khi đó nếu như em, bằng một cách nào đó, dụ được anh conmale hay bất kì lão nào trong BQT HVA vào một cái site do em control, em sẽ dễ dàng delete được hết tất cả các post có trong forum mình. Tưởng tượng em post một bài lên HVA, có đường link đến cái site của em, trong site đó em để một vòng lặp lần lượt delete hết tất cả các post.  

Lỗi được diễn giải (reword) như sau (credit vẫn của Mr Thái ^_^)
Một số action "nhạy cảm" của diễn đàn được thực hiện qua GET action, ví dụ (mà Thái đưa ra) là acn Delete bài viết. Hơn nữa cái action này không thông qua 1 cơ chế confirmation nào trước khi thực thi hết.
Note: Cái javascript pop up lên hỏi "Có xóa hay không?" khi click vào link thì không được tính là "confirmation" trên phương diện bảo mật

Như vậy, nếu có ai đó "dụ" được Admin/Mod/Whoever có quyền "click" vào cái link xóa bài, thế là bài viết sẽ đi tong! (với điều kiện là Admin/Mod đó đang login vào forum).
Cách "dụ" thì quá dễ, và rất muôn hình vạn trạng. Và dụ Admin/Mod lại càng dễ nữa

Đơn cử 1 cách "dụ":

Tạo 1 topic, có title thật "hot" trong 1 box cũng "hot" luôn --> 100% là sẽ có mod hoặc admin nào đó vào xem liền, và nếu người đó cố tình, có thể "canh me" lúc các Admin/Mod online, post 1 bài thật hot thì còn hiệu quả hơn nữa.

Trong topic đó, tìm cách "execute" cái link delete bài viết (hay 1 action "nhạy cảm" nào đó), các execute thì cũng vô cùng đơn giản: dùng thẻ image của diễn đàn, "hook up" cái link vô - dĩ nhiên là image sẽ không hiển thị, nhưng...lúc này thì teo rồi

Cách "dụ" này nguy hại ở chỗ:
- Vì là image nên cái link sẽ được execute ngay khi bài viết được đọc
- Nếu không chú ý, rất khó phát hiện ra cái link "độc" trong cái image, và nhất là nếu dùng 1 số trình duyệt như FF, image không tồn tại nó không "la làng" lên như IE --> còn chết bạo nữa.
- Bài viết trên forum HVA, tag image cũng link tới 1 URL trên HVA --> by pass được hoàn toàn referer và cookie/session check ở server side.  

Một tên gọi khác của cross site request forgery là session riding, nghĩa là em sẽ "mượn dao chém mướn", lấy session của anh để thực hiện hành động xóa hay ẩn bài. Tình huống nó như thế này:

1. Anh đăng nhập vào HVA. Session của anh vẫn còn hiệu lực.

2. Anh vào website của em.

3. Trong website của em, em sử dụng <img hay <iframe (có rất nhiều cách khác nhau) theo kiểu như sau:

Code:

<iframe name="myframe" src="http://hvaonline.net/hvaonline/jforum.html?module=posts&action=hide&post_id=36994&by=conmale" style="width:0px;height:0px;border:0px"></iframe>

4. Lúc đó browser của anh sẽ tự động truy cập vào cái URI là giá trị của thuộc tính src trong cái iframe. Điều đặc biệt là lúc này, browser của anh vẫn sử dụng cái session cũ khi anh đăng nhập vào HVA. Do đó nó hoàn toàn có hiệu lực như thể anh thực hiện hành động đó. 

Em suggest 1 cách đơn giản, đó là submit request = method POST thay vì GET, như đang sử dụng. 

1- Member không có quyền delete thì làm sao biết được cái URI như thế này (tuy nhiên cũng có thể có khả năng xảy ra) .  

1- Member không có quyền delete thì làm sao biết được cái URI như thế này (tuy nhiên cũng có thể có khả năng xảy ra) .  

Cái URL thì dễ thôi, install 1 cái forum y chang, tất nhiên là có quyền Admin sẵn rồi. 

WinDak wrote:

Em suggest 1 cách đơn giản, đó là submit request = method POST thay vì GET, như đang sử dụng. 

) nhưng POST vẫn có thể bị intercept như thường mà? Vấn đề ở chỗ xác thực được hành động xóa bài đó có đúng là moderator thực hiện có chủ định hay vô tình xóa vì dính CSRF. Nếu thay GET bằng POST nhưng không có cơ chế kiểm soát thì đâu có gì khác nhau đâu?
 

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.  

WinDak wrote:

Em suggest 1 cách đơn giản, đó là submit request = method POST thay vì GET, như đang sử dụng. 

) nhưng POST vẫn có thể bị intercept như thường mà? Vấn đề ở chỗ xác thực được hành động xóa bài đó có đúng là moderator thực hiện có chủ định hay vô tình xóa vì dính CSRF. Nếu thay GET bằng POST nhưng không có cơ chế kiểm soát thì đâu có gì khác nhau đâu?

Cả hai ý kiến của hackernohat và PHUCDOAN đều lý thú và có thể ứng dụng cả. Hãy thử phân tích xem, có cách nào lấy được sessionID hiện tại của một moderator nào đó không? ). 

watchd0g wrote:

1- Member không có quyền delete thì làm sao biết được cái URI như thế này (tuy nhiên cũng có thể có khả năng xảy ra) .  

Cái URL thì dễ thôi, install 1 cái forum y chang, tất nhiên là có quyền Admin sẵn rồi. 

Đúng vậy. Nếu dùng các forum có sẵn mà không thêm bớt, điều chỉnh, code thêm... thì cài 1 con y hệt là ra ngay.

Nếu không thì viết một cái script hay chương trình để "crawl" thì thế nào cũng ra thôi ). 

Cám ơn câu hỏi "khó" của anh conmale

Theo kiến thức hạn hẹp mà em có thì em chỉ nghĩ được 2 cách ( rất ư là vô lý ):

1. Trang này phải dính thêm bug XSS.
 

2. Tìm thuật giải mà phần mềm máy chủ dùng để generate SessionID, rồi dựa vào các thông tin khách quan như IP hiện tai của Moderator .v.v. mà tái tạo SessionID.
 

Em còn đang tìm hiểu xem có phương thức nào khác lấy SessionID. Hi vọng là tìm ra

 

sặc..... lạy mấy anh. nếu OpenSource thì không bàn gì nữa.
 

Thử nghĩ xem, phương tiện nào truyền tải những thứ như sessionid, hash... ? Thử nghĩ cái gì không ngăn chặn "biên giới" (hoặc không ngăn chặn đủ) những thông tin không liên quan giữa session của người đang duyệt và session của một người khác ở đâu đó? )  

PHUCDOAN wrote:

sặc..... lạy mấy anh. nếu OpenSource thì không bàn gì nữa.
 

Hình như bồ ám chỉ open source không an toàn? 

<iframe name="myframe" src="http://hvaonline.net/hvaonline/jforum.html?module=posts&action=hide&post_id=36994&by=conmale" style="width:0px;height:0px;border:0px"></iframe> 

> 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 wwwect (as described earlier) to
get the URL mangling (from the Referer), and wwwect 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 wwwects on IMG tags, so I wwwect
you to http://example.net/logo.gif which in turn wwwects 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;