Безопасность по дизайну , в разработке программного обеспечения , означает , что программное обеспечение было разработано с нуля , чтобы быть безопасными . Вредоносные практики воспринимаются как должное и приняты меры , чтобы свести к минимуму воздействие при обнаруженную уязвимость системы безопасности или на неверном пользователя ввода.
Как правило, проекты , которые работают хорошо , не полагаться на быть секретом . Это не является обязательным, но надлежащая безопасность , как правило , означает , что каждый имеет право знать и понимать дизайн , потому что это безопасно . Это имеет то преимущество , что многие люди ищут в коде, а это повышает вероятность того, что любые недостатки будут найдены раньше ( права Линуса ). Конечно, злоумышленники могут также получить код, что делает его легче для них , чтобы найти уязвимости , а также.
Кроме того , важно , что все работает с наименьшим количеством привилегий возможных ( принцип наименьших привилегий). Например, веб - сервер , который работает как пользователь с правами администратора (корень или администратор) может иметь привилегию для удаления файлов и пользователей , которые не принадлежат к себе. Таким образом, недостаток в том , что программа может поставить всю систему под угрозу. С другой стороны, веб - сервер , который работает внутриизолированной среды и имеет только привилегии для требуемых сетевых и файловых функций, не может поставить подугрозу системы он работает на , если безопасности вокруг него не сам по себе также недостаткам.
Безопасность в соответствии с проектом на практике
Многие вещи, особенно вход, должны быть доверяло безопасной конструкцией. Отказоустойчивая программа может даже доверять свои внутренние органы .
Два примера незащищенного дизайна позволяет переполнение буфера и форматная строке уязвимость . Следующая программа C демонстрирует эти недостатки:
Поскольку получает функцию в стандартной библиотеке C не перестанет писать байты в bufferпока он не читает символ новой строки или EOF , набрав более 99 символов в строке является переполнение буфера. Выделяя 100 символов для bufferс предположением , что почти любое имя от пользователя больше не более 99 символов не мешает пользователю фактически набрав более 99 символов. Это может привести к произвольному машинный код исполнения.
Второй недостаток заключается в том , что программа пытается напечатать свой вклад, передавая ее непосредственно в printfфункцию. Эта функция выводит свой первый аргумент, заменив спецификацию преобразования (например, « % S », « % D », и так далее) последовательно с другими аргументами из своего стека вызовов по мере необходимости. Таким образом, если злоумышленник вошел « % D » вместо его имени, программа будет пытаться распечатать несуществующее целое значение, и неопределенное поведение будет иметь место.
Связанная ошибка в веб - программировании для интернет - сценария не для проверки его параметров. Например, рассмотрим сценарий , который извлекает статью, приняв имя файла, который затем считывается сценарий и разобраны . Такой сценарий может использовать следующую гипотетическую URL , чтобы получить статью о корме для собак :
Если скрипт не проверяя никакого входа, вместо того, чтобы верить , что имя файла всегда одобрению, злоумышленник может подделать URL для получения конфигурационных файлов с веб - сервера:
В зависимости от сценария, это может привести к / и т.д. / пароль файл, который на Unix-подобных системах содержит (среди других) идентификаторов пользователей , их логины , домашний каталог путей и оболочек . (См инъекции SQL для подобной атаки.)
Сервер / клиент архитектуры
В клиент / сервер архитектур, программа на другой стороне не может быть авторизованным клиентом и сервером клиента не может быть разрешено сервером. Даже когда они, человек-в-середине атаки может поставить под угрозу коммуникации.
Часто самый простой способ , чтобы сломать безопасность системы клиент / сервер не идти голова к механизмам безопасности, но вместо того, чтобы идти вокруг них. Человек в центре нападения простой пример этого, потому что вы можете использовать его , чтобы собрать данные для олицетворения пользователя. Именно поэтому важно рассмотреть шифрование , хеширование и другие механизмы обеспечения безопасности в вашей конструкции , чтобы гарантировать , что информация , собранная от потенциального злоумышленника не будет разрешен доступ.
Другой ключевой особенностью дизайна безопасности клиент-сервер хорошая практика кодирования . Например, следуя известную структуру проектирования программного обеспечения , такие как клиент и брокер может помочь в разработке стройных структур с прочной основой. Кроме того, если программное обеспечение должно быть изменено в будущем, это еще более важно , что это следует логическое обоснование разделения между клиентом и сервером. Это происходит потому , что если программист приходит и не может четко понять динамику программы они могут в конечном итоге добавлять или изменять что - то , что может добавить брешь в безопасности. Даже лучший дизайн это всегда возможность, но лучше стандартизировать дизайн - тем меньше шансов на это происходит.
