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)	29/01/2007 11:23:32 (+0700) \| #1 \| 38927

conmale
Administrator

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

Cross site request forgery là gì? Nó là phương pháp mượn tay người để thực hiện một hành động không cho phép. Ví dụ, để có thể xóa một bài viết trên diễn đàn, một member có thể mượn tay của một moderator để làm việc đó vì member không đủ chủ quyền nhưng moderator lại đủ chủ quyền để thực hiện hành động này.

Chi tiết về CSRF (hay XSRF) ở đây:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
http://www.tux.org/~peterw/csrf.txt

Gần đây (cách đây 2 tuần), mrro có post một chủ đề rất lý thú trong khu vực ban quản trị để đưa ra vấn đề này này với nội dung như sau:

mrro wrote:

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

Thông tin này được nbthanh diễn giải thêm:

nbthanh wrote:

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.

Tiếp theo đó, mrro khai triển thêm:

mrro wrote:

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.hva?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 đó.

Vậy.... thử bàn giải pháp khắc phục xem sao? smilie

).

Thân.

Il est interdit d’interdire!

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	29/01/2007 17:02:25 (+0700) \| #2 \| 38992

PHUCDOAN
Member

Joined: 04/08/2006 23:50:25
Bài gởi: 32
Offline

Xin góp ý vậy thôi:
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) .
2- script 'confirm' nên đặt ở trang delete_result để chắc chắn mỗi record bị xóa đều có confirmation.
Trình độ có hạn chỉ nghĩ được đến đó thôi mong đừng chê trách.

Biết thì thưa thì thốt
Không biết thì dựa cột mà nghe
Chớ khoe khoang ta đây Hacked
Làm thì ít mà tính thì nhiều.
__________________________________________
* Im lặng là 1 nghệ thuật. *

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	29/01/2007 21:42:32 (+0700) \| #3 \| 39035

xnohat
Elite Member

Joined: 30/01/2005 13:59:19
Bài gởi: 371
Đến từ: The Hell
Offline

Yêu cầu truyền một chuỗi hash vào server script.
Hash này có thể chính là session id truyền trực tiếp lên URI qua GET method.Mọi script sẽ check sự tồn tại của dòng Session này với session id load từ server.

Nếu trùng tức là đang đúng người chủ của session còn không tức là kẻ đang tiến hành CSRF, vì kẻ dụng dao giết người không thể lấy được session ID của vị Moderator vì mỗi lần login vị này có một SessionID khác nhau.

Đó là ý tưởng nảy ra trong đầu em chưa xác thực nên không biết có phù hợp không.

Công ty mình có dịch vụ thiết kế Website,tư vấn xây dựng hệ thống nhận diện thương hiệu, đạt chất lượng cao về tính mỹ thuật và hiệu quả tiếp thị
http://www.onesupport.net
Skype: PhucOS
Email: contact@onesupport.net

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	30/01/2007 02:11:58 (+0700) \| #4 \| 39059

WinDak
Elite Member

Joined: 27/01/2002 11:15:00
Bài gởi: 15
Đến từ: NTU
Offline

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

To live is to fight

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	30/01/2007 03:20:21 (+0700) \| #5 \| 39061

conmale
Administrator

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

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

Il est interdit d’interdire!

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	30/01/2007 12:49:25 (+0700) \| #6 \| 39083

watchd0g
Member

Joined: 30/11/2006 18:05:23
Bài gởi: 42
Offline

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.

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	30/01/2007 17:05:21 (+0700) \| #7 \| 39134

conmale
Administrator

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

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 smilie

Il est interdit d’interdire!

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	30/01/2007 23:21:21 (+0700) \| #8 \| 39190

vietwow
Member

Joined: 28/06/2006 13:15:47
Bài gởi: 87
Offline

