Microsoft-beveiligingsbulletin MS11-100 - Kritiek

Met beperkende factoren wordt verwezen naar een instelling, de algehele configuratie of algemene tips voor een standaardstatus waarmee de ernst van misbruik via een beveiligingslek kan worden verminderd. De volgende beperkende factoren kunnen in uw situatie van pas komen:

• IIS is op geen enkel Windows-besturingssysteem standaard ingeschakeld
• Websites die HTTP-inhoud van het type application/x-www-form-urlencoded of multipart/form-data niet toestaan, zijn niet kwetsbaar
• ASP.NET wordt niet standaard samen met .NET Framework geïnstalleerd. Alleen klanten die ASP.NET handmatig installeren en inschakelen, kunnen last hebben van dit probleem.

Tijdelijke oplossingen zijn wijzigingen in een instelling of configuratie waardoor het beveiligingslek zelf niet wordt gedicht, maar waarmee aanvalsvectoren wel worden geblokkeerd voordat u de update uitvoert. Microsoft heeft de volgende methoden en statussen om het probleem te omzeilen getest om uit te zoeken of een tijdelijke oplossing functionaliteit vermindert:

• Configuratie-afhankelijke tijdelijke oplossing

  Met de volgende tijdelijke oplossing configureert u de limiet voor de maximale aanvraaggrootte die ASP.NET van een client accepteert. Door de maximale aanvraaggrootte te verkleinen, neemt de gevoeligheid van de ASP.NET-server voor een Denial of Service-aanval af.

  Opmerking: Maak een back-up van uw configuratie voordat u deze wijzigt.

  Deze configuratiewaarde kan globaal worden toegepast op alle ASP.NET-websites op een server door de invoer toe te voegen aan web.config of applicationhost.config in de hoofdmap. U kunt deze configuratie ook beperken tot een bepaalde website of toepassing. Daartoe voegt u de vermelding toe aan een web.config-bestand voor de betreffende website of toepassing. Voor meer informatie over de configuratie van ASP.NET raadpleegt u het MSDN-artikel ASP.NET Configuration Overview.

  1. Als uw toepassing ViewState gebruikt, voegt u de volgende configuratie toe aan het juiste ASP.NET-configuratiebestand om de maximale aanvraaggrootte die ASP.NET van een client accepteert in te stellen op 200 KB.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="200”/>
  </system.web>
</configuration>

  2. Als uw toepassing ViewState niet gebruikt, voegt u de volgende configuratie toe aan het juiste ASP.NET-configuratiebestand om de maximale aanvraaggrootte die ASP.NET van een client accepteert in te stellen op 20 KB.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="20”/>
  </system.web>
</configuration>

  Voor meer informatie over de configuratieoptie maxRequestLength zoekt u in de MSDN-documentatie naar het httpRuntime Element.

  Opmerking: Door de standaard HTTP-querytekenreeks en limieten voor de grootte van de aanvraagheader te vergroten, neemt de gevoeligheid van de server voor het Denial of Service-probleem dat in dit advies wordt beschreven, toe. Voor meer informatie over hoe u deze limieten instelt, raadpleegt u Http.sys registry settings for IIS.

  Gevolgen van de tijdelijke oplossing: Clientaanvragen die langer zijn dan de geconfigureerde maxRequestLength resulteren in een ConfigurationErrorsException op de server waarna een http-foutstatus aan de client wordt teruggegeven. De limieten die eerder zijn geconfigureerd, dienen als uitgangspunt en kunnen worden aangepast om toepassingsfouten te vermijden. Hoe lager de waarde die voor maxRequestLength wordt geconfigureerd, des te lager is de gevoeligheid van de server voor deze specifieke denial of service. Toepassingen die clientbestandsuploads accepteren en toepassingen die een omvangrijke weergavestatus genereren, zijn voorbeelden van toepassingen die door dit tijdelijke oplossing kunnen worden getroffen.

  Nadat u deze tijdelijke oplossing hebt toegepast, kan de volgende clientaanvraagfout in een toepassingslogboek worden weergegeven.

  Event code: 3004
