[Hướng dẫn] Lập trình an toàn ứng dụng web

By | 3:28 pm | 09/11/2017

web-application-security-600-2x

Ở bài viết trước, TT ATTT đã đưa ra một số đầu mục cần có trong checklist kiểm thử bảo mật của mỗi quản trị viên hệ thống nhằm đảm bảo an toàn cho hệ thống CNTT nói chung. Và trong bài viết này sẽ đưa ra một số đầu mục cần chú ý dành cho các lập trình viên nói riêng khi lập trình các website, để mỗi website được tạo ra đều đảm bảo an toàn chống lại được các cuộc tấn công của hacker.

1. Cập nhật thư viện (Lib) bản vá cho web Framework

  • Nguy cơ: Các ứng dụng web thường được phát triển bằng các framework (Struts, ADempiere, ZK…), các thư viện trong các framework version cũ có nhiều lỗ hổng về ATTT đã được public, kẻ tấn công có thể lợi dụng để khai thác tấn công hệ thống (VD: lỗ hổng Struts2 Remote Command Execution…).
  • Khắc phục: Thực hiện cập nhật các thư viện mới nhất, cập nhật bản vá bảo mật cho các thư viện, framework được sử dụng

2. Kiểm soát các truy vấn cơ sở dữ liệu để tránh tấn công SQL Injection

  • Nguy cơ: Khi truy vấn tới cơ sử dữ liệu, lập trình viên thường sử dụng cách cộng xâu Input từ người dùng, các câu truy vấn này có thể bị mắc lỗi SQL Injection hoặc HQL Injection (nếu sử dụng Hibernate). Bằng việc lợi dụng các lỗi này, kẻ tấn công có thể xem, thêm, sửa, xóa dữ liệu trong database từ đó chiếm được tài khoản admin, lấy cắp thông tin người dùng…
  • Khắc phục:
    • Truy vấn SQL phải dùng PrepareStatement, tất cả tham số phải được add bằng hàm (setParam..), không được xử dụng cách cộng xâu trong truy vấn.
    • Với một số trường hợp sử dụng ORDER BY không thể dùng được hàm setParam thì có thể định nghĩa một mảng chứa toàn bộ các column (field) cần ORDER BY gọi là whitelist. Mỗi khi cần ORDER BY thì kiểm tra lại xem column (field) đó có thuộc mảng whitelist đã định nghĩa không.

3. Xử lý dữ liệu đầu vào để tránh lỗ hổng XSS

  • Nguy cơ: Kết quả server trả về cho người dùng chủ yếu dưới dạng HTML. Nội dung trả về thường bao gồm cả những giá trị mà người dùng nhập vào hệ thống có thể bị mắc lỗi XSS nếu không kiểm soát dữ liệu đầu vào.
  • Khắc phục: Encode dưới dạng HTML các ký tự đặc biệt do client gửi đến bao gồm: <, >, &, ’, ”, / trong các trường hợp:
    • Dữ liệu client gửi lên máy chủ
    • Dữ liệu lấy ra từ database khi trả về cho client

4. Sử dụng Token để tránh lỗ hổng CSRF

  • Nguy cơ: CSRF(Cross – site request forgery) là phương pháp mượn quyền của người dùng khác để thực hiện một hành động không cho phép. Ví dụ: Để có thể xóa một bài viết trên diễn đàn một member có thể mượn tay của một admin để làm việc đó vì member không đủ đặc quyền nhưng admin thì có.Kẻ tấn công lừa admin truy cập vào trang web có chứa đoạn mã xóa bài viết trên diễn đàn (Admin đang đăng nhập vào diễn đàn) như vậy admin đã gửi yêu cầu xóa bài viết trên diễn đàn mà không hề biết.
  • Khắc phục: Đối với các yêu cầu gây ảnh hưởng tới dữ liệu, quá trình hoạt động và có khả năng làm mất an toàn thông tin của hệ thống. VD: yêu cầu đọc, ghi, sửa, xóa thông tin, dữ liệu hệ thống phải sử dụng thêm token. Trên server sẽ kiểm tra token trong yêu cầu gửi lên từ client, nếu token không hợp lệ thì yêu cầu sẽ không được thực hiện.

5. Kiểm soát file trên hệ thống

  • Nguy cơ: Các thao tác với file thường sử dụng tên file, đường dẫn file được gửi lên từ client, nếu ứng dụng không kiểm soát tốt các giá trị này (việc kiểm soát phải được thực hiện phía server) có thể dẫn đến việc download hoặc upload các file không hợp lệ.
  • Khắc phục: Kiểm soát tên file, đường dẫn file được gửi lên từ client, phần mở rộng của file (chỉ cho phép thực hiện với các file có định dạng theo yêu cầu). Không bắt buộc phải kiểm tra nội dung file.
    • Các hàm liên quan đọc ghi file, biến đường dẫn file phải được lọc /, \và kí tự null.
    • Phần file name ban đầu người dùng upload lên server phải bỏ đi, dùng 1 chuỗi mới ngẫu nhiên thay thế cho tên file. Tên này được sinh ra ngẫu nhiên không được dùng các thuật toán md5, sha256… Thay vào đó có thể sử dụng các hàm sinh chuỗi ngẫu nhiên có sẵn trong ngôn ngữ lập trình để sinh ra tên file.

6. Mã hóa dữ liệu nhạy cảm

  • Nguy cơ: Khi hệ thống bị tấn công và kẻ tấn công lấy được thông tin trong cơ sở dữ liệu, các dữ liệu nhạy cảm sẽ bị lộ nếu không được mã hóa hoặc mã hóa không an toàn. Note: Các thông tin sau được cho là nhạy cảm: Thông tin về tài khoản/mật khẩu, thẻ ngân hàng, thông tin về tiền…
  • Khắc phục: Mã hóa các dữ liệu nhạy cảm trong cơ sở dữ liệu. Các hàm mã hóa 1 chiều phải có thêm salt. Chú ý: salt phải đảm bảo tính ngẫu nhiên. Salt được sinh ngẫu nhiên cho từng user, và được lưu trong CSDL

7. Kiểm tra quyền truy cập người dùng

  • Nguy cơ: Trong các hệ thống có phân quyền, mỗi người dùng chỉ được phép truy cập các chức năng, các dữ liệu mà mình được phép. Tuy nhiên, nếu việc kiểm tra quyền không được kiểm soát tốt thì người dùng có thể truy cập được các chức năng, các dữ liệu không được quyền.
  • Khắc phục: Kiểm tra quyền trong từng request gửi lên server.Việc kiểm tra quyền gồm 2 nội dung kiểm tra là:
    • Người dùng có được phép thực thi chức năng theo request hay không?
    • Nếu người dùng được phép thực thi chức năng thì kiểm tra tiếp người dùng có được phép thao tác chức năng đó trên dữ liệu trong request hay không?

8. User enumeration

  • Nguy cơ: Trường hợp thông báo lỗi trên trang đăng nhập phân biệt giữa nhập sai tên đăng nhập và sai mật khẩu -> Dựa vào đó hacker có thể thử và tìm ra các user có trên hệ thống. Với các chức năng phải thông báo tên user nhập vào là đúng hay sai như các chức năng reset password, forgot password, chức năng đăng ký thì hacker có thể thử và tìm ra các user có trên hệ thống.
  • Khắc phục: Sử dụng chung thông báo lỗi cho cả 2 trường hợp nhập sai tên đăng nhập và mật khẩu trên trang đăng nhập vào hệ thống. Sử dụng captcha cho các chức năng đăng ký, reset, forgot mật khẩu để tránh các công cụ tự động khai thác lỗi user enumeration.

9. Session fixation

  • Nguy cơ: Kỹ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ bằng cách gửi một session ID hợp lệ đến người dùng, sau khi người dùng đăng nhập vào hệ thống thành công, hacker sẽ dùng lại session ID đó và nghiễm nhiêm trở thành người dùng hợp lệ.
  • Khắc phục:
    • Biện pháp 1: Chống việc đăng nhập với một session ID có sẵn: Ứng dụng phải hủy bỏ session ID được cung cấp bởi trình duyệt của người dùng khi đăng nhập và luôn tạo một session ID mới khi người dùng đăng nhập thành công.
    • Biện pháp 2: Giới hạn phạm vi ứng dụng của session ID.
      • Kết hợp session ID với địa chỉ của trình duyệt. Chú ý trường hợp mạng client có sử dụng NAT để truy cập vào server ứng dụng sẽ không dùng được phương pháp này.
      • Xóa bỏ session ID khi người dùng thoát khỏi hệ thống hay hết hiệu lực, có thể thực hiện trên trình máy chủ.
      • Thiết lập thời gian hết hiệu lực cho session, tránh trường hợp hacker có thể duy trì session và sử dụng nó lâu dài.

