Wenige Tage ist es her, da war die MSDN Website für einige Stunden nicht erreichbar. Dir Ursache mag ein technischer Defekt gewesen sein oder aber auch ein Hack. Jedenfalls sind einige interessante Infos zu Tage getreten die ich nicht vorenthalten möchte.
Nach Aufruf der Site msdn.microsoft.com kam folgender Screen.
Hier verbirgt sich bereits ein großes Sicherheitsproblem. Der User sieht Codefragment und kommt (so wie ich) auf die Idee mal weiter zu forschen. Dies lässt sich aber unterbinden indem man die Datei 500-100.asp umprogrammiert und/oder im IIS in den Eigenschaften-Basisverzeichnis-Konfiguration-Debuggen der Anwendung die Skriptfehlermeldungen unterbindet. Dabei wird einfach nur ein Standardtext an den Client gesandt. Die Programmierer bzw. Administratoren dieser Seite haben dies vernachlässigt.
Die Strafe ist, das ich nun weis, das es ein Inlcude File gibt. Obwohl weit verbreitet, ist dies die nächste Sünde. Include Files können direkt über den Browser geöffnet werden. So sieht man welcher Code dort ausgeführt wird. Konkret sind das Fragmente wie
function transData(oXML, iContentID){ sContent = ""; sWhere = buildPath(iContentID, true); sWhere = sWhere.substr(0, sWhere.lastIndexOf(".")) + ".tmp" if(!bFeedDirty){ try{ var fso = Server.CreateObject("Scripting.FileSystemObject"); var a = fso.OpenTextFile(sWhere); sContent = a.ReadAll(); a.Close(); }catch(e){ } } |
Damit hat man schon ein bisschen was in der Hand um weiter zu machen.
Besonders hart finde ich folgende Stelle:
var oRS = Server.CreateObject("ADODB.Recordset"); var sSQL = "exec dbo.GetContent"; if(sID > 100000000)return null; if (sGUID) { sSQL += " @ContentId = '{" + sGUID + "}'"; } if (sID){ sSQL += " @LocalId = " + sID; } oRS.Open( sSQL, sConnect, 0);
|
Sconnet ist die Variable für den Connection String. Hier haben aber die Entwickler mitgedacht und die Variable nicht in der Seite gesetzt. So wären die Zugangsdaten zum SQL Server offen. Dieses mal haben Sie auch mit einem Include File gearbeitet diesem aber die Extension ASP gegeben. Damit wird beim Aufruf dieses vom IIS interpretiert und nicht direkt zum Browser geschickt.
<!-- #include virtual="/library/shared/xmlcache/inc/locals.asp" --> |
Trotzdem habe ich das Include File einfach mal aufgerufen und auch hier haben sich die Entwickler wieder einen Fehler erlaubt. So wie es aussieht, ist der ASP Code in dieser Seite nicht in Script Blöcke bzw. <%%> eingeschlossen. So wird wieder ein Teil des Codes im Browser angezeigt.
Ganz Nebenbei haben wir dabei jede Menge über die verwendeten Techniken und Verzeichnisse gelernt.
Ausdrücklich möchte ich mich distanzieren vom Hacken von Websites. Vielmehr möchte ich aufmerksam machen, das es viele Dinge zu beachten gibt. Speziell im Fehlerfall sind plötzlich Tür und Tor geöffnet ( siehe Code Red Worm).
Dank möchte ich noch an Christoph Wille ausprechen, der meine Tipps auch gleich in die Tat umgesetzt hat und auf devtrain diesen Artikel ins Nirwana befördert hat. Ich möchte auch hier nicht verheimlichen wie es funktioniert. Durch ausspähen des Quellcodes hat er einen Link extrahiert, der den Artikel löscht.
<script language="javascript"> function delnews(sANr) { var byesno = confirm("Wollen Sie diesen Artikel wirklich loeschen?"); if(byesno) location.href = "news.asp?del=1&artnr=509" ; } </script> |
Wenn jemand eine weitere Lücke entdeckt.... Bitte nicht ausprobieren- DANKE!