Zur Zeit wird gefiltert nach: Sicherheit
Filter zurücksetzen

Cloud Security aus der Marketingperspektive

Ich habe mir die 3 teilige Webcastserie zu Sicherheitsgedanken in der Cloud angesehen und daraus ein grobes Mindmap erstellt. Eins vorweg, diese Serie reicht nicht aus, um sich mit der Cloud-Sicherheit auseinanderzusetzen. Ich werde mich jetzt auf die Suche nach Literatur von Gray-Hats machen, um einen objektiveren Überblick zu erhalten. ;-) Gut ich gebe es zu, die habe ich schon längst, aber noch nicht vollständig gelesen.

Gut an der Serie ist, dass sie die 3 Bereiche Kunde, Applikation und Cloud im Bezug auf die Sicherheit betrachtet. Weniger gelungen finde ich allerdings die Sicherheitsaspekte des Cloud Providers, da wird im Bezug auf Azure mit Fachchinesisch um sich geworfen, damit lässt sich das Management nur schwer überzeugen.

Der eigentliche Schwerpunkt liegt dann auch auf der Anwendungssicherheit und diese vermittelt einen soliden Eindruck. Nur sollten diese Punkte bei der Entwicklung von Webanwendungen jeden Entwickler bekannt sein, leider ist dies nicht so. In der Folge kann hier die Gefahr eines Ping Pong's zwischen Applikations- und Cloud-Provider bestehen.

In dieser Hinsicht freue ich mich auf den Tag, an dem bei Gesprächen unter Entwicklern Begriffe wie SDL, CIA, AAA usw. zum Grundwortschatz gehören und nicht mit einem "Hää" beantwortet werden. Bei SOLID funktioniert es ja auch.

Eigener Request Validator in ASP.NET 4.0

Per Zufall bin ich auf eine neue Klasse in .NET 4.0 gestossen. Im März habe ich mir noch Gedanken gemacht, wie die Request Validation abgeschaltet werden kann – gut der Lösungsweg ist in der Fehlermeldung beschrieben – aber es gibt in .NET 4.0 eine neue Klasse mit dem Namen RequestValidator.

Das Problem mit der bisherigen Request Validation, es ist Best Practice diese zu deaktivieren. Unter anderem auch, weil diese bei Eingaben wie a <b bereits eine Ausnahme wirft und den Bearbeitungsprozess beendet. Zudem ist es gelegentlich eine ausdrückliche Anforderung, das einfache HTML-Elemente erfasst werden können.

Abbildung 1 Eine ungefährliche gefährliche Anfrage ;-)
Abbildung 1
Abbildung 2 Abbruch der Anwendung bei einfachen HTML
Abbildung 2

Ab ASP.NET 4.0 besteht nun die Möglichkeit, in diesen Validierungsprozess einzugreifen. Mithilfe der AntiXSS-Library kann so bspw. auf sicheres HTML geprüft werden, dieses zu erlauben und alles andere zu verwerfen und den Verarbeitungsprozess zu beenden. Der Vorteil, die Verarbeitung wird nur noch abgebrochen, wenn die Eingabe HTML enthält, das nicht durch die Prüfung der AntiXSS-Komponente kommt.

Dazu muss von der Klasse RequestValidator abgeleitet und die Methode IsValidRequestString überschreiben werden.

C#
namespace RequestValidation
{
  using System;
  using System.Web;
  using System.Web.Util;
  using Microsoft.Security.Application;

  public class SafeHtmlRequestValidator : RequestValidator
  {
    protected override bool IsValidRequestString(System.Web.HttpContext context, 
        string value, 
        RequestValidationSource requestValidationSource, 
        string collectionKey, 
        out int validationFailureIndex)
    {
      validationFailureIndex = 0;

      if (requestValidationSource == RequestValidationSource.Form)
      {
        if (IsSafeHtmlString(value))
        {
          return true;
        }
      }

      return base.IsValidRequestString(context, 
                 value, 
                 requestValidationSource, 
                 collectionKey, 
                 out validationFailureIndex);
    }

    private static bool IsSafeHtmlString(string value)
    {
      string value1 = HttpUtility.HtmlDecode(AntiXss.GetSafeHtmlFragment(value));
      return value1 == value;
    }
  }
}

Anschliessend wird dieser in der web.config mit Hilfe des httpRuntime-Elements registriert.

web.config
<system.web>
  <httpRuntime requestValidationType="RequestValidation.SafeHtmlRequestValidator"/>
---

Werden die oberen Eingaben wiederholt, so wird der Verarbeitungsprozess nicht mehr beendet. Lediglich wenn Code mit Scriptinhalten eingegeben wird, erzeugt der angepasste Validator einen Fehler und loggt diesen zusätzlich im Event-Log.

Abbildung 3 Eingabe a <b erzeugt keinen Abbruch mehr
Abbildung 3
Abbildung 4 Einfaches HTML wird akzeptiert
Abbildung 4
Abbildung 5 HTML mit Script <img src="" onerror="alert('Test')" /> wird abgebrochen
Abbildung 5
 

Wichtig dabei ist zu beachten, dass diese Variante nicht als alleiniges Sicherheitsmerkmal betrachtet werden darf. Der Angreifer ist immer im Vorteil, er wird die eine oder andere Möglichkeit finden Code einzuschleussen. Bei den frühren ASP.NET-Versionen war das mit der Out of the Box Request Validation nicht anders.

Hier habe ich einen Mittelweg zwischen User Experience und Sicherheit. Encoding von Eingaben müssen trotzdem weiterverwendet werden. Versuche sind wie bereits erwähnt im Event-Log ersichtlich, ein Vorteil zu bisherigen Best Practice: Abschlaten.

Translate this page

Kategorien