Udostępnij za pośrednictwem

Porady dotyczące zabezpieczeń firmy Microsoft 4021279

  • Artykuł

Luki w zabezpieczeniach platformy .NET Core, ASP.NET Core mogą zezwalać na podniesienie uprawnień

Opublikowano: 9 maja 2017 r. | Zaktualizowano: 10 maja 2017 r.

Wersja: 1.1

Streszczenie

Firma Microsoft publikuje ten poradnik dotyczący zabezpieczeń, aby udostępnić informacje o lukach w zabezpieczeniach w publicznym środowisku .NET Core i ASP.NET Core. W tym biuletynie podano też wskazówki dla deweloperów dotyczące właściwego aktualizowania aplikacji.

Platforma .NET Core i ASP.NET Core to następna generacja platformy .NET, która zapewnia znaną i nowoczesną platformę dla scenariuszy sieci Web i chmury. Te produkty są aktywnie opracowywane przez zespół platformy .NET i ASP.NET we współpracy ze społecznością deweloperów open source działających w systemach Windows, Mac OS X i Linux. Po wydaniu platformy .NET Core numer wersji został zresetowany do wersji 1.0.0, aby odzwierciedlić fakt, że jest to oddzielny produkt od poprzednika -.NET.

Cve i opis problemu

— Cve Opis
CVE-2017-0247 Denial of Service (odmowa usługi)
CVE-2017-0248 Obejście funkcji zabezpieczeń
CVE-2017-0249 Elevation of Privilege (podniesienie uprawnień)
CVE-2017-0256 Spoofing (fałszowanie)

Oprogramowanie, którego dotyczy problem

Luki w zabezpieczeniach wpływają na dowolny projekt platformy Microsoft .NET Core, jeśli korzysta z następujących wersji pakietu, których dotyczy problem.

Pakiet i wersja, której dotyczy problem
Nazwa pakietu Wersje pakietów Naprawiono wersje pakietów
System.Text.Encodings.Web 4.0.0 4.3.0 4.0.1 4.3.1
System.Net.Http 4.1.1 4.3.1 4.1.2 4.3.2
System.Net.Http.WinHttpHandler 4.0.1 4.3.0 4.0.2 4.3.1
System.Net.Security 4.0.0 4.3.0 4.0.1 4.3.1
System.Net.WebSockets.Client 4.0.0 4.3.0 4.0.1 4.3.1
Microsoft.AspNetCore.Mvc 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Core 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Abstractions 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.ApiExplorer 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Cors 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.DataAnnotations 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Formatters.Json 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Formatters.Xml 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Localization 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Razor.Host 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.Razor 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.TagHelpers 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.ViewFeatures 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3
Microsoft.AspNetCore.Mvc.WebApiCompatShim 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 1.0.4 1.1.3

Porady — często zadawane pytania

Jak mogę wiedzieć, czy mam to wpływ?
Platforma .NET Core i ASP.NET Core mają dwa typy zależności: bezpośrednie i przechodnie. Jeśli projekt ma bezpośrednią lub przechodnią zależność od dowolnego z pakietów i wersji wymienionych wcześniej, ma to wpływ.

Uwaga

W ramach stosowania poprawek ASP.NET Core MVC aktualizujemy każdy pakiet Microsoft.AspNetCore.Mvc.*. Jeśli na przykład masz zależność od microsoft.AspNetCore.Mvc, musisz najpierw zaktualizować odpowiednią wersję (1.0.x powinna zostać zaktualizowana do wersji 1.0.4, 1.1.x powinna zostać zaktualizowana do wersji 1.1.3), a także zaktualizuje wszelkie inne wrażliwe zależności Microsoft.AspNetCore.Mvc.

Formaty projektów platformy .NET Core

Platforma .NET Core ma dwa różne formaty plików projektu, w zależności od oprogramowania utworzonego projektu.

  1. project.json jest oryginalnym formatem zawartym w programach .NET Core 1.0 i Microsoft Visual Studio 2015.
  2. csproj to format używany w programie Microsoft Visual Studio 2017.

Musisz upewnić się, że postępuj zgodnie z poprawnymi instrukcjami aktualizacji dla typu projektu.

Zależności bezpośrednie