Event message: Post size exceeded allowed limits.
Exception information:
    Exception type: HttpException
    Exception message: Maximum request length exceeded.
   at System.Web.HttpRequest.GetEntireRawContent()
   at System.Web.HttpRequest.FillInFormCollection()
   at System.Web.HttpRequest.get_Form()
   at System.Web.HttpRequest.get_HasForm()
   at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)
   at System.Web.UI.Page.DeterminePostBackMode()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

  Anders resulteert de mislukte aanvraag in de volgende vermelding in een IIS-logboek.

  #Fields: s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

127.0.0.1 POST /webSite/Default.aspx - 80 - 127.0.0.1 - 500 0 0 1268

  Tijdelijke oplossing verwijderen: Als u de tijdelijke oplossing ongedaan wilt maken, verwijdert u de configuratieonderdelen die in deze tijdelijke oplossing zijn toegevoegd of herstelt u een back-up van de configuratie zoals die vóór de tijdelijke oplossing was.

Wat is de omvang van het beveiligingslek? 
Dit beveiligingslek heeft betrekking op een denial of service. Door dit beveiligingslek kan een niet-geverifieerde aanvaller de prestaties van een ASP.NET-website doen afnemen waardoor een Denial of Service ontstaat.

Waardoor wordt het beveiligingslek veroorzaakt? 
Het beveiligingslek is het gevolg van de manier waarop ASP.NET speciaal vervaardigde aanvragen hasht en deze gegevens in een hashtabel plaatst waardoor een hashbotsing wordt veroorzaakt. Wanneer veel van deze botsingen optreden, nemen de prestaties van de hashtabel dusdanig af dat een Denial of Service ontstaat.

Met welk doel kan een aanvaller het beveiligingslek misbruiken? 
Een aanvaller kan dit beveiligingslek gebruiken om een Denial of Service-aanval te veroorzaken en de beschikbaarheid te verstoren van websites die ASP.NET gebruiken.

Hoe kan een aanvaller dit beveiligingslek misbruiken? 
Een niet-geverifieerde aanvaller kan een klein aantal speciaal vervaardigde ASP.NET-aanvragen naar een getroffen ASP.NET-website verzenden, waardoor een denial of service wordt veroorzaakt.

Voor welke systemen vormt dit beveiligingslek het grootste risico? 
Voor internetsystemen waarop ASP.NET is geïnstalleerd, vormt dit beveiligingslek het grootste risico. Daarnaast lopen interne websites die ASP.NET-formulierverificatie gebruiken het risico te worden getroffen.

Wat doet de update? 
De update lost dit beveiligingslek op door de manier te verbeteren waarop het .NET Framework speciaal ontworpen aanvragen behandelt.

Was dit beveiligingslek openbaar gemaakt op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Ja. Dit beveiligingslek is openbaar gemaakt. Aan dit beveiligingslek is nummer CVE-2011-3414 toegewezen.

Was aan Microsoft gerapporteerd dat er misbruik was gemaakt van dit beveiligingslek op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft geen informatie ontvangen die erop wees dat dit beveiligingslek was gebruikt om aanvallen uit te voeren op klanten op het moment dat dit beveiligingsbulletin oorspronkelijk werd uitgegeven.

Is dit een algemeen probleem?
Aanvallen dit op dit type beveiligingslek zijn gericht, worden hashbotsingsaanvallen genoemd. Dergelijke aanvallen zijn niet kenmerkend voor Microsoft-technologieën en treffen ook andere providers van webservicesoftware. Klanten dienen contact op te nemen met de leveranciers van hun webplatform voor hulp of updates.

Met beperkende factoren wordt verwezen naar een instelling, de algehele configuratie of algemene tips voor een standaardstatus waarmee de ernst van misbruik via een beveiligingslek kan worden verminderd. De volgende beperkende factoren kunnen in uw situatie van pas komen:

