Bảo mật web cho developer phần 2 trình bày tiếp theo phần 1 về các kiến thức bảo mật quan trọng cần biết trong lập trình viên web.
- Insecure Direct Object References
- Cross Site Request Forgery
- Security Misconfiguration
- Unvalidated Redirects And Forwards
- Using Components With Known Vulnerabilities
Lỗi bảo mật Insecure Direct Object References
Lỗi này xuất phát từ việc cho rằng các tham số đầu vào của trang web là tin được. Web dev để user truy cập các tài nguyên (dữ liệu, file) mà không hề kiểm tra quyền. Do đó tin tặc truy cập được vào các dữ liệu mà hắn không có quyền trên máy chủ.
Xét trường hợp sau: trang download.php cho người dùng tải file, tham số của trang là tên file cần down. Ví dụ download.php?file=abc.mp3 . Do sai sót của web dev, việc kiểm tra quyền đã bị bỏ qua. Kẻ tấn công sử dụng lỗ hổng này để tải file khác bằng cách đổi giá trị của biến file. Chẳng hạn như code ứng dụng, hoặc các dữ liệu khác trên máy chủ.
Một trường hợp khác: chức năng reset mật khẩu dựa vào tham số username để gán lại mật khẩu mới. Url hợp lệ là thế này http:/abc.com/resetpass.php?user=teo và kẻ tấn công sẽ đổi tên người dùng trong URL thành http:/abc.com/resetpass.php?user=admin để “đóng giả” admin. Kha kha.
Cách chặn lỗ hổng là phải kiểm tra quyền người dùng . Và có thể kết hợp thêm whitelist để chỉ nhận các giá trị tham số hợp lệ.
Ví dụ khác, web dev tổ chức URL để hiện chi tiết một đơn hàng như sau: http://abc.com/orders/103257 . Code PHP sẽ đọc id 103257 rồi lấy thông tin đơn hàng này để show. Kẻ phá hoại khi thấy code này sẽ thay giá trị 103257 bằng các giá trị khác. Nếu web dev không kiểm soát thì sẽ hiện ra đơn hàng khác theo giá trị mà hắn nhập vào. Kể cả đơn hàng của khách hàng khác cũng hiện ra luôn, ghê chưa.
Chưa cần biết hắn làm gì, chỉ việc “bị qua mặt” thì việc bảo mật website xem như hỏng. Lỗ hổng ở đây là không kiểm soát quyền, để user thoải mái truy cập tài nguyên. Tài nguyên có thể là đơn hàng, file của người khác. Cho nên cần phải phải check xem user có quyền truy cập các dữ liệu hay không rồi mới hiện.
Tóm lại: Nguyên nhân gây ra lỗi này thường là do web dev không kiểm tra quyền của người dùng.
Lỗi bảo mật Cross Site Request Forgery
Bảo mật web cho developer phần 2 trình bày tiếp về lỗi Cross Site Request Forgery. Viết tắt của lỗi này là CSRF. Đây là lỗi này khá phổ biến: trình duyệt bị đánh lừa bởi bên thứ ba. Cross Site Request Forgery tạm dịch là request giả mạo xuyên website.
Ví dụ về lỗi bảo mật Cross Site Request Forgery
Anh A dùng trình duyệt để login vào ngân hàng sử dụng dịch vụ gì đó mà chưa thoát. Tiếp theo, vẫn trong trình duyệt ấy, anh truy cập vào 1 website khác (như XYZ.cơm) để xem thông tin. Tên B biết được và có ý xấu, nên sẽ post thông tin gì đó lên XYZ.cơm để A xem. Ví dụ B sẽ post vào XYZ.cơm 1 comment, hay 1 bài trong forum mục đích để chờ A đọc. Message của B sẽ có nội dung gì đó hấp dẫn và kèm theo 1 hình bí mật như sau :
Giá vàng đang tăng nhanh vũ bão... <img src="http://nganhang.cơm/chuyentien.php?amount=10000&destAccount=987654321" width=0 height=0>
Hình bí mật trong message trên anh A không thấy vì có độ rộng và độ cao là 0. Địa chỉ của hình là đường link chuyển tiền 10000$ trong ngân hàng cho tài khoản của B. Do A chưa đăng xuất và website của ngân hàng lập trình chưa chặt nên A sẽ bị mất tiền. Ngân hàng thấy request trong địa chỉ hình cứ tưởng anh A yêu cầu (vì A chưa đăng xuất). Chết tươi chưa.
Có khi B tấn công A (là admin của 1 website) bằng cách post vào form liên hệ. Anh A khi xem nội dung liên hệ sẽ bị hại. Đường link để hại A không hẵn lúc nào cũng chuyển tiền. Có thể là đường link để xóa hay chỉnh dữ liệu gì đó của A (đang là admin của website)…Hehe
Phòng tránh lỗi bảo mật csrf thế nào?
Với tư cách user, bạn phải đăng xuất ra khỏi các website quan trọng sau khi giao dịch xong. Thoát ra trước khi dùng đến (xem) website khác. Với tư cách người lập trình viên, bạn cần có biện pháp để phòng tránh cho user.
Trong mỗi form, bạn tạo một giá trị token phát sinh ngẫu nhiên trên server. Lưu sẵn giá trị này trên server và chuyển token này về trình duyệt trong biến cookie hoặc field ẩn. Giá trị token này phải được xác minh trước khi thực hiện các chức năng nghiệp vụ. Bạn so sánh cookie/form field gửi lên với giá trị đã lưu trên server. Nếu giống nhau thì mới cho code chạy, còn không giống thì thoát.
Khi đó website bên thứ ba không có sẵn giá trị này nên dẫu có request cũng không có hại.
Cũng có thể tránh lỗi này bằng cách dùng catpcha, nhưng có thể gây chút phiền toái cho người dùng.
Bạn cũng nên sử dụng cookie khác nhau giữa phần admin và public để tránh lỗi này. Hoặc bạn sử dụng tham số $_SERVER[‘HTTP_REFERER’] để biết request đến từ đâu, nếu khác domain website thì không xử lý, như vậy sẽ an toàn hơn.
Hiện tại, các framework nổi tiếng như Codeigniter, Phalcon, Laravel đều hỗ trợ tránh các lỗi này rất tốt.
Lỗi bảo mật Security Misconfiguration
Bảo mật web cho developer – phần 2 đề cập tiếp về một vấn đề khác: lỗi cấu hình bảo mật. Lỗi này thường xảy ra khi cấu hình không tốt hoặc sót. Một vài sai sót như:
1. Chạy website khi chế độ debug được bật, dẫn đến các mật khẩu, cấu trúc folder bị lộ. Ví dụ cấu hình php trên host mà cho display All Error. Hay cấu hình cho biến WP_DEBUG của wordpress set là true (để gỡ lỗi) rồi quên tắt. Khi lỗi xảy ra thì tên database, table, username, đường path đến website sẽ “lòi” ra cho người ngoài xem.
2. Thiếu cấu hình htaccess dẫn đến bị Directory listing. Vậy Directory Listing là gì?
Thường thì Apache sẽ liệt kê mọi file trong folder không có file mặc định như index.html, index.php, home.php. Việc liệt kê danh sách file như vậy gọi là Directory Listring (xem hình dưới) rất nguy hiểm.
Việc liệt kê danh sách file như trên sẽ làm lộ các file bí mật . Ví dụ như các file database, file password, file cấu hình mà người ngoài không được biết.
3. Sử dụng thư viện cũ dẫn đến các lỗi bảo mật (nếu có) bị khai thác. Lỗi này hay bị vì các thư viện nguồn mở trong website bị lỗi thời theo thời gian.
4. Tồn tại các chức năng không cần thiết trong website. Ví dụ bạn thêm các thư viện để upload file mà không dùng. Hay tạo form đăng ký nhưng rồi không xài và rồi quên luôn. Khi đó user đăng ký thoải mái mà admin không biết. Từ đó tin tặc tìm cách nâng cấp tài khoản của mình để có quyền cao hơn…
5. Không thay đổi default key hoặc mật khẩu mặc định trong các thư viện sử dụng. Có khi user, pass đặt sẵn luôn trong form login.
6. Cho phép upload file thoải mái trong các thư viện upload file (ckeditor…)
Unvalidated Redirects And Forwards – Lỗi chuyển hướng không an toàn
Chuyển hướng không an toàn là lỗi xử lý chuyển hướng không tốt của web dev. Giúp hacker tạo link dẫn user đến các web độc để lừa đảo hoặc thu thập thông tin của họ.
Ví dụ: giả sử url hợp lệ để user đăng nhập vào google là https://act.google.com/ServiceLogin?hl=en&continue=https://google.com. Kẻ tấn công sẽ giả bằng cách tạo ra một link gần giống để lừa người dùng thế này https://act.google.com/ServiceLogin?hl=en&continue=https://evil.com. Bạn thấy sao? Liên kết giả nhưng giống y như thật dễ lừa được nạn nhân nhắp vào.
Cách ngăn chặn: Không dùng chức năng chuyển hướng với tham số truyền từ ngoài vào. Hoặc phải dùng phương pháp whitelist liệt kê các giá trị chấp nhận của tham số
redirect.php
<?php
$arr = array('login.php','download.php', 'soft.php');
$url = $_GET['url'];
if (in_array($url, $arr)==true) header("location: ". $url);
Như trong code trên, tham số truyền cho redirect.php là có kiểm soát. Các giá trị của url phải nầm trong array thì mới chuyển hướng, vậy mới an toàn.
Lỗi Using Components With Known Vulnerabilities
Lỗi xảy ra khi website sử dụng các thư viện có các lỗ hổng bảo mật. Cách ngăn chặn không khó, hãy nhớ một số gợi ý mang tính nguyên tắc sau đây:
- Trước khi tích hợp một thư viện vào website, hãy tìm hiểu hoặc kiểm tra bảo mật. Vì các lỗ hổng từ các thư viện này là cửa số để hacker tấn công website.
- Nên download các thư viện từ các nguồn tin cậy và cấu hình cho an toàn khi sử dụng.
- Đảm bảo sử dụng phiên bản mới nhất của các thư viện và cập nhật chúng thường xuyên. Nên đăng ký email để nhận thông tin về liên quan đến các thư viện sử dụng.
Tóm lại, bài bảo mật web cho developer – phần 2 trình bày các lỗi dễ gặp khi phát triển website. Như lỗi Insecure Direct Object References – không kiểm tra quyền truy cập của user một cách chặt chẽ. Lỗi Cross Site Request Forgery – request giả mạo người dùng để thực thi các request gây hại từ website khác. Như Security Misconfiguration – lỗi cấu hình không an toàn. Như lỗi Unvalidated Redirects And Forwards – chuyển hướng không kiểm soát. Lỗi Using Components With Known Vulnerabilities – lỗ hổng từ các thư viện nhúng vào website.
Bạn cần biết cơ bản về các lỗi này, ít ra là về kiến thức nhé. Trong các bài sau, sẽ có hướng dẫn hoặc ví dụ cụ thể hơn.
Tham khảo bài liên quan: Bảo mật web cho Developer phần 1