Bezpośrednie zależności to zależności, w których specjalnie dodajesz pakiet do projektu. Jeśli na przykład dodasz pakiet Microsoft.AspNetCore.Mvc do projektu, masz bezpośrednią zależność od microsoft.AspNetCore.Mvc.

Bezpośrednie zależności można odnaleźć, przeglądając plik project.json lub csproj.

Zależności przechodnie

Przejściowe zależności występują podczas dodawania pakietu do projektu, który z kolei opiera się na innym pakiecie. Jeśli na przykład dodasz pakiet Microsoft.AspNetCore.Mvc do projektu, będzie on zależeć od pakietu Microsoft.AspNetCore.Mvc.Core (między innymi). Projekt ma bezpośrednią zależność od microsoft.AspNetCore.Mvc i zależność przechodnią od pakietu Microsoft.AspNetCore.Mvc.Core.

Zależności przechodnie można przeglądać w oknie Eksplorator rozwiązań programu Visual Studio, które obsługuje wyszukiwanie lub przeglądając plik project.lock.json znajdujący się w katalogu głównym projektu dla projektów project.json lub pliku project.assets.json zawartego w katalogu obj projektu dla projektów csproj. Te pliki są autorytatywną listą wszystkich pakietów używanych przez projekt, zawierających zarówno zależności bezpośrednie, jak i przechodnie.

Jak mogę naprawić moją aplikację, której dotyczy problem?

Należy naprawić zarówno bezpośrednie zależności, jak i przejrzeć i naprawić wszelkie zależności przechodnie. Pakiety i wersje, których dotyczy problem, w poprzedniej sekcji "Oprogramowanie, których dotyczy problem", obejmują każdy pakiet podatny na zagrożenia, wersje podatne na zagrożenia i poprawkowe wersje.

Jeśli używasz ASP.NET Core MVC w projektach, należy najpierw zaktualizować wersję Microsoft.AspNetCore.Mvc zgodnie z poprzednią tabelą wersji, których dotyczy problem. Jeśli obecnie używasz wersji 1.0.0, 1.0.1, 1.0.2 lub 1.0.3, należy zaktualizować pakiet do wersji 1.0.4. Jeśli używasz wersji 1.1.0, 1.1.1 lub 1.1.2, zaktualizuj wersję pakietu do wersji 1.1.3. Spowoduje to zaktualizowanie każdego pakietu MVC do stałych wersji.

Naprawianie zależności bezpośrednich — project.json/VS2015

Otwórz plik project.json w edytorze. Wyszukaj sekcję zależności. Poniżej znajduje się przykładowa sekcja zależności:

    "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        },
        "Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
        "Microsoft.AspNetCore.Mvc ": "1.0.1",
         
      }

W tym przykładzie istnieją trzy bezpośrednie zależności: Microsoft.NETCore.App, Microsoft.AspNetCore.Server.Kestrel i Microsoft.AspNetCore.Mvc.

Microsoft.NetCore.App to platforma docelowa aplikacji, należy to zignorować. Inne pakiety uwidaczniają swoją wersję po prawej stronie nazwy pakietu. W naszym przykładzie nasze pakiety nieplatformowe są w wersji 1.0.1.

Przejrzyj bezpośrednie zależności dla dowolnego wystąpienia pakietów i wersji wymienionych wcześniej. W poprzednim przykładzie istnieje bezpośrednia zależność od jednego z pakietów podatnych na zagrożenia, Microsoft.AspNetCore.Mvc w wersji 1.0.1.

Aby zaktualizować pakiet stały, zmień numer wersji na odpowiedni dla danego wydania. W tym przykładzie zostanie zaktualizowana wartość Microsoft.AspNetCore.Mvc do wersji 1.0.4.

Po zaktualizowaniu wersji pakietu podatnego na zagrożenia zapisz plik project.json.

Sekcja zależności w naszym przykładzie project.json będzie teraz wyglądać następująco:

      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        },
        "Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
        "Microsoft.AspNetCore.Mvc": "1.0.4",
          
      }

Jeśli używasz programu Visual Studio i zapiszesz zaktualizowany plik project.json, program Visual Studio przywróci nową wersję pakietu. Wyniki przywracania można wyświetlić, otwierając okno danych wyjściowych (Ctrl+Alt+O) i zmieniając listę rozwijaną Pokaż dane wyjściowe z listy rozwijanej na Menedżer pakietów.

