Tìm Hiểu Lỗ Hổng Cross Site Request Forgery (CSRF)
Cross Site Request Forgery (CSRF) hay OnClick Attack là cùng 1 hình thức tấn công.
Phương pháp tấn công này không mới nhưng nhiều ae newbie vẫn chưa hiểu bản chất và cách hoạt động của nó. Hôm nay làm bài viết về csrf dựa trên exp cá nhân và bác mr.gugồ để giúp ae hiểu rõ hơn về csrf 
Có sai xót ae cùng đóng góp thảo luận nhe
[+] Khái niệm csrf anh em chúng ta hiểu nôm na là dùng chính victim (nạn nhân) để đâm victim.
[+] Tấn công: Attacker (kẻ tấn công) khi tấn công 1 victim cụ thể nào đó sẽ lừa victim đó:
<*>Click vào liên kết do attacker soạn ra để thực hiện mục đích của mình.
<**>Click vào web site do attacker tạo ra để lấy session còn hiệu lực của nạn nhân hoặc thực hiện những đoạn mã có chủ đích của kẻ tấn công.
*=> liên kết ở đây sẽ là gì? đó là 1 đoạn link dẫn đến site lỗi csrf mà victim đang có quyền đăng nhập và sẽ thực hiện những yêu cầu mà attacker tạo ra trên link đó.
Vd: ở trang forum.com (lỗi csrf) tôi đang có quyền mod, tôi tiến hành gửi cho admin 1 đoạn link dùng để nâng quyền tôi lên thành adm, liên kết như sau,
http://forum.com/setadmin.php?user=attacker&admin=ok
link trên có quyền nâng user là attacker lên thành admin <= khi admin click vào link này thì tôi lên làm admin trang forum
@>Để nâng cao hơn, tranh bị nghi ngờ, ta chèn qua thẻ src của hình ảnh
<img src=”http://forum.com/setadmin.php?user=attacker&admin=ok” height=”0″ width=”0″>
chú ý tham số height và width là rộng và cao của hình.
chèn qua thẻ link, bgsound, script…
<link ref=”stylesheet” type=”text/css” href=”http://forum…ok”/>
<bgsound src=”http://forum..ok”>
<script type=”text/javascript” src=”http://forum…ok”>
Hơi chuối 1 xíu :d nhưng ta có thể hỉu được :v
Chuyên nghiệp hơn nữa tránh ngi ngờ cho những ai cảnh giác, attacker sẽ đặt đoạn code đó trên web của hắn hoặc site uy tín như paypal hay nganluong (đã bị exploit và chèn code)…vd trên chatbox site abc chẳn hạn. nếu tôi chat:
http://abc.com/user.php?setup=admin&user=attacker thì bị ngi ngờ ngay,gì mà admin, setup ..tùm lum, tôi sẽ tạo web csrf.com hoặc exploit được site nào đó như nganluong[.]com và chèn ngay vào index site đó đoạn mã trên, gửi link site csrf hoặc nganluong ra chatbox với 1 lời mời hấp dẫn nữa thì chắc chắn sẽ ok hơn :d
**=> Nếu victim chỉ vào abc.com thì mọi việc bình thường, ta chẳng làm được gì cả. Vấn đề là khi victim đã login vào abc.com và sau đó, attacker gửi cho victim link đến trang của hắn là csrf.com và lừa click vào (trang này đã được chèn mã để lấy phiên làm việc của victim và chuyển hướng ngược lại abc.com để tránh bị nghi ngờ)
Vd: Tôi biết A đăng nhập vào abc.com, tài khoản A có thể xem,xóa, sửa, download,…nói chung là có quyền trên site abc này, tôi tiến hành gửi cho A web csrf.com mà tôi đã nhúng sẵn mã độc dùng để lấy session và ghi các thông tin cần thiết cho lần đăng nhập sau hay thực thi các lệnh cần làm, chỉ cần A vào csrf.com thì lập tức tôi đã có thể dùng nick của A để xóa, sửa, download …trên abc.com
Thêm 1 ví dụ về tiền cho dễ hiểu :v
Bạn có tài khoản ở baokim, đang đăng nhập vào baokim, và vô tình hay cố ý đã truy cập vào site csrf.com do tôi tạo ra, trên csrf.com tôi chèn 1 iframe chuyển tiền, code demo:
<iframe src=”http://baokim.com/chuyentien.php?sotien=100000&nguoinhantien=attacker”/>
-> bạn sẽ chuyển 100k vào tài khoản của tôi
Tinh vi hơn thì tôi chèn thêm đoạn html trong 1s chuyển hướng ngược lại trang baokim thì bạn sẽ không hiểu vì sao mất 100k )
code html:
<meta http-equiv=”refresh” content=”1;url=site-baokim/”>
Trên là ít ví dụ tôi đưa ra cho cách tấn công này, nhưng còn rất rất nhiều cách che dấu khác nữa, với sự biến hóa, ẩn dấu và lừa tình vô cùng đa dạng của các attacker thì nhiều khi victim không nhận ra được mình bị tấn công, trên log file cũng không ghi lại được dấu hiệu gì của cuộc tấn công vì do chính vitim tự thiến mình mà :v
Mặt khác, attacker phải nguyên cứu rất kỹ về victim, về site và các tham số truyền vào qua get post của site đó.
[+] Phòng chống csrf có rất nhiều cách như tạo token có time sống ngắn (điển hình là vụ paypal bị exploit csrf do để token dùng đi dùng lại nhiều lần), tạo capcha cho những thao tác. có người nói dùng post thay cho get vì get truyền dữ liệu bằng text không mã hóa, nhưng tôi thấy post vẫn có thể attack bằng các script thông qua form submit…
ngoài ra nên giới hạn time cho session, nhập lại mật khẩu cho những thao tác quan trọng (có lần mình đã login panel bằng cookie nhưng không làm được gì ngoài hóng ra vì không có pass 
) và facebook cũng dùng cách này để ngăn csrf attack.
Và cuối cùng là yếu tố con người, nhìn chung vẫn là phương pháp social engineering (SE), nên cảnh giác với từng click vào các đướng link lạ
Hết!
Nguồn ceh.vn | Đã Edit