• Dit beveiligingslek kan er niet toe leiden dat een aanvaller rechtstreeks code uitvoert of zich machtigingen toekent, maar wel dat de aanvaller informatie kan genereren waarmee gebruikersinformatie verder kan worden misbruikt.
• Formulierverificatie is niet standaard ingeschakeld in ASP.NET. Het moet expliciet per toepassing zijn geconfigureerd om te worden ingeschakeld.
• Standaard is IIS niet geïnstalleerd.
• ASP.NET wordt niet standaard samen met .NET Framework geïnstalleerd. Alleen klanten die ASP.NET handmatig installeren en inschakelen, kunnen last hebben van dit probleem.
• Om het beveiligingslek te kunnen misbruiken, moet de aanvaller de gebruiker overhalen om op een koppeling te klikken.

Tijdelijke oplossingen zijn wijzigingen in een instelling of configuratie waardoor het beveiligingslek zelf niet wordt gedicht, maar waarmee aanvalsvectoren wel worden geblokkeerd voordat u de update uitvoert. Microsoft heeft de volgende methoden en statussen om het probleem te omzeilen getest om uit te zoeken of een tijdelijke oplossing functionaliteit vermindert:

• Formulierverificatie uitschakelen in web.config
  1. Open het algemene web.config-bestand of het web.config-bestand van de toepassing nadat u een back-up hebt gemaakt
  2. Stel de verificatiemodus in op Windows Passport of Geen.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Details van elke modus vindt u in http://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx.

     De tijdelijke oplossing ongedaan maken. 

     Herstel uw web.config-bestand vanuit uw back-upbestand.

Wat is de omvang van het beveiligingslek? 
Dit is een beveiligingslek dat betrekking heeft op spoofing. Via dit beveiligingslek kan een aanvaller een gebruiker zonder diens medeweten omleiden naar elke door de aanvaller gewenste website. De aanvaller kan vervolgens een phishing-aanval uitvoeren om informatie van de gebruiker te verkrijgen die niet bedoeld is om te worden vrijgegeven. Via dit beveiligingslek kan een aanvaller geen code uitvoeren of rechtstreeks misbruik maken van zijn gebruikersrechten. Het beveiligingslek kan echter wel worden gebruikt om misbruik te maken van de gebruikersinformatie die privé had moeten blijven.

Wat is phishing? 
Online phishing (uitgesproken als fishing) is een manier om computergebruikers middels een frauduleus e-mailbericht of een website ertoe te brengen persoonlijke of financiële informatie te onthullen. Een doorsnee phishing scam begint met een e-mailbericht dat lijkt op een officieel bericht van een vertrouwde bron, zoals een bank, creditcardbedrijf of erkende onlinewinkel. In het e-mailbericht worden ontvangers omgeleid naar een frauduleuze website waar zij worden gevraagd persoonlijke informatie te verstrekken, zoals een rekeningnummer of wachtwoord. Deze informatie wordt vervolgens doorgaans gebruikt voor identiteitsdiefstal.

Waardoor wordt het beveiligingslek veroorzaakt? 
Dit beveiligingslek wordt veroorzaakt wanneer het .NET Framework geretourneerde URL's tijdens het formulierverificatieproces onjuist verifieert.

Wat is Formulierverificatie in ASP.NET? 
Formulierverificatie gebruikt een verificatieticket dat wordt gemaakt wanneer een gebruiker zich aanmeldt op een website, en volgt de gebruiker op de website. Het formulierverificatieticket is doorgaans opgenomen in een cookie. ASP.NET versie 2.0 ondersteunt echter formulierverificatie zonder cookies, waardoor het ticket in een querytekenreeks wordt doorgestuurd. Voor meer informatie raadpleegt u het MSDN-artikel, Explained: Forms Authentication in ASP.NET 2.0.

Met welk doel kan een aanvaller het beveiligingslek misbruiken? 
Een aanvaller die misbruik weet te maken van dit beveiligingslek, kan een gebruiker zonder diens medeweten omleiden naar elke door de aanvaller gewenste website. Via dit beveiligingslek kan een aanvaller geen code uitvoeren of rechtstreeks misbruik maken van zijn gebruikersrechten. Het beveiligingslek kan echter wel worden gebruikt om misbruik te maken van de gebruikersinformatie die privé had moeten blijven.

