Pull to refresh

Comments 7

Эти уязвимости уже настолько обсосаны и разжеваны везде, не только на Хабре, что уже неинтересно читать даже. Без обид.
Конечно, эти векторы — топ-10 и они должны быть известны любому разработчику, казалось бы. Но к сожалению, многим людям они не известны. Только недавно мы проводили дружеский пентест нашим европейским коллегам из одной платежной системы и были просто в ужасе. Статья рассчитана на собственников бизнеса и будет малоинтересна разработчикам, мы об этом сразу сказали в начале материала.
Проблема действительно большая, владельцам бизнесов надо на их языке объяснять вред и потенциальные последствия той или иной уязвимости.

Очень часто сталкиваюсь с отношением владельцев когда буквально говорят: «Adding new features is more priority than fixing security. We don't need that.»
Когда начинаешь разъяснять возможный ущерб, — лучше приходит понимание, но обычно все равно со скрипом.
Мир изменился. Теперь можно показать последствия такого подхода одной ссылкой: http://www.npr.org/sections/thetwo-way/2017/03/02/518089196/yahoo-ceo-marissa-mayer-loses-bonus-and-stock-award-over-security-breach
П.7 пожалуй, лучше было бы перевести, как «Отсутствие контроля доступа на уровне
функций».
К паролям, в частности, должна применяться необратимая хеш-функция – расшифровать шифрограмму при этом не возможно и проверка пароля происходит путем формирования шифрограммы введенного пароля и сравнения ее с имеющейся в базе.


Я б к этому добавил бы, что пароль в процессе перелета может быть перехвачен. Например скриптом на сервере. В таком случае, когда БД уже доступна до такого уровня обычно система тоже бывает доступна. Шифрование в БД не будет безопасно.

Выход из этого low-sec — прегенерированные пароли на сервере (в итоге уведенный пароль бессмыслен для кроме как для этого сервиса) или же hi-sec хеширование на стороне клиента, для чего любая крипто яваскрипт либа подойдет.
Sign up to leave a comment.