Взлом собственного приложения - PullRequest
7 голосов
/ 06 февраля 2009

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

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

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

Ответы [ 6 ]

5 голосов
/ 06 февраля 2009

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

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

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

2 голосов
/ 06 февраля 2009

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

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

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

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

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

2 голосов
/ 06 февраля 2009

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

1 голос
/ 06 февраля 2009

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

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

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

1 голос
/ 06 февраля 2009

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

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

0 голосов
/ 06 февраля 2009

Чтобы защитить приложение win form, откройте его и попытайтесь сделать все, что не должен делать пользователь lambda! Я объясню:

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

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

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

...