2011-01-14 2 views
1

Только один или два доверенных человека имеют пароль. htpasswd находится вне каталога public_html. Скрипт в защищенной папке содержит незащищенные входы. Возможна ли SQL-инъекция без пароля?Насколько безопасно htacces/htpasswd?

+6

Как SQL-инъекция или SQL вообще вступают в игру здесь? – deceze

+0

@deceze: несаминированные входы. – tdammers

+0

Можете ли вы быть немного более подробным? Что вы делаете с этими ресурсами? – deceze

ответ

6

Возможна ли инъекция SQL без пароля?

Предполагая, что ваш .htaccess и .htpasswd на самом деле дают экран для вашего имени пользователя и пароля, он безопасен. Если комбинация имени пользователя и пароля недействительна, Apache вернет заголовок HTTP 403: Forbidden, что означает, что запрос никогда не передавался PHP. Это означает, что ваши протекающие скрипты не могут быть выполнены без действительного имени пользователя и пароля.

Сценарий в защищенной папке содержит незащищенные входы.

Я думаю, вы должны рассмотреть вопрос о том, чтобы всячески защищать входы, защищенные страницы или нет.

+0

Просто следуйте за нами, вы на 100% правильно относитесь к ежедневной дезинфекции данных. Это работало только потому, что A) это старый старый сценарий, который я не написал B) после того, как он предупредил клиента о том, что им нужен самый быстрый и дешевый способ (они уже растянули свой бюджет), а C) только один человек когда-либо использовал скрипт и довольно легко (1 раз в месяц в течение примерно 15 минут) Если бы я когда-либо был в этой ситуации, я бы просто посоветовал, чтобы сценарий был протекающим и сообщал им, чтобы он не использовал его. – MSD

1

SQL Injection невозможно, потому что злоумышленник без пароля не сможет пройти через Apache на первом месте.

Однако HTTP Basic Auth подвержен атаке «человек в середине», так как пароль можно легко перехватить (вы можете использовать HTTPS, если это общедоступный веб-сайт).

0

Поток SQL-инъекций будет по-прежнему здесь просто защищен стеной имени пользователя и пароля.

Вы должны иметь в виду, что если вы не используете SSL, пароль/имя пользователя будет передаваться как чистый текст на провод. Это означает, что если кто-нибудь может понюхать этот трафик, он получит имя пользователя/пароль.

Также это не защищает вас от законных пользователей, пытающихся внедрить SQL-инъекцию в ваше приложение. Вы должны иметь в виду, что большинство атак происходит изнутри.

Я был бы вами, я бы поставил пароль в качестве быстрого исправления, но исправить проблему с вводом/вводом SQL-запросов при возникновении некоторых шансов.

1

Я не думаю, что есть способ обойти защищенный паролем каталог, если он настроен правильно.

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

0

.htaccess не спасет вас от инъекции.

Представьте себе ситуацию, когда один из ваших доверенных людей получает вирус на своем ПК. Virus ставит свой пароль и передает его хакеру. Хакер регистрируется и удаляет вашу базу данных с помощью SQL-инъекции.

Даже если этого не происходит, всегда избегайте ваших запросов, чтобы пользователи могли безопасно использовать charecters как «» в своих запросах.

SELECT `name` FROM `table` WHERE `name` = 'pub 'cosa blanca''; --SQL error 
2

Просто санируйте эти входы. Я серьезно. Система столь же сильна, как и ее самое слабое звено; даже если вы доверяете тем людям, которых вы предоставляете, всегда есть другие атаки, которые люди могут использовать, чтобы обойти это.Несколько возможностей:

  • социальной инженерии (возможности бесконечны здесь)
  • сети нюхают (особенно если сайт обслуживается без SSL)
  • уязвимости в браузере доверенного пользователя или OS
  • слабые пароли
  • скомпрометированы веб-сервер (если кто-то удается удалить файл .htaccess, все потеряно)
  • фишинг
  • DNS spoofing
2

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

<Files ~ "^\.ht"> Order allow,deny Deny from all </Files> 
3

Вне зависимости от настройки, вы всегда, всегда, всегда обрабатывать данные так, как будто он в любой момент выпрыгнет из монитора, и SQL впрыснет прямо в ваше сердце. Вы не спрашиваете, возможно ли это при обстоятельствах x, y и z, вы всегда считаете, что это по умолчанию.

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

Смежные вопросы