Em có 1 thắc mắc hơi ngoài lề xíu, theo em biết khi submit 1 thông tin lên web server thì giao thức HTTP dùng phương pháp POST còn GET chỉ được dùng khi 1 user nào đó muốn "lấy" thông tin về browser của họ, trường hợp ở đây là user submit 1 URL :http://hvaonline.net/hvaonline/jforum.hva?module=posts&action=delete&post_id=12345&start=0

Như vậy thì phải dùng POST mà sao forum hva lại dùng GET nhỉ ??

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 00:31:11 (+0700) \| #9 \| 39203

Mr.Khoai
Moderator

Joined: 27/06/2006 01:55:07
Bài gởi: 901
Offline

Gửi vietwow: Theo khoai được biết, POST chỉ dùng khi bạn cần đưa thật nhiều dữ liệu lên server. Cái đống dữ liệu đó sẽ không thể nằm trọn trong HTTP header, do đó mới dùng method POST và đặt cái dữ liệu vào HTTP payload. Khi đó thì không ngại việc giới hạn của HTTP header size nữa. Còn nếu chỉ muốn đưa một lượng thông tin nhỏ lên server thì có thể đặt trực tiếp trên url. Như vậy, một method POST với url như của bạn:
Code:

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

sẽ không cần thiết có payload.

khoai

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 00:52:31 (+0700) \| #10 \| 39205

mudzot
Elite Member

Joined: 26/06/2006 14:41:27
Bài gởi: 78
Offline

Theo em nghĩ để chống CSRF kiểu này thì chuyển tiếp qua 1 trang để confirm trước khi thực thi là tốt nhất. Tuy nhiên phân tích tiếp em thấy có thể làm đơn giản hơn :

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.

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

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

WinDak
Elite Member

Joined: 27/01/2002 11:15:00
Bài gởi: 15
Đến từ: NTU
Offline

conmale wrote:

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?

^^ uhm, anh nói đúng ạ, nhưng với trường hợp riêng ở trên, thì thay POST cho GET là đưa về tình trạng chung của hệ thống phải không ạ.

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)

Về việc add thêm 1 trường đặc biệt vào trong request gửi đi, theo em vẫn có cách bypass nếu như attacker sử dụng được javascript (XSS ?)...
ví dụ ta có thể xài getElementbyID hoặc document.form[x].field.value etc...

To live is to fight

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 02:17:49 (+0700) \| #12 \| 39213

gamma95
Researcher

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

@mudzot:

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.

referer thì làm giả cái một smilie

Mài bèo wá gà mờ ơi ... ráng tu luyện thành gà nòi tao coi coi smilie

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 13:47:48 (+0700) \| #13 \| 39263

xnohat
Elite Member

Joined: 30/01/2005 13:59:19
Bài gởi: 371
Đến từ: The Hell
Offline

conmale wrote:

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

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

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 14:06:02 (+0700) \| #14 \| 39267

PHUCDOAN
Member

Joined: 04/08/2006 23:50:25
Bài gởi: 32
Offline

conmale wrote:

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

sặc..... lạy mấy anh. nếu OpenSource thì không bàn gì nữa. Giả dụ nó là 1 site bình thường xem sao nào?

ý kiến pác nohathacker thú vị thật, tui thì chỉ lấy kinh nghiệm lập trình của mình thôi.
Thanks & regards

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 15:17:09 (+0700) \| #15 \| 39279

conmale
Administrator

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

hackernohat wrote:

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.

Ở đây mình chỉ bàn ở giới hạn xsrf thôi. Nếu nó còn dính xss nữa thì phải nói là cực kỳ nguy nan smilie

hackernohat wrote:

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.

Giải thuật tạo SESSIONID thì có đầy ra đó. Từ php sang asp, jsp.... đều có tài liệu khắp nơi. Có cả tool để làm việc phân tích và đoán SESSIONID nữa. Tuy nhiên, xác suất đoán ra SESSIONID khá thấp. Nếu giá trị hash đó không phải chỉ lấy ở SESSIONID mà còn một số dữ kiện đặc thù khác của từng người dùng thì sao mà đoán được? smilie

