Làm cách nào tôi có thể khiến các lập trình viên ngừng viết mã dễ bị tấn công SQL?

Đôi khi bạn bận rộn và giao nhiệm vụ nhỏ cho các lập trình viên cơ sở. Nhưng nếu bạn không chú ý đúng mức, bạn sẽ thấy mình có loại mã này trong sản xuất:

class DivtoggleController extends Zend_Controller_Action {

    public function closeAction() {
        /* ... code removed for brevity ... */

        $req = $this->getRequest();
        $formData = $req->getPost();

        $d = $formData['div'];
        $i = $formData['id'];

        $dm = new Model_DivtoggleManager();
        $rs = $dm->setDivToggleById($d, $i);

    }

}


class Model_DivtoggleManager extends Zend_Db_Table {

    public function setDivToggleById($div, $id) {
        $result = $this->getAdapter()->query(
           "update div_toggle set " . $div . "=1 where id=" . $id
        );
    }

}

Vì vậy, do tôi đã loại bỏ logic quản lý phiên / xác thực cho ngắn gọn, ai có thể cho tôi biết vấn đề nào có thể xảy ra với mẫu này?

Bạn có thể dạy chúng. Mọi người làm điều này ngay từ đầu, ngay cả bạn. Nếu loại mã này đưa nó vào sản xuất, đó là lỗi của người cao cấp; không phải đàn em.

Biên tập:

Một trong những điều mà tôi đã làm là cá nhân tôi đã thực hiện để chủ động yêu cầu mọi người xem lại mã của tôi (bao gồm cả đàn em) trước khi phát hành. Mã được xem xét, những người trẻ tuổi coi đó là một kinh nghiệm học tập, mọi người mất đi nỗi sợ đánh giá mã là một hình phạt và họ bắt đầu làm điều tương tự.

Hack mã của họ trước mắt họ sau đó chỉ cho họ cách khắc phục. Hơn và hơn cho đến khi họ hiểu.

Bạn có thể bắt buộc họ tham gia một lớp ngay khi họ gia nhập công ty của bạn, trước khi họ có quyền truy cập kiểm soát nguồn, giới thiệu cho họ về SQL, kịch bản chéo trang, giả mạo yêu cầu trang web chéo và các lỗ hổng phổ biến khác. Các ví dụ trực diện, phá mã xấu trước mặt họ, để họ phá mã xấu và trỏ chúng đến trang web OWASP để biết thêm thông tin sau khi họ "tốt nghiệp".

Ngoài ra, bạn có thể bắt buộc sử dụng thư viện tùy chỉnh xử lý việc này cho bạn, nhưng đó chỉ là giải pháp phụ vì họ chắc chắn sẽ chạy các truy vấn tùy chỉnh khi điều đó trở nên thuận tiện hơn.

Nếu bạn có tài nguyên, đảm bảo nhiều thành viên cao cấp hơn trong nhóm xác minh sự khác biệt của họ trước khi cam kết cũng có thể hữu ích.

Kiên thức là sức mạnh!

Giả sử rằng đó là sự không an toàn mà người khác đã đề cập, với tư cách là nhà phát triển ở mọi cấp độ, thật dễ dàng để quên rằng getPost () không bảo mật dữ liệu trước tiên.

Một cách xung quanh điều này là:

1. Viết một lớp nhận tất cả dữ liệu POST / GET và viết nó như là một lớp Singleton gọi là 'insecure_data'. Sau đó xóa mảng POST / GET.
2. Các nhà phát triển hơn phải truy xuất dữ liệu POST / GET từ mảng 'insecure_data', chứ không phải mảng POST / GET.

Bất kỳ nhà phát triển nào lấy một cái gì đó từ một mảng gọi là 'insecure_data' và không bận tâm để bảo mật nó là không biết gì hoặc lười biếng. Nếu đó là cái trước, hãy cung cấp đào tạo, sau đó nó phải là cái sau - và sau đó bạn có vấn đề về kỷ luật, không phải là vấn đề lập trình.

Một trong những hướng dẫn tốt nhất mà tôi đã đọc về bảo mật web là hướng dẫn bảo mật Ruby on Rails này . Mặc dù đó là Ruby on Rails, rất nhiều khái niệm áp dụng cho bất kỳ sự phát triển web nào. Tôi sẽ khuyến khích bất cứ ai mới để đọc hướng dẫn đó.

Mã bạn đã liên kết ở trên dễ bị tấn công SQL SQL, bởi vì các đầu vào HTTP bạn đang sử dụng trong truy vấn chưa được làm sạch bằng mysql_real_escape_stringhoặc bất kỳ phương tiện nào khác.

Về câu hỏi của bạn (có lẽ là ghi đè) "làm thế nào tôi có thể khiến các lập trình viên ngừng làm việc này", tôi nói rằng hãy tư vấn cho họ một cách thường xuyên, giải thích cẩn thận vấn đề đang được đề cập (và dự phòng tiềm năng, v.v.) và nhấn mạnh tầm quan trọng của các lỗ hổng mã (cả về SQL và kịch bản chéo trang, v.v.) có lẽ là giải pháp hợp lý nhất.

Nếu họ cứ làm phiền bất chấp tất cả những điều trên (bạn có thể muốn để mắt đến những cam kết của họ, v.v. thay vì tìm hiểu "trực tiếp"), thì vấn đề là bạn thất bại với tư cách là người cố vấn, hoặc đó là có lẽ họ cần tìm một cái gì đó phù hợp hơn để kiếm sống.