Jeśli nie używasz programu Visual Studio, otwórz wiersz polecenia i przejdź do katalogu projektu. Wykonaj polecenie dotnet restore, aby przywrócić nową zależność.

Po usunięciu wszystkich bezpośrednich zależności należy również przejrzeć zależności przechodnie.

Naprawianie zależności bezpośrednich — csproj/VS2017

Otwórz plik projectname.csproj w edytorze lub kliknij prawym przyciskiem myszy projekt w programie Visual Studio 2017 i wybierz polecenie Edytuj nazwę projektu.csproj z menu zawartości, gdzie nazwa projektu jest nazwą projektu. Wyszukaj węzły PackageReference. Poniżej przedstawiono przykładowy plik projektu:


    <project sdk="Microsoft.NET.Sdk.Web">
<propertygroup>
<targetframework>netcoreapp1.1</targetframework>
</propertygroup>
<propertygroup>
<packagetargetfallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</packagetargetfallback>
</propertygroup>
<itemgroup>
<packagereference include="Microsoft.AspNetCore" version="1.1.1">
</packagereference><packagereference include="Microsoft.AspNetCore.Mvc" version="1.1.2">
</packagereference></itemgroup>
<itemgroup>
<dotnetclitoolreference include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" version="1.0.0 ">
</dotnetclitoolreference></itemgroup>
</project>

W przykładzie istnieją dwa bezpośrednie zależności pakietu, jak widać w dwóch elementach PackageReference. Nazwa pakietu znajduje się w atrybucie Include, a numer wersji pakietu znajduje się w atrybucie Wersja, który jest udostępniany po prawej stronie nazwy pakietu. W przykładzie przedstawiono dwa pakiety Microsoft.AspNetCore w wersji 1.1.1 i Microsoft.AspNetCore.Mvc.Core w wersji 1.1.2.

Przejrzyj elementy PackageReference dla dowolnego wystąpienia pakietów i wersji wymienionych wcześniej. W poprzednim przykładzie istnieje bezpośrednia zależność od jednego z pakietów podatnych na zagrożenia, Microsoft.AspNetCore.Mvc w wersji 1.1.2.

Aby zaktualizować pakiet stały, zmień numer wersji na odpowiedni pakiet dla danego wydania. W tym przykładzie zostanie zaktualizowana wartość Microsoft.AspNetCore.Mvc do wersji 1.1.3.

Po zaktualizowaniu wersji pakietu podatnego na zagrożenia zapisz plik csproj.

Przykładowy plik csproj będzie teraz wyglądać następująco:


    <project sdk="Microsoft.NET.Sdk.Web">
<propertygroup>
<targetframework>netcoreapp1.1</targetframework>
</propertygroup>
<propertygroup>
<packagetargetfallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</packagetargetfallback>
</propertygroup>
<itemgroup>
<packagereference include="Microsoft.AspNetCore" version="1.1.1">
</packagereference><packagereference include="Microsoft.AspNetCore.Mvc.Core" version="1.1.3">
</packagereference></itemgroup>
<itemgroup>
<dotnetclitoolreference include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" version="1.0.0 ">
</dotnetclitoolreference></itemgroup>
</project>

Jeśli używasz programu Visual Studio i zapiszesz zaktualizowany plik csproj, program Visual Studio przywróci nową wersję pakietu. Wyniki przywracania można wyświetlić, otwierając okno danych wyjściowych (Ctrl+Alt+O) i zmieniając listę rozwijaną Pokaż dane wyjściowe z listy rozwijanej na Menedżer pakietów.

Jeśli nie używasz programu Visual Studio, otwórz wiersz polecenia i przejdź do katalogu projektu. Wykonaj polecenie dotnet restore, aby przywrócić nową zależność.

Ponownie skompiluj aplikację.

Jeśli po ponownym skompilacji zostanie wyświetlone ostrzeżenie o konflikcie zależności, należy zaktualizować inne bezpośrednie zależności do odpowiedniej wersji. Jeśli na przykład projekt odwołuje się do elementu Microsoft.AspNetCore.Routing z numerem wersji 1.0.1 podczas aktualizowania pakietu Microsoft.AspNetCore.Mvc do wersji 1.0.4, kompilacja zostanie wyrzucona:

