Уязвимость SQL инъекций

Question

Я не какой-то hax0r или около того, но у моего босса есть веб-сайт, и я сказал ему, что он уязвим для атак SQL-инъекций.Затем он ответил, что это не опасно, потому что вся информация является публичной;поэтому я сказал ему, что есть возможность бросить столы.

Обычно команда DROP table работает, может кто-нибудь сказать мне, почему не в этом случае?ПРИМЕЧАНИЕ: ЭТА БАЗА ДАННЫХ ТОЛЬКО ХРАНИТ НОВОСТИ, НЕ ЖИЗНЕННАЯ ИНФОРМАЦИЯ!

news.php?id=-99%20union%20all%20select%201,2,3,4,5%20from%20information_schema.columns%20where%20table_schema=0x656e6469616d615--

Пожалуйста, не отвечайте с комментариями hax0r-ненависти, если я хочу знать, как взломать, я буду на каналах irc, а не здесь.

РЕДАКТИРОВАТЬ: Если он в безопасности от редактирования базы данных, я думаю, что он прав.Он мог бы раскрыть SQL-запрос, но это не помогло бы показать, что опасность реальна.

Answer 1

Если вы можете обнаружить имена столбцов по SQL-инъекциям, это означает, что они могут быть нарушены.

Это также означает, что вы можете легко атаковать веб-страницу методом «грубой силы» и обнаруживать всю структуру, пользователей, экспортировать данные и т. Д. Итак, да, сайт уязвим и идет гораздо дальше, чем «Мои данные общедоступнытак что мне все равно "...

Хакер может найти способ вставить данные в базу данных, создать фишинг, украсть данные из XSS-атак, которые он вставит в базу данных.Есть множество причин, чтобы относиться к этому серьезно.SQL-инъекция не означает, что хакер может только читать ваши данные, это может привести к серьезным компромиссам ...

Answer 2

Я бы посчитал любое раскрытие информации опасным - если это не исправить сейчас, что произойдет в будущем, когда / если в эту базу данных будет помещена более конфиденциальная информация? Что если существующие данные были изменены злонамеренно?

SQL-инъекцию очень легко защитить, и если вы знаете о возможной уязвимости, ее следует исправить как можно скорее, независимо от того, что считается чувствительным. Просто мой 2с.

Answer 3

Внедрение SQL не является проблемой, если пользователь SQL имеет доступ только к привилегии SELECT.Любые другие привилегии могут быть угрозой безопасности (в частности, DROP, но также INSERT или DELETE).

Лично я бы просто защитил все это от внедрения SQL, а затем применил бы привилегии к пользователю SQL, которые ограничивают возможностивыполнить атаку, даже если моя линия защиты нарушена.

Даже если данные не являются конфиденциальными, внедрение SQL может привести к фишинговым атакам, мошенничеству и незаконному контенту, отображаемому на уязвимом веб-сайте.Не хорошо.