Pull to refresh

Comments 14

Неплохо! Планируете ли по Android платформе похожие материалы готовить?
А вам правда нужен такой материал по Android? На хабре уже очень много подобного и поэтому мы даже не думали готовить такой материал. Давайте так, если вам нужен такой материал, то ставьте плюс в этот комментарий. По итогу решим.
Даже при использовании HTTPS-соединений остается возможность просмотра данных третьими лицами при обмене с сервером. Например, в публичных сетях злоумышленник мог бы отслеживать трафик с помощью атаки Man-in-the-middle, в которой он становится посредником между приложением и сервером.

Чуть подробнее, пожалуйста. Я подозреваю, что такие атаки действительно есть, но фраза вызывает ощущение, что SSL вообще не защищает от MIM. И насколько хорошо работает в случае таких атак SSL-pinning?

Сам по себе SSL действительно не спасает от MIM, есть ряд методов с помощью которых можно провести такую атаку даже при HTTPS-соединении. Для защиты от этих сценариев как раз и используется пиннинг.

И все же, для непонятливых. Что это за атаки? Мне казалось, SSL как раз и сделан ради защиты от MITM. В голову приходит, только предварительная установка левого сертификата на устройство, но это никак не ложится на ваш сценарий подключения к публичным сетям. Ну ещё есть взлом корневых CA, но я им доверяю чуточку больше админа сервера.

www.roe.ch/SSLsplit — вот такая атака например. Противодействовать ей может только SSL pinning.

Эта атака возможна, если злоумышленник является CA (certifying authority), которому доверяет жертва.
Хотя это теоретически возможно в случае утечки ключей у легитимного CA или нарушения порядка выдачи сертификатов (и даже было на практике: раз, два) — это все же не такая частая ситуация.


Может, вы это и имели в виду, конечно. Просто по тексту вашего комментария складывается ощущение, что каждый встречный может использую sslsplit / mitmproxy осуществить атаку MiTM на SSL — что совсем не так.

Спасибо за развернутую статью, но, поправьте меня, если я не прав: проверка на JailBreak слабовата. Суть JB не в установке Cydia, и не в попытке записи в корневые директории… Да, такая защита подойдет от среднестатистического JB-пользователя, но не от людей, которые просто раздвигают границы дозволенного, а потом так же думают о своей безопасности — меняя SSH пароли и выставлением своих прав на чтение-запись на папки и файлы…
Да, все верно, подобные проверки сработают только для среднестатистического юзера, но именно для него они и предназначены. Если человек настолько хорошо в этом разбирается, то он сам понимает все риски JB.
Раньше можно было установить несколько пакетов в сидии, которые скрывали наличие JB на устройстве. При наличии JB есть возможность зареверсить приложение, изменить исходный код и обратно собрать его на устройство – 100% защиты нет. Но процент пользователей с JB сейчас ничтожно мал и его нет на последние версии ОС.
Спасибо за статью, но по моему личному мнению, статья очень поверхностная и не совсем понятно для защиты от чего написанная. При получении доступа к устройству жертвы и при возможности произвести джейлбрейк и при наличии обкатанной технологии/наличии знаний о устройстве конкретного приложения(предварительно полученные)- вы не не можете абсолютно ничего защитить, абсолютно все можно заменить, переписать, зафейкать и обмануть, вы можете только применить меры, которые усложнят(увеличат время) процессов предварительного сбора информации и непосредственного произведения неправомерного действия, получения личной информации. Единственный адекватный способ защиты- делать тонкие(thin) клиенты и всю логику перемещать на сервер, что собственно почти все и делают. Тут уже остаются только ошибки и уязвимости в протоколе обмена, на логике сервера и тому подобное, что перемешает ответственность на сторону разработчиков сервера, где ей и место и где есть уже промышленные стандарты и по безопасности и по нахождению уязвимостей, такие стандарты, кстати, уже почти есть и в мобильной разработке, тема OWASP- тоже очень слабо развита, приведены не все ссылки на их инструменты и проекты. Таким образом, лично мое мнение, что статья о том как производить абсолютно бесполезные действия(я ни в коем случае не предлагаю передавать через GET и http весь трафик и хранить пароли в плисте, вместе с номерами кредиток), но необходимо понимание, что является бесполезным, а что действительно может значительно усложнить реверс- инжениринг, подмену сертификатов, изменение данных и тому подобные процессы пентеста, а для этого необходимо погружение на темную сторону процесса, изучение инструментов и механик взлома и пентеста. О этой очень интересной и полезной стороне вопроса почти никакой информации не приведено: хотя бы вводная информация, ссылки на литературу была бы достаточной, не говоря о том, что многие инструменты из этого набора очень активно используются и упрощают процессы и разработки и автоматического тестирования и сборки. Так совпало, что на данный момент я занимаюсь активным исследованием этой области и планировал делать какие-либо записки в блоге, во время процесса, и если есть у кого интерес- дайте знать, возможно, сделаю компиляцию информацию и оформлю статью тут. Но вообще, эта тема целой книги, которые периодически выходят.
Назначение статьи — перечислить базовые пункты для разработчиков, особо не занимавшихся безопасностью, чтобы знали в какую сторону дальше копать. Мне и думаю многим другим было бы интересно почитать вашу более подробную статью.
Назначение статьи — перечислить базовые пункты для разработчиков, особо не занимавшихся безопасностью, чтобы знали в какую сторону дальше копать. Мне и думаю многим другим было бы интересно почитать вашу более подробную статью.
А все текстовые поля, в которых вводятся пароли, <...> не поддерживают возможность копирования/вставки
Про это на хабре есть статья, в которой рассказывается, почему это больше плохо, чем хорошо. Она, конечно, про веб, но для мобильных приложений, я думаю, эти доводы тоже справедливы
Sign up to leave a comment.