Konflikt zależności NU1012. Microsoft.AspNetCore.Mvc.Core 1.0.4 oczekiwano microsoft.AspNetCore.Routing >= 1.0.4, ale odebrano 1.0.1

Aby rozwiązać ten problem, zmodyfikuj wersję oczekiwanego pakietu, aktualizując plik csproj lub project.json w taki sam sposób, jak w przypadku aktualizacji wersji pakietu podatnego na zagrożenia.

Po usunięciu wszystkich bezpośrednich zależności należy również przejrzeć zależności przechodnie.

Przeglądanie przejściowych zależności

Istnieją dwa sposoby wyświetlania zależności przechodnich. Możesz użyć Eksplorator rozwiązań programu Visual Studio lub przejrzeć plik project.lock.json (project.json/VS2015) lub project.assets.json (csproj/VS2017).

Korzystanie z programu Visual Studio Eksplorator rozwiązań (VS2015)

Jeśli chcesz użyć programu Visual Studio 2015, otwórz projekt w programie Visual Studio 2015, a następnie naciśnij klawisze Ctrl+; aby aktywować wyszukiwanie w Eksplorator rozwiązań. Wyszukaj każdą z nazw pakietów podatnych na zagrożenia i zanotuj numery wersji wszystkich wyszukiwanych wyników.

Na przykład wyszukiwanie elementu Microsoft.AspNetCore.Mvc.Core w przykładowym projekcie zawierającym odwołanie do pliku Microsoft.AspNetCore.Mvc pokazuje następujące wyniki w programie Visual Studio 2015.

Rysunek 1. Wyszukiwanie odwołań w programie Visual Studio 2015

Wyniki wyszukiwania są wyświetlane jako drzewo. W tych wynikach można zobaczyć, że znaleźliśmy odwołania do microsoft.AspNetCore.Mvc w wersji 1.0.1, która jest podatna na zagrożenia.

Pierwszy wpis w nagłówku Odwołania odnosi się do platformy docelowej używanej przez aplikację. Będzie to . NETCoreApp, . NETStandard lub . NET-Framework-vX.Y.Z (gdzie X.Y.Z jest rzeczywistym numerem wersji) w zależności od sposobu konfigurowania aplikacji. W ramach platformy docelowej będzie lista pakietów, z których masz bezpośrednio zależność. W tym przykładzie aplikacja przyjmuje zależność od microsoft.AspNetCore.Mvc. Microsoft.AspNetCore.Mvc z kolei zawiera węzły liści, które wyświetlają jego zależności i ich wersje. W takim przypadku pakiet Microsoft.AspNetCore.Mvc przyjmuje zależność od wersji podatnej na zagrożenia microsoft.AspNetCore.Mvc.Core i wielu innych pakietów.

Ręczne przeglądanie project.lock.json (project.json/VS2015)

Otwórz plik project.lock.json w edytorze. Zalecamy użycie edytora, który rozumie kod json i umożliwia zwinięcie i rozwinięcie węzłów w celu przejrzenia tego pliku. Zarówno program Visual Studio, jak i program Visual Studio Code udostępniają tę funkcję.

Jeśli używasz programu Visual Studio, plik project.lock.json znajduje się "w" pliku project.json. Kliknij prawym trójkątem wskazującym ,, po lewej stronie pliku project.json, aby rozwinąć drzewo rozwiązania, aby uwidocznić plik project.lock.json. Rysunek 1 poniżej przedstawia projekt z rozwiniętym plikiem project.json w celu wyświetlenia pliku project.lock.json.

Rysunek 2. Lokalizacja pliku project.lock.json

Wyszukaj w pliku project.lock.json ciąg "Microsoft.AspNetCore.Mvc.Core/1.1.0". Jeśli plik project.lock.json zawiera ten ciąg, masz zależność od pakietu podatnego na zagrożenia.

Naprawianie zależności przechodnich (project.json/VS2015)