10. Sử dụng cookie an toàn

  • Nguy cơ: Khi người dùng không thiết lập thuộc tính “HTTPOnly” cho session cookie, hacker có thể sử dụng mã javascript để đánh cắp session cookie của người dùng.
  • Khắc phục: Yêu cầu thiết lập thuộc tính “HTTP Only” cho session cookie.

11. Chuyển hướng và chuyển tiếp thiếu thẩm tra (Unvalidated Redirects and Forwards)

  • Nguy cơ: Hacker có thể lừa người dùng chuyển hướng đến URI có nhiễm mã độc để cài phần mềm độc hại, hoặc lừa nạn nhân khai báo mật khẩu, hoặc những thông tin nhạy cảm khác. Ví dụ:  http://www.example.com/redirect.jsp?url=evil.com , ở đây evil.com chính là trang hacker muốn lừa người dùng chuyển đến.
  • Khắc phục:
    • Hạn chế sử dụng việc chuyển hướng và chuyển tiếp đến URI khác.
    • Nếu sử dụng thì nên hạn chế truyền tham số là trang sẽ chuyển hướng đến, mà nên thiết lập trang mặc định sẽ được tham chiếu đến.
    • Nếu yêu cầu bắt buộc phải truyền tham số trang redirect thì tham số cần phải được kiểm tra tính hợp lệ của nó thông qua whitelist các trang hợp lệ.

12. Để lộ dữ liệu của hệ thống

  • Nguy cơ: Trên hệ thống thường tồn tại các chức năng cho phép kết xuất dữ liệu truy vấn, kết quả cho ra file dưới dạng các file excel, tuy nhiên chức năng này có các lỗi sau có thể làm lộ dữ liệu của hệ thống:
    • File excel được lưu trữ trong thư mục con của thư mục ứng dụng.
    • File excel sau khi được người dùng tải về không được xóa.
    • Cho phép truy cập trực tiếp vào các file excel này mà không qua xác thực.
    • Ví dụ: Những đường link sau sẽ cho phép tải một file excel mà hệ thống đã xuất ra trước đó về mà không cần qua các bước xác thực: http://victim.com:8080/ams/share/report_out/expDMHangHoa20121022090909.xls
  • Khắc phục: Các dữ liệu này lưu trong thư mục bên ngoài thư mục cài đặt web server, việc thực hiện download các dữ liệu này phải qua bước xác thực và tham số phải mã hóa.

13. Thất thoát thông tin do kiểm soát lỗi và ngoại lệ không tốt

  • Nguy cơ: Các ứng dụng hiển thị chi tiết và quá nhiều thông tin lỗi khi xử lý, các thông tin này rất có ích cho hacker. Hacker có thể dựa vào các thông tin này để đoán biết hệ thống cũng như tiếp cận, khai thác lỗ hổng ứng dụng.
  • Khắc phục: Yêu cầu tất cả các ngoại lệ đều phải được xử lý, và được lưu vào trong hệ thống log để được xử lý sau này. Hạn chế hiện thị chi tiết miêu tả lỗi ra phía người dùng cuối, chỉ nên thông báo lỗi đơn giản nhất có thể.

14. Sử dụng captcha an toàn

  • Nguy cơ: Với các chức năng quan trọng, hacker có thể sử dụng công cụ tự động cố gắng thực thi chức năng đó nhiều lần với các tham số khác nhau cho đến khi đạt được ý đồ của hacker.
  • Khắc phục: Sử dụng captcha an toàn và việc kiểm tra captcha của 1 chức năng phải thực hiện trước khi phần chính của chức năng thực thi. Captcha có thể không sử dụng ngay khi thực hiện chức năng mà kích hoạt sau khi có dấu hiệu nghi ngờ có tác động do công cụ tự động. Ví dụ như: Chức năng đăng nhập thực hiện thất bại 5 lần liên tiếp, có khả năng bị bruteforce mật khẩu, lúc đó hệ thống sẽ yêu cầu người dùng cần nhập captcha.

