Thảo luận: cross site request forgery (CSRF hay XSRF)

English | Vietnamese

Nội Quy

Diễn đàn

Portal

Danh sách thành viên

Thống kê

Tìm kiếm

Phòng đọc

Đăng ký

Đăng nhập [ | https ]

Diễn đàn chính

Thảo luận thâm nhập

Thảo luận: cross site request forgery (CSRF hay XSRF)

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	05/03/2007 06:37:26 (+0700) \| #31 \| 44570

mabubeo90
Member

Joined: 02/08/2006 10:46:49
Bài gởi: 11
Offline

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

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	05/03/2007 14:39:38 (+0700) \| #32 \| 44713

stupidmistakez
Member

Joined: 10/08/2006 18:09:15
Bài gởi: 11
Offline

vtv_4 wrote:

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

Vấn đề còn lại là làm sao để lừa yahoo không bị chống flood smilie

. Nếu mà dùng tag <img thì chỉ xóa được <100 entry smilie

, còn dụ victim click link vào trang của mình thì có thể cho nó chạy iframe với mấy trang proxy nữa chắc cũng ổn ; smilie

, he he, em bị xóa gần 100 cái đang tức ói máu đây nhưng chỉ tội ngu ráng chịu smilie

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	05/03/2007 15:32:54 (+0700) \| #33 \| 44725

mrro
Administrator

Joined: 27/12/2001 05:07:00
Bài gởi: 683
Online

Phát hiện của vtv_4 thật có ích. Tôi nghĩ nó sẽ làm cho các web-developer ở VN chú ý hơn đến lỗi này.

-m

http://vnhacker.blogspot.com

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	05/03/2007 22:04:24 (+0700) \| #34 \| 44749

conmale
Administrator

Joined: 07/05/2004 23:43:15
Bài gởi: 9023
Đến từ: down under
Online

mabubeo90 wrote:

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

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

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

[Hỏi đáp] Re:Thảo luận: cross site request forgery (CSRF hay XSRF)	05/03/2007 23:56:28 (+0700) \| #35 \| 44772

peo
Member

Joined: 05/03/2007 10:22:58
Bài gởi: 1
Offline

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?

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	06/03/2007 00:08:48 (+0700) \| #36 \| 44775

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Bài gởi: 1297
Đến từ: ░░▒▒▓▓██
Offline

@vtv4

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.

ko hiểu khúc này ?? đã lợi dụng CSRF để chém mướn thì IP trước sau hoàn toàn là IP của victim chứ nhỉ ?? nên IP trước sau gì cũng đâu có thay đổi đâu ?? smilie

Cánh chym không mỏi

[Hỏi đáp] Re:Thảo luận: cross site request forgery (CSRF hay XSRF)	06/03/2007 00:11:37 (+0700) \| #37 \| 44776

conmale
Administrator

Joined: 07/05/2004 23:43:15
Bài gởi: 9023
Đến từ: down under
Online

peo wrote:

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?

Cái token này là hash của những thành phần khác nhau và nó không phải là auth_key. Dùng nó "khơi khơi" không có tác dụng gì hết vì token này phải được so sánh với giá trị ngay thời điểm một request được xảy ra. Token này cũng có thể thay đổi liên tục tùy theo request được ai thực hiện và thực hiện ở đâu nữa. Ví dụ, token này chỉ dùng cho /abc/def.php?t=123&user=some_admin chẳng hạn, nếu token đó bị chôm và lúc ấy some_admin không ở trong t=123 thì nó hoàn toàn vô tác dụng. Đó là chưa kể đến khía cạnh token thay đổi khi sessionid thay đổi nữa. Ví dụ token đó bị chôm và admin hiện đang trong t=123 nhưng cái token đó được tạo ra khi admin login lần trước thì nó cũng không thể dùng để làm gì cả.

peo wrote:

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?

sessionid là sessionid, token là token. token là "sản phẩm" của nhiều yếu tố cộng lại và sessionid chỉ là 1 trong các yếu tố.