Jeśli nie znaleziono żadnego odwołania do pakietów podatnych na zagrożenia, oznacza to, że żadna z bezpośrednich zależności nie zależy od żadnych pakietów podatnych na zagrożenia lub problem został już rozwiązany przez zaktualizowanie bezpośrednich zależności.

Jeśli przegląd zależności przechodnich odnalazł odwołania do dowolnego z pakietów narażonych, musisz dodać bezpośrednią zależność do zaktualizowanego pakietu do pliku project.json, aby zastąpić zależność przechodnią. Otwórz project.json i znajdź sekcję zależności. Na przykład:


      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        },
        "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
        "Microsoft.AspNetCore.Mvc": "1.1.0"
      }

Dla każdego z pakietów podatnych na zagrożenia zwrócone wyszukiwanie należy dodać bezpośrednią zależność do zaktualizowanej wersji, dodając ją do pliku project.json. Można to zrobić, dodając nowy wiersz do sekcji zależności, odwołując się do stałej wersji. Jeśli na przykład wyszukiwanie wyświetliło przechodnie odwołanie do wrażliwej wersji System.Net.Security w wersji 4.0.0, należy dodać odwołanie do odpowiedniej stałej wersji 4.0.1. Edytuj plik project.json w następujący sposób:


      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        },
        "System.Net.Security": "4.0.1",
        "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
        "Microsoft.AspNetCore.Mvc": "1.1.1"
      }

Po dodaniu bezpośrednich zależności do stałych pakietów zapisz plik project.json.

Jeśli używasz programu Visual Studio, zapisz zaktualizowany plik project.json, a program Visual Studio przywróci nowe wersje pakietu. Wyniki przywracania można wyświetlić, otwierając okno danych wyjściowych (Ctrl+Alt+O) i zmieniając listę rozwijaną Pokaż dane wyjściowe z listy rozwijanej na Menedżer pakietów.

Jeśli nie używasz programu Visual Studio, otwórz wiersz polecenia i przejdź do katalogu projektu. Wykonaj polecenie dotnet restore, aby przywrócić nowe zależności.

Korzystanie z programu Visual Studio Eksplorator rozwiązań (VS2017)

Jeśli chcesz użyć Eksplorator rozwiązań, otwórz projekt w programie Visual Studio 2017, a następnie naciśnij klawisze Ctrl+; aby aktywować wyszukiwanie w Eksplorator rozwiązań. Wyszukaj każdą z nazw pakietów podatnych na zagrożenia i zanotuj numery wersji wszystkich wyszukiwanych wyników.

Na przykład wyszukiwanie elementu Microsoft.AspNetCore.Mvc.Core w przykładowym projekcie zawierającym pakiet, który przyjmuje zależność od microsoft.AspNetCore.Mvc, pokazuje następujące wyniki w programie Visual Studio 2017.

Rysunek 3. Wyszukiwanie odwołań w programie Visual Studio 2017

Wyniki wyszukiwania są wyświetlane jako drzewo. W tych wynikach można zobaczyć, że znaleźliśmy odwołania do elementu Microsoft.AspNetCore.Mvc.Core w wersji 1.1.2.

W węźle Zależności będzie węzeł NuGet. W węźle NuGet będzie lista pakietów, od których masz bezpośrednio zależność i ich wersje. W tym przykładzie aplikacja przyjmuje bezpośrednią zależność od microsoft.AspNetCore.Mvc. Microsoft.AspNetCore.Mvc z kolei zawiera węzły liści, które wyświetlają jego zależności i ich wersje. W przykładzie pakiet Microsoft.AspNetCore.Mvc przyjmuje zależność od wersji Microsoft.AspNetCore.Mvc.ApiExplorer, która z kolei przyjmuje zależność od wersji podatnej na zagrożenia microsoft.AspNetCore.Mvc.Core.

Ręczne przeglądanie project.assets.json (VS2017)

Otwórz plik project.assets.json z katalogu obj projektu w edytorze. Zalecamy użycie edytora, który rozumie kod json i umożliwia zwinięcie i rozwinięcie węzłów w celu przejrzenia tego pliku. Zarówno program Visual Studio, jak i program Visual Studio Code udostępniają tę funkcję.

