Ich habe seit Ende 2016, auf Basis von Informationen, die hauptsächlich von Declan O’Riordan stammen, angenommen, die Grundidee der Interactive Application Security Testing Technik beruhe auf dem Metadata Facility Framework, welches unter dem JSR 175 in Java eingeführt wurde. Matthias Rohr hielt am 23. Oktober 2019 einen Vortrag im Rahmen des OWASP Stammtisches in Hamburg und war über meine Nachfrage, warum er dies unerwähnt gelassen habe, sehr verwundert, da er nur die Instrumentierung des Codes als Schlüssel zum Erfolg darstellte, und so habe ich Jeff Williams, Gründer und (Mit-) Erfinder der Technik und eines der IAST-Tools, direkt via LinkedIn angefragt und die korrigierende Aussage am 27. November 2019 bekommen:
„Hi Jogi – we don’t use JSR175. We use standard Java Instrumentation API. That’s the breakthrough innovation that enabled Contrast to exist. We use all our own sensors and analysis engine on top of that API. We had to invent different instrumentation techniques for .NET, .NET core, Node.js, Ruby and Python.“
Jeff Williams, Co-Founder and CTO at Contrast
Nun, an den Ergebnissen der Technik ist in meinen Präsentationen nichts falsch, da ich sie ja auch selber durchgeführt habe, nur ist es eben etwas anderes, wenn man durch Code-Instrumentierung Aktionen auslöst (Dtrace, den Tracer von Sun, den ich immer als Vergleich auf Betriebsystemebene herangezogen habe, macht dieses nämlich auch!) oder „mitlaufende“ Metadaten analysiert werden. Der Code wird zur Laufzeit in dem Application Container „angefasst“ (verändert) während das bspw. bei Ausnutzung der JSR 175 nicht unbedingt notwendig gewesen wäre, da die Metadaten ja „mitlaufen“.
Danke an Matthias Rohr für den Hinweis, der mich dazu nötigte meine unreflektierte Übernahme einer Aussage nun zu korrigieren. Ich werde die Dokumente, sofern sie unter meiner Kontrolle sind, entsprechend anpassen.