В чем заключается опасность предоставления учетной записи сетевой службы разрешений на чтение / запись для веб-приложения ASP.NET?

Question

В чем заключается опасность предоставления учетной записи сетевой службы разрешений на чтение / запись для веб-приложения ASP.NET? Я должен сделать это для любого каталога, в который нужно записать мое приложение, например, App_Data для моей базы данных VistaDb и несколько случайных каталогов для загрузки изображений, внесения изменений в текстовые файлы и т. Д. В чем заключается опасность при этом? И допустимо ли просто предоставлять права на чтение / запись всему веб-приложению для сетевой службы?

Answer 1

Наибольший риск безопасности при предоставлении учетной записи сетевой службы разрешений на запись в папки возникает в Shared Hosting или при запуске нескольких веб-сайтов на одном сервере.

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

Answer 2

хорошо, непосредственная опасность состоит в том, что сетевой сервис может читать / записывать в эти папки, конечно, но для Microsoft - эта учетная запись является наименее привилегированной учетной записью компьютера с ограниченными разрешениями. Если вы находитесь в домене, лучшим подходом может быть использование доменной учетной записи - подробную информацию о них можно найти по адресу http://msdn.microsoft.com/en-us/library/ms998320.aspx

Answer 3

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

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

Answer 4

Хорошо, поэтому, если я смогу выяснить, как заставить ваше приложение записать файл в файловую систему, потому что вы предоставили чтение / запись в виртуальный каталог всего приложения, я могу теперь написать файл aspx своего веб-сайта, запускайте его и запускайте произвольный код, включая такие интересные вещи, как вызовы WMI и COM-взаимодействие.

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

Теперь, если вы предоставите право только для App_Data, даже если я напишу файл aspx в эту папку, я не смог бы вызвать его, потому что папка App_data обрабатывается средой как особая и не будет обслуживать никакие файлы. оттуда (чтобы кто-то просто не позвонил http://yourserver.com/app_data/data.mdb и взломал ваш БД, просто скачав файл). Очевидно, что к этим файлам в App_Data можно получить доступ с помощью ADO и т.п., но это не проблема безопасности.