In meinen ersten Beitrag habe ich ja schon über die interessanten Nebeneffekte von Sharepoint berichtet. Auch diese Woche hatte ich wieder Nebeneffekte, die schon arg Grenzwertig waren. Eine Technolgie, die sich als Zeitfresser entpuppte war Linq to Sharepoint.

Meine Best Practice - Empfehlung: Nicht einsetzen für Business-Anwendungen, die ihren Namen gerecht werden wollen und auch einiges an Daten zu verwalten haben.

Details und Workaround-Frickelein werden folgen.

Zurzeit bin ich immer noch in der dritten Phase und ich glaube, dass es nach dieser Phase drei mögliche Wege gibt, die von Entwicklern eingeschlagen werden. Aktuell gehe ich tiefer in die Materie zu Workflows ein. Seit der PDC 2008 habe ich mich dazu entschieden, Microsoft-Technologien nur noch systematisch anzugehen, da der pragmatische Weg in meinen Augen unkontrollierbar geworden ist. Linq to Sharepoint hat mich zusätzlich darin bestärkt, hier habe ich zu sehr auf die Aussagen von Sharepoint MVP´s vertraut. Kommt nicht wieder vor.

Im Bereich der Workflows habe ich die möglichen Ansetze und Varianten im nachfolgenden Mind Map festgehalten. Hier muss ich zugeben, dass mich dieser Bereich von Sharepoint sehr interessiert.  

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.

Wie man sieht ist der "unsichere" IE in diesem Fall besser als sein Ruf und schützt den Anwender.

Aus der Skriptmeldung wird ersichtlich, es handelt sich um die Seite der SBB. Also liebe SBB, bevor eure Java-Entwicklungsabteilung ein neues Framework bauen will, um dieses Problem zu lösen. Es gibt da eine Organisation die macht sich über so etwas wirklcih Gedanken.

Die Seite mit dem Namen The Open Web Application Security Project hat sogar eine Top Ten, die im Schnitt alle 3 Jahre aktualisiert wird. Würden eure Entwickler diese Top Ten kennen, dann wäre dieser Bug nicht passiert.

Dann gibt es noch den SDL ursprünglich von Microsoft, einige Java-Entwickler müssen wohl hier mal über ihren Schatten springen und sich damit auseinander setzen. Vielleicht ist die diesjährige Jazoon ein guter Anfang. ;-)

Anderseits ist die SBB ja nicht alleine mit diesem Problem, es gibt im Projektgeschäft immer so viele Ausreden, um das Thema Secure Coding zu blocken und als Einzelner in einem Team kann man keine ausreichende Sicherheit erreichen. :-(

In dieser Hinsicht wäre die Auseinandersetzung mit OWASP und SDL schon ein sehr grosser Fortschritt, da es solche Anfänger-Fehler verhindern hilft.

Ob der IE 9 nun besser ist oder nicht, darüber kann man diskutieren. Bei diesem Szenario hat er zum Schutz des Anwenders beigetragen.

Und für den Fall, dass die Java-Entwickler nicht für die Plattform zuständig sind, ein Blick auf OWASP und den SDL schadet trotzdem nicht. ;-)

Ich habe mal wieder meine alten Aufzeichnungen überfolgen und dabei folgendes Mindmap im Bereich der Prüf-/Testarten gesichtet. ;-) Dieses hat jetzt schon mind. 5 Jahre auf den Buckel.

Interessant an dem Thema ist der Unterschied von Theorie und Praxis. Im Bereich der statischen Prüfverfahren konnte ich so wieder einiges lernen. ;-)

Im letzten Randprojekt lief es folgendermassen ab:

Der Review wurde an eine Firma im Auftrag gegeben, die faktisch von Schulung, Training, Eigene Projekte, Unterstützung von Firmen alles macht. Sollte ich nochmal so eine Situation erleben, werde ich mich vorher genauer erkundigen, ob die Methoden religiös praktiziert werden.

Bleiben wir mal bei der Theorie. Die Herausforderung, das "Team" war interdisziplinär. Laut Lehrbuch würde man das Team aufbauen. Der Teambildungsprozess mit den typischen Phasen Forming, Storming, Norming und Performing wurde schon mal nicht durchlaufen. Zugegeben, man kann nicht immer nach Lehrbuch arbeiten, da häufig auch zu viel Ideologie im Spiel ist, aber die Grundprinzipien sollten in einem Projekt erkennbar sein.

Die Folgen davon:

• Es gab keine intensiven Beziehungen zwischen den Projektbeteiligten. Versuche wurden mit der Begründung Single Point of Contact an den wichtigen Schnittstellen abgewürgt.
• Ein Gemeinschaftsgeist für das Projekt bestand auch nicht. Die Folge hiervon, es kam weder ein Team noch eine Arbeitsgruppe zustande, eher ein Gegeneinander.

Dieser Punkt liegt eigentlich in der Verantwortung der Projektleitung und zeigt das Theorie und Praxis zwei Welten darstellen können.

Wie sah nun die Theorie beim Review aus:

Abschliessend kann man sagen, das in jeden Witz auch ein wenig Wahrheit liegt:

Theorie ist, wenn man alles weiss und nichts klappt. Praxis ist, wenn alles funktioniert und keiner weiss warum. In diesem Projekt waren Theorie und Praxis vereint, nichts funktionierte und keiner wusste warum. ;-)

Das Projekt hat aber auch ein Vorteil: Nachdem ich dieses "Chaos" erlebte, schätze ich die langjährigen Geschäftspartner noch mehr. ;-)

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"/>
---