Thân mến.

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

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	08/03/2007 01:02:22 (+0700) \| #38 \| 45204

conmale
Administrator

Joined: 07/05/2004 23:43:15
Bài gởi: 9023
Đến từ: down under
Online

Có vài người "hỏi riêng" tôi cách tạo token trong trường hợp trên và ứng dụng như thế nào, sẵn topic này còn... nóng, tôi xin phép trả lời chung luôn.

Tổng quát mà nói, khi nhấn trên một đường dẫn, trình duyệt sẽ gởi request đến web server và request này có thể là GET hoặc POST tùy ứng dụng.

- 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" />

Giá trị của token ở đây là giá trị hash của một số dữ kiện nào đó tùy chọn và nó được gởi ngược từ server đến trình duyệt khi trình duyệt vào trang có chứa link để thực thi hành động del. Ví dụ, user đi vào trang moderate.php chẳng hạn, trình duyệt sẽ nhận được được chuỗi token. Chuỗi token này sẽ được dùng để xác thực quyền "del" khi nhấn nút "delete" một cái gì đó.

Khi nhấn nút "delete", token trên được gởi đến server, cơ chế kiểm soát (một class, một function.. nào đó) sẽ lấy giá trị này đồng thời thực thi một bước tạo hash cũng dựa trên một số dữ kiện nào đó như trước. Sau đó nó so sánh 2 giá trị trước và sau xem chúng có trùng nhau hay không thì mới thực thi hành động cần thực thi.

Riêng việc xây dựng như thế nào thì tùy vào tình huống, cấu trúc của web application và độ sáng tạo smilie

) . Tuy nhiên, hash của token nên có 2 điều kiện quan trọng:
- nó dùng dữ kiện thuộc về người có thẩm quyền thực thi chức năng. Ví dụ, tên người dùng, sessionid của người dùng, IP của người dùng....

- nó phải thay đổi (dynamic) dựa trên những điều kiện liên quan đến việc thực thi chức năng. Ví dụ: người dùng ở trên mỗi URI thì có giá trị khác, người dùng bấm trên mỗi đường dẫn sẽ tạo ra một random value nào đó và random value này được đưa vào chuỗi thông tin để tạo hash...

Lý do? Giả sử ai đó chôm được cái token của một moderator và xác định được moderator này đang ở đúng vị trí nào đó trên forum, "ai đó" có thể dùng nó để tạo 1 trang web nào đó và đồng thời chat + dụ moderator này xem. Lúc moderator này đồng ý vào trang web "độc địa" ấy thì random value đã thay đổi và bởi thế cái token bị chôm và bị dùng kia cũng không còn giá trị nữa --> thực thi việc "mượn tay chém" không được nữa smilie

).

Tất nhiên là token / hash / so sánh ... đều xảy ra trên memory mà không hề đụng đến database bởi vì chúng cần thực hiện nhanh chóng và an toàn.

Thân mến.

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

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	08/03/2007 05:27:45 (+0700) \| #39 \| 45241

namviet
Member

Joined: 20/10/2003 11:31:31
Bài gởi: 20
Đến từ: miền cát trắng
Offline

comale wrote:

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

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 ạ ?! em vẫn chỉ biết 1 cách lưu trên máy client là qua cookie/GET(url)/POST(form) thôi!

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	08/03/2007 10:26:45 (+0700) \| #40 \| 45302

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Bài gởi: 1071
Đến từ: /dev/null
Offline

Memory ý anh conmale nó là dùng chung cho các dạng thức mà Browser dùng để lưu các thông tin "nhạy cảm" theo cách mà bạn nói smilie

Just clear, "What I need to do and how to do it"

Box tán gẫu dời về: http://www.facebook.com/hvaonline

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	08/03/2007 11:01:19 (+0700) \| #41 \| 45310

namviet
Member

Joined: 20/10/2003 11:31:31
Bài gởi: 20
Đến từ: miền cát trắng
Offline

@ 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 ?!

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	08/03/2007 11:30:43 (+0700) \| #42 \| 45313

stupidmistakez
Member

