Уязвимости и платежные сервисы
Зачастую программисты при разработке финансовых систем по причине отсутствия опыта допускают простые, но довольно серьёзные ошибки. И хотя не всегда прямая вина лежит на разработчике, как правило одной из причин появления таких ошибок является отсутствие понимания их последствий.
В этой статье я расскажу о некоторых распространенных ошибках, которые допускают программисты при разработке платежных сервисов, а также приведу примеры последствий, к которым они могут привести.
Началось все с того, что однажды, когда я работал над одним из таких проектов, в нашу компанию поступило письмо от клиента о том, что им на нашем сайте обнаружена уязвимость, позволяющая получить доступ к любому файлу на сервере. Это было неприятно. И хотя уязвимость быстро исправили, и каких-либо серьезных последствий этот инцидент не имел, мне стало интересно, есть ли ещё подобные уязвимости в моем проекте. В последствии я начал их искать и на других сайтах. Теперь меня интересовал другой вопрос: на сколько надежно хранятся критичные для пользователя данные в сторонних системах. В первую очередь меня интересовали платежные сервисы, так как обнаружение уязвимостей на них могло иметь намного более серьезные последствия, нежели обнаружение уязвимостей на сайтах знакомств. Со временем я понял, что программисты даже в самых популярных и, на первый взгляд, надежных проектах, допускают довольно простые ошибки. Тем не менее такие простые ошибки приводят к появлению серьезных дыр в безопасности, которые позволяют не только получать несанкционированный доступ к личной информации клиентов, но и порой выполнять финансовые операции над их денежными средствами.
Заранее предупрежу, я специализируюсь на поиске уязвимостей, реализуемых через HTTP протокол и соответственно все примеры будут с использованием этого протокола.
Для простоты, там, где это возможно. я буду описывать пример в виде GET запроса вместо POST для более удобного восприятия.
И так, поехали…
Читать дальше →
В этой статье я расскажу о некоторых распространенных ошибках, которые допускают программисты при разработке платежных сервисов, а также приведу примеры последствий, к которым они могут привести.
Началось все с того, что однажды, когда я работал над одним из таких проектов, в нашу компанию поступило письмо от клиента о том, что им на нашем сайте обнаружена уязвимость, позволяющая получить доступ к любому файлу на сервере. Это было неприятно. И хотя уязвимость быстро исправили, и каких-либо серьезных последствий этот инцидент не имел, мне стало интересно, есть ли ещё подобные уязвимости в моем проекте. В последствии я начал их искать и на других сайтах. Теперь меня интересовал другой вопрос: на сколько надежно хранятся критичные для пользователя данные в сторонних системах. В первую очередь меня интересовали платежные сервисы, так как обнаружение уязвимостей на них могло иметь намного более серьезные последствия, нежели обнаружение уязвимостей на сайтах знакомств. Со временем я понял, что программисты даже в самых популярных и, на первый взгляд, надежных проектах, допускают довольно простые ошибки. Тем не менее такие простые ошибки приводят к появлению серьезных дыр в безопасности, которые позволяют не только получать несанкционированный доступ к личной информации клиентов, но и порой выполнять финансовые операции над их денежными средствами.
Заранее предупрежу, я специализируюсь на поиске уязвимостей, реализуемых через HTTP протокол и соответственно все примеры будут с использованием этого протокола.
Для простоты, там, где это возможно. я буду описывать пример в виде GET запроса вместо POST для более удобного восприятия.
И так, поехали…
Читать дальше →
Источник: Хабрахабр
Похожие новости
- Быстрый старт в маскировании данных PostgreSQL с инструментом pg_anon
- [Перевод] Свой среди чужих: насколько токсична рабочая среда безопасника?
- [Перевод] Обход двухфакторной аутентификации в публичной баг-баунти программе: путь к $6000
- Кратко про XHTTP для VLESS: что, зачем и как
- [Перевод] Как я нашёл уязвимость в ядре Linux при помощи модели o3
- SelfCoerce для локального повышения привилегий на Windows 10
- Теория мертвого 2GIS
- Постквантовые криптостандарты США на алгоритмы электронной подписи на основе хеш-функций с сохранением состояния
- Новые возможности менеджера секретов Deckhouse Stronghold: пространства имён, резервные копии и репликация данных
- [Перевод] Single Sign-On c OpenAM и OpenIG: практические примеры реализации