Lý lịch
Tôi đã được ký hợp đồng để giúp một công ty duy trì máy chủ của họ. Tôi làm việc trên một số dự án PHP nhỏ nhưng cũng xem xét các vấn đề về hiệu năng và gần đây, quét nhật ký cho tin tặc.
Những kẻ này đã chạy máy chủ của họ một thời gian và có cái mà tôi sẽ gọi là một ứng dụng cũ trên đôi chân cuối cùng của nó. Nó sử dụng các trích dẫn ma thuật, các biến toàn cục (cho phép $idghi đè bằng $_GET['id']), sử dụng .htaccess làm bảo mật duy nhất của chúng trong một số trường hợp, bạn đặt tên cho nó. Một cơn ác mộng về bảo mật và lập trình.
Chúng tôi đã bị hack trong quá khứ, chủ yếu là với SQL tiêm, sẽ chạy SLEEP(99999999)các lệnh và hoạt động như một cuộc tấn công DOS. May mắn thay, họ đã không chạy "bàn bgie nhỏ",
XKCD: http://xkcd.com/327/
Vì vậy, tôi đã viết lại các câu lệnh SQL dễ bị tổn thương của họ từ mysql_query()(không phải mysqli) sang các giao dịch PDO. Tôi cũng đang phân tích các truy vấn SLEEPvà UNION, chúng tôi không sử dụng nhưng tiêm có. Càng xa càng tốt.
Vấn đề mới nhất
Gần đây, chúng tôi đã được thông báo rằng các hồ sơ đang thay đổi trong DB cho người dùng, chẳng hạn như địa chỉ email của họ thành địa chỉ có thể được tạo bởi những kẻ gửi thư rác.
Tôi nhận thấy các cột của họ không có last_modifiedcột, vì vậy chúng tôi thậm chí không thể biết khi nào chúng được thay đổi, chứ đừng nói đến ai. Tôi đã thêm cột đó, nhưng đó chỉ là bước đầu tiên.
Khi tôi nhìn vào bảng này, tôi nhận thấy các mật khẩu không được muối hoặc thậm chí không được băm, chỉ được lưu dưới dạng văn bản gốc.
Giao tiếp khách hàng
Làm thế nào tôi có thể tiếp cận họ về toàn bộ tình huống, với tư cách là một nhà thầu, mà không vung tay như một kẻ điên? Có lời khuyên nào không? Tôi đã suy nghĩ một cách tiếp cận bình tĩnh của,
VẤN ĐỀ # 1
Tóm tắc
Tại sao đây là một vấn đề
Điều gì có thể xảy ra nếu điều này không được sửa
Đề xuất sửa chữa
VẤN ĐỀ 2
Tóm tắc
Tại sao đây là một vấn đề
Điều gì có thể xảy ra nếu điều này không được sửa
Đề xuất sửa chữa