Przeszukaj plik project.assets.json dla każdej nazwy pakietów w tabeli pakietów podatnych na zagrożenia, a następnie /. Na przykład wyszukiwanie elementu Microsoft.AspNetCore.Mvc wymaga użycia ciągu wyszukiwania "Microsoft.AspNetCore.Mvc/". Jeśli plik project.assets.json zawiera ten ciąg, a pełny numer wersji (numer po / we wszystkich trafieniach wyszukiwania) jest zgodny z jedną z wymienionych wcześniej wersji podatnych na zagrożenia, istnieje zależność od pakietu podatnego na zagrożenia.

Naprawianie zależności przechodnich (csproj/VS2017)

Jeśli nie znaleziono żadnego odwołania do pakietów podatnych na zagrożenia, oznacza to, że żadna z bezpośrednich zależności nie zależy od żadnych pakietów podatnych na zagrożenia lub problem został już rozwiązany przez zaktualizowanie bezpośrednich zależności.

Jeśli przegląd zależności przechodnich odnalazł odwołania do dowolnego z pakietów narażonych, musisz dodać bezpośrednią zależność do zaktualizowanego pakietu do pliku csproj, aby zastąpić zależność przechodnią. Otwórz plik projectname.csproj w edytorze lub kliknij prawym przyciskiem myszy projekt w programie Visual Studio 2017 i wybierz polecenie Edytuj nazwę projektu.csproj z menu zawartości, gdzie nazwa projektu jest nazwą projektu. Poszukaj węzłów PackageReference, na przykład:


    <project sdk="Microsoft.NET.Sdk.Web">
<propertygroup>
<targetframework>netcoreapp1.1</targetframework>
</propertygroup>
<propertygroup>
<packagetargetfallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</packagetargetfallback>
</propertygroup>
<itemgroup>
<packagereference include="Microsoft.AspNetCore" version="1.1.1">
</packagereference><packagereference include="Microsoft.AspNetCore.Mvc" version="1.1.3">
</packagereference></itemgroup>
<itemgroup>
<dotnetclitoolreference include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" version="1.0.0">
</dotnetclitoolreference></itemgroup>
</project>

Dla każdego z pakietów podatnych na zagrożenia zwrócone wyszukiwanie należy dodać bezpośrednią zależność do zaktualizowanej wersji, dodając ją do pliku csproj. Można to zrobić, dodając nowy wiersz do sekcji zależności, odwołując się do stałej wersji. Jeśli na przykład wyszukiwanie wyświetliło przechodnie odwołanie do wrażliwej wersji System.Net.Security w wersji 4.3.0, należy dodać odwołanie do odpowiedniej stałej wersji 4.3.1.


    <project sdk="Microsoft.NET.Sdk.Web">
<propertygroup>
<targetframework>netcoreapp1.1</targetframework>
</propertygroup>
<propertygroup>
<packagetargetfallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</packagetargetfallback>
</propertygroup>
<itemgroup>
<packagereference include="System.Net.Security" version="4.3.1">
</packagereference><packagereference include="Microsoft.AspNetCore" version="1.1.1">
</packagereference><packagereference include="Microsoft.AspNetCore.Mvc" version="1.1.3">
</packagereference></itemgroup>
<itemgroup>
<dotnetclitoolreference include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" version="1.0.0">
</dotnetclitoolreference></itemgroup>

Po dodaniu odwołania do bezpośredniej zależności zapisz plik csproj.

Jeśli używasz programu Visual Studio, zapisz zaktualizowany plik csproj, a program Visual Studio przywróci nowe wersje pakietu. Wyniki przywracania można wyświetlić, otwierając okno danych wyjściowych (Ctrl+Alt+O) i zmieniając listę rozwijaną Pokaż dane wyjściowe z listy rozwijanej na Menedżer pakietów.

Jeśli nie używasz programu Visual Studio, otwórz wiersz polecenia i przejdź do katalogu projektu. Wykonaj polecenie dotnet restore, aby przywrócić nowe zależności.

Ponowne kompilowanie aplikacji

Na koniec ponownie skompiluj aplikację, przetestuj ją w zwykły sposób i ponownie wdróż przy użyciu preferowanego mechanizmu wdrażania.

Inne informacje

