Заменить пхпшный файл регистрации на СИшный

https://en.wikipedia.org/wiki/Security_through_obscurity

http://security.stackexchange.com/a/106433

https://security.stackexchange.com/questions/66552/why-is-security-through-ob...

Краткий ответ: Ты не прав. Для развёрнутого ответа мне лень натирать мозоли на пальцах.

https://ru.wikipedia.org/wiki/CGI

Обфускация дело хорошее, однако сишный код тоже можно «затенить», тем самым ещё больше запутать злоумышленника. Или я ошибаюсь? ... По Вашей первой ссылке не понятна вот эта фраза: Security through obscurity is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: «System security should not depend on the secrecy of the implementation or its components.»

Вроде как что-то не рекомендуется...

Не сочтите за труд, дайте чуть более развёрнутый ответ.

Если не затруднит, добавьте контекста в Ваш пост, ибо не понятно причём здесь цги?

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

раскрытие исходников не влияло на безопасность

Интереснейший парадокс.

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

Вопрос: как написать код, чтоб раскрытие этого пхп-файла не повлияло на безопасность?

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

Не уловил, если негодяи получат Си файл, в который могут передавать любые данные и смотреть выхлоп (по идее так и будет), они и так разберуться что там с данными творится, я не прав?

Вопрос: как написать код, чтоб раскрытие этого пхп-файла не повлияло на безопасность?

/etc/mysql/my.cnf:

bind-address = 127.0.0.1

в пхп-файле.

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

А как раскрытие исходников повлияет на безопасность, если авторизация написана верно? Хоть Си, хоть пхп, можно пример живой? Мимопроходил

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

если очень хочется, то делай php extension
и уже вызывай его в коде

std_mysql_registration($login, $password, $email, $mysql_username, $mysql_password) 

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

И тогда придётся искать место откуда и как он запускается.

Обфускация дело хорошее, однако сишный код тоже можно «затенить», тем самым ещё больше запутать злоумышленника. Или я ошибаюсь? ... По Вашей первой ссылке не понятна вот эта фраза: Security through obscurity is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: «System security should not depend on the secrecy of the implementation or its components.»

Вроде как что-то не рекомендуется...

Все с точностью до наоборот. Там написано, что обфускация (считай и компиляция) не рекомендуются в контексте обеспечения безопасности и ведут чаще к большим проблемам с ней, чем к решениям этих проблем. Что касается производительности - тут другой вопрос, компиляция будет в большинстве случаев предпочтительнее.

Что же до вашего случая. Тот логин и пароль к БД, которые указаны в конфиге php файла должны быть максимально урезаны для доступа только к определенной базе, с определенного хоста и с определенными правами. Сам конфиг должен лежать за пределами www папки, без прямого доступа к нему.

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

Если же ты так боишься за логин и пароль, я тебе открою тайну: /etc/mysql/debian.cnf (убунты и прочие деб дистрибутивы - тоже) - фактически root доступ ко всей БД (пользователь debian-sys-maint), на /etc/passwd можно натравить johntheripper, на RedHat дистрибутивах, если не ошибаюсь, вроде раньше так было, sudo -u mysql -H mysql залогинит пользователя в mysql без вопросов о пароле к самой mysql (ну тут надо знать или установить пароль системного юзера mysql, или получить доступ к /etc/sudoers)

Так что пиши корректный код, не совершай детских ошибок, ПОМЕНЬШЕ СВОИХ ВЕЛОСИПЕДОВ! именно в них большинство дыр кроется, в таких вот Си реализациях в том числе. Используй стойкие пароли, не используй стандартные логины (demo, admin, root) и будет все хорошо, но риск всегда есть. Вон у Руби регулярно уязвимой становится вся платформа, а не приложения, в PHP когда-то был ключ «s», выдававший весь код plain-text'ом вместо исполнения и т.д. Люди учатся на ошибках и все это фиксят, но 100% тебя никто не защитит, только бэкапы и время реагирования. Потерять БД, при наличии бекапов и правильно захешированных паролей (не md5(), а password_hash() с солью) - совсем не страшно, особо никому она ничего не даст, если только список мыл для СПАМа. Неприятно, но пользователи с твоего ресурса скорее всего не уйдут.

