Личный кабинет - косвенная работа с деньгами, какие могут быть уязвимости?

Sanchez

Новичок
Личный кабинет - косвенная работа с деньгами, какие могут быть уязвимости?

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

Я пока сказал им что подумаю, т.к. боязно браться за то, где ошибка может привести к попадалову)))
В принципе, как я прикинул - нанести вред можно, сняв деньги на "чужой" счет. Но фирма согласна на то, что личный банковский счет забивается заранее и клиент самостоятельно его изменить не может, вариант для смены один - только лично связавшись с ними. И перевод автоматически делается на этот его счет. Тогда снять деньги налево можно, пробравшись в базу Mysql и вручную изменив значение. Пробраться в базу данных можно 2мя способами:
1. Сломав что-то у хостера
2. Через дыру в сайте

По поводу 1 - вообще, насколько хорошо продумана защита у известных хостинговых компаний (Агава, мастерхост, свеб), были ли случаи взлома через их бреши?
По поводу 2 - достаточно ли защитить базу (где будут логины, пароли и прочие данные) от SQL-инъекций и применить вход в личный кабинет через генерацию случайной сессии (т.е. уникального номера, ну известный короче способ)? Или есть какие-то еще уязвимости, которые нужно иметь в виду?

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

Да, и еще вопрос - они мне как аналог показывали один из кабинетов похожих контор, там применялось InterPro вместо стандартного SSL, чем это вызвано? Обычный SSL уже не обеспечивает нужного уровня защищенности?
 

WP

^_^
Товарищ, если ты задаешь этот вопрос, значит это не для тебя. Ну или сделай без договора и отправь их нах когда взломают.
 

Sanchez

Новичок
Если бы здесь была работа с деньгами напрямую, например с вебманями, или сразу бы делали перевод, не проверяя данные, я бы не взялся, но здесь вроде все просто... Поэтому и спрашиваю.
 

WP

^_^
Реши простой вопрос. Если есть полный доступ к серверу можно или нельзя спи.. деньги?
 

boombick

boombick.org
я в шоке просто!!! Финансовые операции на шаред-хостинге, разработка поручается студенту, задающему подобные вопросы на форуме...
Куда катится этот мир?
 

WP

^_^
Все просто) Посредник берет дофига бабла, 95% кладет в себе, а на остальные 5% создает видимость результата нанимая не лучших студентов на шаред-хостинге что-то мутить.
 

Sanchez

Новичок
А по существу кто-нибудь ответить может или гораздо приятней обсуждать куда катится мир?

Еще раз - никакой работы с деньгами НАПРЯМУЮ через сервер не будет. Клиент делает заявку - мол я хочу снять деньги со своего внутреннего счета в вашей конторе на свой банковский счет. Через сервер делается только заявка! Вся информация о том, сколько у какого клиента денег на счету и т.п. - будет храниться у них в локальной базе.

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

gonza

Новичок
Re: Личный кабинет - косвенная работа с деньгами, какие могут быть уязвимости?

Автор оригинала: Sanchez
снять деньги налево можно, пробравшись в базу Mysql и вручную изменив значение. Пробраться в базу данных можно 2мя способами:
1. Сломав что-то у хостера
2. Через дыру в сайте

По поводу 1 - вообще, насколько хорошо продумана защита у известных хостинговых компаний (Агава, мастерхост, свеб), были ли случаи взлома через их бреши?
Ломали, ломают и будут ломать...

Автор оригинала: Sanchez
По поводу 2 - достаточно ли защитить базу (где будут логины, пароли и прочие данные) от SQL-инъекций и применить вход в личный кабинет через генерацию случайной сессии (т.е. уникального номера, ну известный короче способ)?
Если ты не владелец сервера, то любых действий будет недостаточно - все равно полного контроля не добъешся
А для развития кругозора достаточно подумать над тем что уязвимости бывают не только в скриптах но и в самом пыхе. апаче, sql серверах. Они (уязвимости) есть неотъемлимая сущность софта :D
 

Vladson

Сильнобухер
Автор оригинала: Sanchez
1. Сломав что-то у хостера
2. Через дыру в сайте
1. Регулярно такое бывает.
2. Зависит от того кто сайт делал
3. В последнее время гораздо чаще встречаю случаи когда с помощью троянов "тырят" пароли у админов и без всяких дыр получают доступ на сайт. (увы уж очень много "умных" людей открывают файлы полученные по почте, среди них часто попадаются владельцы казалось бы серьёзных сайтов)

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

Mr_Max

Первый класс. Зимние каникулы ^_^
Команда форума
+свой сервак в стойке провайдера
 

Sanchez

Новичок
Re: Re: Личный кабинет - косвенная работа с деньгами, какие могут быть уязвимости?

Автор оригинала: gonza
Если ты не владелец сервера, то любых действий будет недостаточно - все равно полного контроля не добъешся
Это имеется в виду, что невозможно будет организовать защиту по полностью своему усмотрению?

Т.е., как я понял, желательно просто исключать из сервера объект для взлома, как я описывал, например все нужные сведения хранить где-то локально?
 

Андрейка

Senior pomidor developer
если продумать так, что основная информация будет храниться у них локально, а на сайте - лишь дублироваться

тогда разработка сводицца примерно к этому
PHP:
<?php

$res = mysql_query('SELECT * FROM bablo WHERE client="'.$clientID.'"');
$bablo_info = mysql_fetch_assoc($res);

echo $bablo_info['amount'].' тугриков у вас на счету';

?>
 

tashkentchi

