Andreas Mersch

Single Sign-On mit ASP.NET 2.0 über zwei Applikationen

andreas.mersch@gmx.de (andreas mersch) — Sun, 16 Mar 2008 18:48:15 GMT

Um auf Anmeldeinformationen einer Web Applikation aus einer anderen Web Applikation auf der selben Maschine zugreifen zu können und so eine Art von Single Sign-On abzubilden, ist entscheidend, dass in der web.config beider Applikationen der selbe machineKey konfiguriert wurde.

LoginWebSite:

web.config:
<system.web>
    

   <authentication mode="Forms">
       <forms loginUrl="Login.aspx"/>
   </authentication>

   <authorization>
       <deny users="?"/>
   </authorization>

       <machineKey validationKey="D61B3C89CB33A2F1422FF158AFF7320E8DB8CB5CDA1742572A487D94018787EF42682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE" decryptionKey="FBF50941F22D6A3B229EA593F24C41203DA6837F1122EF17" />

    
</system.web>

Login.aspx:
    
    <div>
        <asp:Login ID="Login1" runat="server">
        </asp:Login>
    </div>
    

ApplWebSite:

web.config:
<system.web>
    

   <authentication mode="Forms">
       <forms loginUrl="/Login/Login.aspx"/>
   </authentication>

   <authorization>
       <deny users="?"/>
   </authorization>

       <machineKey validationKey="D61B3C89CB33A2F1422FF158AFF7320E8DB8CB5CDA1742572A487D94018787EF42682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE" decryptionKey="FBF50941F22D6A3B229EA593F24C41203DA6837F1122EF17" />

    

</system.web>

ASP.NET 1.1: Configuration Error - Access is denied

andreas.mersch@gmx.de (andreas mersch) — Tue, 21 Aug 2007 06:49:03 GMT

Ich bin kürzlich auf die hinlänglich diskutierte Fehlermeldung "Configuration Error" von ASP.NET 1.1 gestoßen.

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: Access is denied: 'mydll'.

Source Error:

Line
169: <add assembly=<System.Drawing, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a>/>



Line 170: <add assembly=<System.EnterpriseServices, Version=1.0.3300.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a>/>

Line 171: <add assembly=<*>/>

Line 172: </assemblies>

Line 173:

Source File: c:\winnt\microsoft.net\framework\v1.0.3705\Config\machine.config Line: 171
Version Information: Microsoft .NET Framework Version:1.0.3705.0; ASP.NET Version:1.0.3705.0