Joined: 10/08/2006 18:09:15
Bài gởi: 11
Offline

namviet wrote:

@ 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?

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	08/03/2007 11:44:50 (+0700) \| #43 \| 45318

namviet
Member

Joined: 20/10/2003 11:31:31
Bài gởi: 20
Đến từ: miền cát trắng
Offline

stupidmistakez wrote:

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?

Thực sự mình chưa rành về cái này , nhưng theo post của anh conmale:

conmale wrote:

- 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" />

Thì những thứ đó cũng chỉ là ở trong GET và POST thôi mà ?!

Có gì ngớ ngẩn xin được thông cảm và chỉ rõ smilie

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	09/03/2007 00:16:45 (+0700) \| #44 \| 45387

conmale
Administrator

Joined: 07/05/2004 23:43:15
Bài gởi: 9023
Đến từ: down under
Online

namviet wrote:

@ 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 điểm nên tránh đã nêu trong bài trước là tránh "vận chuyển" những thứ nhạy cảm như auth_key, pasword hash... Tránh chứa những thứ trên trong cookie và cookie không thuộc dạng "transient" (có nghĩa là cookie lưu trên đĩa của máy chạy trình duyệt chớ không hủy bỏ sau mỗi xuất truy cập).

Tất nhiên với giao thức HTTP, giữa client và server vẫn phải dùng những method thông thường như POST và GET để chuyển gởi thông tin. Tuy nhiên, cái khác biệt ở chỗ là những gì chuyển gởi và lưu chỉ có giá trị tạm thời hoặc không thể access từ một kẻ thứ ba.

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 ạ ?

Tạm thời hình dung thế này. Trên server, cứ mỗi lần một user đăng nhập, nó dành một mảng bộ nhớ để chứa trọn bộ các thông tin thuộc về user này, mỗi mảng được phân biệt bởi session id. Session id này do chính web application cung cấp và phải được xác thực mỗi khi client gởi request đến server để tránh tình trạng dùng session id không giá trị.

Web server
| session id 1 | session id 2 | session id 3| ... | session id n |

Trên máy client, giá trị session id này được lưu trong cookie (thường gặp) hoặc phương pháp URLrewrite (ứng dụng nhiều trên jsp / servlet). Nếu dùng persistent cookie (cookie lưu trong đĩa của client và có giá trị dài hạn) thì cookie phải được cập nhật để cập nhật giá trị session id lần kế tiếp đăng nhập. Nếu dùng transient cookie (cookie không lưu trên đĩa mà chỉ có giá trị đến khi nào trình duyệt bị tắt bỏ, cookie này lưu trên memory của trình duyệt), cookie này sẽ được tạo ra cho mỗi xuất truy cập.

Nếu session chấm dứt, web application hủy và xóa trọn bộ thông tin thuộc về session đó trên memory của server. Bởi thế, nếu ai dùng giá trị session id cũ và truy cập đến server thì sẽ được cấp một session id hoàn toàn mới vì session id cũ hiện không có trên server.

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

Hy vọng đã phần nào giải thích rõ hơn.

Thân mến.

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

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	06/05/2011 19:59:38 (+0700) \| #45 \| 236763

dazzlingvit
Member

Joined: 17/01/2011 20:58:03
Bài gởi: 36
Offline

conmale wrote:

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 ạ ?

Dazzling V.I.T
Hãy gọi tôi là vịt

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	06/05/2011 23:30:26 (+0700) \| #46 \| 236770

mrro
Administrator

Joined: 27/12/2001 05:07:00
Bài gởi: 683
Online

dazzlingvit wrote:

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 ạ ?

Có thể xảy ra nếu như trang thứ ba mà bạn nói có cùng origin [1] với abc.php. Nói cách khác, nếu mà đã bị XSS rồi thì kẻ tấn công có thể dễ dàng vượt qua các cơ chế phòng thủ CSRF.

[1] http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy.

-m

http://vnhacker.blogspot.com

Chuyển đến:

Các thành viên đang hiện diện ở đây
1 Khách