Hoe kan een aanvaller dit beveiligingslek misbruiken? 
Een aanvaller kan een speciaal vervaardigde URL maken en een gebruiker overhalen om erop te klikken. Nadat een gebruiker zich heeft aangemeld bij een verwachte website, leidt de aanvaller de gebruiker om naar een website die door de aanvaller wordt bestuurd. Vervolgens zou de aanvaller de gebruiker kunnen overhalen om informatie te verstrekken die privé had moeten blijven. Een aanvaller kan een gebruiker er echter niet toe dwingen de inhoud van de aanvaller weer te geven. In plaats daarvan zou een aanvaller gebruikers ertoe moeten overhalen om een actie te ondernemen, gewoonlijk is dat het klikken op een Instant Messenger-bericht waardoor gebruikers worden omgeleid naar de website van de aanvaller nadat zij zich bij een verwachte website hebben aangemeld.

Voor welke systemen vormt dit beveiligingslek het grootste risico? 
Voor internetsystemen waarop ASP.NET is geïnstalleerd, vormt dit beveiligingslek het grootste risico. Daarnaast lopen interne websites die ASP.NET-formulierverificatie gebruiken het risico te worden getroffen.

Wat doet de update? 
De update lost dit beveiligingslek op door de manier te verbeteren waarop het .NET Framework geretourneerde URL's tijdens formulierverificatie verifieert.

Was dit beveiligingslek openbaar gemaakt op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft uit betrouwbare bronnen informatie over dit beveiligingslek ontvangen.

Was aan Microsoft gerapporteerd dat er misbruik was gemaakt van dit beveiligingslek op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft geen informatie ontvangen die erop wees dat dit beveiligingslek was gebruikt om aanvallen uit te voeren op klanten op het moment dat dit beveiligingsbulletin oorspronkelijk werd uitgegeven.

Met beperkende factoren wordt verwezen naar een instelling, de algehele configuratie of algemene tips voor een standaardstatus waarmee de ernst van misbruik via een beveiligingslek kan worden verminderd. De volgende beperkende factoren kunnen in uw situatie van pas komen:

• Een aanvaller moet een account op de ASP.NET-toepassing kunnen registreren en moet een bestaande gebruikersnaam kennen.
• Formulierverificatie is niet standaard ingeschakeld in ASP.NET. Het moet expliciet per toepassing zijn geconfigureerd om te worden ingeschakeld.
• Standaard is IIS niet geïnstalleerd.
• ASP.NET wordt niet standaard samen met .NET geïnstalleerd. Alleen klanten die ASP.NET handmatig installeren en inschakelen, kunnen last hebben van dit probleem.

Tijdelijke oplossingen zijn wijzigingen in een instelling of configuratie waardoor het beveiligingslek zelf niet wordt gedicht, maar waarmee aanvalsvectoren wel worden geblokkeerd voordat u de update uitvoert. Microsoft heeft de volgende methoden en statussen om het probleem te omzeilen getest om uit te zoeken of een tijdelijke oplossing functionaliteit vermindert:

• Stel ticketCompatibilityMode in op Framework40

  Dit is alleen van toepassing op websites waarop ASP.NET 4 en nieuwer wordt uitgevoerd, omdat de instelling ticketCompatibilityMode pas in ASP.NET v4.0 is geïntroduceerd.

  1. Open het algemene web.config-bestand of het web.config-bestand van de toepassing nadat u een back-up hebt gemaakt
  2. Stel ticketCompatibilityMode in op Framework40. De standaardwaarde voor deze instelling is "Framework20"

     <system.web>
  <authentication mode="Forms">
    <forms ticketCompatibilityMode="Framework40" />
  </authentication>
</system.web>

  De tijdelijke oplossing ongedaan maken. 

  Herstel uw web.config-bestand vanuit uw back-upbestand.

• Formulierverificatie uitschakelen in web.config
  1. Open het algemene web.config-bestand of het web.config-bestand van de toepassing nadat u een back-up hebt gemaakt
  2. Stel de verificatiemodus in op Windows Passport of Geen.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Details van elke modus vindt u in http://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx.

     De tijdelijke oplossing ongedaan maken. 

     Herstel uw web.config-bestand vanuit uw back-upbestand.

