Для всех слишком многих компаний, только после того, как произошло нарушение, веб-безопасность становится приоритетом. В течение моих лет работы в качестве специалиста по ИТ-безопасности я снова и снова видел, как небезопасно мир ИТ-безопасности многим моим коллегам-программистам, поетому узнай всю уязвимость своего сайта.

Эффективный подход к безопасности ИТ должен, по определению, быть активным и защитным. С этой целью этот пост нацелен на то, чтобы спровоцировать менталитет безопасности, надеясь, что он вводит читателя здоровой дозой паранойи.

В частности, это руководство фокусируется на 10 общих и значительных ловушках безопасности в Интернете, о которых следует знать, включая рекомендации о том, как их можно избежать. Основное внимание уделено 10 уязвимостям Web-уязвимостей, выявленным в рамках проекта Open Web Application Security Project (OWASP), международной некоммерческой организации, целью которой является повышение безопасности программного обеспечения во всем мире.

Говоря с другими программистами и ИТ-специалистами, я часто сталкиваюсь с путаницей в отношении различия между авторизацией и аутентификацией. И, конечно, тот факт, что аббревиатура auth часто используется для обоих, помогает усугубить эту общую путаницу. Эта путаница настолько распространена, что, возможно, эта проблема должна быть включена в этот пост как «Common Web Vulnerability Zero».

Итак, прежде чем мы продолжим, давайте четко разграничим эти два термина:

Аутентификация: проверка того, что пользователь (или, по крайней мере, по-видимому) является конкретным пользователем, так как он правильно предоставил свои учетные данные безопасности (пароль, ответы на вопросы безопасности, сканирование отпечатков пальцев и т. Д.).
Авторизация: подтверждение того, что конкретный пользователь имеет доступ к определенному ресурсу или получает разрешение на выполнение определенного действия.
Иными словами, аутентификация - это знание того, кто является сущностью, тогда как авторизация знает, что может сделать данный объект.


Общая ошибка №1: Недостатки впрыска

Ошибки впрыска являются результатом классического отказа от фильтрации ненадежного ввода. Это может произойти при передаче нефильтрованных данных на SQL-сервер (SQL-инъекция), в браузер (XSS - об этом мы поговорим позже), на LDAP-сервере (LDAP-инъекция) или где-либо еще. Проблема здесь в том, что злоумышленник может вводить команды этим сущностям, что приводит к потере данных и захвату браузеров клиентов.

Все, что ваше приложение получает от ненадежных источников, должно быть отфильтровано, предпочтительно в соответствии с «белым списком». Вы почти никогда не должны использовать черный список, так как получение этого права очень сложно и обычно легко обойти. Антивирусные программные продукты обычно предоставляют звездные примеры неудачных черных списков. Совпадение шаблонов не работает.

Профилактика: Хорошей новостью является то, что защита от инъекций «просто» - это вопрос правильной фильтрации вашего ввода и размышления о том, можно ли доверять вводу. Но плохая новость заключается в том, что все входные данные должны быть надлежащим образом отфильтрованы, за исключением случаев, когда это может быть неоспоримо заслуживающим доверия (но здесь приходит в голову мысль «никогда не говорить никогда»).

Например, в системе с 1000 входами успешно удалять 999 из них недостаточно, так как это все еще оставляет одно поле, которое может служить исцелением Ахилла, чтобы сбить вашу систему. И вы можете подумать, что включение результата SQL-запроса в другой запрос является хорошей идеей, поскольку базе данных доверяют, но если периметр отсутствует, вход поступает косвенным образом у парней с малейшей целью. Это называется Second Order SQL Injection, если вы заинтересованы.

Поскольку фильтрация довольно сложно сделать правильно (например, крипто), то, что я обычно советую, - это полагаться на функции фильтрации вашей инфраструктуры: они доказали свою эффективность и тщательно изучены. Если вы не используете фреймворки, вам действительно нужно много думать о том, действительно ли использование их действительно имеет смысл в вашей среде. В 99% случаев это не так.

Дата: 22.09.2017.