Series bảo mật nhập môn – CSRF – Những cú lừa ngoạn mục

Trong Tam Quốc, các bậc quân sư tài năng có tài điều binh khiển tưởng, ngồi trong trướng bồng quyết thắng cách đó hàng ngàn dặm.

Trong Tu Chân, các cao thủ có chiêu “Cách Không Thủ Vật” điều khiển đồ vật từ xa, hoặc “Ngự Kiếm Phi Hành”, dùng chân khí để điều động phi kiếm hay pháp bảo.

Ngày nay, hacker cũng có “chiêu thức” tương tự gọi là CRSF. Hacker có thể ngồi tại website A mà dụ dỗ người dùng tấn công site B và site C khác.

Bài viết này sẽ giải thích cách hacker tấn công, đồng thời hướng dẫn cách phòng chống cho các bạn lập trình viên nhé.

Cơ bản về CSRF 

CSRF có tên đầy đủ là Cross Site Request Forgery (Tên khác là XSRF). Lỗ hổng này khá phổ biến, Netflix và Youtube cũng từng là nạn nhân của lỗ hổng nó.

Hậu quả do nó gây ra cũng “hơi” nghiêm trọng nên CRSF hân hạnh được nằm trong top 10 lỗ hổng bảo mật của OWASP.

Nguyên tắc hoạt động của CRSF rất đơn giản. Ở bài trước, chúng ta biết rằng server sẽ lưu trữ cookie ở phía người dùng để phân biệt người dùng. Mỗi khi người dùng gửi một request tới một domain nào đó, cookie sẽ được gửi kèm theo.

1. Đầu tiên, người dùng phải đăng nhập vào trang mình cần (Tạm gọi là trang A).
2. Để dụ dỗ người dùng, hacker sẽ tạo ra một trang web độc.
3. Khi người dùng truy cập vào web độc này, một request sẽ được gửi đến trang A mà hacker muốn tấn công (thông qua form, img, …).
4. Do trong request này có đính kèm cookie của người dùng, trang web A đích sẽ nhầm rằng đây là request do người dùng thực hiện.
5. Hacker có thể mạo danh người dùng để làm các hành động như đổi mật khẩu, chuyển tiền, ….

Để dễ hiểu hơn, bạn hãy đọc phần ví dụ phía dưới nhé.

Các kiểu tấn công thường gặp

Kiểu 1. Dùng form

Ngày xửa ngày xưa, có hai anh em nhà nọ tên là Tưng và Tườn. Tưng, người anh, chăm lo học hành, chí thú làm ăn nuôi vợ con. Người em, Tườn thì người lại, suốt ngày lên thiên địa share hàng và tìm địa điểm mát xa.

Một hôm nọ, cãi nhau với vợ, Tưng buồn quá muốn bỏ đi mát xa. Tiếc thay, lên thiendia hỏi địa chỉ không ai cho vì Tưng tín dụng quá thấp.

Biết Tườn là thành viên cộm cán, Tưng bèn năn nỉ Tườn cho mượn acc nhưng vì sợ anh hư hỏng nên Tườn không cho. Đúng là anh em tốt!! Phẫn chí, Tưng quyết định dùng lỗi CSRF để chôm account của Tườn.

Ta hãy quan sát HTML của form đổi mật khẩu thiên địa. Form này gồm 2 field là password và password_confirm, submit tới http://thiendia.com/account/security-save

Tưng làm giả một trang web JAV, giả vờ gửi cho thằng em xấu số. Trong trang web có một form ẩn với các giá trị tương tự form trên (Các đồng d*m vui lòng để ý form HTML bên trái và button bên phải).

Thanh niên Tườn ngây thơ mù IT, lỡ tay vào link và bấm vào button. Một request đổi password được gửi đến thiendia, kèm theo cookie account của Tườn.

Thế là xong! Tưng chỉ cần dùng email + mật khẩu mới là 123456 để đăng nhập vào account của thằng em xấu số.

Kiểu 2. Dùng thẻ img

Chuyện tới đây chưa hết. Có địa điểm mát xa, nhưng tiền bạc do vợ nắm cả, Tưng không có tiền đi mát xa. Tưng quyết định hack luôn tài khoản ngân hàng của Tườn.

Tườn sử dụng JAVBank (Japan America Vietnam Bank). Mỗi lần chuyển khoản, ngân hàng sẽ tạo 1 URL. Giả sử người A muốn chuyển 1000 cho người B, url được tạo ra sẽ có dạng http://jav.bank?from=Person1&to=Person2&amount=1000.

