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 :: Реализация доступа к сайту для запросов с определенных сайтов

 PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (4): [1] 2 3 4 »   

> Описание: Реализация доступа к сайту для запросов с определенных сайтов
mk.vizet
Отправлено: 21 Марта, 2015 - 18:07:06
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




Доброго времени суток, уважаемые форумчане! Подмигивание

Есть сайт "А", к которому будут обращаться другие сайты. Доступ к сайту "А" должен быть только у определенного списка сайтов, всем остальным доступ закрыт.

Реализация:
1 этап:
Если ip, с которого поступил запрос отсутствует в списке серверов, на которых находятся сайты с разрешенным доступом в доступе отказывается.
2 этап:
Если запрос произведен без соответствия уникального (для данного ip сервера и запроса) ключа в доступе отказывается.

В связи с тем, что есть вероятность хищения ключа и последующего получения доступа с его помощью с сайта на этом же хосте или с тем, что его владелец сможет его использовать на другом сайте, размещенном на этом же хосте требуется дополнительные меры безопасности, есть какие-нибудь соображения по устранени подобной уязвимости? Закатив глазки
 
 Top
DeepVarvar Супермодератор
Отправлено: 23 Марта, 2015 - 06:02:20
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Тот сайт который "защищенный" сделать локальным бекендом, если нельзя - в любом случае проксировать с основного. Например запрос на основном:
CODE (htmlphp):
скопировать код в буфер обмена
  1. http://public.tld/protected/a/b/c

Проксировать на:
CODE (htmlphp):
скопировать код в буфер обмена
  1. http://protected.tld/a/b/c

А на защищенном разрешить доступ только с айпи основного (вплоть до 127.0.0.1 если они на одной машине).
 
 Top
mk.vizet
Отправлено: 23 Марта, 2015 - 18:24:11
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




DeepVarvar пишет:
Тот сайт который "защищенный" сделать локальным бекендом, если нельзя - в любом случае проксировать с основного. Например запрос на основном:
CODE (htmlphp):
скопировать код в буфер обмена
http://public[dot]tld/protected/a/b/c

Проксировать на:
CODE (htmlphp):
скопировать код в буфер обмена
http://protected[dot]tld/a/b/c

А на защищенном разрешить доступ только с айпи основного (вплоть до 127.0.0.1 если они на одной машине).

а что все это даст?

(Отредактировано автором: 23 Марта, 2015 - 18:25:27)

 
 Top
DeepVarvar Супермодератор
Отправлено: 23 Марта, 2015 - 18:27:46
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Гибкость настройки, в том числе и желаемой.
 
 Top
mk.vizet
Отправлено: 23 Марта, 2015 - 18:36:59
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




DeepVarvar пишет:
Гибкость настройки, в том числе и желаемой.

Честно говоря не вижу новых возможностей в этомНедовольство, огорчение можете по подробнее описать о каких именно настройках идет речьУлыбка
 
 Top
Ts.Saltan
Отправлено: 23 Марта, 2015 - 20:18:42
Post Id



Посетитель


Покинул форум
Сообщений всего: 384
Дата рег-ции: Дек. 2013  
Откуда: Belarus


Помог: 22 раз(а)




mk.vizet пишет:
В связи с тем, что есть вероятность хищения ключа и последующего получения доступа с его помощью с сайта на этом же хосте или с тем, что его владелец сможет его использовать на другом сайте, размещенном на этом же хосте требуется дополнительные меры безопасности, есть какие-нибудь соображения по устранени подобной уязвимости?

Не передавать ключ в открытом виде либо использовать ssl. Если же без ssl, можно подписывать запросы ключом.
Например, вот запрос к серверу А
CODE (text):
скопировать код в буфер обмена
  1.  
  2. GET /api/method/rand123 HTTP/1.1
  3. Host: A.aa
  4. X-Verify: md5("GET /api/method/rand123".$secret_key)
  5. Connection: close
  6.  

Ключ $secret_key известен только серверу и клиенту, и он не передаётся в открытом виде. Сервер рассчитывает свой хеш и сравнивает с полученным X-Verify, если всё совпало - сервер наш.
 
 Top
mk.vizet
Отправлено: 23 Марта, 2015 - 20:30:32
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




Ts.Saltan
имеется ввиду кража ключа в случае получения доступа злоумышленником к одному из сайтов
 
 Top
Ts.Saltan
Отправлено: 23 Марта, 2015 - 20:43:29
Post Id



Посетитель


Покинул форум
Сообщений всего: 384
Дата рег-ции: Дек. 2013  
Откуда: Belarus


Помог: 22 раз(а)




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

1. Клиент подключается к серверу "А", сообщает ему в заголовке свой домен (например, в Referer), постоянно держит соединение не закрывая его.
CODE (text):
скопировать код в буфер обмена
  1. GET /hello/ HTTP/1.1
  2. Host: A
  3. Referer: my-domain.com
  4. Connection: keep-alive


2. Сервер обращается к скрипту расположенному на my-domain.com, сообщает ему какой-то рандомный ключ. Этот ключ надо хранить у себя и дать ему определенное "время жизни".
CODE (text):
скопировать код в буфер обмена
  1. POST verify-server.php HTTP/1.1
  2. Host: my-domain.com
  3. Connection: close
  4.  
  5. randomPhrase_blablabla


3. Скрипт на клиенте сохраняет временный ключ, например, в БД.

