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ủaserver dành cho user

Output:Lợi dụng lòng tin củauser 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ì?

ServerClient

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:

HeaderKey – ValueKey – Value

Body

HeaderKey – Value

Set-Cookie – ValueKey – Value

Body

Response

HeaderKey – Value

Cookie – ValueKey – Value

Body

Client Server

Request

Request

Cookie là opaque data:server set cái gì trongresponse thìclient lần request sausẽ trả về nguyên xi

Q: Làm thế nào để thực hiệntí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

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/

CSRF

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="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";

</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