• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Những lỗi bảo mật web thường gặp ở phần application
 

Những lỗi bảo mật web thường gặp ở phần application

on

  • 5,058 views

Giải thích về session, cookie v.v.

Giải thích về session, cookie v.v.

Statistics

Views

Total Views
5,058
Views on SlideShare
5,058
Embed Views
0

Actions

Likes
2
Downloads
114
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Những lỗi bảo mật web thường gặp ở phần application Những lỗi bảo mật web thường gặp ở phần application Presentation Transcript

    • GNTech Seminar Những lỗi bảo mật web thường gặp ở phần application
    • Mục đích buổi seminar Load balancer Web server Application MySQL Memcached ... Những phần khác application thì cả thế giới đều dùng chung nên cả thế giới đều ra sức bịt lỗi bảo mật. Còn phần application lập trình viên tự viết nên phải tự giải quyết. => Chúng ta là lập trình viên web. Buổi seminar này nâng cao hiểu biết về các lỗi bảo mật thường gặp ở phần application, phần do chính chúng ta tự tay tạo ra !
      • GNT sẽ triển khai sang mảng web cho PC. Web cho PC phức tạp hơn, dễ bị lỗ hổng bảo mật hơn. (Càng phức tạp càng dễ bị lỗ hổng ← Một trong nhiều lí do nên dùng framework vì nó giúp giảm độ phức tạp!)
      • => Chúng ta cần:
      • Nâng cao kiến thức về lập trình web cho PC (để viết được + viết với năng suất cao)
      • Tìm hiểu các lỗi bảo mật và cách tránh
      ...
    • Triết lí để tránh lỗi bảo mật
      • Lỗ hổng chẳng qua là do lòng tin bị lợi dụng mà thôi
      • Input (bảo vệ mình): không được tin tưởng 100% thông tin đến từ nguồn không tin cậy mà không có bước kiểm tra
      • Output (bảo vệ những người khác): khi xuất thông tin cho user, cần kiểm tra xem thông tin xuất ra có gây tổn hại cho user hay không
    • Input: Lợi dụng lòng tin của server dành cho user Output: Lợi dụng lòng tin của user dành cho server
    • Căn bản về session Nhiều lỗ hổng liên quan đến session => Trước hết chúng ta ôn lại về session
    • WHAT: Session là gì? Server Client Cùng 1 client Server nhận nhiều request độc lập Vấn đề là server phải làm sao để nhận biết chúng cùng thuộc về 1 user => Khái niệm session Request Request Request
    • Ví dụ thực tế
      • Mỗi lần Trần Quang Độ đến máy ATM
      • để rút tiền,
      • làm sao máy ATM biết
      • Trần Quang Độ đúng là Trần Quang Độ?
    • HOW: Các cách lưu session
      • Vấn đề: Giao thức của web là HTTP. HTTP là stateless protocol, nghĩa là bản thân chuẩn HTTP không qui định sẵn 1 cách lưu session nào cả, để bà con cứ thế mà theo. => Có nhiều cách!
      Nhóm 1: Chỉ lưu ở client * Nhúng vào URL (href của link hoặc action của form) * Cookie Nhóm 2: Lưu ở cả client và server * Client: chỉ lưu key (lưu ở URL hoặc cookie) * Server: lưu key và value (lưu ở file, memory, ở máy khác (DB, memcached v.v.)) Chắc chắn phải lưu cái gì đó ở client Session thường được biểu diễn dưới dạng hash (key-value)
    • Demo
      • Cách lưu session của:
      • * Java Servlet 2.5: adon.jp
      • * Rails 3
    • Q: Cookie là gì?
    • A: Header Key – Value Key – Value Body Header Key – Value Set-Cookie – Value Key – Value Body Header Key – Value Cookie – Value Key – Value Body Client Server Cookie là opaque data: server set cái gì trong response thì client lần request sau sẽ trả về nguyên xi Response Request Request
    • Q: Làm thế nào để thực hiện tính năng login cho trang web?
    • Lời khuyên về session
      • Session không là nơi lưu trữ tạm, lập trình viên muốn lưu cái gì thì lưu. Khi thiết kế chương trình, cần qui định sẵn trong tài liệu thiết kế là session sẽ lưu cái gì.
      • Khi xử lí form, không lưu dữ liệu tạm (để chuyển giữa các màn hình) trong session. Ví dụ logic sẽ sai nếu 2 lập trình viên dùng cùng key hoặc các form dùng chung key => adon.jp đang bị, sửa chỉ có cách viết lại toàn bộ -> Lưu vào <input type=”hidden”... />
      • Không lưu value lớn trên client (URL: 1KB, cookie: 4KB) -> Lưu trên server
      • Không lưu dữ liệu quan trọng, mang tính persistent trong session (ví dụ lưu trong memory + server down là mất hết) -> Lưu trong DB
    • Mục lục
      • SQL injection
      • CSRF
      • Redirection (một trong nhiều cách phishing)
      • Cookie replay
      • XSS
      • Session fixation
      • Các lỗi có thể:
      • * Liên quan với nhau, ví dụ XSS và session fixation, XSS và CSRF
      • * Bị nhầm với nhau, ví dụ XSS hay bị nhầm với CSRF
    • SQL injection
      • Cách tránh:
      • * Dùng prepared statement ← Ưu tiên số 2
      • * Dùng hàm tiện ích để SQL escape tham số
      • Hầu hết các framework và thư viện đều giúp escape sẵn ← Ưu tiên số 1
    • CSRF Trên blog của mình, nạn nhân Camanh viết: Khóc... như một đứa trẻ bị người khác giật lấy 200 trang nhật ký... xé tan... Q: 2 screenshot giống nhau ở điểm nào? http://vnexpress.net/Vietnam/Vi-tinh/Hacker-Virus/2007/03/3B9F3B21/ http://vnexpress.net/Vietnam/Vi-tinh/2007/03/3B9F3BF1/
      • Nguyên nhân:
      • Lập trình viên (và designer !) lẫn lộn GET và POST, dùng GET để sửa, xóa, tạo v.v. dữ liệu
      • <a>, <img>, <form method=”get”> ← GET
      • (<a> có thể là POST nếu dùng Ajax, lúc này <a> chỉ dùng để tạo event)
      • Cách nhớ: GET = lấy = copy dữ liệu từ server về, nên không được làm thay đổi dữ liệu trên server
      • Thậm chí không cần lừa user phải click,
      • chỉ cần xem nội dung trang web là đã chết ngay:
      • <img src=”http://vn.blog.yahoo.com/setup/profile_photo.php?act=del&prf_photo=1” />
      • Cách tránh:
      • * Dùng POST khi không phải là GET (link có thể là POST nếu dùng Ajax)
      • * Form phải dùng POST trừ form đặc biệt, ví dụ form search
      • * Thậm chí dùng POST cũng vẫn chết như thường (xem XSS) => Cần dùng kèm token (mà user này không thể đoán ra được token của user kia, ví dụ session ID)
      • * Có thể dùng GET, nhưng URL phải chứa token
      • <img src=”http://...?act=del&prf_photo=1&token=16d5b78abb28e3d6206b60f22a03c8d9” />
    • Redirection (một trong nhiều cách phising)
      • Khi user vào trang http://mobion/abc nào đó, server kiểm tra nếu user chưa login thì sẽ redirect user đến /login?url= http://mobion/abc
      • Sau khi user login thành công, server sẽ redirect user đến url ở trên
    • Cookie replay
      • Trang web lưu session ở client only (URL hoặc cookie ← Lỗi thường gặp với cookie hơn)
      • Số tiền trong tài khoản load từ DB hoặc đâu đó lưu tạm ở session
      • User mua đồ => bị trừ tiền trong session
      • User set lại session => số tiền ban đầu được phục hồi
      • Cách tránh: Lưu session ở server, hoặc không lưu tài khoản trong session
    • XSS
      • Bị lỗi này là thôi rồi, hacker coi như toàn quyền điều khiển trang web (có thể làm giả mọi user khi họ truy cập vào trang chứa nội dung do hacker post). Hacker có thể lợi dụng để tấn công chính site này và những site khác (nếu chúng bị lỗi bảo mật khác như CSRF)
      • <script>$.post(“/delete_article/1”)</script>
      • <script>$.post(“http://mobion.com/delete_article/1”)</script>
      • Cách tránh:
      • * Nếu trang web chỉ cho user nhập plain text: HTML escape (HTML escape chứ không phải SQL escape) chuỗi khi xuất ra cho user
      • * Nếu trang web cho phép user nhập HTML: Cần qui định chỉ những tag nào mới hợp lệ (white list) + sanitize input ← Chú ý: dùng white list, không dùng black list vì black list đã được chứng minh là không an toàn
    • Session fixation
      • Hacker bằng cách nào đó cố định (fix) được session ID của user
      • Ví dụ: Độ đến máy của Nhi, copy đè tập tin cookie
      • Ví dụ:
      • <script>
document.cookie=&quot;_session_id=16d5b78abb28e3d6206b60f22a03c8d9&quot;;

      • </script>
    •  
      • Cách tránh:
      • * Tránh XSS
      • * Reset session ngay khi user login
      • Tránh session fixation chỉ cần 1 câu lệnh:
      • (1 câu lệnh cứu cả thế giới ☃)
      • reset_session
    • Tham khảo
      • Ruby on Rails Security Guide: http://guides.rubyonrails.org/security.html
      • Căn bản về web: http://redmine.gnt.co.jp/documents/show/48