Zgłaszanie problemów z zabezpieczeniami

  • Jeśli w programie .NET Core znaleziono potencjalny problem z zabezpieczeniami, wyślij wiadomość e-mail na adres . Raporty mogą kwalifikować się do bounty błędów platformy .NET Core. Szczegóły bounty błędów platformy .NET Core, w tym warunki i postanowienia, znajdują się pod adresem https:.

Microsoft Active Protections Program (MAPP)

Aby zwiększyć ochronę zabezpieczeń dla klientów, firma Microsoft udostępnia informacje o lukach w zabezpieczeniach głównym dostawcom oprogramowania zabezpieczającego przed każdym comiesięcznym wydaniem aktualizacji zabezpieczeń. Dostawcy oprogramowania zabezpieczającego mogą następnie używać tych informacji o lukach w zabezpieczeniach, aby zapewnić klientom zaktualizowane zabezpieczenia za pośrednictwem oprogramowania lub urządzeń zabezpieczeń, takich jak oprogramowanie antywirusowe, systemy wykrywania nieautoryzowanego dostępu do sieci lub systemy zapobiegania włamaniom oparte na hoście. Aby określić, czy aktywne zabezpieczenia są dostępne od dostawców oprogramowania zabezpieczającego, odwiedź aktywne witryny sieci Web udostępniane przez partnerów programu wymienionych w programie Microsoft Active Protections Program (MAPP).

Opinia

  • Możesz przekazać opinię, wypełniając formularz Pomoc i obsługa techniczna firmy Microsoft, skontaktuj się z nami.

Pomoc techniczna

  • Pytania dotyczące tego problemu można zadawać w witrynie GitHub w organizacjach platformy .NET Core lub ASP.NET Core. Znajdują się one w lokalizacji </https:>https: i </https:https:>. Repozytorium Anonsów dla każdego produktu (https://github.com/dotnet/Announcements i https://github.com/aspnet/Announcements) będzie zawierać ten poradnik jako problem i będzie zawierać link do problemu dyskusji, w którym można zadawać pytania.
  • Klienci w Stany Zjednoczone i Kanadzie mogą otrzymywać pomoc techniczną od działu pomocy technicznej. Aby uzyskać więcej informacji, zobacz Pomoc i obsługa techniczna firmy Microsoft.
  • Klienci międzynarodowi mogą otrzymywać pomoc techniczną od swoich lokalnych spółek zależnych firmy Microsoft. Aby uzyskać więcej informacji, zobacz International Support (Pomoc techniczna międzynarodowa). * Microsoft TechNet Security zawiera dodatkowe informacje na temat zabezpieczeń w produktach firmy Microsoft.

Podziękowania

Firma Microsoft dziękuje za współpracę z nami w celu ochrony klientów:

  • David Fernandez z rozwiązania Sidertia do raportowania luki w zabezpieczeniach ASP.NET podstawowej odmowy usługi (CVE-2017-0247)
  • Mikhail Shcherbakov do raportowania luki w zabezpieczeniach ASP.NET core fałszowania (CVE-2017-0256)

Zastrzeżenie

Informacje podane w tym poradniku są dostarczane "tak, jak jest" bez gwarancji jakiegokolwiek rodzaju. Firma Microsoft nie udziela wszelkich gwarancji, wyraźnych lub domniemanych, w tym gwarancji możliwości handlowych i przydatności do określonego celu. W żadnym wypadku Firma Microsoft Corporation lub jej dostawcy nie ponosi odpowiedzialności za wszelkie szkody, w tym bezpośrednie, pośrednie, przypadkowe, wtórne, utratę zysków biznesowych lub szkody specjalne, nawet jeśli firma Microsoft Corporation lub jej dostawcy zostali poinformowani o możliwości takich szkód. Niektóre państwa nie zezwalają na wyłączenie lub ograniczenie odpowiedzialności za szkody wtórne lub przypadkowe, więc powyższe ograniczenie może nie mieć zastosowania.

Poprawki

  • Wersja 1.0 (9 maja 2017 r.): Biuletyn został opublikowany.
  • Wersja 1.1 (10 maja 2017 r.): Porada zmieniona w celu uwzględnienia tabeli cve problemów i ich opisów. Jest to tylko zmiana informacyjna.

Strona wygenerowana 2017-05-10 13:08-07:00. </https:>