Lập trình an toàn

Hôm nay mình được tham dự buổi đào tạo về lập trình an toàn. Đây là một buổi học đi kèm với gói đánh giá về bảo mật về hệ thống của công ty.
Nhìn chung buổi đào tạo cũng khá ổn, cung cấp cho mình thêm một số kiến thức nhất định nhưng cảm giác diễn giả còn lúng túng. Không nêu bật ra được vấn đề nhưng có thể đó là do dân kỹ thuật thường hay vậy.
Mình tóm tắt lại một số ý mình tiếp thu được như sau:

  • Lỗi XSS, lỗi này được khai thác dựa trên các input không được validate dữ liệu. Kẻ tấn công sẽ gửi cho người dùng URL của website chứa các tham số đã được định trước, các tham số này chứa các đoạn mã javascript thực thi mà kẻ tấn công muốn. Cách này cho người dùng tin vào đường dẫn đúng của website mình sử dụng.
    Để dễ hiểu hơn, bình thường mình gửi cho ai đó từ khóa để người ta tự tìm trên google, nhưng ta có thể gửi luôn URL mình thu được sau khi mình đã tìm kiếm. Nghĩa là mình copy cả URL luôn, nó sẽ chứa cả tham số loằng ngoằng rất dài đó.
  • Vẫn là lỗi XSS nhưng lỗi này nguy hiểm hơn. Do input không được validate dữ liệu nên kẻ tấn công cố tình chèn, lưu các đoạn script vào hệ thống như là comment, viết bài… Các đoạn script này được lưu vào DB và hiển thị ra nếu người dùng truy cập nên ai vào thì cũng bị dính. Các script này sẽ gửi thông tin tới máy chủ kẻ tấn công hoặc chứa mã đào tiền ảo…
  • Lỗi không kiểm tra input dẫn tới việc thực thi một số lệnh của máy chủ mà ta không mong muốn. Ví dụ ta có một tính năng thực thi một script shell hoặc chương trình nào đó với input được nhập vào thông qua input. Kẻ tấn công sẽ bổ sung thêm một số lệnh của OS để việc thực thi sẽ tiến hành thêm các lệnh mà kẻ tấn công muốn. Nguy hiểm như các lệnh xóa, khởi động hoặc làm gì đó từ phía hệ điều hành.
  • Lỗi SQL injection, lỗi này trước đây rất phổ biến nhưng giờ cũng nhiều người chú ý hơn. Đó cũng là việc không validate dữ liệu nhập từ input, kẻ tấn công sẽ thêm các mã lệnh sql để câu lệnh mình sử dụng với input sẽ sai lệch như: điều kiện sẽ là luôn đúng, drop table hoặc list ra toàn bộ thông tin của DB…
  • Lỗi XML, khi ta muốn sinh ra file XML dựa trên input của người dùng để một hệ thống khác sẽ thực thi. Tương tự SQL injection, kẻ tấn công sẽ thêm các ký tự, mã lệnh làm sai lệch nội dung XML để hệ thống thực thi sai.
  • Lỗi tải file không mong muốn lên. Ví dụ hệ thống có tính năng load file lên để xử lý. Nếu không validate loại file hoặc giới hạn các file được phép thực thi ở webserver thì kẻ tấn công có thể lợi dụng load các file mã độc, virut, shell script tự động thực thi các lệnh không mong muốn để chiếm quyền điều khiển hệ thống.
  • Lỗi cho tải file xuống. Ví dụ hệ thống cho nhập tên file để tải file log xuống, nếu không validate tên và phân quyền đúng đắn. Kẻ tấn công có thể thêm các đường dẫn khác nhau thường có ở hệ điều hành hoặc các file config hòng xem được.
  • Lỗi về việc phân quyền của người dùng có thể nhìn thấy được các dữ liệu của nhau. Ví dụ người dùng có thể xem được trang mà không được phân quyền, xem profile hoặc thực thi các việc mà không được phép. Diễn giả có đề cập thuật ngữ phân quyền dọc và ngang. Dọc là theo role đã chỉ định trước, ngang là ngang hàng có hay không được thực thi các công việc giống nhau.
  • Lỗi cho phép kẻ tấn công có thể sử dụng session của website đang thực thi để thực hiện các công việc tự động gì đó. Ví dụ người bị tấn công, khi đăng nhập vào ngân hàng, trình duyệt chứa một web ẩn thực thi lệnh chuyển tiền không mong muốn sử dụng chính session của người dùng.

Từ đó họ cũng đã khuyến cáo hoặc chỉ các khắc phục như sau:

  • Đặt mật khẩu lớn hơn hoặc bằng 8 ký tự, yêu cầu chứa cả ký tự đặc biệt và thường xuyên đổi mật khẩu.
  • Không lưu mật khẩu bằng text mà phải mã hóa trước khi lưu, ít nhất là hàm băm SHA125
  • ID user không nên cho số nguyên tự tăng mà sẽ sử dụng một quy tắc định trước như GUID…
  • Lưu ý tất cả input cần giới hạn độ dài phù hợp, luôn luôn phải validate input ở phía server
  • Cấu hình webserver được thực thi tự động một số file định trước
  • Giới hạn các quyền trên OS, các lệnh được thực thi, phân quyền thư mục…
  • Nếu sử dụng XML cần sử dụng DTD làm các header
  • Lập trình thao tác xuống CSDL tốt nhất nên sử dụng các procedure hoặc phải tham số hóa các input, tuyệt đối không dùng string để cộng chuỗi thành câu lệnh SQL.
  • Nghiên cứu sử dụng TOKEN, xác thực 2 lớp, JWT, capcha… để xác thực người dùng
  • Lưu ý với mỗi thực thi không những kiểm tra role của user mà nên quan tâm cả vùng thao tác của user (phân quyền ngang – dọc phù hợp)
  • Nghiên cứu học thêm các lỗi về Build code, config webserver, config hệ điều hành…
  • Khi code có thể sử dụng 1 số các plugin của IDE check lỗi code
  • Sử dụng các tool hoặc thuê các bên khác review, kiểm tra, quét ứng dụng thường xuyên.