A1-Injection

Tìm hiểu về tiêm nhiễm mã độc(Injection) và sai lầm trong kiểm tra định danh (broken authenticate and session management):

1. A1 - Tiêm nhiễm mã độc (Injection)

Đối tượng nguy hiểm {threat agent} Khả năng tấn công: Sự phổ biến Khả năng phát hiện Tác động đến kỹ thuật Tác động đến kinh doanh ? Dễ Nhiều ? Trung bình Trung bình
Ai cũng có thể gửi các dữ liệu khác nhau đến hệ thống: người dùng bên ngoài, nội bộ, và quản trị viên Kẽ tấn công có thể gửi những mã dạng văn bản tận dụng sơ hở trong cú pháp của trình biên dịch. Hầu như bất cứ đoạn mã nguồn nào cũng có thể mắc lỗi bao gồm cả những mã nguồn nội bộ Lỗi nhúng mã có thể sảy ra khi một ứng dụng gửi những đoạn mã độc đến trình biên dịch. Lỗi này rất phổ biến đặc biệt ở những đoạn mã nguồn được sử dụng nhiều, như trong truy vấn SQL, LDAP, XPATH, các câu lệnh hệ điều hành, các tham số của chương trình v.v… Lỗi nhúng mã thường dễ phát hiện khi rà soát mã nguồn, nhưng khó phát hiện hơn khi chạy thử chương trình. Những công cụ quét kiểm tra có thể giúp kẻ tấn công tìm ra chúng. Lỗi này có thể khiến bạn mất hoặc hư hỏng hoặc không thể kiểm tra hay truy cập đến dữ liệu. Nặng hơn nó có thể dẫn đến toàn bộ hệ thống bị chiếm quyền Ta cần cân nhắc đến giá trị của những dữ liệu bị ảnh hưởng và các nền tảng đang chạy trình biên dịch. Tất cả dữ liệu có thể bị đánh cắp hoặc hủy hoại. Điều này có thể ảnh hưởng nghiêm trọng đến danh tiếng của bạn không ?

Tôi có bị mắc lỗi nhúng mã hay không ? Cách tốt nhất để kiểm tra xem ứng dụng có mắc lỗi hay không là xác minh nếu tất cả các dữ liện đầu vào của trình biên dịch có thể phân biệt rõ ràng giữa mã độc và câu truy vấn hay câu lệnh. Ví dụ như trong truy vấn SQL, ta cần phải sử dụng tất cả những biến số trong những câu lệnh được chuẩn bị hay những thủ tục được lưu trữ, tránh sử dụng những câu truy vấn động. Kiểm tra mã nguồn có thể là cách nhanh và chính xác để xác định nếu ứng dụng có an toàn hay không. Những công cụ phân tích mã nguồn có thể giúp nhân viên bảo mật hiểu được trình biên dịch và luồng dữ liệu đi trong ứng dụng. Những chuyên viên thâm nhập có thể xác thực những vấn đề tìm ra bằng cách tạo những chương trình thâm nhập thử vào hệ thống Chương trình quét tự động có thể đưa ra những thông tin sâu sắc nếu chương trình của bạn thực sự mắc lỗi nhúng mã. Máy quét không thể luôn kiểm tra được trình biên dịch và khó biết chắc chắn nếu có một phương thức tấn công thành công. Những phần xử lý lỗi có thể giúp tìm ra lỗ hổng dể dàng hơn Làm cách nào để tôi có thể ngăn chặn lỗi nhũng mã Để ngăn chặn cần phải phân biệt được mã độc và câu lệnh hay truy vấn

1. Tùy chọn thường được dùng là sử dụng một thư viên API an toàn, nó giúp bạn tránh việc sử dụng trình biên dịch một cách trực tiếp và cung cấp một giao diện phân tách tham số. Cần cẩn thận với APIs, như thủ tục lưu trữ dù đã phân tách tham số nhưng lỗi nhúng mã vẫn có thể sảy ra ở bên trong
2. Nếu không có những thư viện phân tách tham số, bạn có thể cẩn thận loại bỏ những kí tự đặc biệt bằng những công cụ của trình biên dịch đó. OWASP’s ESAPI có cung cấp thông tin về những công cụ đó.
3. Chúng tôi khuyến khích kiểm tra những dữ liệu đầu vào hợp lệ bằng các từ điển tiêu chuẩn {canonicalization} phù hợp. Đây vẫn chưa phải là cách phòng thủ an toàn nhất vì nhiều ứng dụng sử dụng những ký tự đặc biệt trong các thông tin đầu vào. OWASP’s ESAPI cũng cung cấp 1 danh sách rất nhiều những thư viện công cụ để kiểm tra dữ liệu đầu vào hợp lệ

Ví dụ về kịch bản tấn công Ứng dụng sử dụng mã độc khi xây dựng truy vấn SQLsau: String query = "SELECT * FROM accounts WHEREcustID='" + request.getParameter("id") +"'"; Kẻ tấn công có thể thay thế tham số ‘id’ trong trình duyệt để gửi đến: ‘ or ‘1’=’1. Việc này thay đổi ý nghĩa của câu truy vấn và trả ra giá trị của tất cả các tài khoản trong cơ sở dữ liệu thay vì chỉ của 1 nhân viên mà thôi http://example.com/app/accountView?id=' or '1'='1 Trong trường hợp xấu nhất, kẻ tấn công có thể sử dụng điểm yếu này để thực thi những thủ tục lưu trữ trong cơ sở dữ liệu và giúp hắn chiếm quyền điều khiển cơ sở dữ liệu hoặc toàn bộ máy chủ