EL
Оооо, ты задал замечательный вопрос
Есть какой опыт по этой теме?
Size: a a a
2020 September 02
EL
Я чет ничего не смог найти/придумать. Может просто неправильно гуглил
A
ммм, понимаю, вот думаю смогу ли я в отчете это указать как М2
Ну для некоторых приложений это ок, ну потому что модель угроз позволяет. Для других вопрос, а что за токен. Конечно, да можно указать особенно если доступ без рута и не зашифрован.
BF
Я чет ничего не смог найти/придумать. Может просто неправильно гуглил
Вот и мне ничего в голову не приходит, когда есть огромная система и там всё уже сделано как есть - сложно что-то придумать
IV
Ну для некоторых приложений это ок, ну потому что модель угроз позволяет. Для других вопрос, а что за токен. Конечно, да можно указать особенно если доступ без рута и не зашифрован.
токен аторизации, судя по тому что в json файле написано, ну и как бы в апи я смог атовризоваться с этим токеном без приложени
A
токен аторизации, судя по тому что в json файле написано, ну и как бы в апи я смог атовризоваться с этим токеном без приложени
Ну это явно бажина)
EL
Вот и мне ничего в голову не приходит, когда есть огромная система и там всё уже сделано как есть - сложно что-то придумать
Не, вопрос не в том что нужно чот перепилить, а вообще в возможности прикрыть зад каким-нибудь образом
IV
понял, спасибо за ответы всем)
BF
Не, вопрос не в том что нужно чот перепилить, а вообще в возможности прикрыть зад каким-нибудь образом
Поставьте дропающие весь трафик файрволлы между частями сети, которые вообще не должны друг к другу иметь доступа, и мониторьте логи
BF
Как только кто-то любопытный захочет просканировать сеть, вы его тут же поймаете
EL
Поставьте дропающие весь трафик файрволлы между частями сети, которые вообще не должны друг к другу иметь доступа, и мониторьте логи
Не, они должны иметь доступ. Ну банально сервис 1 ходит в сервис 2 по своим нуждам. Тачку с сервисом 1 похекали и залили туда шелл. Вопрос - можно ли сделать так, чтоб шел не мог получить доступ к апи сервиса 2.
BF
Не, они должны иметь доступ. Ну банально сервис 1 ходит в сервис 2 по своим нуждам. Тачку с сервисом 1 похекали и залили туда шелл. Вопрос - можно ли сделать так, чтоб шел не мог получить доступ к апи сервиса 2.
если это легитимный апи, который юзается регулярно, то нет. Только мониторить обращения на предмет странных и неожиданных запросов к апи, наверное
EL
если это легитимный апи, который юзается регулярно, то нет. Только мониторить обращения на предмет странных и неожиданных запросов к апи, наверное
ну вот только это и приходит на ум, да
BF
Тебя никто не взломает если у тебя не будет доступа к сервису который могут взломать 😎
EL
Бетоном залить!
BF
Принцип минимальных привилегий же ещё - не давай больше инфы чем надо
BF
В качестве дополнительных мер можете впилить в апи какие-нибудь интересные методы типа debug или auth_legacy, и если атакующий их будет изучать, тут же спалится
EL
ага, приманка из словарей
EL
Или можно трекать невалидные запросы, пока атакующий будет подбирать параметры
N
Не, они должны иметь доступ. Ну банально сервис 1 ходит в сервис 2 по своим нуждам. Тачку с сервисом 1 похекали и залили туда шелл. Вопрос - можно ли сделать так, чтоб шел не мог получить доступ к апи сервиса 2.
Нет нельзя, однако, если у вас будет какая-нибудь система авторизации, она позволит, например, отозвать/перевыпустить токен при подозрениях на компрометацию и тем самым ограничить доступ к API для атакующего. Только вопрос в таком случае ещё к тому как вы это мониторите