Về việc tấn công XSRF - .:: HVAOnline ::.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Về việc tấn công XSRF

[Question] Về việc tấn công XSRF	26/10/2007 23:20:01 (+0700) \| #1 \| 93160

Ho4ngy3nxinhdep
Member

Joined: 25/10/2007 23:50:07
Messages: 8
Location: VHS
Offline

Em thấy HVA có bài của anh Thái và anh Comale về tấn công XSRF rất hay và muốn tham gia nhưng không có quyền reply vậy mạo muội post ở đây nhờ các mod ghép topic nếu thấy có thể

Các anh có topic thảo luận rất hay. em không rành về lập trình và code nên không dám khẳng định gì cả, tuy nhiên vì là người "ngoại đạo" nên có một số cách nhìn đơn giản và phiến diện như sau:
- Cách của anh comale giải quyết được vấn đề đầu bài nêu, tuy nhiên nếu dính XSS thì đó chưa phải đã giải quyết được triệt để vì attacker có thể bắt được toàn bộ session khi đang online.
- Cách của anh comale em thấy có thể dễ với coder khá nhưng đa phần có thể không tự fix được như HVA đã fix (không biết có phải không?)
- Theo em nghĩ đơn giản là các bài xóa sẽ biến mất (ẩn) hiện tại trên phần front end mà thôi, chứ chưa mất hết trong CSDL, sau đó các mod hay admin có thể đăng nhập lần 2 (với 1 password kép khác với pass nick) vào phần control panel đầy đủ để thao tác confirm. Cái này nhiều nơi đã thực hiện nếu các anh để ý. Tức là các thao tác đơn giản thì cho phép thực hiện tại frontend còn thao tác quan trọng cần thiết qua 1 lần đăng nhập nữa và khi quay ra frontend thì quyền sẽ quay về phần prontend. Như vậy attacker không có cách nào tấn công XSS hay XSRF với bất kỳ cách nào.
- Tuy nhiên vấn đề này rất hay, các mod hay admin sẽ rút kinh nghiệm khi thực hiện các tác vụ trong về sau.

[Question] Re: Về việc tấn công XSRF	26/10/2007 23:59:48 (+0700) \| #2 \| 93166

Quan Vân Trường
HVA Friend

Joined: 19/07/2002 10:13:30
Messages: 115
Location: 9:00PM-6:00AM
Offline

Chào bạn,
Hi vọng bạn lưu ý trong chủ đề bàn về CSRF của anh conmale đã phân định rõ là đang bàn về CRSF chứ không nhắc đến XSS. Chính anh conmale đã nói: "Nếu nó còn dính xss nữa thì phải nói là cực kỳ nguy nan".
Về giải pháp khắc phục, giả định là bị XSS chúng ta vẫn có thể hạn chế bằng "intermediate confirmation step" như anh conmale nói. Sử dụng captchar có thể vô hiệu được CRSF (tuy có hơi phiền phức đối với 1 "hành động" hợp lệ). Nhưng dù sao thì nó có vẽ vẫn đơn giản hơn là giải pháp bạn đưa ra.
Nếu sử dụng cách của bạn (nghe có vẻ giống chức năng ẩn bài viết của HVA quá):
1/ Sẽ tạo ra 1 cái gọi là "xác thực 2 lần" cho 1 "hành động" (bất kể là nó hợp lệ hay không hợp lệ) như thế theo mình vừa phiền phức, vừa có thể tốn tài nguyên (nếu bạn quên "xác thực" lần 2 thì nó vẫn nằm đó trên DB của bạn - đối với 1 "hành động" hợp lệ)
2/ Làm cho web application trở nên cồng kềnh, nhiều thao tác trên DB. Và không có gì đảm bảo cái "xác thực" lần 2 ấy không có vấn đề.

Vài ý kiến.
Thân.

Kernel Panic.

[Question] Re: Về việc tấn công XSRF	27/10/2007 00:15:22 (+0700) \| #3 \| 93167

Ho4ngy3nxinhdep
Member

Joined: 25/10/2007 23:50:07
Messages: 8
Location: VHS
Offline

Mình không phải coder nên không biết cái nào đơn giản hơn, nhưng đó cũng là một cách giải quyết được vấn đề tấn công XSRF đó chứ? bạn nói làm web "cồng kềnh" hơn thì mình không hoàn toàn đồng ý vì hiện nay nhiều Web đã làm vậy như một số Báo điện tử, khi PV post hay xóa bài đều là dạng ẩn, cần phải có 1 quyền khác Approved , Vấn đề nữa là 1 ứng dụng quan trọng, để tránh hoàn toàn XSS, hay XSRF thì cần thiết phải khắc phục và việc coder biết càng nhiều cách sẽ càng có lợi cho họ. Bạn nói lần đăng nhập 2 không chắc có an toàn hay không thì mình khẳng định là tương đối chắc chắn hơn nhiều so với việc không xử lý, và trong 1 web app, điều đó là đã khá tốt. Tuy nhiên nếu bạn thấy bài này không có giá trị thì mình sẽ không tham gia thêm nữa

[Question] Re: Về việc tấn công XSRF	27/10/2007 00:40:18 (+0700) \| #4 \| 93171

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

Phương pháp fixed CSRF được cho là đạt yêu cầu khi không bắt người quản trị phải nhập thêm pasword, hay captcha hay bất cứ điều gì để confirm thêm một lần nữa trước khi thực thi một action nào đó smilie

Vì thế giải pháp sinh ra random token của HVA là một trong những giải pháp chuẩn
Nhưng cho mình hỏi thêm câu này : Check HTTP_REFERER có chống được CSRF attack ko và tại sao? smilie

Cánh chym không mỏi
lol

[Question] Re: Về việc tấn công XSRF	27/10/2007 00:42:24 (+0700) \| #5 \| 93173

Quan Vân Trường
HVA Friend

Joined: 19/07/2002 10:13:30
Messages: 115
Location: 9:00PM-6:00AM
Offline

Mình phải sửa lại bài viết, có lẽ lúc nãy mình hiểu nhầm ý của bạn HYXD. Ý của bạn là khi thực hiện 1 hành động xoá, sẽ tiếp bước thứ 2 là xác nhận người dùng bằng pasword phụ ??
Nếu vậy thì nó giống với việc sử dụng captchar (mình nghĩ dùng captchar có vẻ tiện hơn vì nó random và ko cần phải khai báo pasword phụ khi đăng kí).

Thân.

Kernel Panic.

[Question] Re: Về việc tấn công XSRF	27/10/2007 01:01:44 (+0700) \| #6 \| 93178

Ho4ngy3nxinhdep
Member

Joined: 25/10/2007 23:50:07
Messages: 8
Location: VHS
Offline

Mình cũng xin sửa lại, Mình đâu dám tự ái, rất vui là các bạn đã góp ý, Cách của HVA dĩ nhiên là chuẩn rồi nhưng xin hỏi tại sao trước đây đa phần chưa nơi nào xử lý được? ngay cả cái Jforum này, như vậy chứng tỏ cũng không phải là đơn giản đối với hầu hết các coder ? Và có bao nhiêu web app trên TG đã áp dụng cách của bác Conmale?

[Question] Re: Về việc tấn công XSRF	27/10/2007 03:31:40 (+0700) \| #7 \| 93213

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Ho4ngy3nxinhdep wrote:

Mình cũng xin sửa lại, Mình đâu dám tự ái, rất vui là các bạn đã góp ý, Cách của HVA dĩ nhiên là chuẩn rồi nhưng xin hỏi tại sao trước đây đa phần chưa nơi nào xử lý được? ngay cả cái Jforum này, như vậy chứng tỏ cũng không phải là đơn giản đối với hầu hết các coder ? Và có bao nhiêu web app trên TG đã áp dụng cách của bác Conmale?

Theo anh biết, JForum nguyên thuỷ không nghĩ đến chuyện này vì nhóm phát triển JForum tuy rất kỹ lưỡng nhưng đối với bảo mật, có quá nhiều khía cạnh để xét đến. Khi JForum mang về HVA, tình hình khác đi bởi vì không những anh em thành viên ở HVA thử tìm lỗi để kiện toàn mà những nguồn bên ngoài vẫn thường xuyên "tìm lỗi" dùm smilie

. Bởi thế, mức ứng dụng bảo mật và thắt chặt bảo mật của phiên bản JForum HVA đang dùng rất khác với bản nguyên thủy. Thật sự mà nói, cho đến nay, cái "lõi" bên trong JForum mà HVA đang dùng đã rất khác nhánh hiện có trên JForum website.

Quay lại chuyện XSRF, có khá nhiều phương pháp để khắc phục chuyện này nhưng cách nào gọn nhẹ, trong suốt vẫn là cách hay nhất. Dùng captcha hay một dạng validation step cũng tốt nhưng nó gây phiền toái cho người dùng. Dùng client side scripting (javascript) thì hoàn toàn loại bỏ khỏi danh sách vì nó vô giá trị. Việc ứng dụng xóa "giả", có nghĩa là data trong CSDL vẫn còn cũng là một cách bảo vệ data. Tuy nhiên, nó cũng có cái phiền cho việc theo dõi và quản lý. Trước khi ứng dụng phương pháp tạo token và xác thực token, anh đã thử phân tích nhiều dạng nhưng rốt cuộc thực hiện "token" bởi vì nó gọn nhẹ và trong suốt nhất. Tuy vậy nó cũng có một số nhược điểm.

1) token chỉ vững nếu nó thay đổi thường xuyên và ngẫu nhiên.
2) token chỉ vững nếu nó hoàn toàn cá biệt và có nhiều phần tử (factor) được dùng.
3) nếu một trong những factor được dùng để tạo token không ổn định thì token sẽ gây trở ngại cho người dùng.