Это стоковые настройки конфига, чем это поможет.

Здоровый, красивый и умный — сходил бы ты читать маны.

С данной настройкой mysql будет принимать соединения только с текущего хоста. Так что твой логин и пароль к мускулю вне сервера будет бесполезным.

Все с точностью до наоборот.

Большушая благодарность Вам от меня. Прям небольшой чеклист получился.

Содержательно. Спасибо. Запомнил, пригодится))

безопасность

СИ

Бгг.

вне сервера будет бесполезным

Заполучив пхп-файл с паролем и логином от базы, а так же зная «хитрости» которые применены для хеширования и т.д., я буду на пол пути к манипуляциям скриптами расположенными на сервере.

...

Топик писался с целью понять, как можно обезопасить непосредственно «открытый» пхп-файл. Не более того.

Нельзя основывать безопасность на удаче.

Разумеется это не будет панацеей, но однако же возможно снизит риск.

Это усложнит поддержку системы и создаст видимость защищенности там где ее нету. За такое нужно увольнять.

За такое нужно увольнять

Для себя делаю)))

В целом я всё понял и ответ на вопрос получил. Всем великое спасибо.

Вопрос: как написать код, чтоб раскрытие этого пхп-файла не повлияло на безопасность?

Создать пользователя в БД с правами только на INSERT (и только для тех объектов, с которыми он работает).

причём здесь цги?

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

This.

используйте шифрование/дешифрование на стороне клиента

если хочется скрыть исходники, значит в архитектуре что-то не так ...

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

Вот именно что не рекомендуется. А ты этого и хочешь добиться. Кроме того, ставлю свои носки на то, что ты в первой же форме сделаешь себе буфер оферфлоу, и следущим твоим тредом будет «Си для веба не подходит»

Заполучив пхп-файл с паролем и логином от базы

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

я буду на пол пути к манипуляциям скриптами расположенными на сервере

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

Заполучив пхп-файл с паролем и логином от базы

а, все понятно

Переменные окружения?

Каким образом ты защитишь логику написав её на Си? То что ты не можешь читать дизассемблированный листинг программы - еще не означает, что другой не может этого делать. Как бы ты не извращался с этой темой, но если кому то нужно вытащить логику - он её вытащит имея её представление в любом возможном виде. Любая «защита» на основе обфускации - это такая тема для быдла, например как БАДы, чтобы ты заплатил денег за какой-нибудь ionCube и т.п. и спал спокойно, якобы, но адекватным людям это как два пальца. Умело настроить роли, привилегии, сервисы на парке серверов - это вот то во что стоит вложить время и деньги, так возможно у тебя будет бастион достаточной толщины, чтобы абы кто в него не мог проникнуть. Твоя же идея защитит тебя только от самого днища, скрипткиддисов и т.д. Если у тебя есть возможность утечки php кода - то это явно очень гиблая ж*па, которую ты таким образом очень не правильно пытаешься одолеть.

если «хулиган» каким-то образом заполучит этот самый пхп-файл

Эти файлы в основном лежат на виду под свободными лицензиями.

<а давайте поменяем PHP на C, где новичок две строки без переполнения буфера не сконкатенирует, че уж там про SQL говорить>
снизит риск

успеха разве что.

Наверно я не совсем правильно сформулировал вопрос, посему попробую перефразировать.

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

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

То что ты не можешь читать дизассемблированный

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

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

Понял Вас, спасибо.

Zend Encoder, ionCube - озадачивались этим кое кто, даже продают решения. Но если у человека есть доступ к файлам сервера, то это мёртвому припарка.

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

Ну насколько тупым должен быть злоумышленник, чтобы запустить бинарник вне песочницы?

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

Это всё защита от дураков и пионэров. Любой, кто закончил хотя бы ПТУ, разберётся с такой «защитой» глазом не моргнув.

чтобы запустить бинарник вне песочницы

95%

Это всё защита от дураков и пионэров

95%

95%

Не осилят даже похапе. И что, когда тебя ломанут, тебя сильно будет утешать, что это сделали оставшиеся 5%?

«Никогда не презирайте вашего неприятеля, каков бы он ни был...» Суворов А.В.