Kapcsolódó témakörök
×
Bejelentkezés Microsoft-fiókkal
Jelentkezzen be, vagy hozzon létre egy fiókot.
Üdvözöljük!
Válasszon másik fiókot.
Több fiókja van
Válassza ki a bejelentkezéshez használni kívánt fiókot.

Kiadás dátuma:
2020. október 13.

Verzió:
.NET-keretrendszer 4.8

Összefoglalás

Biztonsági fejlesztések

Az információk felfedése akkor áll fenn, ha a .NET-keretrendszer helytelenül kezeli a memóriában lévő objektumokat. A biztonsági rést sikeresen kihasználó támadó felfedte az érintett rendszer memóriájának tartalmát. A biztonsági rés kihasználásához egy hitelesített támadónak egy speciálisan kialakított alkalmazást kell futtatnia. A frissítés a biztonsági rést úgy javítja ki, hogy a .NET-keretrendszer hogyan kezeli az objektumokat a memóriában.

A biztonsági résekkel kapcsolatos további információkért olvassa el a következő gyakori biztonsági réseket és expozíciókat (CVE).

Minőség- és megbízhatósági fejlesztések

WCF1

– Elhárítottuk azt a hibát, amely miatt a WCF-szolgáltatások időnként nem indulnak el több szolgáltatás egyidejűleg történő indításakor.

Winforms

Kijavítottunk egy regressziót, amely a .NET Framework 4.8-as keretrendszerében jelent meg, ahol a Control.AccessibleName, a Control.AccessibleRole és a Control.AccessibleDescription tulajdonságok nem működnek a következő vezérlőkhöz: Label, GroupBox, ToolStrip, ToolStripItems, StatusStripItems, PropertyGrid, ProgressBar, ComboBox, MenuStrip, MenuItems, DataGridView.

- Kijavítottunk egy, az adathoz kötött kombinált listaelemek akadálymentes nevében regressziót. A .NET-keretrendszer 4.8-as keretrendszere a DisplayMember tulajdonság értéke helyett a típusnevet kezdte használni akadálymentes névként, ez a fejlesztés ismét a DisplayMember tulajdonságot használja.

ASP.NET

– Az AppPathModifier nem használható ASP.Net vezérlő kimenetében.

– A httpcookie-objektumok a ASP.Net környezetben a cookie-jelölők alapértelmezett beállításaival fognak létrejönni a cookie-jelölő helyett. A NET-stílusú egyszerű alapértelmezett értékek az "új HttpCookie(név)" viselkedésével egyeznek.

SQL

– Elhárítottunk egy hibát, amely időnként akkor fordult elő, amikor egy felhasználó csatlakozik egy Azure SQL-adatbázishoz, enkláve-alapú műveletet hajtott végre, majd ugyanazon a kiszolgálón egy másik adatbázishoz csatlakozott, amely ugyanazt az Url-címet tartalmazza, és enclave műveletet hajtott végre a második kiszolgálón.

CLR2

- Felvett egy Thread_AssignCpuGroups (alapértelmezés szerint 1) clr konfigurációs változót, amely beállítható 0-ra, hogy letiltsa a ClR által a Thread.Start() és a szálkészlet-szálláncok által létrehozott új témák automatikus processzorcsoport-hozzárendelését, így az appok saját száleltárásokat is végezhetnek.

- Elhárítottuk azt a ritka adatsérülést, amely az új API-k (például a Nem biztonságos.ByteOffset<T>) használata során fordulhatott elő, amelyeket gyakran használnak az új Span típusokkal. A sérülés akkor fordulhat elő, ha GC-műveletet hajt végre, miközben egy szál nem biztonságos.ByteOffset<T> egy hurokból.

- Kijavítottunk egy, a nagyon hosszú határidővel a vártnál jóval korábban időzített időzítőkre vonatkozó problémát, amikor az AppContext kapcsoló "Switch.System. Threading.UseNetCoreTimer" engedélyezve van.


1 Windows Communication Foundation (WCF)
2 Common Language Runtime (CLR)

A frissítés ismert problémái

ASP.Net hibaüzenettel való előkompatiálás során sikertelenek az alkalmazások

Tünetek
A .NET-keretrendszer 4.8-as biztonsági és minőségi összegző frissítésének 2020. október 13-i alkalmazása után egyes ASP.Net-alkalmazások nem fognak működni az előkompatiálás során. A hibaüzenet valószínűleg tartalmazza az "ASPCONFIG hiba" szöveget.

Ok
Érvénytelen konfigurációs állapot a "sessionState", a "anonymouseIdentification" vagy a "authentication/forms" (Hitelesítés/űrlapok) szakaszban a "System.web" konfigurációban. Ez akkor fordulhat elő a build- és közzétételi rutinok során, ha a konfigurációs átalakítások az Web.config fájlt köztes állapotban hagyják az előkompatiáláshoz.

