YII Framework: Sử dụng token để tránh lỗ hổng CSRF

CSRF (Cross Site Request Forgery) là kĩ thuật tấn công bằng cách sử dụng quyền chứng thực của người sử dụng đối với 1 website khác. Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử dụng, sau đó thực thi các câu lệnh này.

Hacker sử dụng phương pháp CSRF để lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng dụng web. Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ dc thực hiện với quyền chứng thực của người sử dụng.

CSRF còn dc gọi là “session riding“, “XSRF“

Thật may trong Yii Framework đã được tính hợp sẵn YII_CSRF_TOKEN nên bạn chỉ cần gọi ra và sử dụng là được.

Bạn cần mở file config/main.php. Tìm và thêm  ‘enableCsrfValidation’=>true

return array(
    'components'=>array(
        'request'=>array(
            'enableCsrfValidation'=>true,
        ),
    ),
);

Tên mặc định của CSRF Token trong YII sẽ là: YII_CSRF_TOKEN, nếu muốn đổi bạn thêm: ‘csrfTokenName’=>’TÊN_TOKEN_CỦA_BẠN’

'request'=>array(    
    'enableCsrfValidation'=>true,
    'csrfTokenName'=>'TÊN_TOKEN_CỦA_BẠN',
),

Trên tất cả các form gửi đi bằng phương thức POST bạn cần thêm trường

<input 
type="hidden" 
name="<?php echo Yii::app()->request->csrfTokenName; ?>" 
value="<?php echo Yii::app()->request->csrfToken; ?>"
>

Nếu không sẽ xảy ra lỗi: 400 – The CSRF token could not be verified.

Đối với các Request gửi đi bằng AJAX bạn cần phải thêm vào POST DATA trước khi gửi đi:

data: { 
 <?php echo Yii::app()->request->csrfTokenName; ?>: '<?php echo Yii::app()->request->csrfToken ?>'
}

Lịch sử về tấn công CSRF

Các kiểu tấn công CSRF xuất hiện từ những năm 1990, tuy nhiên các cuộc tấn công này xuất phát từ chính IP của người sử dụng nên log file của các website k cho thấy các dấu hiệu của CSRF. Các cuộc tấn công theo kĩ thuật CSRF k dc báo cáo đầy đủ, đến năm 2007 mới có một vài tài liệu miêu tả chi tiết về các trường hợp tấn công CSRF.

Năm 2008 người ta phát hiện ra có khoảng 18 triệu người sử dụng eBay ở Hàn Quốc mất các thông tin cá nhân của mình. Cũng trong năm 2008, một số khách hàng tại ngân hàng Mexico bị mất tài khoản cá nhân của mình.Trong 2 trường hợp kể trên hacker đều sử dụng kĩ thuật tấn công CSRF.

Kịch bản tấn công CSRF

Người dùng Alie duyệt qua 1 diễn đàn yêu thích của mình như thường lệ. Một người dùng khác, Bob đăng tải 1 thông điệp lên diễn đàn. Giả sử rằng Bob có ý đồ k tốt và anh ta muốn lấy tiền từ những người có tài khoản tại ngân hàng như Bob. Alie sẽ tạo 1 thông báo, trong đó có chèn 1 đoạn code như sau:

eBank vừa công bố lãi xuất mới….<img height=0″ width=”0″ src=”http://eBank.com/withdraw?
account=bob_id&amount=1000000&for=Alie_ id”/>

Đoạn mã trên dc che giấu rất khéo léo, thứ nhất nó thêm các thông điệp bình thường để người dùng không chú ý. Thứ hai thẻ “<img” sử dụng trong trường hợp này có kích thước 0x0 pixel và người dùng sẽ không thể thấy dc. Giả sử Alie vừa mới truy cập vào tài khoản ngân hàng của mình và chưa thực hiện logout để kết thúc. Trình duyệt của Bob sẽ gửi câu lệnh HTTP GET đến địa chỉ lưu trong thẻ “<img” trong đoạn mã trên và nó sẽ dc thực hiện bằng quyền chứng thực của Bob.

Trong ví dụ trên hacker có thể sử dụng 1 URL khác, ví dụ: http://www.projectpage.com/admin/project/13/delete để xóa đi một dự án quan trọng nào đó mà Bob đang làm. Một chú ý là cần phải có 1 chút kĩ thuật về Social Engineering để có thể biết dc victim sử dụng tài khoản ngân hàng nào, account của dịch vụ nào và forum thường hay vào là gì.  Xem thêm Social Engineering

Ngoài thẻ “<img“, các thẻ html có thể sử dụng kĩ thuật trên có thể là:

1. <iframe height=”0″ width=”0″ src=”http://eBank.com/withdraw? account=bob_id&amount=1000000&for=Alie_ id”/>
2. <link ref=”stylesheet” href=”http://eBank.com/withdraw?account=bob_id&amount=1000000&for=Alie_ id” type=”text/css”/>
3. <bgsound src=”http://eBank.com/withdraw?account=bob_id&amount=1000000&for=Alie_ id”/>
4. <background src=”http://eBank.com/withdraw?account=bob_id&amount=1000000&for=Alie_ id”/>
5. <script type=”text/javascript” src=”http://eBank.com/withdraw?account=bob_id&amount=1000000&for=Alie_ id”/>

Các kĩ thuật CSRF rất đa dạng, lừa người dùng click vào link, gửi email chứa các đoạn mã độc đến người dùng… Hacker còn có thể che giấu các link ở trên rất khéo léo. Ví dụ trong trường hợp thẻ “<img“, người dùng có thể nhận ra nếu vào đường link chứa trong <ing src=”http://eBank.com/ withdraw?account=bob_id&amount=1000000&for=Alie_ id”/> Tuy nhiên, người dùng sẽ rất có phát hiện nếu hacker dùng đường link như sau: <img height=”0″ width=”0″ src=” http://www.ahackersite.com/abc.jpg”/> và cấu hình lại máy chủ: Redirect 302/abc.jpg http://eBank.com/withdraw?account=bob_id&amount=1000000&for= Alie_ id”/>. Như vậy người dùng sẽ rất khó để có thể phát hiện, vấn đề trách nhiệm phần lớn thuộc về các website của các nhà cung cấp.

Trong bài tới tôi sẽ giới thiệu tiếp với các bạn các cách để phòng tránh CSRF đối với người dùng và đối với người phát triển website.

Tham khảo thêm từ Internet – và thằng bạn làm YII đã nhiều năm.