WHCMS уязвимость от 18 октября

Хм, видимо у меня, как программиста, иные взгляды. Код WHMCS закрыт - я его не вижу, поправить ничего нельзя. Фактически у меня отняли руки.

В итоге, как альтернатива, это своя "обертка", где я буду уверен, что данные будут передаваться к биллингу на API в отфильтрованном виде.

Что Вас смущает, что API работает от имени администратора? То, что пароль будет хранится в открытом виде в PHP файле? Данные доступа к базе данных тоже хранятся в открытом виде в конфигурационном фале, если получить доступ сразу к БД, то проблема мне кажется даже слаще будет.

Не считаю, в общем, это проблемой.

Если использовать апи до лучше уж дописать функцию "пользовательского апи". Если уж самому писать то писать то что меньше вреда принести может в случаи чего. Ну а пользовательский апи создать не так уж сложно. И для этого открывать код не нужно! И это огромный + whmcs.

Возможно мы не понимаем друг друга. Что Вы имеете под пользовательским API?

Я предлагал такую схему, поясню на примере оформления заказа.

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

2. Мы обрабатываем эти данные, если все нормально, но передаем их в безопасном виде на метод addorder самого биллинга: http://docs.whmcs.com/API:Add_Order

3. Клиенту отдаем страницу "Спасибо за заказ".

Клиент полностью работает с нашим сайтом и нашим скриптом. Он никак не доходит до биллинга WHMCS и понятия не имеет о его существовании.

Что в данном случае небезопасного? Поясните мне, пожалуйста.

В этом api есть только функции админа, т.е. то что вы создаете из админки, нету функций клиента. Проще говоря чтобы клиент выполнил заказ нужно соеденится с логином/паролем админа, а не клиента.

И если вы хорошо изучали whmcs то там есть несколько операций, хоть и не больно нужных, которые можно выполнить только из под клиента.

Если вы допускаете ошибку в своем коде или же находят уязвимость в нем, хакер получает _полный_ доступ к whmcs. В случае соединения с логином/паролем клиента если и взломают то только одного клиента. И полагаю пока додумаются как добраться к админу, даже если возможность будет, вы успеете закрыть дыру.

Только не нужно говорить что в вашем коде ошибок быть не может! Ошибаются ВСЕ.

То, что нет в API, можно реализовать самостоятельно. WHMCS берет данные из БД, если в API нет метода, можно сделать это самостоятельно, прямым обращением в БД. Основные функции можно реализовать полностью на API, а как Вы сами сказали "не больно нужные" можно вовсе не реализовывать, либо реализовать по схеме выше - прямым обращением в БД.

Вы вновь упоминаете о пользователе администратора. Я вновь подчеркиваю, чем это небезопасно, чем Вас это смущает? Соединение происходит на стороне сервера, а не клиента. Клиент не узнает, имя пользователя администратора и его пароль.

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

Все методы, пароль и имя пользователя администратора взаимодействуют только на стороне сервера с биллингом. Злоумышленник максимум, что передаст опасные данные на API, даже если у нас не сработает фильтр. Каким образом он по Вашему получит ПОЛНЫЙ доступ к биллингу?

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

Евгений Русаченко мыслит в абсолютно верном направлении, о деталях можно спорить, но мы в процессе реализации похожего подхода :)

Павел Гаврилин, согласен, идея вполне хорошая.

Евгений Русаченко, давайте то что можно без апи упустим, так как речь зашла именно об использовании апи без написания своего. Т.е. имеем то что имеем.

Ваш биллинг >> whmcs

Чтобы в whmcs было что либо выполнено необходимо передать логин и пароль админа. А они будут хранится где? В вашем биллинге.

И если в вашем биллинге будет дырка и взломщик сможет найти и прочесть данные эти то вопрос входа в саму whmcs это только вопрос времени.

Разумеется здесь очень много "если". Я не оспариваю вашу идею, просто если делать верно, то делать верно ВСЕ.

WapGraf:
Павел Гаврилин, согласен, идея вполне хорошая.

Евгений Русаченко, давайте то что можно без апи упустим, так как речь зашла именно об использовании апи без написания своего. Т.е. имеем то что имеем.

Ваш биллинг >> whmcs
Чтобы в whmcs было что либо выполнено необходимо передать логин и пароль админа. А они будут хранится где? В вашем биллинге.
И если в вашем биллинге будет дырка и взломщик сможет найти и прочесть данные эти то вопрос входа в саму whmcs это только вопрос времени.
Разумеется здесь очень много "если". Я не оспариваю вашу идею, просто если делать верно, то делать верно ВСЕ.

Это палка о двух концах. Вам необходимо хранить либо данные базы данных, либо данные администратора. Пользователя ведь как-то надо создать в биллинге :) Есть еще идеи, но озвучивать их не буду, чтобы не возникли еще дискуссии...

И мое мнение, лучше хранить данные администратора, чем данные базы, если рассматривать два этих варианта... Но, как сказал, уважаемый Павел: "о деталях можно спорить"...

То, что я предложил, это моя первая идея, которая появилась относительно недавно. Я её не продумывал, и не прорабатывал. Так сказать, наброски. Понятно, что при реализации, что-то может быть переработано.

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

А вот по поводу пользовательского апи - общался с разработчиками недели две назад. Его создание возможно и не сложное. И только по этому и начал этот спор. Зачем везде использовать данные админа, если можно использовать во многих местах данные клиента. =)

Этим самым мы повышаем безопасность в глобальном понимании.

Если говорить про API через данные админского доступа и боязнь за их компрометацияю - то права доступа легко настраиваются, можно создать админа (или кучу админов), который может только создавать клиентов Add New Client и не иметь больше доступа ни к чему, в том числе, к просмотру информации о клиентах или счетах, например.