Ergänzend zum Microsoft Support Eintrag (http://support.microsoft.com/default.aspx?scid=kb;en-us;329065) habe ich festgestellt, dass nicht nur der Indexing Service dieses Problem auslösen kann.

Zur Vermeidung des Problems sind die Verzeichnisse

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

ebenfalls aus einer Virenscanner Überwachung auszuschließen. Allgemein: Jedes Tool, welches IO Zugriffe auf der Platte überwacht muss diese Verzeichnisse ignorieren.

Security mit ASP.NET 2.0 Teil 2 - Eingabe Validierung

andreas.mersch@gmx.de (andreas mersch) — Wed, 31 Jan 2007 13:12:44 GMT

Dieser zweite Teil der Webcastserie zum Thema Sicherheit mit ASP.NET 2.0 von Dominick Baier befasste sich schwerpunktmäßig mit der Thematik der Eingabe Validierung.

Für mich interessant waren die Punkte HTML Injection, SQL Injection und Cross Side Scripting (XSS). Hatte ich schon erwähnt, dass sich die Homepage meines Abiturjahrgangs vorzüglich für SQL Injection eignet..? Aber das gehört hier nicht hin!

Als Gegenmaßnahme, bzw. Vorsichtsmaßnahme gegen SQL Injection gehört grundsätzlich Stringverkettungen von SQL Statements und Eingabewerten zu vermeiden. Hierbei lassen sich mit simplen Mitteln eigene SQL Statements dem System unterschieben. Daher sollten SQL Statements in .NET stets über SqlCommand Objekte mit SqlParameter Objekten realisiert werden. Das Thema SQL Injection lässt sich damit schon einmal fürs erste absichern.

Html Injection und XSS ist ein Thema bei Gästebüchern, Foren, Web Content Management Systemen. Mit diesen Angriffen lassen sich z.B. Cookieinhalte auslesen und an Dritte weiterleiten. Die HttpCookie bietet einen kleinen Schutz vor einem Cookieklau über die Eigenschaft "HttpOnly = true". Diese Eigenschaft funktioniert jedoch nur im Internet Explorer und verhindert hier, dass ein Cookie von einer anderen Seite als der aufgerufenen abzufragen.

Grundsätzlich können alle Eingaben nach HTML / XML Tags gefiltert werden. Dies erfolgt über die Seiten-Direktive "ValidateRequest". Ist dieser Wert auf "true" gesetzt, werden alle Eingaben, die "<a-z", "<!", oder "&#" enthalten abgewiesen und mit einer "HttpRequestValidationException" beantwortet.

Besser eignet sich hier vielleicht die Verwendung der Microsoft AntiXss Bibliothek, die zum kostenlosen Download bei Microsoft bereitsteht. Mit dieser Bibliothek lässt sich ein Whitelisting bestimmter HTML / XML Tags realisieren (bsp. <b>..</b> für Fettdruck ist erlaubt).

Erwähnenswert ist auch das von Herrn Baier angesprochene "turkish I" Problem. Stringvergleiche auf bestimmte Werte müssen nicht zwangsläufig zum richtigen Ergebnis führen. So ist in der Darstellung ein "i" beim englischen, deutschen und türkischen Zeichensatz optisch das selbe Zeichen, die Repräsentation im Speicher beim türkischen Zeichensatz ist jedoch verschieden und würde bei einem Vergleich fehlschlagen.

Zum Schluss möchte ich noch das Tool "Microsoft Fiddler" erwähnen. Dieses Tool ist ein Http Debugging Proxy und eignet sich prima zum Nachverfolgen und Manipulieren von Http Requests. Herr Baier stellte dieses Tool im Zusammenhang von Manipulation von Postback Daten vor. Um eine Manipulation der Postback Daten und Viewstate Zuständen zu erschweren kann die Seitendirektive "EnableEventValidation=true" definiert werden. In seinem Beispiel wurde das Event eines unsichtbaren Buttons ausgelöst und ausgewertet. Ist die o.g. Seitendirektive jedoch aktiv reagiert ASP.NET 2.0 nur noch auf zum Abrufzeitpunkt sichtbare Controls. Bei eigenen Controls muss für dieses Feature eine entsprechende Funktion implementiert werden.

Zu guter Letzt noch eine Seitendirektive: "ClientTarget='downlevel'". Mit dieser (undokumentierten) Anweisung lässt sich die Verarbeitung einer ASP.NET Seite bei deaktiviertem JavaScript simulieren. Kann auch mal praktisch sein...

Die größten Schnitzer zum Thema Sicherheit sind im Übrigen unter http://www.owasp.org zu finden.

ASP.NET AJAX

andreas.mersch@gmx.de (andreas mersch) — Fri, 19 Jan 2007 06:37:27 GMT

AJAX... Was ist das? AJAX steht für Asynchronous JavaScript and XML und beschreibt eine Technik, Inhalte einer Webseite je nach Kontext nachzuladen, ohne die Seite im Ganzen zu aktualisieren. Dr. Schwichtenberg zeigte dies am Beispiel einer Demowebsite für Flugauskünfte und Flugbuchungen. Hierbei wurde nach einer Suchanfrage lediglich der Bereich des Suchergebnisses nachgeladen.

Ich habe bereits ähnliches programmiert, jedoch ohne die Verwendung der Michrosoft ASP.NET AJAX (früher Codename "Atlas") Erweiterung - s. http://www.fdp-bottrop.de

Die Beispiele aus dem Webcast hat Dr. Schwichtenberg auf seiner Homepage unter http://www.IT-Visions.de/WWWings zum Download bereitgestellt. Zu laden ist das Paket für .NET 3.0, da dieses die AJAX Komponenten enthält. In seinem Vortrag unterschied Schwichtenberg zwischen AJAX im engeren und AJAX im weiteren Sinne. AJAX im engeren Sinne ist nach seiner Aussage alles, was unmittelbar mit der Webseite und den asynchronen Requests zurück zum Server zusammen hängt. AJAX im weiteren Sinne hingegen sind Erweiterungen rund um das Thema AJAX, wie clientseitige Control-Bibliotheken. So hat auch Michrosoft auf der Website http://ajax.asp.net neben der ASP.NET AJAX Komponente auch eine Sammlung mit etwa 30 Client-Controls zum Download bereitgestellt (s. ASP.NET AJAX Control Toolkit). Auf der Website http://www.ajaxian.com hingegen findet sich bereits eine Liste von über 260 AJAX Bibliotheken für die unterschiedlichsten Plattformen.

AJAX verwendet die jeweilige Browser Implementierung des XmlHttpRequest Objektes. In den Browsern Firefox, Safari u.ä. ist dieses Objekt Bestandteil der JavaScript Engine. Im Internet Explorer bis Version 6 einschließlich wird das XmlHttpRequest Objekt über eine ActiveX Komponente realisiert. Zu beachten ist jedoch bei allen Browsern, dass die jeweilige Implementierung unterschiedlich sein kann. Hier ist also gründliches Testen erforderlich.

Bevor man sein eigenes AJAX Projekt mit ASP.NET 2.0 starten kann, müssen die AJAX Komponenten von der Website http://ajax.asp.net geladen und installiert werden. Anschließend kann im Visual Studio 2005 ein neues Webprojekt gestartet oder ein bestehendes Projekt mit AJAX Komponenten erweitert werden. Damit eine Seite AJAX Funktionalitäten besitzt muss zunächst aus der Toolbox das Script Manager Element auf der Seite platziert werden. Dieses Element erzeugt zur Laufzeit die notwendigen JavaScript Codeblöcke. Danach ist das Update Panel Element in der Seite zu verwenden und alle übrigen ASP.NET Controls, die innerhalb eines AJAX Requests verwendet werden sollen dort hinein zu ziehen. Auf diese Art und Weise können einfache Datenbindungen und Datenaktualisierungen mit wenigen Mausklicks realisiert werden.

Für erweiterte Funkionalitäten müssen eigene Webservices erstellt werden. Wichtig hierbei ist, das es sich bei diesen Webservices um JSON Webservices und nicht um klassische SOAP Webservices handelt. Die Abkürzung JSON steht für JavaScript Object Notation und ist eine auf AJAX optimierte Webservice Variante. Ein solcher Webservice kann einfach durch das Class Attribute

[System.Web.Script.Services.ScriptService()]

über der Klassendeklaration erstellt werden. Anschließend muss im oben bereits genannten Script Manager ein Verweis auf diesen Webservice erstellt werden. Für eine detaillierte Beschreibung der Vorgehensweise empfehle ich jedoch die Folien des Vortrages und die Beispiele von Dr. Schwichtenberg.

Der nächste Webcast zu diesem Thema findet am 6.2., der dritte Teil am 8.2. statt.

Security mit ASP.NET 2.0

andreas.mersch@gmx.de (andreas mersch) — Thu, 18 Jan 2007 07:35:32 GMT

Gestern, 17.01.2007, habe ich an einem Webcast von Dominick Baier (http://www.leastprivilege.com) zum Thema "Security mit ASP.NET 2.0" teilgenommen. Dieser Webcast ist Teil einer Serie und der Schwerpunkt der gestrigen Veranstaltung war "Authentifizierung und Autorisierung". Für ASP.NET Entwickler, die schon mit ASP.NET 1.1 gearbeitet haben, keine großen neuen Erkenntnisse. Einige Kleinigkeiten möchte ich dennoch als Ergebnisse und als Gedankenstütze hier festhalten:

Die Sicherheitsmechanismen von ASP.NET schützen nur Webinhalte, die auch von ASP.NET verwaltet werden. Statische Inhalte wie HTML Dateien, Grafiken oder Dokumente werden standardmäßig vom IIS direkt ausgeliefert. Folglich fallen diese Dateitypen nicht unter die Sicherheitsmechanismen von ASP.NET.

Sollen diese Dateien dennoch geschützt werden, müssen im IIS entsprechende Mappings (Wildcard-Mapping in Windows Server 2003) konfiguriert werden. Hierbei kann es dann aber Einbußen in der Performance geben.
ASP.NET verwendet verschiedene Authorization Provider (je nach Bedarf), die als Module in der Verarbeitungs-Pipeline registriert sind. Zu allen diesen Providern ist der Quellcode bei Microsoft erhältlich: http://download.microsoft.com/download/a/b/3/ab3c284b-dc9a-473d-b7e3-33bacfcc8e98/ProviderToolkitSamples.msi
Forms Authentication kann über Applikationsgrenzen (z.B. für zwei getrennte Webapplikationen) auf dem gleichen Server verwendet werden (-> SSO). In diesem Fall muss bei allen Applikationen in der web.config ein identischer <machineKey> Tag vorhanden sein.
Mit den neuen Membership Providern von ASP.NET 2.0 existieren nun einheitliche Schnittstellen für Authentifizierungsmechsnismen, so dass diese ohne Änderung des Quellcodes austauschbar sind. Standardcontrols, wie das neue asp:Login Control verwenden den in der web.config konfigurieren Membership Provider.

Soweit fürs Erste. Am 29.1.2007 hält Dominick Baier den zweiten Teil dieser Serie. Bis dahin...