Взлом собственного приложения

Question

Я веб-разработчик, который очень заботится о безопасности и стараюсь сделать свои веб-приложения максимально безопасными.

Однако когда-либо я начал писать свои собственные приложения для Windows на C#, и когда дело дошло до тестирования безопасности моего приложения C#, я на самом деле только новичок.

Просто интересно, есть ли у кого-нибудь хорошие руководства/файлы сведений о том, как взломать собственное приложение Windows и написать безопасный код.

Answer 1

Книги Майкла Ховарда — хорошая отправная точка;

• 19 смертных грехов безопасности программного обеспечения (с примерами на нескольких языках)
• Написание безопасного кода

Там масса ссылок и интересных статей из блога Майкла Ховарда. здесь

Есть интересная презентация Microsoft в PowerPoint об оценке угроз, рисках и ASP. здесь.

Answer 2

Помимо всех очевидных ответов на предотвращение переполнения буфера, внедрения кода, перехвата сеанса и т. д.ал.вам следует найти кого-нибудь другого, чтобы проверить ваш код/программное обеспечение, потому что вы можете думать только о способах взлома вашего программного обеспечения, которые вы знаете, как предотвратить.Только то, что вы не можете найти способ взломать собственное программное обеспечение, не означает, что никто другой не может.

Answer 3

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

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

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

Во время написания программного обеспечения вам следует думать о безопасности.Изучите лучшие практики и рассмотрите каждый метод и класс, которые вы пишете, с точки зрения безопасности.Это идет рука об руку с модульным тестированием. Попробуйте подумать, какие входные данные могут привести к поломке этой конкретной части моей программы.а затем разобраться с ними на этом уровне.

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

Answer 4

Мелочи, с которыми я столкнулся на собственном опыте.

• Не используйте динамический SQL, иначе вы станете уязвимы для SQL-инъекций.Лучше используйте SQL-запросы с параметрами.
• Не используйте увеличивающиеся идентификаторы, такие как user_id = 1, 2, 3 и т. д. и т. д., а затем используйте их в URL-адресе Something.aspx?user_id=1, тогда я смогу угадать следующий идентификатор и надежду сеанса.То же самое касается учетных записей и всего остального, что является конфиденциальным.
• Остерегайтесь XSS (межсайтовый скриптинг).Если вы принимаете ввод пользователя и сохраняете его напрямую, убедитесь, что он не может вставить alert() для своего имени или чего-то еще.

Это далеко не полный список.Просто то, с чем я недавно столкнулся.

Answer 5

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

Обратите внимание, что в этой книге объясняется, как обеспечить безопасность с самого начала, а не как ее взломать, но описание различных ошибок безопасности должно дать вам хорошее представление о том, с чего начать поиск.

Answer 6

Чтобы защитить свое приложение формы выигрыша, откройте его и попробуйте сделать все, что не должен делать пользователь лямбда-выражения!Я объясню:

Если вы «скажите, введите yes или no", попробуйте использовать A-Z, 0-9, потому что именно это делают некоторые пользователи, пытаясь найти какую-нибудь трассировку стека, которая может быть интересна.Так что ставьте валидаторы повсюду.

Остерегайтесь подключения к базам данных, но если вы занимаетесь веб-разработкой, вы должны быть более осведомлены, чем я :).

Самое сложное — следить за утечками памяти и тому подобным, но это касается больших приложений или плохо разработанных приложений.