Является ли простой текстовый пароль в сценарии CGI дырой в безопасности?

Я читал, что с вашим веб-сервером что-то может пойти не так, что может привести к отображению сценариев PHP в виде простых текстовых файлов в веб-браузере; следовательно, я переместил большинство своих PHP-скриптов в каталог за пределами корневого веб-каталога. Теперь мне интересно, может ли то же самое случиться со сценариями CGI в моем cgi-bin.

да. Если что-то пойдет не так, из-за чего программы будут обслуживаться, а не выполняться, то любое их содержимое будет раскрыто. Это точно такая же проблема, как и с PHP (за исключением того, что, учитывая способ, которым обычно настраиваются каталоги cgi-bin (т. Е. Псевдоним каталога вне корневого веб-каталога), решить проблемы немного сложнее. происходить).

Меня больше всего беспокоит один сценарий, который содержит имя пользователя и пароль для моей базы данных MySQL. Если это возможная дыра в безопасности (по крайней мере, в том, что касается содержимого базы данных), есть ли способ поместить конфиденциальные данные в другое место и получить их оттуда (например, сохранить их в файле в другом каталоге и прочитать это из того файла, например)?

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

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

Мои скрипты, кстати, написаны на Perl.

Я бы посмотрел на использование одного из модулей Config :: * для этого.

Одна проблема, о которой стоит упомянуть, относится к виртуальному хостингу.

Если вы находитесь на хосте, совместно используемом с другими пользователями, возможно, будет невозможно скрыть от них пароль. Это зависит от деталей конфигурации ОС и веб-сервера.

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

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

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

Жестко закодировать пароль в скрипте - определенно не лучшая идея, если вы можете этого избежать. К счастью, и Postgres, и MySQL поддерживают загрузку учетных данных БД из файла. Для Postgres вы используете ~ / .pgpass, а для MySQL, я считаю, это ~ / .my.cnf. В любом случае вы должны настроить разрешения так, чтобы только пользователь, запускающий сценарий, имел разрешение на чтение файла. Преимущество этого подхода в том, что вам не нужно писать код для чтения файла - клиентская библиотека БД делает это автоматически.

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

Если вы используете каталог, настроенный как cgi-bin, файл не может отображаться, кроме ошибки с конфигурацией Apache. Если вы используете программы Perl вне каталогов cgi-bin, но внутри корня сайта, это может произойти.

Кроме того, вы можете настроить БД на прием соединений только из локального сокета, поэтому знание пароля БД будет бесполезно.

Вы уже получили ответы лучше, чем я могу дать, но в качестве примечания:

Хранить пароли в виде открытого текста - очень плохой тон.

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