A cross-site request forgery (CSRF) là kiểu tấn công làm cho không biết HTTP yêu cầu từ đâu, thường nó yêu cầu quyền truy cập và sử dụng session của nạn nhân để truy cập. Yêu cầu HTTP sẩy ra khi nạn nhân dùng tài khoản của mình để mua hàng thay đổi hoặc xoá thông tin ngưòi dùng.
Khi một XSS tấn công khai thác sự tin tưởng của ngưòi dùng vào ứng dụng, một yêu cầu được gải mạo ứng dụng được người sử dụng tin tường, một yêu cầu đuợc cho là hợp pháp được gửi đi thât khó có thể phát hiện ra có phải thực sự người sự dụng muốn thưc hiện yêu cầu đó. Trong khi đó yêu cầu được đưa ra ngoài ứng dụng bạn, thường sử dụng là các cuộc tấn công CSRF. Nó sẽ không ngăn ngừa ứng dụng nhận yêu cầu gải mạo. Vậy ứng dụng của bạn phải có khả năng phát hiện yêu cầu hợp lệ trong đó có chứa mã có hại hay không
Ví dụ:
Chúng ta có 1 web site cho mọi người có thể đăng kí một account và họ có quyền xem các mục sách để mua . có thể giả thuyết rằng một kẻ có dã tâm
đăng kí một acount và quá trình sử lý mua sách là trong suốt với site. Cách thức này được phát hiện ra 1 cách tình cờ:
+ đăng nhập và mua hàng
+ Chọn 1 cuốn sách để mua rồi bấm vào nút “buy” nó sẽ chuyển đên trang checkout.php
+ Cô ấy nhìn thấy action check out là POST, nhưng các tham số checkout sẽ được bỏ vì chuỗi truy vấn(GET) làm việc
+ Khi đặt là checkout.php?isbn=0312863551&qty=1 thì thấy báo giao dịch thành công
Với điều mộ kẻ có dã tâm dễ dàng mua hàng trên 1 site mà không mất đồng nào. rễ dàng 1 người sử dụng có thể sử dụng chèn một thẻ ảnh (img) vào vùng không được phép. nội dung của thẻ img như sau:
<img src="http://example.org/checkout.php?isbn=0312863551&qty=1" /> Thậm chí image gắn ở site khác vẫn có thể tiếp tục tạo ra cái yêu cầu mua hàng trên site. Hầu hết mọi trường hợp yêu cầu thất bại bởi vì user phải đăng nhập mới mua được hàng. Sự tấn công nàylà sự tin tưởng của web site với người dùng. Giải pháp cho kiểu tấn công này thay thế POST bằng GET tấn công được là do checkout.php sử dụng $_REQUEST, mảng này sẽ truy cập và lấy isdn và qty. Chúng ta nên sử dụng POST để giảm thiểu rủi do về loại tấn công này. Nhưng nó không thể bảo vệ tất cả các yêu cầu đã được nguỵ tạo.
Một sự tấn công phức tạp có thể tạo yêu cầu POST rễ ràng bằng GET. Trừ khi có một phương pháp ngăn chặn phương pháp mã thông báo(token) này bắt buộc sử dụng form của bạn. Mã thông báo tạo ra bằng cách sinh ngẫu nhiên một mã thông báo và lưu nó trong session khi user truy cập trang chứa form sẽ đặt nó vào trong form dưói 1 trường ẩn. Sẽ sử lý kiểm tra mã thông báo POST từ form với giá trị lưu trong session. Nếu đúng thì nó là yêu cầu hợp lệ nếu sai thì không sử lý và thay vào đó là thông báo lỗi .
Ví dụ: < Mã: ?php
session_start();
$token = md5(uniqid(rand(), TRUE)); $_SESSION[’token’] = $token; ?>
<form action="checkout.php" method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>" /> <!-- Remainder of form -->
</form>
sử lý khi form được submit: if (isset($_SESSION[’token’]) && isset($_POST[’token’])
&& $_POST[’token’] == $_SESSION[’token’]) {
// Token is valid, continue processing form data }