hackernohat wrote:

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

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 đó? smilie

)

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?

Il est interdit d’interdire!

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	31/01/2007 16:49:18 (+0700) \| #16 \| 39291

PHUCDOAN
Member

Joined: 04/08/2006 23:50:25
Bài gởi: 32
Offline

conmale wrote:

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 đó? )

Nể ông anh thiệt. Từ tư dẫn lối cho ae thấy nhé smilie

conmale wrote:

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?

tôi không ám chỉ opensource ko an toàn (đang sử dụng opensource muh). Vì tui đang nói đến cách geturl của 1 site bất kì chứ đâu có đề cập đến 1 OpenSource nào đâu, rõ khổ, OpenSource thì ai cũng có bàn làm gì??????

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	01/02/2007 12:34:56 (+0700) \| #17 \| 39453

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Bài gởi: 627
Offline

em cũng tìm kiếm nhiều, nghĩ ra mộ cách là hide sessionID này đi, nhưng hình như nó ko hiệu quả.
Nếu anh "mở" thêm 1 chút nữa, chắc em cũng kiếm đc 1 vài cái nữa
Waiting.........

no sacrifice, no victory.

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	02/02/2007 00:36:24 (+0700) \| #18 \| 39546

omega-toplist
Member

Joined: 15/12/2006 11:10:04
Bài gởi: 3
Offline

Trích cả đoạn trong sách ra để tham khảo cho nó dễ, không biết cái này có giúp ích gì cho các bác

Session Hijacking
The most common session attack is session hijacking . This refers to any method that an attacker can use to access another user's session. The first step for any attacker is to obtain a valid session identifier, and therefore the secrecy of the session identifier is paramount. The previous sections on exposure and fixation can help you to keep the session identifier a shared secret between the server and a legitimate user.

The principle of Defense in Depth can be applied to sessions some minor safeguards can offer some protection in the unfortunate case that the session identifier is known by an attacker. As a security-conscious developer, your goal is to complicate impersonation. Every obstacle, however minor, offers some protection.

The key to complicating impersonation is to strengthen identification. The session identifier is the primary means of identification, and you want to select other data that you can use to augment this. The only data you have available is the data within each HTTP request:

GET / HTTP/1.1
Host: example.org
User-Agent: Firefox/1.0
Accept: text/html, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234

You want to recognize consistency in requests and treat any inconsistent behavior with suspicion. For example, while the User-Agent header is optional, clients that send it do not often alter its value. If the user with a session identifier of 1234 has been using Mozilla Firefox consistently since logging in, a sudden switch to Internet Explorer should be treated with suspicion. For example, prompting for the password is an effective way to mitigate the risk with minimal impact to your legitimate users in the case of a false alarm. You can check for User-Agent consistency as follows:

<?php

session_start();

if (isset($_SESSION['HTTP_USER_AGENT']))
{
if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT']))
{
/* Prompt for password */
exit;
}
}
else
{
$_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);
}

?>

I have observed that some versions of Internet Explorer send a different Accept header depending upon whether the user refreshes the browser, so Accept should not be relied upon for consistency.

Requiring a consistent User-Agent helps, but if the session identifier is being propagated in a cookie (the recommended approach), it is reasonable to assume that, if an attacker can capture the session identifier, he can most likely capture the value of all other HTTP headers as well. Because cookie disclosure typically involves a browser vulnerability or cross-site scripting, the victim has most likely visited the attacker's web site, disclosing all headers. All an attacker must do is reproduce all of these to avoid any consistency check that uses HTTP headers.

A better approach is to propagate a token in the URLsomething that can be considered a second (albeit much weaker) form of identification. This propagation takes some workthere is no feature of PHP that does it for you. For example, assuming the token is stored in $token, all internal links in your application need to include it:

