CSRF Attack Technical and Secure
Trang 1 trong tổng số 1 trang
CSRF Attack Technical and Secure
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....
http get đến địa chỉ lưu trong thẻ "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 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ẻ "
" target="_blank" rel="nofollow">http://www.ahackersite.com/abc.jpg"/>
và cấu hình lại máy chủ
Redirect 302/abc.jpg http://mexicobank.com/withdraw?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:
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.
Đâ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 )
Đ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 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....
- Code:
<img height=0" width="0" src="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id"/>
http get đến địa chỉ lưu trong thẻ "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 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ẻ "
- Code:
<iframe height="0" width="0" src="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id"/>
<link ref="stylesheet" href="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id" type="text/css"/>
<bgsound src="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id"/>
<background src="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id"/>
<script type="text/javascript" src="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id"/>
- Code:
"<img",người dùng có thể nhận ra nếu vào đường link chứa trong src="http://mexicobank.com/withdraw?account=bob_id&amount=1000000&for=Malory_ id"/>.
" target="_blank" rel="nofollow">http://www.ahackersite.com/abc.jpg"/>
và cấu hình lại máy chủ
Redirect 302/abc.jpg http://mexicobank.com/withdraw?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:
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.
- Code:
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,session.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 )
- Code:
<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
Similar topics
» Khai thác và phòng chống Path Traversal Attack
» Attack ARP spoofing
» Layer 2 attack: MAC flooding
» Kỹ thuật attack một website
» Phòng chống local attack!
» Attack ARP spoofing
» Layer 2 attack: MAC flooding
» Kỹ thuật attack một website
» Phòng chống local attack!
Trang 1 trong tổng số 1 trang
Permissions in this forum:
Bạn không có quyền trả lời bài viết
27/8/2013, 11:45 am by echcondihoc
» Quản Lí Tiến Trình Dùng Thư Viện PSAPI
11/10/2011, 9:42 pm by CNTT_DH
» xin tai lieu tieng viet
31/8/2011, 6:59 am by bantoisg
» Theo dõi tiến trình
27/8/2011, 5:51 pm by haigaopro01
» Giải pháp Bảo mật của Cisco
17/6/2011, 8:50 am by admin
» Nghiên cứu và đưa ra giải pháp phòng chống tấn công DoS, DDoS (Phần 1)
16/6/2011, 2:32 pm by admin
» Learn to hack !
16/6/2011, 8:49 am by admin
» Giải pháp hệ thống dành cho doanh nghiệp với thiết bị mạng Fortinet (Phần 1)
15/6/2011, 11:12 am by admin
» Ô Long Viên (Tập II)
27/9/2010, 4:56 pm by root
» những ebook về hack tiếng việt cho người mới tìm hiểu.
27/9/2010, 4:54 pm by root