Tưng bỏ url này vào 1 thẻ img. Khi Tườn truy cập trang, trình duyệt sẽ tự gọi GET request, gắn kèm với cookie trên JAVBank của Tường. Thông qua cookie, ngân hàng xác nhận đó là Tườn, chuyển tiền qua cho Tưng.

Có tiền lại có địa điểm, Tưng dối vợ lên đường mát xa. Chuyện về sau có nội dung 18+ nên mình không kể nữa….

Lưu ý

Tất nhiên, trong bài chỉ là ví dụ. Theo nguyên tắc, request GET chỉ được dùng để truy cập dữ liệu, không được dùng để thực hiện các hoạt động thay đổi dữ liệu như edit/delete.

Các ngân hàng thường bảo mật rất kĩ bằng cách set cookie có thời gian sống khá ngắn, không cho phép chuyển tiền mà không có code OTP v…v.

Ngoài ra, thiendia cũng có các biện pháp bảo mật khá tốt (xem phía dưới) nên các bạn không dùng cách này để chôm account của bạn bè được đâu, đừng thử nhé!

Tuy nhiên, ngày xưa, khi các lỗ hổng bảo mật còn chưa phổ biến thì đây là chính là cách mà hacker sử dụng. Chỉ cần post 1 tấm ảnh chứa đường dẫn như trên lên 1 forum nào đó, sẽ có vô số người dính bẫy khi truy cập vào forum đó.

Phòng chống cho website

Dưới đây là một số cách phòng chống CSRF cơ bản:

• Sử dụng CSRF Token: Trong mỗi form hay request, ta đính kèm một CSRF token. Token này được tạo ra dựa theo session của user. Khi gửi về server, ta kiểm tra độ xác thực của session này. Do token này được tạo ngẫu nhiên dựa theo session nên hacker không thể làm giả được (Các framework như RoR, CodeIgniter, ASP.NET MVC đều hỗ trợ CSRF token).

Ảnh minh hoạ từ thiên địa, trang này có CSRF token

• Kiểm tra giá trị Referer và Origin trong header: Origin cho ta biết trang web gọi request này. Giá trị này được đính kèm trong mỗi request, hacker không chỉnh sửa được. Kiểm tra giá trị này, nếu nó là trang lạ thì không xử lý request.
• Kiểm tra header X-Requested-With: Request chứa header này là request an toàn, vì header này ngăn không cho ta gửi request đến domain khác (chi tiết).
• Cần cẩn thận đề phòng lỗi XSS: Với XSS, hacker có thể cài mã độc trên chính trang web cần tấn công. Lúc này, mọi phương pháp phòng chống CSRF như token, referrer đều bị vô hiệu hoá. Bản thân bác juno_okyo từng áp dụng lỗi CSS kết hợp CSRF để tấn công sinhvienit.net (Chi tiết).

Kết

Ngày trước lỗi này khá nghiêm trọng và phổ biến. Gần đây các framework hầu như đều mặc định chống lỗi này nên tần suất gặp cũng ít đi. Tuy vậy ta vẫn phải đề phòng, nhất là các website tự code nhé (Đặc biệt là code bằng PHP, ahihi).

Ngoài ra, là một user, bạn cần biết tự bảo vệ mình theo nhiều cách sau:

• Đăng xuất khỏi account sau khi sử dụng để tránh lưu cookie.
• Không click quảng cáo hay button lung tung.
• Không ghé thăm các trang bậy bạ, nguy hiểm. Như đã nói phía trên, nhiều khi ta không bấm nút gì, chỉ cần truy cập trang, trình duyệt cũng tự động post dựa trên javascript hoặc thẻ img.

Nguồn để tham khảo thêm:

• https://en.wikipedia.org/wiki/Cross-site_request_forgery
• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
• http://stackoverflow.com/questions/17478731/whats-the-point-of-the-x-requested-with-header
• https://www.youtube.com/watch?v=m0EHlfTgGUU
• Định post thêm link thiên địa mà nghĩ lại ai cũng biết rồi nên thôi

Những bài viết khác thuộc Series bảo mật nhập môn

_ Series bảo mật nhập môn – SQL injection – Lỗ hổng bảo mật thần thánh

_ Series bảo mật nhập môn – lỗ hỏng bảo mật xss nguy hiểm đến mức nào?

_ Series bảo mật nhập môn – Lưu trữ cookie – tưởng hại ai ngờ hại không tưởng

_ Series bảo mật nhập môn – Giao thức HTTP “BẢO MẬT” đến mức nào

_ Series bảo mật nhập môn – Bảo mật cơ bản cho developer

Techtalk via toidicodedao