Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков. Таня Янка
Читать онлайн книгу.
требующих постоянной сохранности, – далеко не безопасное решение.
Жесткое кодирование обычно считается симптомом плохой разработки программного обеспечения (есть и исключения). Если вы столкнулись с ним в одном месте приложения, следует проверить все приложение на его наличие, поскольку маловероятно, что найденный вами экземпляр – единственный.
«Никогда не доверяй, всегда проверяй»
Если вы вынесете из этой книги только один урок, то он должен быть следующим: никогда не доверяйте ничему за пределами вашего собственного приложения. Если приложение обращается к API, убедитесь, что это правильный API и что у него есть полномочия на то, что он пытается делать. Если приложение принимает данные из любого источника, выполняйте проверку данных (необходимо убедиться, что полученные данные правильные. Если же это не так, блокируйте их). Даже данные из вашей собственной базы могут содержать вредоносный ввод или другие средства заражения. Если пользователь пытается получить доступ к той части приложения, которая требует специального разрешения, перепроверяйте, есть ли у него разрешение на каждую используемую им страницу или функцию. Если пользователь прошел аутентификацию (доказал, что он тот, за кого себя выдает) и переходит между страницами, необходимо все время удостоверяться, что это тот же самый пользователь (это называется управлением сессиями). Нельзя полагать, что одной проверки достаточно. Нужно постоянно проверять и перепроверять.
ПРИМЕЧАНИЕ. Мы проверяем данные из нашей базы, поскольку они могут содержать хранимый межсайтовый скриптинг (Cross-Site Scripting, XSS) или другие значения, способные навредить программе. Хранимый XSS появляется в тех случаях, когда программа не выполняет надлежащую проверку вводных данных и случайно сохраняет XSS-атаку в своей базе. Когда пользователь в приложении выполняет действие, вызывающее вредоносный скрипт, начинается атака в браузере жертвы. Пользователь не в состоянии защититься от этой атаки, и, как правило, она считается критической опасностью, если обнаруживается во время тестирования безопасности.
Довольно часто разработчики забывают об этом уроке и полагаются на доверие из-за сложившихся условий. Например, к выпущенному вами интернет-приложению применяются чрезвычайно строгие меры безопасности. Внутри вашей сети (в обход брандмауэра) веб-приложение постоянно вызывает API (#1), который затем вызывает другой API (#2), изменяющий данные в соответствующей базе. Часто разработчики не утруждают себя аутентификацией (подтверждением личности) в первом API или проверкой API (#1) на наличие у приложения права на вызов той части API, к которой оно обращается. А если они и выполняют такую проверку, то часто применяют меры безопасности только для API #1, но не для API #2. В результате кто или что угодно в вашей сети может вызвать API #2, включая злоумышленников, которых там быть не должно, внутренние угрозы или даже случайных пользователей (рис. 1.7).
Рис. 1.7. Пример вызова API приложением и при необходимости аутентификации
Вот