<?php

$url = array();
$html = array();

$url['token'] = rawurlencode($token);
$html['token'] = htmlentities($url['token'], ENT_QUOTES, 'UTF-8');

?>

<a href="index.php?token=<?php echo $html['token']; ?>">Click Here</a>

To make propagation a bit easier to manage, you might consider keeping the entire query string in a variable. You can append this variable to all of your links, which makes it easy to refactor your code later, even if you don't implement this technique initially.

The token needs to be something that cannot be predicted, even under the condition that the attacker knows all of the HTTP headers that the victim's browser typically sends. One way to achieve this is to generate the token using a random string:

<?php

$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';

$token = md5($string);
$_SESSION['token'] = $token;

?>

When you use a random string (SHIFLETT in this example), prediction is impractical. In this case, capturing the token is easier than predicting it, and by propagating the token in the URL and the session identifier in a cookie, multiple attacks are needed to capture both. The exception is when the attacker can observe the victim's raw HTTP requests as they are sent to your application, because this discloses everything. This type of attack is more difficult (and therefore less likely), and it can be mitigated by using SSL.

Some experts warn against relying on the consistency of User-Agent. The concern is that an HTTP proxy in a cluster can modify User-Agent inconsistently with other proxies in the same cluster.

If you do not want to depend on User-Agent consistency, you can generate a random token:

<?php

$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;

?>

This approach is slightly weaker, but it is much more reliable. Both methods provide a strong defense against session hijacking. The appropriate balance between security and reliability is up to you.

Omega-Toplist

[Hỏi đáp] Re: Thảo luận: cross site request forgery (CSRF hay XSRF)	02/02/2007 15:05:23 (+0700) \| #19 \| 39646

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Bài gởi: 627
Offline

cách của bro ko đc, HVA dùng JForum mà
-----------------------------------------------
Tối hôm qua vắt tay lên trán nghĩ tới nghĩ lui,keke, nghĩ thêm đc chút, post lên đây xem thế nào.
Theo em cookies là trở ngại lớn trong vấn đề này. Cả 2 cái sessionID và hash đều lấy từ Cookies ra cả.
VD thế này:
Khi anh Conmale hay bác mod nào logon, thông tin logon đc lưu vào cookies, sau đó vào một topic có kèm link này

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

(link của bài đầu)

Cái url trong src=".." bắt buộc phải truy xuất thằng Cookies để có đc quyền của anh, sau đó mới delete bài đc <=phải ko a.?ko đúng thì bỏ quá cho em,hihi.
Với suy nghĩ trên em nêu ra đc một cách, chẳng hạn như anh làm cách nào đó cho cookies ko tham gia vào quá trình này ( chắc mod phải đăng nhập liên tục quá) hoặc: xác định những url có khả năng là CSRF, sau đó thiết lập một rule, giống dạng signature ko cho queue Cookies là có thể giải quyêt đc.
Vài ý kiến.

no sacrifice, no victory.

[Hỏi đáp] Thảo luận: cross site request forgery (CSRF hay XSRF)	02/02/2007 15:31:08 (+0700) \| #20 \| 39649

Luke
Elite Member

Joined: 05/09/2002 13:21:20
Bài gởi: 82
Offline

Theo Luke nghĩ thì việc giả POST cũng không khó
có thể convert GET sang POST thông qua việc sửa lại request qua 1 file trên server mình.
Victim -> Malcious Site -> IMG Tag -> GET -> Attacker php/asp/jsp.. -> POST -> Victim's Server
Tuy nhiên cách này thì ko thể tận dụng được cái HTTP_REFERER
Nhưng xét cho cùng thì chẳng có mấy ai check cái HTTP_REFERER và khi đưa về server mình xử lí thì việc tạo ra multi-broadcasting request càng dễ.

Nói ngắn gọn để đỡ bị "châm".

Chuyển đến:

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