Новичок
Автор оригинала: Vladson
3. В последнее время гораздо чаще встречаю случаи когда с помощью троянов "тырят" пароли у админов и без всяких дыр получают доступ на сайт. (увы уж очень много "умных" людей открывают файлы полученные по почте, среди них часто попадаются владельцы казалось бы серьёзных сайтов)
В последнем своем проекте против этого такую фичу сделал: "Черный" и "белый" список IP для доступа с определенными (например, - админскими) правами. Для админского доступа заносятся в "черный" список весь мир (IP от 0.0.0.0 до 255.255.255.255) а в "белый" список (который отменяет "черный") - диапазоны IP, с которых могут заходить админы заказчика. Т.к. заказчик имел постоянный IP, то никто мимо его прокси зайти с админскими правами на сайт не мог. Все было хорошо, пока клиент не сменил провайдера и, следовательно, - IP. А поправить "белый" список заранее не побескоился. Админы остались без админских прав ;) Пришлось срочно их выручать.
 

Skubent

Новичок
Sanchez, тебе нужно:
1. Свой сервер. (много уже говорили, да.)
2. Несколько месяцев времени. (а быстрее сколько-нибудь сложная система, позволяющая чуть больше, чем Андрейкин вариант, не поднимается).
3. Лекарство от нервов. (да-да. Читаешь почту. Уязвимость в пхп, уязвимость в апаче, уязвимость в openSSL и так далее. Вспоминаешь, что у тебя вот это-это-это используется. В зависимости от масштабов финансовых операций волосы начинают шевелиться в разнообразных местах).

ЗЫ. Кто там что про договор говорил ? При попадании заказчика на хорошие бабки оный заказчик вполне может терморектальными методами добиться любого договора. Вопрос исключительно финансовой заинтересованности :)
 

Sanchez

Новичок
Ок, тогда еще вопросы:
1. Свой сервер - с какой точки зрения, с той что там не сделаешь свои настройки безопасности или больше играет роль то, что там кроме тебя есть куча соседей?
И если я покупаю выделенный сервер, то можно ли доверять специалистами из хостинговой компании, которые будут делать его настройку? Т.е. не колокейшн, т.к. сам я безопасно сервер точно не настрою, админством мало занимался.
2. У меня как раз такой простой вариант, пока сайт, как центральное место, в котором будет храниться и обрабатываться информация, использовать не планируется.

И еще я подумал, а если все данные, представленные на сайте в базе, шифровать, применив в качестве ключа пароль пользователя? Т.е. в таком случае, даже если злоумышленник получает полный доступ к базе, то эти данные ему ничего не дадут. Конечно, стоит вопрос в выборе алгоритма шифрования, но наверняка ведь есть уже решения кроме md5.
 

Alexandre

PHPПенсионер
если я покупаю выделенный сервер, то можно ли доверять специалистами из хостинговой компании, которые будут делать его настройку?
Доверять никому нельзя. Мне можно. (с)Мюллер.
надо прописать финансовую ответственность в договоре с хостинговой компанией. В принципе все зависит от того, сколько бабла крутится в этой финансовой компании. Если это небольшие бабки, типа на бытовые покупки в размере до 10 -30 тыс руб, то и при здравом подходе достаточно и шаред хостинга (как говорится, раз все финансовые операции проводятся по локальным БД)
Если крутятся большие пакеты акций, то однозначно свой сервак, и желательно свой админ.
И еще я подумал, а если все данные, представленные на сайте в базе, шифровать, применив в качестве ключа пароль пользователя? Т.е. в таком случае, даже если злоумышленник получает полный доступ к базе, то эти данные ему ничего не дадут.
пароль пользователь забыл?
а пароль хранится где? - думаешь по исходникам не трудно вытащить его имея доступ к серваку ???

-~{}~ 17.04.07 10:45:

Конечно, стоит вопрос в выборе алгоритма шифрования, но наверняка ведь есть уже решения кроме md5.
конечно есть, это использование открытых ключей и сертификатов подлинности. Опять же вопрос в организации хранения ключей. Для этого существуют "криптопровайдеры", предлагающие соответствующие услуги. Тогда вопрос в бюджете проекта??? стоит ли защита тех средств на соответствующие увеличение бюджета???



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

Sanchez

Новичок
С паролями - я думал о такой схеме - у каждого пользователя есть информация в БД. Соответственно у каждого она шифруется собственным паролем. Пароли можно хранить локально в открытом виде (на случай если забыл и + для собственных нужд), а на сервере - вообще не хранить их. Соответственно, даже при полном доступе к серваку, если хацкер не знает пароля клиента, то данные из БД ему ничего не дадует, к тому же узнав один пароль он не сможет получить доступ к чужим данным - т.к. у них пароль (а сл-но, и ключ к дешифрации) другой.

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

Dreammaker

***=Ф=***
Не нужно забывать собсно и о транзакциях, а то и без хакеров попадалово может быть...

Стандартный пример: после того, как запрос о том, что клиент поставил на вывод денежку отработался в БД произошёл сбой.

И до sql-запроса о списании средств с его внутреннего счёта время не дошло...

Что имеем: контора теряет из-за скрипта енную сумму...
 

Wicked

Новичок
Dreammaker
когда контора теряет, это может быть даже не так страшно, как когда деньги теряет клиент, ибо репутация, доверие, и т.д. :) Хотя в любом случае, и то, и другое крайне неприятно.
 

Alexandre

PHPПенсионер
Wicked Dreammaker - если операции по переводу делается с локального клиента, то о каких потерях может быть речь? просто не пришел запрос на перевод денег и все!! хотя репутация все равно потрепана - техника не справилась.
 
Сверху