Какому пользователю я должен дать разрешение в IIS?
Сервисы, работающие с учетной записью машины, получат полномочия Администратора домена. Пользователи вошли в ту машину, не наследует такой privs. Иногда это сделано, если некоторый плохо записанный сервис, который не может работать как пользователь по некоторым причинам, должен иметь доступ ко всему домену. Кроме того, ленивые администраторы.
Как дефект безопасности это не является важнейшим, но это должно быть разрешено. Не должно быть никакой причины (за исключением дрянного кода), чтобы это было сделано.
Весь доступ к объектам в операционных системах на базе Windows NT осуществляется в контексте учетной записи пользователя. Когда анонимные пользователи обращаются к вашему веб-сайту, IIS обращается к файлам и сценариям под учетной записью пользователя IUSR_machinename . Эта учетная запись пользователя имеет очень ограниченные права и служит для разделения анонимного доступа.
Функциональность аутентификации в IIS позволяет удаленным пользователям аутентифицироваться таким образом, что IIS будет «олицетворять» свою учетную запись пользователя Windows и получать доступ к файлам и сценариям под их , а не контекст учетной записи анонимного пользователя.
Если у ваших удаленных пользователей нет учетных записей пользователей Windows, то они просто анонимные пользователи и не имеют возможности аутентифицироваться в IIS. В этом случае (который является типичным) вы re просто нужно будет предоставить права анонимной учетной записи пользователя, чтобы делать все необходимое для работы вашего приложения. Так уж и обстоит дело с некоторыми приложениями - у вас нет возможности для аутентификации пользователей, поэтому вы должны сделать должное с анонимным доступом и предоставлением разрешений анонимной учетной записи пользователя.
Это "рискованно". "? Это зависит от вашего приложения. Если анонимные пользователи имеют возможность загружать произвольные файлы в каталог и, например, выполнять их, то вы фактически открываете доступ к общедоступной оболочке на своем сервере. Это будет определять архитектура приложения.
Приложения, которые позволяют анонимным пользователям загружать файлы произвольного типа, количества и размера на удаленный серверный компьютер, на первый взгляд кажутся мне очень рискованными. Это' sa complete showstopper, если каталог, в котором хранятся загрузки, доступен для загрузок через веб-сервер, потому что, по сути, вы только что сделали свой сервер общедоступным сайтом для обмена файлами. Это также полная остановка, если пользователь может заставить любой загружаемый контент (включая EXE-файлы и / или файлы сценариев) выполняться либо Windows, либо интерпретатором PHP.
Чем больше «удалена» запись из пользовательского контроля ( т.е. если сценарий просто хранит файлы для отслеживания состояния, а не позволяет пользователям загружать произвольный контент), это кажется менее «рискованным». Я бы искал сценарий, который хорошо справлялся бы с дезинфекцией пользовательского ввода и ограничивал количество данных, которые пользователь может заставить сценарий писать (чтобы предотвратить DoS-атаку).
То, что вы действительно ищете, в конечном итоге , это обзор архитектуры безопасности приложений и, возможно, пентест. Если это широко используемый сценарий, который поддерживается и общедоступен, то, будем надеяться, простые ошибки безопасности уже должны быть устранены. Если это что-то более изысканное или нестандартное, я бы не стал доверять архитектуре безопасности приложения без ее проверки.