Wat is de omvang van het beveiligingslek? 
Dit is een beveiligingslek met betrekking tot misbruik van bevoegdheden waardoor een externe niet-geverifieerde aanvaller toegang kan krijgen tot een andere account op de ASP.NET-toepassing waardoor een aanvaller willekeurige opdrachten op de website kan uitvoeren in de context van de aangevallen gebruiker.

Waardoor wordt het beveiligingslek veroorzaakt? 
Dit beveiligingslek wordt veroorzaakt wanneer het ASP.NET Framework speciaal vervaardigde gebruikersnamen op onjuiste wijze verifieert.

Met welk doel kan een aanvaller het beveiligingslek misbruiken? 
Een aanvaller die misbruik weet te maken van dit beveiligingslek kan elke willekeurige actie in de context van die bepaalde gebruiker, waaronder het uitvoeren van willekeurige opdrachten, op de website kunnen uitvoeren.

Hoe kan een aanvaller dit beveiligingslek misbruiken? 
Om misbruik te kunnen maken van dit beveiligingslek, moet een niet-geverifieerde aanvaller eerst een bestaande accountnaam kennen om zich op de website als een andere gebruiker voor te doen. De aanvaller zou dan een speciale webaanvraag kunnen vervaardigen met een eerder geregistreerde accountnaam om toegang te krijgen tot die account. De aanvaller kan dan elke willekeurige actie in de context van die bepaalde gebruiker, waaronder het uitvoeren van willekeurige opdrachten, op de website kunnen uitvoeren.

Voor welke systemen vormt dit beveiligingslek het grootste risico? 
Voor internetsystemen waarop ASP.NET is geïnstalleerd, vormt dit beveiligingslek het grootste risico. Daarnaast lopen interne websites die ASP.NET-formulierverificatie gebruiken het risico te worden getroffen.

Als mijn website een webfarm gebruikt, moet ik dan alle computers in de webfarm bijwerken? 
Ja. Deze update verandert de indeling van het formulierverificatieticket dusdanig dat deze niet meer compatibel is met de eerdere indeling. Dat betekent dat tickets die op de nieuwe wijze zijn gegenereerd, niet meer kunnen worden gelezen door computers die de oude werking gebruiken en omgekeerd. Beheerders van toepassingen die formulierverificatie gebruiken, moeten specifieke stappen uitvoeren bij de implementatie van deze beveiligingsupdate om ervoor te zorgen dat al hun servers tegelijkertijd overschakelen op de nieuwe werking.

Raadpleeg het Microsoft TechNet-artikel 2659968 voor meer informatie.

Is het mogelijk om de computers in mijn webfarm een voor een bij te werken in plaats van allemaal tegelijkertijd? 
Ja. Als het niet haalbaar is om MS11-100 op alle servers tegelijkertijd te implementeren in een bepaalde webfarm, kunt u een compatibiliteitsschakeloptie in uw web.config- of machine.config-bestand instellen voordat u de update installeert, om ervoor te zorgen dat de oude werking wordt gehandhaafd nadat de update is geïnstalleerd. Gebruik de volgende compatibiliteitsschakeloptie:

<appSettings>
  <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />
</appSettings>

Door deze schakeloptie in te stellen, blijven webfarms waarvan slechts enkele machines zijn bijgewerkt, toch correct functioneren. Het is echt belangrijk te weten dat computers waarop de configuratieoptie is ingeschakeld, zich in een onveilige toestand bevinden. De oplossing in deze beveiligingsupdate wordt niet op deze computers toegepast. Nadat MS11-100 op alle computers in een farm is geïmplementeerd, moet de configuratieschakeloptie worden verwijderd om de nieuwe, veilige werking in te schakelen.

Houdt deze update rekening met de instelling van ticketCompatibilityMode voor formulierverificatie op mijn website? 
Nee. Aangezien de oplossing in deze beveiligingsupdate de indeling van formulierverificatietickets verandert, wordt de configuratie-instelling van ticketCompatibilityMode niet langer ondersteund zodra MS11-100 is geïnstalleerd.

Wat doet de update? 
De update lost dit beveiligingslek op door te verbeteren hoe het ASP.NET Framework gebruikers verifieert.