Kerülő megoldás
Azok az ügyfelek, akik új váratlan hibákat vagy funkcionális problémákat figyelnek meg, implementáljanak egy alkalmazásbeállítást az alábbi kód alkalmazáskonfigurációs fájlhoz való hozzáadásával (vagy egyesítésével). Az "igaz" vagy a "hamis" beállítással elkerülheti a problémát. Azt javasoljuk azonban, hogy állítsa ezt az értéket "true" értékre az olyan webhelyeknél, amelyek nem támaszkodnak cookieless funkciókra.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
      <appSettings>
          <add key=”aspnet:DisableAppPathModifier” value=”true” />
     </appSettings>
</configuration>

ASP.Net előfordulhat, hogy az alkalmazások nem kézbesítik a cookie-t nem szabadító jogkivonatokat az URI-ban

Tünetek
A .NET-keretrendszer 4.8-as biztonsági és minőségi összegző frissítésének 2020. október 1-jét követően egyes ASP.Net-alkalmazások esetleg nem biztosítják a cookieless tokeneket az URI-ban, ami 302-átirányítási hurkot vagy elveszett vagy hiányzó munkamenetállapotot eredményezhet.

Ok
A munkamenet állapota, a névtelen azonosítás és a forms-hitelesítés ASP.Net szolgáltatásai mind a tokenek webes ügyfélalkalmazásnak való kibocsátására támaszkodnak, és mind lehetővé teszik, hogy a tokenek cookie-ban vagy az URI-be ágyazva, a cookie-kat nem támogató ügyfelek számára is elérhetőek. Az URI-beágyazás hosszú ideje nem biztonságos és nem megfelelő gyakorlat, és ez a tudásbáziscikk csendesen letiltja a jogkivonatok URI-k kiadását, hacsak a három szolgáltatás egyike kifejezetten nem kér "UseUri" cookie-t a konfigurációban. Az "AutoDetect" vagy a "UseDeviceProfile" beállítást megadó konfigurációk véletlenül azt eredményezhetik, hogy megkísérlik és nem sikerült beágyazni ezeket a jogkivonatokat az URI-ban.

Kerülő megoldás
Azok az ügyfelek, akik új váratlan viselkedést figyelnek meg, azt javasoljuk, hogy ha lehetséges, módosítsa mindhárom cookie-nélküli beállítást "UseCookies" beállításra.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <system.web>
          <anonymousidentification cookieless="UseCookies" />
          <sessionState cookieless="UseCookies" />
          <authentication>
               <forms cookieless="UseCookies" />
          </authentication>
     </system.web>
</configuation>

Ha egy alkalmazásnak továbbra is URI-beágyazott jogkivonatokat kell használnia, és ezt biztonságosan meg tudja tenni, az alábbi appSeting funkcióval újra engedélyezhető. De ismét erősen javasoljuk, hogy ne ágyazza be ezeket a jogkivonatokat az URI-jukba.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <appSettings>
          <add key="aspnet:DisableAppPathModifier" value="false" />
     </appSettings>
</configuation>

A frissítés letöltése

A frissítés telepítése

Release Channel

Elérhető

Következő lépés

Windows Update és Microsoft Update

Igen

Nincs. Ezt a frissítést a rendszer automatikusan letölti és telepíti a Windows Update-ről.

Microsoft Update katalógus

Igen

A frissítés különálló csomagját a Microsoft Frissítési katalógus webhelyéről szerezze be.

Windows Server Update Services (WSUS)

Igen

Ez a frissítés automatikusan szinkronizálódik a WSUS-val, ha a termékeket és a besorolásokat az alábbiak szerint konfigurálja:

Termék:Windows10 1709-es verzió

Besorolás:Biztonsági frissítések

Fájladatok

A frissítésben megadott fájlok listájának letöltéséhez töltse le a fájlinformációkat az összegző frissítéshez.

Információk a védelemről és biztonságról

További segítségre van szüksége?

További lehetőségeket szeretne?

Fedezze fel az előfizetés előnyeit, böngésszen az oktatóanyagok között, ismerje meg, hogyan teheti biztonságossá eszközét, és így tovább.

A közösségek segítségével kérdéseket tehet fel és válaszolhat meg, visszajelzést adhat, és részletes ismeretekkel rendelkező szakértőktől hallhat.

Hasznos volt ez az információ?

Mennyire elégedett a fordítás minőségével?
Mi volt hatással a felhasználói élményére?
Ha elküldi a visszajelzést, a Microsoft felhasználja azt a termékei és szolgáltatásai továbbfejlesztéséhez. Az informatikai rendszergazda képes lesz ezeket az adatokat összegyűjteni. Adatvédelmi nyilatkozat.

Köszönjük a visszajelzését!

×