làm thế nào để bảo mật trang web của tôi

Question

Tôi biết đảm bảo bất kỳ trang web nào là một chủ đề rất khó khăn và rộng rãi để thảo luận nhưng tôi muốn liên hệ câu hỏi này với trang web cụ thể của tôi mà tôi đang nghiên cứu. Nó được mã hóa bởi php bởi một số lập trình viên khác vào khoảng năm 2004 và tôi chịu trách nhiệm quản lý nó. Vấn đề của tôi là nó bị tấn công nhiều lần. Tôi đã nhận thấy những điều sau đây khi nó bị tấn công.

1. .htaccess tập tin đã được sửa đổi
2. index.php và config.php file đã được sửa đổi
3. mật khẩu quản trị đã được thay đổi
4. file tải lên trong máy chủ
5. thay đổi sự cho phép tập tin của tập tin và thư mục

Tôi đã làm việc trên mã, nó đã được thoát đúng cách tôi nghĩ rằng không có xác suất tiêm sql. Vì hầu hết các vấn đề có liên quan đến các tập tin và sự cho phép tôi có nghi ngờ về bảo mật máy chủ nhưng vì lý do nó được mã hóa vào năm 2004 nên nó sẽ thiếu bảo mật, vì vậy những thứ khác tôi cần làm trong mã của mình ngăn trang web của tôi bị tấn công vì các vấn đề đã đề cập ở trên?

Xin cảm ơn trước.

Answer 1

Vì các tệp đã được sửa đổi, điều này không xảy ra do lỗi SQL injection.

khả năng để có được các tập tin:

• Guess/ăn cắp mật khẩu FTP của bạn
• Hack máy chủ (bạn có thể không thực sự làm bất cứ điều gì về điều đó)
• cách ly đủ trên máy chủ, có nghĩa là các khách hàng khác có thể thay đổi tệp của bạn (bạn cũng không thể thực hiện bất kỳ điều gì về điều đó)
• Lỗi thực thi mã từ xa

Bây giờ kể từ khi bạn nói trang web là từ năm 2004, nó có thể là nó sử dụng eval cho templating hoặc include cho những thứ như site.php?section=foo và sau đó bao gồm foo.php trong mã ở một nơi nào đó được thực hiện thường xuyên trở lại vào năm 2004. Vì vậy, tôi sẽ làm một cách nhanh chóng tìm kiếm tập tin cho eval và regex include(.*\$.*) cũng như require(.*\$.*). Đó là những nghi phạm chính tùy thuộc vào cách chúng được sử dụng.

Answer 2

Ai đó có thể có quyền truy cập trực tiếp vào máy chủ, chứ không phải (a) tập lệnh cụ thể. Điều này không giống như một vấn đề an ninh có nguồn gốc của nó trong codebase.

Bạn có thể muốn xem xét di chuyển toàn bộ trang web sang một nhà cung cấp khác nếu điều này xảy ra theo thời gian và thời gian. Bắt đầu lại ở một nơi khác, với mật khẩu mới, kiểm soát truy cập, v.v.

Answer 3

OWASP top 10 được đọc rất tốt. Một số phỏng đoán của tôi.

• Hệ điều hành lỗi thời có lỗ hổng bảo mật.
• tiêm MySQL và có thể tất cả mật khẩu được lưu trữ ở dạng văn bản thuần túy rất xấu. Để xác thực bạn nên sử dụng một cái gì đó như openID thay thế.Ngoài ra khi bạn có MySQL-injection bạn nên pronto cập nhật mã để sử dụng PDO (chuẩn bị báo cáo) nếu có thể.
• quyền đọc/ghi không được đặt đúng hoặc APACHE/PHP chạy ở mức cao?

Lời khuyên của tôi cho bạn là:

• đọc thêm thông tin về OWASP. Sau đó, nhìn rõ ràng cho các lỗ hổng trong mã của bạn. Mỗi dòng có thể là nguồn tắt vấn đề. Có lẽ bạn nên mương mã cũ, bởi vì rất không an toàn?
• cài đặt lại hệ điều hành của bạn, bởi vì bạn thậm chí có thể có rootkit?

Answer 4

• Không bao giờ sử dụng chỉ chia sẻ lưu trữ, sử dụng máy chủ ít nhất quản lý/giữ cho hệ thống cập nhật
• Kiểm tra php.ini của bạn về các vấn đề an ninh (mà bạn có thể google)
• Kiểm tra Apache của bạn/nginx/... configs cho ghi đè
• Chưa bao giờ giao tiếp được mã hóa với máy chủ (sử dụng SFTP, SSH, ...)
• Không bao giờ tin tưởng các giá trị bên ngoài (cũng từ Cookies), luôn luôn thoát khỏi/đúc những
• Fi lter đầu vào người dùng (loại bỏ ngắt dòng, 0x00 ký tự, thẻ, ... nơi không mong muốn)
• Kiểm tra tất cả các tài khoản người dùng hiện có cho máy chủ/cơ sở dữ liệu/...
• Kiểm tra xem tất cả dịch vụ có phải là người dùng chính xác
• Kiểm tra file (ghi/thực hiện) cho phép trong các thư mục web của bạn
• thoát mọi thứ bạn hiển thị trên các trang web, thậm chí không tin tưởng dữ liệu cơ sở dữ liệu của bạn được an toàn trong bất kỳ cách nào
• Nếu bạn sử dụng phần mềm của bên thứ 3, nhìn ra để được tư vấn bảo mật
• cài đặt lại máy chủ, bạn có thể đã được bắt nguồn từ
• Sử dụng báo cáo đã chuẩn bị

Đó là điều đó;) Điều này sẽ tăng cường bảo mật cho bạn, nhưng những kẻ tấn công có kinh nghiệm rất khó khăn.