Was dit beveiligingslek openbaar gemaakt op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft uit betrouwbare bronnen informatie over dit beveiligingslek ontvangen.

Was aan Microsoft gerapporteerd dat er misbruik was gemaakt van dit beveiligingslek op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft geen informatie ontvangen die erop wees dat dit beveiligingslek was gebruikt om aanvallen uit te voeren op klanten op het moment dat dit beveiligingsbulletin oorspronkelijk werd uitgegeven.

Met beperkende factoren wordt verwezen naar een instelling, de algehele configuratie of algemene tips voor een standaardstatus waarmee de ernst van misbruik via een beveiligingslek kan worden verminderd. De volgende beperkende factoren kunnen in uw situatie van pas komen:

• Standaard worden ASP.NET-antwoorden niet door de OutputCache opgeslagen. De ontwikkelaar van de website moet specifiek voor de opslag van uitvoer kiezen via de instructie OutputCache op een pagina.
• Een aanvaller die erin slaagt misbruik te maken van dit beveiligingslek, kan dezelfde rechten over het systeem verkrijgen als de voor de aanval beoogde gebruiker. Gebruikers met accounts waarvoor minder gebruikersrechten op het systeem zijn ingesteld, lopen minder risico dan gebruikers die met beheerdersrechten werken.
• IIS is standaard niet geïnstalleerd in de besturingssysteemversies waarin dit probleem optreedt. Alleen klanten die dit handmatig hebben geïnstalleerd, kunnen last hebben van dit probleem.
• ASP.NET wordt niet standaard samen met .NET geïnstalleerd. Alleen klanten die ASP.NET handmatig installeren en inschakelen, kunnen last hebben van dit probleem.

Tijdelijke oplossingen zijn wijzigingen in een instelling of configuratie waardoor het beveiligingslek zelf niet wordt gedicht, maar waarmee aanvalsvectoren wel worden geblokkeerd voordat u de update uitvoert. Microsoft heeft de volgende methoden en statussen om het probleem te omzeilen getest om uit te zoeken of een tijdelijke oplossing functionaliteit vermindert:

• Beperk formulierverificatiecookies tot SSL-kanalen

  Open het algemene web.config-bestand of het web.config-bestand van de toepassing nadat u een back-up hebt gemaakt.

  Stel requireSSL="true" in voor het <forms>-element zoals in de volgende code wordt weergegeven.

  <forms loginUrl="Secure\Login.aspx"
    requireSSL="true" />

  De tijdelijke oplossing ongedaan maken. 

  Herstel uw web.config-bestand vanuit uw back-upbestand.

• Schakel verschuivend verloop uit voor formulierverificatiecookies
  1. Open het algemene web.config-bestand of het web.config-bestand van de toepassing nadat u een back-up hebt gemaakt
  2. Stel slidingExpiration="false" in voor het <forms>-element zoals in de volgende code wordt weergegeven.

     <forms slidingExpiration="false"/>

  Gevolgen van de tijdelijke oplossing. Gebruikers moeten zich opnieuw aanmelden nadat hun tickets zijn verlopen.

  De tijdelijke oplossing ongedaan maken. 

  Herstel uw web.config-bestand vanuit uw back-upbestand.

• Schakel OutputCache uit
  1. Maak een back-up van uw webtoepassingsmap.
  2. Verwijder alle <%@ OutputCache %>-instructies in uw webpagina's.
  3. Als uw website een MVC-toepassing is, dient u ook alle OutputCache-kenmerken uit uw controlleracties te verwijderen.

  Gevolgen van de tijdelijke oplossing. Gebruikers moeten zich opnieuw aanmelden nadat hun tickets zijn verlopen.

  De tijdelijke oplossing ongedaan maken. 

  Herstel uw webtoepassingsmap.

Wat is de omvang van het beveiligingslek? 
Dit is een beveiligingslek met betrekking tot misbruik van bevoegdheden waarbij een externe niet-geverifieerde aanvaller toegang krijgt tot een andere account op de .NET-toepassing.

