Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Реализация доступа к сайту для запросов с определенных сайтов
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
Доброго времени суток, уважаемые форумчане!
Есть сайт "А", к которому будут обращаться другие сайты. Доступ к сайту "А" должен быть только у определенного списка сайтов, всем остальным доступ закрыт.
Реализация: 1 этап:
Если ip, с которого поступил запрос отсутствует в списке серверов, на которых находятся сайты с разрешенным доступом в доступе отказывается. 2 этап:
Если запрос произведен без соответствия уникального (для данного ip сервера и запроса) ключа в доступе отказывается.
В связи с тем, что есть вероятность хищения ключа и последующего получения доступа с его помощью с сайта на этом же хосте или с тем, что его владелец сможет его использовать на другом сайте, размещенном на этом же хосте требуется дополнительные меры безопасности, есть какие-нибудь соображения по устранени подобной уязвимости?
DeepVarvar
Отправлено: 23 Марта, 2015 - 06:02:20
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Тот сайт который "защищенный" сделать локальным бекендом, если нельзя - в любом случае проксировать с основного. Например запрос на основном:
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
DeepVarvar пишет:
Тот сайт который "защищенный" сделать локальным бекендом, если нельзя - в любом случае проксировать с основного. Например запрос на основном:
CODE (htmlphp):
скопировать код в буфер обмена http://public[dot]tld/protected/a/b/c
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
DeepVarvar пишет:
Гибкость настройки, в том числе и желаемой.
Честно говоря не вижу новых возможностей в этом можете по подробнее описать о каких именно настройках идет речь
Ts.Saltan
Отправлено: 23 Марта, 2015 - 20:18:42
Посетитель
Покинул форум
Сообщений всего: 384
Дата рег-ции: Дек. 2013 Откуда: Belarus
Помог: 22 раз(а)
mk.vizet пишет:
В связи с тем, что есть вероятность хищения ключа и последующего получения доступа с его помощью с сайта на этом же хосте или с тем, что его владелец сможет его использовать на другом сайте, размещенном на этом же хосте требуется дополнительные меры безопасности, есть какие-нибудь соображения по устранени подобной уязвимости?
Не передавать ключ в открытом виде либо использовать ssl. Если же без ssl, можно подписывать запросы ключом.
Например, вот запрос к серверу А
Ключ $secret_key известен только серверу и клиенту, и он не передаётся в открытом виде. Сервер рассчитывает свой хеш и сравнивает с полученным X-Verify, если всё совпало - сервер наш.
mk.vizet
Отправлено: 23 Марта, 2015 - 20:30:32
Новичок
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
Ts.Saltan
имеется ввиду кража ключа в случае получения доступа злоумышленником к одному из сайтов
Ts.Saltan
Отправлено: 23 Марта, 2015 - 20:43:29
Посетитель
Покинул форум
Сообщений всего: 384
Дата рег-ции: Дек. 2013 Откуда: Belarus
Помог: 22 раз(а)
Я так понимаю, нужна проверка, что запрос пришел именно от такого-то ip и такого-то домена, тогда можно сделать так.
1. Клиент подключается к серверу "А", сообщает ему в заголовке свой домен (например, в Referer), постоянно держит соединение не закрывая его.
2. Сервер обращается к скрипту расположенному на my-domain.com, сообщает ему какой-то рандомный ключ. Этот ключ надо хранить у себя и дать ему определенное "время жизни".
Тут какое-нибудь сообщение, мол, временный ключ передан, запрос надо делать именно с ним. Кстати, такое же сообщение можно отправлять, если у предыдущего ключа истёк "срок годности"
5. Теперь клиент делает запросы именно с этим ключом
Тут логика такая, клиент узнает временный ключ для запросов только в том случае, если он будет расположен на указанном домене. Ключ надо генерировать (т.е. выполнять пункт 2) только в том случае, если клиент не передал временный ключ или время жизни ключа истекло. Также можно делать проверки на соответствие IP->Домен, если сервер имеет такую информацию.
p.s. Вообще, не самая хорошая идея привязываться к домену, ИМХО. Если клиент не позаботился о защите ключа, это его проблемы. Тем более, там нечего защищать, закинул в БД и делов то. На всякий случай можно сделать сброс ключа.
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
Ts.Saltan
На сколько я понял информацию о домене предоставляет сам клиент, следовательно с точки зрения безопастности это дыра
Ts.Saltan пишет:
Если клиент не позаботился о защите ключа, это его проблемы
в итоге каждый, кто получил этот ключ, получил доступ к сайту А, таким образом и это тоже дыра
LIME
Отправлено: 24 Марта, 2015 - 05:40:26
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Наддоело мне это слушать
Предоставь разные тарифы по количеству запросов в единицу времени
Потеряли ключ - ваши проблемы... запросы быстро закончились
Хотите один ключ на все ваши службы? Тоже не проблема берите максимальный тариф (Добавление)
А еще есть такая штука называется oAuth
mk.vizet
Отправлено: 24 Марта, 2015 - 16:42:45
Новичок
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
LIME пишет:
Наддоело мне это слушать
ну если надоело - не слушайте, вас никто не заставляет
LIME пишет:
Предоставь разные тарифы по количеству запросов в единицу времени
Потеряли ключ - ваши проблемы... запросы быстро закончились
Хотите один ключ на все ваши службы? Тоже не проблема берите максимальный тариф
(Добавление)
это не подойдет, т.к. все запросы будут происходить в фоновом автоматическом режиме и никаких ограничений по их количеству быть не должно
LIME пишет:
А еще есть такая штука называется oAuth
да, хороший протокол, возможно его принцип будет взят для 3 этапа аутентификации, требуемого для решения следующей задачи:
mk.vizet пишет:
есть вероятность хищения ключа и последующего получения доступа с его помощью с сайта на этом же хосте
(Добавление)
Уважаемые модераторы тему можно закрыть
LIME
Отправлено: 24 Марта, 2015 - 17:12:43
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
ну тогда отслеживай всплески активности
если за неделю запросы выросли более чем на 20% меняй явки и пароли
ну и по ip проверять тоже можно но надо учесть что датацентр может его сменить не предупретив клиента
это только как совокупность мер
Ts.Saltan
Отправлено: 24 Марта, 2015 - 21:00:05
Посетитель
Покинул форум
Сообщений всего: 384
Дата рег-ции: Дек. 2013 Откуда: Belarus
Помог: 22 раз(а)
mk.vizet пишет:
На сколько я понял информацию о домене предоставляет сам клиент, следовательно с точки зрения безопастности это дыра
Нисколько.
Для того и предлагается "костыль" с обратной связью к переданному домену.
Даже если злоумышленник обратится с того же ip, но с другого домена, у него ничего не выйдет.
LIME
Отправлено: 24 Марта, 2015 - 21:07:50
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Насколько помню oauth какраз и исполняет типа тройного рукопожатия
mk.vizet
Отправлено: 25 Марта, 2015 - 20:34:48
Новичок
Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015
Помог: 0 раз(а)
LIME пишет:
ну тогда отслеживай всплески активности
если за неделю запросы выросли более чем на 20% меняй явки и пароли
да, хорошая идея, спасибо
LIME пишет:
ну и по ip проверять тоже можно но надо учесть что датацентр может его сменить не предупретив клиента
доступ будет даваться только для выделенных ip. там не сменят же?)
Ts.Saltan пишет:
mk.vizet пишет:
На сколько я понял информацию о домене предоставляет сам клиент, следовательно с точки зрения безопастности это дыра
Нисколько.
Для того и предлагается "костыль" с обратной связью к переданному домену.
Даже если злоумышленник обратится с того же ip, но с другого домена, у него ничего не выйдет.
Полностью с вами согласен, не правильно понял, что вы до этого написали
oAuth использует подобный алгоритм
LIME пишет:
Насколько помню oauth какраз и исполняет типа тройного рукопожатия
именно, только в моем случае не требуется авторизация
Всем, принявшим участие в обсуждении, огромное спасибо! ! Удачи!
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.