Почему сборки со строгим именем не могут использовать сборки без подписи? - PullRequest
5 голосов
/ 15 мая 2009

Чтобы подписать сборку A, необходимо убедиться, что все сборки B, C, D, используемые A, подписаны, а затем все сборки, используемые B, C, D и т. Д. Я не понимаю, в чем выгода для безопасности. Я думаю, что это должно предотвратить несанкционированное вмешательство, но сборка А может открыть любой файл, и это может быть подделано. То же самое касается внешнего веб-сервера.

Кроме того, слишком легко подписать сборку с помощью файла .snk, который вы публикуете, обходя требование.

Ответы [ 3 ]

8 голосов
/ 15 мая 2009

Дело в том, что в противном случае вы можете заменить сборку B / C / D на другую (взломанную), и A никогда не заметит; он загрузит их и выполнит код. При строгих именах вы не сможете сделать это, не переподписав взломанный B / C / D тем же ключом или взломав A.

2 голосов
/ 15 мая 2009

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

EDIT

Пример сценария: Если вы помещаете сборку в GAC, она должна иметь строгое имя, чтобы обеспечить параллельное управление версиями. Вы не могли бы поместить его в GAC, хотя, если бы не были его зависимости (иначе, они не смогли бы загружаться во время выполнения). Для того, чтобы эти сборки были загружены надежно, они также должны иметь строгие имена и в GAC.

1 голос
/ 15 мая 2009

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

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

...