1

Например, удалив выходной файл во время выполнения, направляя два экземпляра sw на один и тот же IO и т. Д.?Как я могу предотвратить нарушение моего настольного приложения, когда пользователь возится со своими файлами во время выполнения?

+0

Я не понимаю: какого рода злоупотребления вы имеете в виду? – Treb 2008-10-29 12:03:24

+0

А теперь я вижу: удаление выходного файла должно быть примером для злоупотреблений, а не для хороших практик ... имеет немного больше смысла в этом направлении ;-) – Treb 2008-10-29 12:19:38

ответ

7

Существует мало что можно сделать, чтобы пользователь не мог этого сделать, но то, что вы можете сделать, это применить defensive programming.

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

Никогда не предполагайте, что распределение ресурсов будет успешным, всегда проверяйте, что вы не контролируете. Короче говоря, считать как можно меньше и проверить все.

«Мне говорят, чтобы получить доступ к этому файлу, чтобы написать ему. Это уже открыто? У меня есть разрешения? Имеет ли он ожидаемый формат? Имеет ли диск достаточно места? и т.д.'

Существует еще много об этом. Просто Google для защитного программирования, и вы получите много о чем почитать.

1

Ничего не принимайте. Проверяйте каждую операцию, которая использует IO, каждый раз. Поместите дополнительный слой в ваше ПО для ввода-вывода со встроенными проверками.

1

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

Также подумайте об атаках SQL-инъекций через поисковые запросы. например Ищите людей, где фамилия ___, и пользователь вводит «кузнец»; выберите * у пользователей *. Что будет с этим слоем базы данных?

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

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

Создайте единичные тесты с намеренно плохим вводом veri что приложение может справиться с этим.

0

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

1

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

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

Будет ли программа использоваться людьми, которые этого не хотят, например, приложение времени для записи, когда люди вбиваются и выходят? Кому-то нужно учитывать физическую безопасность (коммерческие версии предназначены для большого злоупотребления) и безопасности программного обеспечения (поэтому никто не может изменить время). Вам необходимо предоставить очень простой интерфейс и подробно проверить ввод данных.

0

А как насчет того, чтобы с ними были хорошие тестеры, имитирующие злоупотребления?

0

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

Я большой поклонник защитного программирования (как упоминалось выше, Vinko). Вы можете приблизиться к нему с точки зрения анализа опасности. Посмотрите на ресурсы, которые ваше приложение использует и модифицирует (файлы, устройства, данные и т. Д.) И мозговой штурм, что может пойти не так с этими ресурсами и спланировать его.

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

Все это занимает немного планирования и работы, но эй, это то, что нам платят за :)