4. Теперь же надо ответить клиенту на запрос из п1.
CODE (htmlphp):
скопировать код в буфер обмена
  1. HTTP/1.x 401 Unauthorized
  2.  
  3. Тут какое-нибудь сообщение, мол, временный ключ передан, запрос надо делать именно с ним. Кстати, такое же сообщение можно отправлять, если у предыдущего ключа истёк "срок годности"


5. Теперь клиент делает запросы именно с этим ключом
CODE (text):
скопировать код в буфер обмена
  1. POST /hello/ HTTP/1.1
  2. Host: A
  3. X-My-Key: randomPhrase_blablabla
  4. Connection: keep-alive
  5.  
  6. Текст запроса блаблабла



Тут логика такая, клиент узнает временный ключ для запросов только в том случае, если он будет расположен на указанном домене. Ключ надо генерировать (т.е. выполнять пункт 2) только в том случае, если клиент не передал временный ключ или время жизни ключа истекло. Также можно делать проверки на соответствие IP->Домен, если сервер имеет такую информацию.

p.s. Вообще, не самая хорошая идея привязываться к домену, ИМХО. Если клиент не позаботился о защите ключа, это его проблемы. Тем более, там нечего защищать, закинул в БД и делов то. На всякий случай можно сделать сброс ключа.

(Отредактировано автором: 24 Марта, 2015 - 21:01:02)

 
 Top
mk.vizet
Отправлено: 24 Марта, 2015 - 03:17:50
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




Ts.Saltan
На сколько я понял информацию о домене предоставляет сам клиент, следовательно с точки зрения безопастности это дыра

Ts.Saltan пишет:
Если клиент не позаботился о защите ключа, это его проблемы

в итоге каждый, кто получил этот ключ, получил доступ к сайту А, таким образом и это тоже дыра
 
 Top
LIME
Отправлено: 24 Марта, 2015 - 05:40:26
Post Id


Активный участник


Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010  


Помог: 322 раз(а)




Наддоело мне это слушать
Предоставь разные тарифы по количеству запросов в единицу времени
Потеряли ключ - ваши проблемы... запросы быстро закончились
Хотите один ключ на все ваши службы? Тоже не проблема берите максимальный тариф
(Добавление)
А еще есть такая штука называется oAuth
 
 Top
mk.vizet
Отправлено: 24 Марта, 2015 - 16:42:45
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




LIME пишет:
Наддоело мне это слушать

ну если надоело - не слушайте, вас никто не заставляет

LIME пишет:
Предоставь разные тарифы по количеству запросов в единицу времени
Потеряли ключ - ваши проблемы... запросы быстро закончились
Хотите один ключ на все ваши службы? Тоже не проблема берите максимальный тариф
(Добавление)

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

LIME пишет:
А еще есть такая штука называется oAuth

да, хороший протокол, возможно его принцип будет взят для 3 этапа аутентификации, требуемого для решения следующей задачи:
mk.vizet пишет:
есть вероятность хищения ключа и последующего получения доступа с его помощью с сайта на этом же хосте

(Добавление)
Уважаемые модераторы тему можно закрыть
 
 Top
LIME
Отправлено: 24 Марта, 2015 - 17:12:43
Post Id


Активный участник


Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010  


Помог: 322 раз(а)




ну тогда отслеживай всплески активности
если за неделю запросы выросли более чем на 20% меняй явки и пароли
ну и по ip проверять тоже можно но надо учесть что датацентр может его сменить не предупретив клиента
это только как совокупность мер
 
 Top
Ts.Saltan
Отправлено: 24 Марта, 2015 - 21:00:05
Post Id



Посетитель


Покинул форум
Сообщений всего: 384
Дата рег-ции: Дек. 2013  
Откуда: Belarus


Помог: 22 раз(а)




mk.vizet пишет:
На сколько я понял информацию о домене предоставляет сам клиент, следовательно с точки зрения безопастности это дыра

Нисколько.
Для того и предлагается "костыль" с обратной связью к переданному домену.
Даже если злоумышленник обратится с того же ip, но с другого домена, у него ничего не выйдет.
 
 Top
LIME
Отправлено: 24 Марта, 2015 - 21:07:50
Post Id


Активный участник


Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010  


Помог: 322 раз(а)




Насколько помню oauth какраз и исполняет типа тройного рукопожатия
 
 Top
mk.vizet
Отправлено: 25 Марта, 2015 - 20:34:48
Post Id


Новичок


Покинул форум
Сообщений всего: 35
Дата рег-ции: Март 2015  


Помог: 0 раз(а)




LIME пишет:
ну тогда отслеживай всплески активности
если за неделю запросы выросли более чем на 20% меняй явки и пароли

да, хорошая идея, спасибо

LIME пишет:
ну и по ip проверять тоже можно но надо учесть что датацентр может его сменить не предупретив клиента

доступ будет даваться только для выделенных ip. там не сменят же?)

Ts.Saltan пишет:
mk.vizet пишет:
На сколько я понял информацию о домене предоставляет сам клиент, следовательно с точки зрения безопастности это дыра

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

Полностью с вами согласен, не правильно понял, что вы до этого написали
oAuth использует подобный алгоритм

LIME пишет:
Насколько помню oauth какраз и исполняет типа тройного рукопожатия

именно, только в моем случае не требуется авторизация

Всем, принявшим участие в обсуждении, огромное спасибо! ! Удачи! Подмигивание Радость
 
 Top
Страниц (4): [1] 2 3 4 »
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« Программирование на PHP »


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



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB