Kiểm tra lỗ hổng bảo mật trên các ứng dụng web

Question

Rất nhiều công ty sử dụng phần mềm CMS cập nhật thường xuyên, thường là các bản sửa lỗi bảo mật, ngụ ý rằng phiên bản trước có lỗ hổng bảo mật. Nhưng hầu hết khách hàng không bao giờ nâng cấp điều này, hoặc thậm chí CMS đã được sửa đổi để cập nhật sẽ phá vỡ trang web. Có các trang web ghi lại các khai thác này và hướng dẫn cách kiểm tra chúng không? Hay thông tin này thậm chí không được xuất bản? (để không có người cố gắng khai thác chúng)

Cũng có danh sách kiểm tra dựa trên php/js chung để ngăn chặn các nỗ lực hack? Tôi biết về tiêm SQL và XSS, nhưng tôi chắc chắn rằng có nhiều mối đe dọa hơn ở đó.

Hòa bình

Answer 1

Các trang web mà catalô tất cả những lỗ hổng là ví dụ

• SecurityFocus
• milW0rm
• packetstormsecurity

Danh sách kiểm tra cơ bản cho webapps có thể được tìm thấy trên OWASP , đó là một danh sách kiểm tra rất chung chung.

http://www.owasp.org/index.php/Top_10_2010-Main

Answer 2

SQL Tiêm và XSS tấn công đều giải quyết bằng cách phân tích tất cả các thông tin đó là nhận được mã của bạn (addslashes, loại bỏ "" thẻ và vân vân); Magic trích dẫn thi đua và register_globals off giải quyết các vấn đề từ quan điểm của tôi. Hãy cẩn thận, không biết chính xác khi nào, nhưng magic_quotes sẽ không được chấp nhận vì vậy đừng dựa vào đó.

Vì vậy, các mối đe dọa khác là gì? Theo kinh nghiệm của tôi, những sai lầm phổ biến nhất của con người có liên quan đến việc xác thực. Điều này không có nghĩa là người dùng không đăng nhập, nhưng điều đó có nghĩa là người dùng có thể đọc/ghi thông tin cho người dùng khác. Vì vậy, bất cứ khi nào bạn nhìn thấy một liên kết xóa như thế này: index.php? Page = images & action = xóa & id = 2, hãy thử với id khác, của hình ảnh của người dùng khác. Bạn sẽ nhận được một câu nói sai "không phải hình ảnh của bạn" hoặc một cái gì đó. Điều này rất khó kiểm tra, vì vậy bạn phải dựa vào kinh nghiệm của nhà phát triển.

Vấn đề lớn thứ hai mà tôi gặp phải không liên quan đến mã nhưng đến máy chủ. Mật khẩu FTP đã bị đánh cắp bởi virus (virus IFrame và những người khác), hoặc máy chủ đã bị tấn công bằng cách sử dụng phương pháp bạo lực khác nhau.

Kết luận là: nếu bạn chắc chắn bạn đã kiểm tra tấn công SQL Injection và XSS, điều cuối cùng bạn phải làm là giải quyết vấn đề xác thực (một lần nữa, xác thực có nghĩa là thông tin bạn nhận/thay đổi là YOURS). Mọi người có xu hướng là một chút hoang tưởng về các vấn đề an ninh nhưng các hack phổ biến nhất không phải là lỗi của nhà phát triển.

Hy vọng điều này sẽ hữu ích;

Trân trọng, Gabriel