Что бы вы хотели увидеть в книге по безопасности для начинающих ASP.NET

Question

Это бесстыдное упражнение по сбору информации для моей собственной книги.

Одним из выступлений, которые я провожу в сообществе, является введение в уязвимости веб-сайтов. Обычно во время беседы я вижу, как минимум два зрителя очень бледнеют; и это основные вещи, межсайтовый скриптинг, SQL-инъекция, утечка информации, межсайтовые запросы и т. д.

Итак, если вы можете вернуться к тому, чтобы быть единым целым, как начинающему веб-разработчику (будь то ASP.NET или нет), что, по вашему мнению, было бы полезной информацией о веб-безопасности и как ее безопасно разрабатывать? Я уже буду покрывать OWASP Top Ten

(И да, это означает, что stackoverflow будет в списке подтверждений, если кто-то придумает что-то, о чем я еще не подумал!)

Все уже сделано и опубликовано, спасибо всем за ваши ответы

Answer 1

Во-первых, я бы указал на ненадежность Интернета таким образом, чтобы сделать его доступным для людей, для которых разработка с учетом безопасности может (к сожалению) стать новой концепцией. Например, покажите им, как перехватить заголовок HTTP и осуществить атаку XSS. Причина, по которой вы хотите показать им атаки, заключается в том, что они сами лучше понимают, от чего они защищаются. Разговор о безопасности выше этого - это здорово, но без понимания типа атаки, которую они должны предотвратить, им будет сложно точно «проверить» свои системы на безопасность. Как только они смогут проверить безопасность, пытаясь перехватить сообщения, подделать заголовки и т. Д., Они, по крайней мере, узнают, работает ли какая-либо защита, которую они пытаются реализовать, или нет. Вы можете научить их любым методам, которые вы хотите использовать для обеспечения безопасности, с уверенностью, зная, что если они ошибаются, они на самом деле узнают об этом, потому что они не пройдут тесты безопасности, которые вы им показали.

Answer 2

Хотелось бы узнать, чем безопасность ASP.NET отличается от безопасности ASP Classic.

Answer 3

Я думаю, что все уязвимости основаны на том, что программисты не задумываются, либо на мгновенные ошибки, либо на то, о чем они не думали. Одна большая уязвимость, которая была в приложении, которое мне было поручено «исправить», заключалась в том, что они вернули 0 (ноль) из метода аутентификации, когда пользователь, который входил в систему, был администратором. Из-за того факта, что переменная была изначально инициализирована как 0, если возникли какие-либо проблемы, например, из-за сбоя базы данных, это вызвало исключение. Переменная никогда не будет установлена ​​на правильный «защитный код», и тогда пользователь получит доступ администратора к сайту. В этот процесс вошли абсолютно ужасные мысли. Итак, это подводит меня к основной концепции безопасности; Никогда не устанавливайте начальное значение переменной, представляющей «уровень безопасности» или что-либо в этом роде, равным полному контролю над сайтом. Еще лучше использовать существующие библиотеки, которые прошли через огонь использования в огромных количествах производственных сред в течение длительного периода времени.

Answer 4

Защитное программирование как архетипическая тема, которая охватывает все конкретные атаки, так как большинство из них, если не все, вызваны тем, что не думают достаточно оборонительно.

Сделайте эту тему центральной колонкой книги. Тогда мне было бы полезно знать о методах никогда не доверять чему-либо, а не только об одном совете, как "не разрешать комментарии SQL или специальные символы в ваш ввод".

Еще одна интересная вещь, которую я хотел бы узнать ранее, - это как на самом деле проверить их.

Answer 5

Как убедиться, что ваш метод безопасности является масштабируемым с SQL Server. Особенно о том, как избежать сериализации запросов SQL Server от нескольких пользователей, поскольку все они подключаются с одним и тем же идентификатором ...

Answer 6

Я всегда стараюсь показать наихудший сценарий о том, что может пойти не так. Например, о том, как внедрение межсайтового скрипта может работать как атака черного ящика, которая работает даже на страницах приложения, к которым хакер не может получить доступ, или как даже инъекция SQL может работать как черный ящик и Как хакер может украсть ваши конфиденциальные бизнес-данные , даже если ваш сайт подключается к вашей базе данных с обычной непривилегированной учетной записью для входа.

Answer 7

Рад слышать, что у вас будет десятка OWASP. Почему бы не включить освещение ошибок программирования SANS / CWE Top 25

Answer 8

лисицы