all your base

[stas]

Тут вот пишут об очередной дыре в безопасности сайтов. Надо сказать, я не удивлен. Система безопасности, которая бы не позволила таком случиться - на уровне программном или на уровне организационном - неудобна, дорога, а главное - когда она работает, всему этому нет ровно никакого оправдания - ничего же не случается! А если случается, то чаще всего - это ложное срабатывание.
Если вы думаете, что это что-то новое в компьютерной отрасли - то вот вам пример.

A suburban New York City nuclear power plant's siren system has mistakenly
blared out the warning, "Emergency! Emergency! Emergency!"  The ominous
message rattled some of the residents of New City, about 30 miles north of
midtown Manhattan. Auto shop worker Rudy Gaspari says the mechanical voice
had an unsettling, post-apocalyptic overtone to it.

The voice came from an Indian Point plant siren located downtown during a
test Friday, The Journal News reported.  Indian Point spokesman Jerry Nappi
says the voice message "shouldn't have happened." He says plant officials
have disabled the voice mechanism in the siren.

Т.е. на атомной электростанции есть механизм, который о чем-то там предупреждает. Пост-апокалиптичексим голосом. В один прекрасный день эту систему проверяют, и в ходе проверки она ложно срабатывает. Что делают в этом случае люди? Выключают голосовой механизм. Как замечают в рассылке RISKS, what could possibly go wrong there?

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

А Британские Ученые (TM) тем временем собираются доверить компьютерам чтение экзаменационных сочинений.

Конечно, школьные сочинения типа "Онегин как образ лишнего человека" и писать можно компьютером, не то что читать, но я бы предпочел, чтобы мое сочинение читал кто-то разумный. Что, впрочем, и без участия компьютеров совсем не гарантировано. 

Comments

[digest.livejournal.com]

Не совсем разглядел Дыру. Не позволить такому случиться очень просто: production серверы на *всем* адресуемом http-пространстве сайта не должны содержать ничего, кроме доступного конечному пользователю. Тем более не содержать исходников, систем контроля версий, файлов паролей к швейцарским сейфам и т.п. Дыра там в голове у админов. Торвальдс отнесся бы еще суровее к людям, использующим SVN :), но в данном случае публичному веб-серверу нельзя содержать даже каталог .git :)

[stas]

Вы, конечно, правы, не должен. Но кто ж за этим следит?

[alexcohn.livejournal.com]

Вообще говоря, я не вижу проблемы в том, чтобы исходники php публичного сервиса, типа почты, были доступны. В том числе, через SVN. До тех пор, конечно, пока туда не вписаны в виде строковых констант пароли доступа к данным этого сайта.

[digest.livejournal.com]

А разве есть другой способ держать пароли доступа (к БД и проч.) для PHP сайта, кроме как строковой константой?

[stas]

Вообще говоря это странный вопрос. Пароли ничем не отличаются от любых других данных. Разве есть способ держать данные в PHP, кроме как в строковых константах? Конечно, есть :)

[digest.livejournal.com]

:)
Тем не менее, находятся ли данные в строковых константах или отдельном файле, эти данные должны быть доступны самому PHP-скрипту, то есть любому посетителю сайта. Или за те 10 лет, что я не работал с PHP, произошли какие-то кардинальные изменения в PHP-security?
Или я просто торможу и предлагается вынести файл с паролями за веб-пространство вообще, типа mkdir /secretphpdata && chown apache:apache /secretphpdata? Но и это достаточно уродливое решение. Не, с PHP я всё же был бы однозначен: *никаких* посторонних файлов, ни даже вебсерверного доступа к существующим. Хэндлинг только через PHP.

[stas]

эти данные должны быть доступны самому PHP-скрипту, то есть любому посетителю сайта

Вот это "то есть" мне определенно нравится. Уж не утверждаете ли вы, что посетитель сайта автоматически имеет право доступа к любым данным, к которым имеет доступ код сайта? Это было бы замечательно, с точки зрения безопасности.

предлагается вынести файл с паролями за веб-пространство вообще, типа mkdir /secretphpdata && chown apache:apache /secretphpdata? Но и это достаточно уродливое решение.

Я не предлагаю никаких решений, поскольку решений может быть миллион, в зависимости от постановки задачи (в том числе возможна постановка, при которой строковые константы тоже ОК). Очевидно, что задача, поставленная как "скрипт может получить данные, а некто, полностью контролирующий этот скрипт - нет" - неразрешима по определению, однако она обычно так и не ставится. У PHP тут нет никаких отличий от чего-либо другого.

Не, с PHP я всё же был бы однозначен: *никаких* посторонних файлов, ни даже вебсерверного доступа к существующим

Это обычно имеет смысл. Хотя php.net уже почти 10 лет живет с открытым доступом ко всем сорцам сайта и ничего :) Но в общем случае это действительно разумный совет.

[digest.livejournal.com]

Уж не утверждаете ли вы, что посетитель сайта автоматически имеет право доступа к любым данным, к которым имеет доступ код сайта? Это было бы замечательно, с точки зрения безопасности.

Ну так в доброй половине расшаренных вебхостингов мое утверждение истинно. И если не принимать никаких специальных телодвижений вроде .htaccess с deny all, то таки да, посетитель и скрипт имеют одинаковый доступ к данным, т.к. имеют одинаковый uid. На грамотном хостинге, собственном сервере или VPS свободы разумеется больше, т.к. скрипту доступна файловая система, а посетителю только заданные директории и DocumentRoot.

[stas]

таки да, посетитель и скрипт имеют одинаковый доступ к данным, т.к. имеют одинаковый uid

Вы, похоже, полагаете, что "имеет доступ к данным" == "имеет, с точки зрения вебсервера, доступ на чтение к файлам, расположенным в тех частях файловой системы, которые, согласно конфигурации вебсервера, соответствуют определенным URL". Это один из случаев, да. Однако данные бывают сильно разные :)
Что касаемо расшареных вебхостингов, то требовать от самоката безопасности Вольво несколько наивно :) В этом случае, вероятно, строковые константы будут одним из возможных решений, если администрация не придумает чего получше.

[alexcohn.livejournal.com]

кстати, про явки и пароли... Можно еще одну книжку у тебя купить?

[alexcohn.livejournal.com]

Ой, да вы тут в серьез это обсуждаете? Прости, я думал, это ты прикололся. Потому что разговор-то не про доступ к скриптам сайта, а к их исходникам (т.е. SVN-копия этого же сайта). На самом деле, файлы конфигурации, вместе с работающими скриптами, должны конечно храниться в сторонке. А вот класть эти файлы, с прописанными в них паролями, в публичный SVN не следует.

[stas]

какую?

[digest.livejournal.com]

Да, можно.

[alexcohn.livejournal.com]

Игорь ведь e-bookи в Израиль импортирует

[stas]

А, не знал.