Eric Lee
Die Session beginnt wie die letzten VS Session. Eine Übersicht und Erklärung, wieso es verschiedene Studios gibt und wie VS aufgebaut ist. (Siehe Bild bei der vorangenegnen Sessions)
Hingegen ist der Fokus dieser Session nun der Developer. (und ein kleiner Teil der des Testers)
Es geht ja darum, robuste und sichere Software zu schreiben. Eric zeigt einen Geschichltichen Hintergrund der bekanntesten Software "Failures" und Viruses etc. Danach erklärt er zuerst, was eigentlich ein Buffer Overflow ist und wie diese ausgenutzt werdenkönnen. Andere "Pitfalls" sind Memory Leaks und SQL Injection.Memory Leaks sind mit .net eigentlich Vergangeheit. Was aber häufig vorkommt im .net sind Resource Leaks (z.b. File Handle nicht freigegeben).
In der Demo wird gezeigt, wie man Code Analysis macht...danach zeigt er das Beispiel einer SQL Injection. Er hat eine Webseite, wo man nach Produkten suchen kann. Als such String gibt er nun ein % ein, und eine ASP Exception kommt. Nun nimmt er die Fehelermeldung und zeigt, wie man hier bereits Informationen bekommt. Nun gibt er im Such - String eine komplette SQL Query ein wo er ein UNION macht auf den Customer Table und Custermer Details Table. Nun ist er in der Lage, nur durch die Eingabe des Querys anstelle des Suchbegriffs, die Kunden dieser Website inkl. den Credit Card Information anzuzeigen. Im nächsten Schritt macht er sogar einen Update und fügt einen Customer eine neue Credit Card hinzu. Es gäbe 1000'de von Websites, welche so "verwundbar" sind. Danach folgt natürlich die Anweisung bzw. Demo wie man den Code sicher macht...und wie immer ist dies ja sooo einfach ;-)
Als Beispiel für einen Fatalen Buffer Overflow wird der Ariane 5 Absturz von 1996 genannt. Danach zeigt Eric wieder einmal, wie man die Unit Tests generiert. Ist schon cool...Code Coverage markiert wieder alles grün im Code, was durch Unit Tests erfolgreich abgedeckt wird und getestet wurde. Alles was rot ist, muss nun genau angeschaut werden. Weshalb wurde es nicht getestet, bzw. weshalb war der Test nicht erfolgreich.
Nun kommt er nochmals auf den Performance Wizard zu sprechen. Zeigt, das Unmengen von Daten gesammelt und ausgewertet werden können. Dazu kommt er auch auf die Midlife Crysis zu sprechen. Ja, die .net Memory Midlife Crysis. Das.Net Framework hat 3 "Speicherarten", frisch alloziertes, aktuller und benutzter Speicher und einen Bereich der alten Speicher beinhaltet. Dazwischen wird das Memory dynamisch hin und her geschoben. Dabei ist der aktuelle Teil der Resourcen der Intensivste. Nun kann man mit dem Performance Wizard bestimmen, wie lange es dauert, bis etwas vom aktuelllen Speicher in den alten Speicher geschoben wird.
Hauptproblem bei vielen .net Aplikationn, welche Performance Schwierigkeiten haben sei, das zu viel und zu lang aktuller Speicher benutzt wird. Deshalb .net Memory Midlife Crysis....
Keine Kommentare:
Kommentar veröffentlichen