Gần đây có một số moderators gặp phải trở ngại khi thực thi một số chức năng điều hợp, khi điều tra anh không hề thấy có lý do nào hiển nhiên ngoài một factor có thể bị thay đổi bất chợt đó là IP -*-. Nếu IP được dùng như một trong các factors để tạo token và IP lại thay đổi trong khi thực thi công việc gì đó, token mà user nhận được lần trước so với lúc thực thi công tác sẽ không match. Do đó, không thực thi thành công và đây là trở ngại anh thấy được cho đến nay.

Nếu chỉ đơn giản dùng POST thay vì GET (để tránh bị xào nấu request parameters trên URI) thì vẫn bị exploit như thường. Gamma95 đã chứng minh điều này.

Việc thống kê có bao nhiêu web applications trên TG đã dùng phương pháp token thì impossible hoặc cực khó. Tuy vậy, anh biết các hệ thống AAA cao cấp của IBM (như Tivoli Access Manager), của Sun (như Identity Manager), của CA (trước đây là Netegrity như Siteminder) đều ít nhiều xoay quanh khái niệm token. Cách ứng dụng của họ khác nhau nhưng cũng sử dụng HTTP header, HTTP payload hoặc cookie. Token ở đây là một điều kiện để xác thực xem user x có đủ quyền hạn thực thi việc gì đó. HVA không ứng dụng cái này trên cookie mà ứng dụng trực tiếp vào "event" và giá trị token phần lớn gói trong payload của HTTP (ngoại trừ vài trường hợp cá biệt). Khi một biến cố (hành động) quan trọng xảy ra, luôn luôn có một bước xác thực (so sánh) chủ quyền.

Hy vọng phần nào giải thích được câu hỏi của em.

Thân mến.

-*- theo anh điều tra, một user ở VN đi ra ngoài Internet có thể đi qua 1 hoặc 2 proxy servers (có IP khác nhau). Có thể vài phút trước, user đó truy cập HVA từ IP 203.x.x.x (IP của một proxy) nhưng vài phút sau, user đó lại truy cập HVA từ IP khác 203.x.x.y.

PS: phân mục "Các bài viết giá trị" ở chế độ lưu trữ nên member chỉ có thể đọc nhưng không thể tiếp tục thảo luận.

What bringing us together is stronger than what pulling us apart.

[Question] Re: Về việc tấn công XSRF	27/10/2007 07:03:20 (+0700) \| #8 \| 93253

Ho4ngy3nxinhdep
Member

Joined: 25/10/2007 23:50:07
Messages: 8
Location: VHS
Offline

Cám ơn bác đã chỉ giảng rõ ràng , Về việc bất tiện cho Mod hay admin khi quản lý qua việc xóa giả em bổ xung thêm là các dữ liệu bị xóa sẽ tự động xóa hẳn sau 1 thời gian xác định như là 24h để tránh phiền hà cho việc quản lý, nếu trong 24h admin phát hiện ra có cuộc tấn công thì có thể undo lại các record đã xóa, như vậy cũng đỡ phần nào. Em không rành lắm nên cứ suy nghĩ thủ công như vậy mong các anh góp ý

[Question] Re: Về việc tấn công XSRF	28/10/2007 00:35:03 (+0700) \| #9 \| 93386

nhuhoang
Elite Member

Joined: 27/06/2007 00:49:10
Messages: 111
Location: /dev/null
Offline

Theo em cách confirm bằng một trang thứ 2 xác nhận thao tác là khá ổn và dễ thực hiện (trong vBulletin đã làm như vậy). Còn việc xóa bài thì mặc định sẽ move vào thùng rác hoặc xóa tạm (soft delete), sau một thời gian thì xóa hẳn

[Question] Re: Về việc tấn công XSRF	28/10/2007 00:38:31 (+0700) \| #10 \| 93387

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Ho4ngy3nxinhdep wrote:

Cám ơn bác đã chỉ giảng rõ ràng , Về việc bất tiện cho Mod hay admin khi quản lý qua việc xóa giả em bổ xung thêm là các dữ liệu bị xóa sẽ tự động xóa hẳn sau 1 thời gian xác định như là 24h để tránh phiền hà cho việc quản lý, nếu trong 24h admin phát hiện ra có cuộc tấn công thì có thể undo lại các record đã xóa, như vậy cũng đỡ phần nào. Em không rành lắm nên cứ suy nghĩ thủ công như vậy mong các anh góp ý

Giả sử dữ liệu tự động xóa hẳn sau 24 giờ và trong khoảng thời gian này admin không thể theo dõi (đi vắng chẳng hạn) thì hóa ra những dữ liệu quan trọng vẫn bị xóa sao?

Ngoài dữ liệu ra, XSRF không chỉ nhắm vào dữ liệu mà còn vào những tính năng khác của một diễn đàn, ví dụ: lock account, ẩn bài viết, dời bài viết.... và những việc này sẽ gây rối loạn không nhỏ. Đối với các ứng dụng web khác, nó còn tạo nên những rắc rối khác chớ không chỉ dữ liệu bị xóa.

Thân mến.

What bringing us together is stronger than what pulling us apart.

Go to:

Users currently in here
1 Anonymous