15. File inclusion (Dành cho dự án dùng ngôn ngữ PHP)

  • Nguy cơ: Khi lập trình PHP, có thể từ file hiện tại gọi đến file khác thông qua các lệnh như include, require, require_once, include_once. Từ đó dẫn đến nguy cơ nếu không kiểm soát tốt file được gọi đến thì hacker có thể chuyển hướng lời gọi đến các file chứa lệnh độc hại, khi đó ứng dụng sẽ gọi đến và chạy các lệnh hacker mong muốn. Hoặc hacker có thể lợi dụng để đọc các file bất kỳ của ứng dụng.
  • Khắc phục: Thiết lập websever an toàn bằng cách phân quyền cho các thư mục hợp lý, tránh ứng dụng có thể truy cập vào các file không cần thiết.
    • Không cho phép include remote file nếu không cần thiết bằng cách thiết lập cấu hình trong file php.ini như sau: allow_url_fopen=Off
    • Hạn chế cho phép người dùng điều khiển file include. Nếu phải thực hiện thì sử dụng đường dẫn tuyệt đối khi include file, nên có whitelist chứa danh sách các file được phép include.

16. Command injection

  • Nguy cơ: Khi ứng dụng cho phép người dùng đưa dữ liệu vào các câu lệnh thực thi trên hệ điều hành, hacker có thể lợi dụng để chèn các ký tự đặc biệt cho phép nối, thực thi nhiều câu lệnh khác của hệ điều hành.
  • Khắc phụcValidate chặt chẽ dữ liệu người dùng gửi vào, tránh các ký tự cho phép nối thêm các câu lệnh thực thi của hệ điều hành. Sử dụng whitelist là danh sách chứa các ký tự được phép xuất hiện trong dữ liệu, để so sánh, đối chiếu loại bỏ các ký tự không nằm trong danh sách đó.

17. Xml/Xpath injection

  • Nguy cơ: Khi dữ liệu từ người dùng đưa vào để phân tích, xử lý xml có nguy cơ bị hacker đưa vào các dữ liệu có chứa các thẻ xml gây ra mất tính đúng đắn của dữ liệu. Khi dùng xpath để thao tác dữ liệu xml, lập trình viên thường sử dụng cách cộng xâu Input từ người dùng, các câu truy vấn này có thể bị mắc lỗi Xpath Injection, bằng việc lợi dụng lỗi này, kẻ tấn công có thể xem, thêm, sửa, xóa dữ liệu trong file xml, từ đó chiếm được thông tin người dùng, ứng dụng, …
  • Khắc phục:
    • Escape hoặc encode XML dữ liệu trước khi đưa vào file dữ liệu dạng XML, để tránh hacker có thể chèn dữ liệu có chứa thẻ xml gây ra sai lệch dữ liệu trong file xml.
    • Dữ liệu input từ người dùng phải được tham số hóa trước khi đưa vào thư viện xử lý Xpath.

18. Các lỗi liên quan đến luồng xử lý nghiệp vụ

  • Nguy cơ: Khi lập trình viên không xử lý đúng luồng nghiệp vụ của ứng dụng, xử lý sai về logic, có thể gây ra các lỗi mà kẻ tấn công có thể lợi dụng khái thác, tấn công chiếm quyền điều khiển ứng dụng. Ví dụ: khi xử lý sai luồng nghiệp vụ logic, kẻ tấn công có thể lợi dụng tấn công (spam SMS, viết chương trình tự động đăng ký dịch vụ, tài khoản…)
  • Khắc phục: Lập trình viên khi xây dựng, phát triển ứng dụng cần lắm rõ luồng nghiệp vụ, logic của ứng dụng, xử lý các trường hợp mà kẻ tấn công có thể lợi dụng thực hiện viết chương trình tự động để thực hiện.

 

VNPT Software