Waardoor wordt het beveiligingslek veroorzaakt? 
Dit beveiligingslek wordt veroorzaakt wanneer het .NET Framework inhoud in de cache onjuist behandelt wanneer Formulierverificatie met verschuivend verloop wordt gebruikt.

Met welk doel kan een aanvaller het beveiligingslek misbruiken? 
Een aanvaller die misbruik weet te maken van dit beveiligingslek, kan op de website in de context van de aangevallen gebruiker elke willekeurige actie ondernemen, waaronder de uitvoering van willekeurige opdrachten, die de gebruiker zou kunnen uitvoeren.

Hoe kan een aanvaller dit beveiligingslek misbruiken? 
In een aanval via e-mail kan een aanvaller misbruik maken van het beveiligingslek door een speciaal gemaakte koppeling naar de gebruiker te versturen en de gebruiker te overtuigen op de koppeling te klikken. Een aanvaller kan een gebruiker er niet toe dwingen om naar de website te gaan. In plaats daarvan moet een aanvaller gebruikers overhalen om een actie te ondernemen, doorgaans door op een koppeling in een e-mailbericht of een Instant Messenger-bericht te klikken.

Wat is Formulierverificatie in ASP.NET? 
Formulierverificatie gebruikt een verificatieticket dat wordt gemaakt wanneer een gebruiker zich aanmeldt op een website, en volgt de gebruiker op de website. Het formulierverificatieticket is doorgaans opgenomen in een cookie. ASP.NET versie 2.0 ondersteunt echter formulierverificatie zonder cookies, waardoor het ticket in een querytekenreeks wordt doorgestuurd. Voor meer informatie raadpleegt u het MSDN-artikel, Explained: Forms Authentication in ASP.NET 2.0.

Voor welke systemen vormt dit beveiligingslek het grootste risico? 
Voor internetsystemen waarop IIS en ASP.NET zijn geïnstalleerd, vormt dit beveiligingslek het grootste risico. Daarnaast lopen interne websites die ASP.NET-formulierverificatie gebruiken het risico te worden getroffen.

Wat doet de update? 
De update corrigeert de manier waarop ASP.NET in de cache opgeslagen inhoud behandelt.

Was dit beveiligingslek openbaar gemaakt op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft uit betrouwbare bronnen informatie over dit beveiligingslek ontvangen.

Was aan Microsoft gerapporteerd dat er misbruik was gemaakt van dit beveiligingslek op het moment dat dit beveiligingsbulletin werd uitgegeven? 
Nee. Microsoft heeft geen informatie ontvangen die erop wees dat dit beveiligingslek was gebruikt om aanvallen uit te voeren op klanten op het moment dat dit beveiligingsbulletin oorspronkelijk werd uitgegeven.

Referentietabel

In de volgende tabel vindt u informatie over de beveiligingsupdate voor deze software. Aanvullende informatie vindt u in de subsectie Informatie over implementatie van deze sectie.

Opmerking De update voor ondersteunde versies van Windows XP Professional x64 Edition is ook van toepassing op ondersteunde versies van Windows Server 2003 x64 Edition.

Referentietabel

In de volgende tabel vindt u informatie over de beveiligingsupdate voor deze software. Aanvullende informatie vindt u in de subsectie Informatie over implementatie van deze sectie.

Opmerking De update voor ondersteunde versies van Windows Server 2003 x64 Edition is ook van toepassing op ondersteunde versies van Windows XP Professional x64 Edition.

Referentietabel

In de volgende tabel vindt u informatie over de beveiligingsupdate voor deze software. Aanvullende informatie vindt u in de subsectie Informatie over implementatie van deze sectie.

Referentietabel

In de volgende tabel vindt u informatie over de beveiligingsupdate voor deze software. Aanvullende informatie vindt u in de subsectie Informatie over implementatie van deze sectie.

Referentietabel

In de volgende tabel vindt u informatie over de beveiligingsupdate voor deze software. Aanvullende informatie vindt u in de subsectie Informatie over implementatie van deze sectie.

Referentietabel

In de volgende tabel vindt u informatie over de beveiligingsupdate voor deze software. Aanvullende informatie vindt u in de subsectie Informatie over implementatie van deze sectie.