Trước tiên, tôi không cố gắng hack hoặc làm bất cứ điều gì bất hợp pháp. Nghĩ rằng tôi cho các bạn biết. Tôi có một khách hàng muốn tôi làm một số sửa đổi trên hệ thống của mình, khi tôi nhìn vào nó, tôi nhận thấy rằng NOTHING đã bị trốn thoát. Tôi không nói đùa, không có gì đang được trốn thoát. Tôi giải thích với anh ta rằng nó không an toàn để có một hệ thống như thế. Sau đó anh ta nói với tôi rằng anh ta có hệ thống của mình như thế này trong vài năm và không có gì xảy ra cả. Tôi cần phải cho anh ta thấy rằng hệ thống của anh ta không an toàn, nhưng tôi thực sự không biết thực hiện tiêm sql. Dưới đây là một số truy vấn sử dụng $ _GET và không được thoát.cần hỗ trợ với tiêm sql
SELECT *,DATE_FORMAT(joined,'%M %d, %Y') as \"Joined\" FROM `members` WHERE `name` LIKE '".$ltr."%' ORDER BY points DESC LIMIT $page,50
Dưới đây là một số khác:
SELECT * FROM groups WHERE id=$thisladder[grid]
Điều duy nhất mà tôi thấy rằng "có thể" làm sạch $ _GET là chức năng này:
if (!ini_get('register_globals')) {
$superglobals = array($_SERVER, $_ENV,
$_FILES, $_COOKIE, $_POST, $_GET);
if (isset($_SESSION)) {
array_unshift($superglobals, $_SESSION);
}
foreach ($superglobals as $superglobal) {
extract($superglobal, EXTR_SKIP);
}
}
Có thể là các chức năng trên có thể được khử trùng các biến. Và có, hệ thống cũng sử dụng đăng ký globals, đó cũng là xấu.
Tôi cũng đã sao lưu, chỉ trong trường hợp.
Bạn có muốn biết cách ngăn chặn việc tiêm SQL hoặc chứng minh cho khách hàng của mình rằng nó không an toàn không? – skyuzo
Ôi trời, không chỉ họ không thoát khỏi bất cứ điều gì, nhưng họ * rõ ràng * mô phỏng chức năng 'register_globals' nếu nó bị vô hiệu hóa! Đây là lần đầu tiên! – rid
Tôi không biết làm thế nào để chứng minh điều đó. Nhưng tôi biết rằng mysql_real_escape và báo cáo chuẩn bị là con đường để đi. – user962449