Okay, dann fange ich jetzt mit dem Vortrag einfach an. Die Technik haben wir, glaube ich, im Griff. Also ich rede heute über die Sicherheit von Ruby on Rails. Wie programmiert man eigentlich sicher?

Oder vielmehr, wie programmiert man unsicher? Ich muss noch ein bisschen mit der Technik üben. So, ich bin Mario Manow. Hier ist ein Bild von mir, wie ich auf der Froskone einen Vortrag halte. Und ich freue mich also wieder auf der Froskone einen Vortrag zu halten. Ich bin Softwareentwickler, ich habe so ein bisschen so einen Hintergrund in der IT-Sicherheit und ich arbeite bei I22

und programmiere da also auch tatsächlich Ruby. Es ist also nicht so, dass ich jetzt hier irgendwie über die Sprache blästern wollte oder sowas, sondern ich bin immer noch überzeugter Ruby-Benutzer. Und der Vortrag ist jetzt auch kein Ausflug in vergleichende Programmierwissenschaften oder sowas, sondern ich glaube, die Software-Systeme, die wir heute einsetzen, haben halt alle Probleme

und da muss man einfach schauen, wie man damit umgeht. Ich werde im ersten Teil über das Verfahren reden. Ich habe ja eine Ankündigung geschrieben, dass ich ungefähr 30.000 Git-Repositoris gescannt habe auf Sicherheitslücken. Das werde ich kurz erläutern. Dann werde ich so ein bisschen erzählen,

was für Probleme haben wir eigentlich in den Frameworks mit Schwerpunkt auf 2013, 2014 und dann einzelne Schwachstellen in konkreten Anwendungen zeigen, die ich gefunden habe, hauptsächlich in der Analyse mit Breakman. Das erkläre ich aber gleich alles noch ein bisschen im Detail. Ausgangspunkt war für mich, dass wir in der Firma eine Sicherheitsüberprüfung von ungefähr

40 Rails-Anwendungen gemacht haben und das sind also die Anwendungen der letzten drei Jahre. Der Vortrag hier arrangiert in der didaktischen Qualität hinter Stablerfahrer Klaus zurückbleiben. Wer dieses Video kennt, ja die meisten wahrscheinlich, das liegt einfach daran,

dass ich nur zeige, was schlecht ist und ich zeige euch nicht, wie man es richtig macht. Stablerfahrer Klaus zeigt auch, wie man es richtig macht und das ist vielleicht auch die wertvollere Information. Also hier gibt es jetzt nur die Unfälle zu sehen. Erstmal aber zum Verfahren. Also grundsätzlich kann man Software auf verschiedenen Ebenen testen,

wenn man jetzt mal so Tests auf Deployments außen vor lässt. Also alles, was wir so bei Deployten-Apps, da testen wir ja oft dann die Netzwerksicherheit, die Sicherheit des Hosts, ist das Betriebssystem aktuell, weil wenn wir uns jetzt auf die Software beschränken, gibt es hier unten so als Baseline meiner Ansicht nach automatische statische Code-Analyse,

weil es eine rein einfache Maßnahme ist, die einem eine Liste von Ergebnissen zurückgibt, die auch sehr schnell läuft, also im Sekundenbereich. Dann gibt es manuelle Code-Security-Reviews, die werden natürlich einfacher, umso häufiger man sie macht am Produkt. Also so ein initiales Code-Review oder von einer neuen Software ist natürlich jetzt auch sehr aufwendig

und eignet sich eigentlich auch erst, wenn man so einen bestimmten Sicherheitslevel erreicht hat, also alle Updates eingespielt zum Beispiel. Dann gibt es das, was man oft macht mit so Application-Security-Scannern, da gibt es ja einige kommerzielle, ich nenne hier immer OWESP-ZAP, ansonsten sind PAROS und so weiter auch noch recht bekannt.

Die heißen automatisiert, sind es aber eigentlich nicht wirklich, also da ist ein gewisses Setup notwendig, man muss zum Beispiel beibringen, wo ist der Lockout-Knopf, damit er den beim Scannen nicht immer drückt, muss ihm sagen, wie kann man sich eigentlich einloggen, damit man nicht nur die Startseite scannet und man muss die Applikation vor allen Dingen installiert haben,

was ja dann teilweise schon nicht ganz real ist. Also bis man so eine Ruby-Applikation mal installiert hat, bekomme ich zumindest bei den Open Source-Projekten, wo ich dran mitarbeite, ziemlich viele Nachfragen, wie das funktioniert. Und hier kriegt man auch so ein Assessment zurück, also das ist quasi eine lange Liste von Fehlern, die kann man durcharbeiten

und wenn man das alles, wenn man meint, man steht da gut da, kann man tatsächlich so einen manuellen Application-Test machen, da braucht man dann auch meistens Fachleute für. Diese Penetrationstests sind oft angelegt als zielorientierte Übungen, also es geht da gar nicht so darum, eine Liste von Schwachstellen zu bekommen, sondern hier will man auf die Datenbank durchdringen

oder die Kundendaten stehlen oder eine Shell bekommen oder sowas. Ja, also ich habe mich für die automatische Code-Analyse entschieden, weil es geht halt um knapp 32.000 Repositories. Das ist im Grunde genommen Whitebox-Ansatz, auch wenn jetzt hier keine Dokumentation vorlag,

ich brauche die Anwendungen nicht installieren und die Geschwindigkeit ist sehr hoch, dafür haben wir recht viele false positives. Bei manchen Tests mehr als bei anderen Fehlertypen, das sehen wir aber gleich noch. Ja, und es werden natürlich auch nicht alle Fehlertypen gefunden,

je nachdem welche Überprüfung man da wählt, findet man auch so ein bisschen andere Fehlertypen. Vorteil hat es hier, dass die Code-Zeilen, in denen der Fehler vermutet wird vom Scanner, auch direkt aufgeführt werden. Ich habe das dann gelöst, also mit so einem Klick, und dann habe ich direkt auf GitHub die Zeile gesehen, die da angenägelt wurden. Ich habe im Wesentlichen Brakeman und Dawn-Scanner benutzt,

die ich auch beide sehr gut finde und auch beide empfehlen würde, wobei Brakeman schon überlegen ist, auch wenn er nur Rails scannen kann und Rails-Engines, während Dawn in der Lage ist, Ruby zu scannen und dann natürlich auch Sinatra und so weiter unterstützt. Ja, beide verwenden internen Ruby-Parser, Ruby-Parser, der an Ruby geschrieben wurde,

und können also auf dem Syntax-Tree suchen. Und da kam also dann so die Idee, wie steht es eigentlich derzeit um die Sicherheit von Rails? Man könnte doch mal auf GitHub gucken, wie sieht es denn aus mit diesen Sicherheitslücken aus 2013, als Ruby als Rails so negativ in der Presse war?

Wie sind diese Frameworks da? Was gibt es da für Exploits? Ja, was passiert, wenn die Updates fehlen? Und konkret in den Anwendungen, die dann mit Rails geschrieben wurden, was haben wir da eigentlich für Schwächen? Was haben wir da für Probleme? Also habe ich mir gedacht, ja, dann scannen wir jetzt mal GitHub. So, am besten das ganze GitHub.

Es stellt sich heraus, GitHub hat mehr als 40 Millionen Repositories. Über die GitHub API kann ich 60 Anfragen pro Stunde machen. Wenn ich mich da einlogge, erhöht sich das auf 5.000. Das war so ungefähr, ich sage mal, im März. Und es war klar, bis zur Frostcon 10 wird man damit nicht fertig. Also, wie findet man jetzt nur Rails-Repositories auf GitHub?

Da habe ich also ein sehr weites Netz ausgeworfen. Hier habe ich mal so eine Ölförderplattform als Metapher hier gewählt. Also hier unten, da will man irgendwie ankommen. 40 Millionen GitHub-Repositories, also habe ich mich mit 6 Millionen Pushes auf sogenannte Ruby-Repositories beschäftigt.

Davon sind 711.000 GitHub URLs übergeblieben. Davon habe ich 241.000 überprüft über die GitHub API, ob es sich um Rails handelt. Damit habe ich 61.000 Rails-Repositories gefunden und davon habe ich dann die Hälfte gescannt und in einer Analyse habe ich dann nochmal 6.000 rausgeworfen.

Im Detail habe ich also hier Google BigQuery benutzt und ungefähr 3,5 Terabyte von Queries abgesetzt. So bin ich auf die 711.000 gekommen. Das war zum Glück eine freie Promo von Google, fand ich sehr nett.

Sonst hätte ich 7 Cent dafür gezahlt. Das ist weniger als eine SMS. Finde ich eigentlich ein ganz guter Tarif. Dann über die GitHub API mit 5.000 pro Stunde. Das ist ungefähr 3 Tage gelaufen. Dann habe ich die alle gedownloadet. Das waren nochmal so eineinhalb Tage. In der Analyse mit AAP-Project sind dann nachher die Sachen rausgeflogen.

Da gibt es gleich eine Folie. Das ist so ein SQL-Statement hier, wo ich 2013 und 2014 lediglich berücksichtige. Neuere Daten konnte ich nicht berücksichtigen, weil sich in dem Datensatz das Format geändert hat für 2015.

Da ist jetzt die Sprache nicht mehr drin. Also da konnte ich dann diese Einschränkung auf Ruby leider nicht mehr machen. Hier noch das Query, um dann nachher die repo-URL zu bekommen. Schließlich hatte ich 126 Rails-Versionen in meinen Datensätzen.

Das hat also alle Grafen total unmöglich gemacht. Also habe ich gesagt, ich nehme alles, wo mehr als 9 Apps die Version haben. Da sind 67 Rails-Versionen übergeblieben. Habe ich also gesagt, AAP-Project kann sowas berechnen. Der sagte 802 wäre gut. Da bleiben 17 Rails-Versionen über.

Damit kann man arbeiten. Und so komme ich dann auf meine 26.000 Repositories. Die aktuelle Version damals war 3.2.1, 3.2.1.20. Davon gab es nur 155 Apps. Hat mich überrascht. Ergibt sich aber so ein bisschen aus den untersuchten Daten, die sich gleich zeigt.

Wenn man jetzt noch mal kurz die Rails-Versionen sich anschaut, sieht man also hier schon so eine Verteilung. Es gibt so Versionen, die sind populärer. Die 3.2.3 sind die 4.0 besonders, 4.0.2. Warum das so ist, weiß ich nicht.

Aber alles in allem hatte ich schon den Eindruck, dass ich jetzt eine gute Aussage über die Grundgesamtheit machen kann bei 26.000 untersuchten Repositories. Außer man hat systematische Fehler in den Daten. Es könnte ja sein, z.B. das GitHub die Sprache Ruby nicht korrekt erkennt.

Und dann habe ich diese Repositories nicht gefunden. Es kann auch sein, dass die Scanner die Rails-Versionen nicht korrekt erkennen. Und dann stellt sich heraus, wenn man sich die Sachen genauer anguckt, dass da extrem viele Forks bei sind. Und das funktioniert so, dass die Leute auf GitHub forken und anschließend nie wieder aktualisieren. Also in diesen 26.000 Anwendungen ist dieselbe Anwendung

in unterschiedlichen Versionen mehrmals enthalten. Mit Modifikationen vom Forker. Und hätte man bestimmt machen können.

Aber dann hätte man noch mal anders untersuchen müssen. Also die Information hätte man wahrscheinlich vorher aus der GitHub API rausholen müssen, bevor ich da tiefer abgestiegen bin. Und wie groß die Auswirkungen davon sind, ist mir dann auch erst später im Lauf der Untersuchung aufgefallen. Das ist halt tatsächlich, wenn man sich dann anguckt,

was man so gescannt hat, stellt sich halt raus, die häufigste App ist Sample-App. Gefolgt von First-App und Demo-App. Pinterest ist One Month of Rails, OM Rail. Das ist das Pinterest. Das gibt es hier total oft.

Und dann sind hier noch so ein paar großartige Demo, Workshop, also ganz viel Code Academy. Und wir üben Rails programmieren. Also habe ich das mal bereinigt. Und es bleibt also immer noch Blog. Das ist häufig. Rails-Tutorial ist häufig. Also man sieht halt schon, was hier gescannt wurde,

sind jetzt nicht die großen bekannten Rails-Anwendungen. Tatsächlich habe ich das nochmal nachvollzogen. Es gibt Rails Open Source, so eine Webseite, die 32 große bekannte Rails-Projekte auflistet. Und wenn man die scannt, bekommt man auch ganz andere Ergebnisse. Die sind natürlich aktuell. Da findet man auch kaum noch, oder sagen wir mal, nicht mehr so einfach bekannte Sicherheitslücken.

Die sind offensichtlich besser gepflegt als dieser reiche Fundus an Fehlern, den man so oft gehabt findet. Was aber eigentlich für diesen Vortrag auch sehr gut ist, weil ich suche ja gerade diese Fehler. Also es geht ja gerade auch um 2013 und nicht um aktuelle Software.

Also Schwachstellen in Rails und in den Gems kurz im Überblick. Worüber reden wir hier eigentlich? Rails hat ja von Haus aus eine recht hohe Sicherheit, finde ich. Also zumindest wird es mit jeder Version besser. Wir haben Prepared Statements, um uns vor SQL-Injection zu schützen.

Wir haben Escaping in den Views, um Cross-Site-Scripting zu verhindern. Das ist seit Rails 3 auch per Default eingeschaltet. Und gegen diese Mars-Assignment-Lücken haben wir jetzt, glaube ich, mit Strong-Parameters auch seit Rails 4 einen recht wirkungsvollen Schutz.

Es gibt regelmäßige Security-Updates für Rails. Ich finde die auch sehr gut geschrieben und sehr umfangreich. Man kann da bis auf die Kotzeile oft nachverfolgen, wo der Fehler war. Ich finde den Umgang also vorbildlich mit Sicherheitslücken. Haus-Aussagen, also Rails hat eine sehr kurze Syntax. Man sieht viel auf einen Blick.

Und es gibt auch sehr viele Bibliotheken, die die Sachen hoffentlich richtig machen. Allerdings hat man natürlich auch die Risiken, dass man durch diese Konvention einfach mal so eine Auszeichnung vergisst. Und dann, wenn AuthorizeUser fehlt, dann fragt der Controller nicht nach einem Passwort. Das ist eine Zeile, die da zwischen Gutfall und Fehlerfall den Unterschied macht.

Wer InheritedBase-Controller schon mal gesehen hat, das sind dann irgendwie zwei Zeilen in so einer Klasse. Das ist dann eine komplette Westfull-ARP-Controller. Das ist eindrucksvoll. Eine angenehme Abkürzung, aber man übersieht schnell, welche Mächtigkeit dahinter steckt. ActiveRecord ist auch ein wunderschönes Pattern,

finde ich total gut, so direkt auf die Datenbank zuzugreifen. Aber es fehlt halt jede Indirektion, was dazu führt, dass natürlich auch irgendwie die Datenbankfelder direkt im View landen. Also es gibt ja keine Repositories, keine Layer dazwischen, dass irgendwie sagt, jeder User kriegt dabei diese oder jeden Felder nicht. Also das muss man dann selber besorgen.

Und in alten Rails-Versionen hatten wir halt diese unsicheren Defaults. Ich denke an Mass Assignment, das Strong-Parameter ist jetzt der dritte Ansatz, um das Problem in den Griff zu bekommen. Und man hat zu viele Bibliotheken. Also man hat schnell mehr als 100 Bibliotheken in einem Rails-Projekt. Das ist so ein bisschen manchmal, als würde man da versuchen,

so möglichst viele von zu sammeln in seiner Software. Es kann immer noch ein Jam dabei. Das Gegenteil will man auch nicht. Das ist das Not-Invented-Here-Syndrom. Das ist dieses, ich brauche kein Device, ich programmiere mir das mal eben selber. Was soll schiefgehen? Und also irgendwo dazwischen ist die goldene Mitte wahrscheinlich.

Ja, und hier betrachte ich jetzt sogenannte CVE-Einträge, also Common Vulnerabilities and Exposures. Das ist eine Liste von gemeldeten Sicherheitslücken. Also so ein Security Researcher kann so eine CVE-Nummer beantragen. Und wenn er dann seinen Release-Prozess von der Lücke durch hat, wird die veröffentlicht. Das ist also auch so ein Datenbankformat mit vorgegebenen Feldern.

Und ja, wenn man sich jetzt die CVEs nach Jahren anguckt, sieht man hier auch, dass das irgendwann sprungacht hochgeht. Also der blaue Balken hier 2010, das ist nicht so, dass Rails da sicher war, sondern mein Eindruck ist eher, dass es keinen Security Researcher gab, der sich die Mühe gemacht hat, das anzugucken.

Die haben natürlich auch nur begrenzte Zeit, stehen aber einer unendlichen Menge von Fehlern gegenüber. Das heißt also, man muss da auch wahrscheinlich so ein bisschen prioritisieren. Und da nimmt man dann natürlich auch so, also hier 2011 würde ich sagen, ist auf jeden Fall so ein Jahr, wo Rails an Popularität gewonnen hat. Ja, und seitdem genießt man hier auch regelmäßige Überprüfungen.

Problematisch bei den CVE-Anträgen ist, dass die oft mehrere Versionsnummern betreffen. Also hier mal so ein Auszug von CVE 2014 3483. Das sind also einige Versionen. Manchmal sind diese Listen fehlerhaft, weil sich natürlich jetzt niemand die Mühe macht,

das bei allen Versionen auch noch auszuprobieren. Ja, und dann kommt hinzu, dass die Version jetzt nicht unbedingt was darüber aussagt, wie alt das Rails ist. Also um so ein bisschen Überblick zu geben, Anfang 2013 hatten wir noch 3019.

Ja, dann gibt es hier 3213, ist ja so eine ganz beliebte Version. Hier kamen auch irgendwelche Sicherheitslücken raus. März 2013 und 402 ist dann Dezember 2013. 2014 sind wir dann schon bei 3217. Und dann, aber hier tut sich dann lange nichts, ja, bis 3211 im November.

Ja, wenn wir jetzt im Detail, würde ich jetzt so ein paar Lücken vorstellen, die ich interessant fand, also die möglichst große Auswirkungen auf schadhafte Applikationen mit Schwächen haben. Also hier zum Beispiel, wie kann man das überhaupt genießen?

Das Mars Assignment, von dem ich die ganze Zeit rede, hier mal als einfaches Beispiel immer. Wenn so ein Hash an ein Model übergeben wird, besteht halt die Gefahr, dass der User hier Parameter dazu schummelt, wie zum Beispiel die Rolle Admin, die er da nicht setzen sollte.

Und Mars Assignment Protection sagt dann halt auf dem Model hier, das ist verboten, also wir hatten da in, was will ich lügen, in Rail 2 hatten wir da noch eine Blacklist. Also Rolle darf nicht gesetzt werden. Dann hatten wir in 3 hatten wir eine White List, ja. Also bitte hier nur Name setzen, alle anderen nicht.

Und mit Strong Parameters wandert das jetzt endlich in den Controller, raus aus dem Model, wo es auch irgendwie hingehört. Dieser CVE-Line-Trag beschäftigt sich aber damit, dass man die White List umgehen kann. Und zwar, wenn man New Lines in seine Parameter einfügt.

Was so ein bisschen zusammenhängt mit so einer Requex-Problematik, die Ruby hat, da komme ich auch gleich, da gibt es gleich noch mehr Beispiele. Und ja, also hat einem nicht zu helfen, Attribute Protected in sein Proz zu schreiben. Cross-Site Scripting ist ja auch nicht so harmlos, ja, wenn Dritte im Rahmen unserer Webseite JavaScript und HTML an Benutzer ausliefern können,

können sie halt unsere Cookies stehlen und dergleichen. Da gibt es also hier einen Sanitize CSS, das wieder mit New Lines, also ich vermute, wird auch wieder ein Problem mit der Requex sein, in Sanitize HTML. Und dann gab es noch ein Problem mit dem I18-Fallback. Da wurde dann quasi gesagt, den String kann ich nicht übersetzen.

Und hier ist der String, ja, da hat man dann also direkt seinen Chartcode platzieren können. Number to Currency Helper, Simple Format Helper und so weiter. Query Manipulation finde ich auch gut. Es gibt hier mehrere, so eine ganze Reihe von CVEs, wo man es geschafft hat, ist Null in die Datenbahn Queries einzuschleusen.

Das ist ja jetzt nicht immer unbedingt sofort ausnutzbar, aber vielleicht kann man das jetzt zu irgendwas gebrauchen in bestimmten Anwendungsfällen. Und dann gab es hier so eine Lücke, das war schon so ein bisschen das Vorspiel Jason-

und XML-Parameter-Typecasting. Also, dass Rails 3 überhaupt XML-Parameter annimmt, ist, glaube ich, so ein bisschen eine Überraschung gewesen für die meisten. Und dass man sich in diesen Parametern dann auch noch den Typ wünschen kann von den Werten, die man da übergibt, das war sozusagen noch das I2-Pilchen oben drauf. Und dann konnte man halt so einen Query hier produzieren,

in dem man halt es geschafft hat zu sagen, der Parametoken ist in Wirklichkeit ein Integer. Ob das jetzt in einer konkreten Anwendung zu Erfolg führt, schwer zu sagen. Dann kam der große Bereich der Deserialisierungslücken. Da hat man also zuerst herausgefunden, dass in Model-Attributen,

wenn die vom User bestimmt werden und dann mit YAML in der Datenbank gespeichert, dann kann der User sich in dem YAML halt eine Klasse wünschen. Und das kann, wenn er da eine gute Klasse wählt, zu Code Execution führen. Dasselbe gab es dann in Remote mit XML-Parametern.

Also hat man das YAML direkt in den XML-Parametern untergebracht. Also hier so ein XML und dann sage ich hier der Type. Von dem XML ist übrigens YAML. Und dann wird das auch noch gepasst, was da drin steht. Da konnte man also direkt Code mit ausführen. Das wurde dann schnell gefixt.

Man hat dann einfach auch die XML-Parameter, die wirklich keiner brauchte, abgeschaltet. Es stellt sich heraus, das ging auch bei JSON-Parametern. Na ja, dann war aber auch schon 2014 und da haben wir jetzt auch so großartige Lücken hier, wie PostgreSQL Array Columns. Also da hat man irgendwie über einen Backslash mehr Daten reingekriegt, als man sollte.

Wieder ein Cross-Site-Scripting im Lambda-Helper. Ich mag die Root-Globbing-Lücke hier unten total gerne. Muss aber gleich dazu sagen, also ich habe bisher noch keine Anwendung gefunden, wo die wirklich ausnutzbar ist. Also weil Root-Globbing ist auch so ein bisschen so ein esoterisches Feature, glaube ich, was wenige benutzen und wenn man es benutzt, benutzt man es meistens nicht mit Parametern,

sodass man es also auch nicht schafft, hier sich einen Dateinamen zu wünschen. Das ist mit mir und der Fernbedienung ist das nicht so gut. Sich hier so einen Dateinamen zu wünschen, der dann auch tatsächlich von der Festplatte geladen wird. Hätte man aber eine Anwendung, wo das geht, ist man in der glücklichen Situation,

dass die Datei als View ausgeliefert wird, in dem Embedded Ruby interpretiert wird. Also man muss es jetzt nur hinkriegen, zum Beispiel in die Log-Datei von Rails. Da weiß man ja, wo die liegt, Punkt Punkt Log, Production Log. Da muss man jetzt also nur Embedded Ruby reinkriegen und dann könnte man über die Root-Globbing-Lücke genau die Datei ausspielen an den User und hätte Code Execution.

Total großartig erinnert mich an PHP, da hat man das damals so gemacht, dass man den Chart-Code in den User-Agent geschrieben hat und dann hat man sich den aus Prox, Self and Viron geladen. Also es ist alles wieder wie früher. Aber wie gesagt, ich habe leider noch keine Anwendung gefunden, wo das geht.

Oder zum Glück. Dann wieder Post-SQL-Range und Bitstrings ermöglichen. Die ermöglichen SQL-Injection habe ich auch noch nie in Verwendung gesehen. Create-Writs konnte man Strong-Parameters umgehen. Und dann gab es eine ganze Reihe von Problemen für den Fall,

dass man statische Assets selber ausliefert. Das ist auch so ein Passenger-Deployment wahrscheinlich nicht betrifft, aber so Yoroku vielleicht eher. Ja, wir haben aber nicht nur Probleme in dem Rails-Framework selber. Klar, wir haben auch Probleme im Ruby-Interpreter. Die habe ich jetzt mal außen vor gelassen.

Wir haben auch Probleme in den Gems. Da fand ich besonders schön JSON. Kleiner 177 gab eine Code Execution. Dann gab es dann noch so ein DOS. DOS ist ja oft eigentlich nur die Vorstufe für Code Execution. Da hat noch niemand herausgefunden, wie man auch noch Code ausführt. Die Device ist so ein Gem. Das benutzt man, um Logins zu machen.

Da gab es eine Lücke, um das Login zu umgehen. Das war schön. REC, das ist besonders fies, weil REC läuft natürlich vor der eigenen Rails-Anwendung. Wenn da die Parameter schon kaputt gemacht werden oder so, da kann man sich gar nicht wehren. Man kriegt noch nicht mal einen Stack-Trace. Der ist irgendwie von REC dann ... Ja, Nori, weiß ich gerade nicht.

Kokain führt Befehle aus. Das führt hier beliebige Befehle aus. Dann gibt es den Fusion Passenger, eine lokale Privilege Escalation, was als Second-Order-Attack immer ganz nett ist. Wenn man schon Code ausfüllen kann auf der Kiste und dann noch eine local Privilege Escalation findet, dann ist man natürlich schon einen Schritt weiter.

Hier kriegt man aber wahrscheinlich nur die Rechte vom Fusion Passenger und nicht Root. Also mäßig. Neu dabei, während ich den Vortrag noch entworfen habe, ist hier einmal so ein Gem-File-Man-in-the-Middle-Attack. Ruby Gems werden nicht signiert. Das ist nicht so gut. Ich habe aber nur 127 Anwendungen gefunden, die sie auch noch über HTTP ziehen.

Also, die meisten Gems werden tatsächlich über HTTPS gezogen. Insofern ist man dann hier so ein bisschen geschützt. Ja, und Paperclip hat auch immer wieder mal Probleme mit Cross-Site-Scripting, was so ein bisschen in der Natur der Sache liegt, weil es halt eben User-Uploads ermöglicht und die dann nachher wieder ausspielt. Und ich sag mal, wenn die dann nicht zum Download angeboten werden,

sondern direkt im Browser gerendert, dann hat man halt mit allen möglichen Datei-Typen Probleme. Also da hat man JavaScript in HTML, JavaScript in SVG und so weiter und so weiter. Ja, da habe ich gerade schon so ein bisschen gesagt. Also nur weil so eine Schwachstelle vorhanden ist, heißt das jetzt leider nicht, dass man auch durchdringen kann und nachher irgendwie die Anwendung owned,

sondern oft braucht man eine ganz bestimmte Konstellation, um die dann auszunutzen. Und die statischen Scanner, die ich jetzt verwendet habe, erkennen auch oft dann zu viel oder zu wenig, weil sie dann einfach auch nicht wissen können, ob der Parameter ungefiltert in den Aufruf geht.

Also es wird deutlicher, wenn wir uns in tatsächlichen Apps Schwachstellen angucken. Das hier ist das Ergebnis von so einem Dawn-Scan. Hier sieht man ganz schön, dass er hauptsächlich so CVEs findet, die viele Versionsnummern abdecken. Also das ist einmal hier der Root-Globbing.

Und der andere ist Bit-String. Also es kann mir keiner erzählen, dass das alles postresquell-Anwendungen sind, die Bit-String benutzen, sondern das ist einfach so, dass der Dawn halt so vorgeht. Er guckt im Gem-File nach den Versionen und sagt dann, ja, so, eventuell geblieben.

Und finden tut er dann also im Mittel bei 3-2-11 fast 20 CVEs. Dann geht das hier immer hübsch weiter runter, umso höher die Version wird. Umso weniger erkennt er auch. So als Boxplot mit Standardabweichung,

ja, also hält so ein bisschen. Also es wird auf jeden Fall weniger, umso höher die Version wird. Ja, das habe ich gerade gesagt. Bei Brakeman, wenn ich jetzt Warnungen betrachte, die Brakeman mit hoher Konfidenz ausgibt, also er gibt noch so eine Bewertung mit, wie wahrscheinlich ist es, dass diese Lücke hier tatsächlich vorhanden ist,

ergibt sich allerdings ein ähnliches Bild, allerdings mit deutlich reduzierter Anzahl, also 6 statt 20 Warnings. Und hier sieht man auch, das ist meistens, umso mehr man updatet, umso mehr ist man da geschützt. Klar, das meiste, was Brakeman findet,

sind SQL Injections, Session Setting. Und ja, das sind auch teilweise, natürlich liegt es auch teilweise an einer fehlerhaften Erkennung. Mars Assignment hat Brakeman 22.000 Mal als problematisch identifiziert.

Da ist der Scanner meiner Ansicht nach auch sehr empfindlich. Also ich habe wenige Fälle gefunden, wo ich dann wirklich sagen konnte, hier haben wir ein Mars Assignment Problem, was daran liegt, dass es auch sehr auffällig ist, das manuell zu überprüfen. So eine SQL Injection kann ich deutlich schneller finden, hier muss ich durch deutlich mehr Dateien hüpfen,

bis ich weiß, ob so ein Parameter wirklich durchkommt, bis an die Stelle. Aber es sind auch solche dabei, also die dann einfach alles erlauben unterhalb von Registration.

Nee, muss es nicht. Nee, es muss nachher auch eine Situation sein, wo man es ausnutzen kann. Das sage ich halt, es ist superschwierig da zu sagen, hier ist eine. Also es ist eher so was, was man ausprobiert. Mit OBSet einfach mal so ein Request abschicken und ein paar Felder austauschen, gucken, ob es klappt. SQL Injection finde ich, kann man sehr viel besser so auf dem Papier sehen.

Also es ist immer der Fall, wo SQL in Zeichenketten zusammengesetzt wird. Die Rails-Mechanismen selber sind ja vergleichsweise sicher. Und das ist natürlich immer besonders schlimm, wenn das ein anonymer User machen kann. Also so ein Atmenbackend kann man jetzt noch so ein bisschen diskutieren, wie schlimm das ist. Und tritt meiner Ansicht nach besonders auf den Such- und Sortierfunktionen auf.

Also tatsächlich habe ich hier mal so ein komplizierteres Beispiel. Also der gibt sich hier so ein bisschen Mühe. Also hier ruft er das mit Sign Reset, mit Params ID auf. Vorher wird das auch noch irgendwie so mit Jollen, da werden dann so Kommas dazwischengesetzt. Und dann geht hier mit Plus, ja hübsche String-Additionen,

gehen die IDs hier rein. Wird auch noch geguckt, ob sie vorhanden sind. Sollte eine SQL Injection sein. Schön finde ich immer sowas hier. Da wird auf dem Model Order aufgerufen. Mit Sort-Column und Sort-Direction.

Also das habe ich so gefunden und habe mir gedacht, das ist jetzt hier mit den Klammern schon, das sieht schon so unordentlich aus. Ich habe dann geschaut, da gibt es den Matthäus-Effekt. Denn wer da hat, dem wird gegeben, dass er die Fülle habe. Wer aber nicht hat, dem wird auch das genommen, was er hat. Also der Teufel macht immer auf den größten Haufen.

Und da habe ich weitergeguckt und dann habe ich das nochmal gefunden, hier mit den Klammern in einem anderen Programm. Und hier sieht man also auch ganz schön, hier Ticket-Column. Wird auch noch so ein bisschen so ein Deep-Volt gesetzt. Und dann kommt Params Sort. Aber direkt hier rein und wird dann hinten in dem Order-Statement, hat man dann die SQL Injection.

Dann habe ich mir gedacht, vielleicht suche ich mal im Internet, wo das herkommt hier mit dieser Syntax und der Sort-Column. Und dann habe ich einen Rails-Cast 228 gefunden. Wir haben hier dieses Beispiel ohne die Klammern. Und dann steht da drüber, Achtung, das ist eine SQL Injection.

Und gleich in dem Tutorial machen wir die weg. Ja, ich lese die auch nicht bis zum Ende, muss ich gestehen. Total großartig. Ja, Remote Code Execution. Das sind diese ganzen Situationen, wo Ival, Send und Constantize benutzt werden. 22.000 Mal angemahnt.

Oft hat man hier so das Problem, dass die Parameter vorher bereinigt werden oder so. Also da sind einige Fehlerkennungen bei. Aber ich glaube, also viele funktionieren, die zum Beispiel, ach, das ist echt, das waren die 9 Euro nicht wert, das Gerät. Also wie hier zum Beispiel, da geht der Form-Alias rein in die Form-Data.

Und ich finde das Beispiel so schön, weil man hier nicht nur Ival hat mit Parametern, die der User bestimmt, sondern man darf sich hier auch noch eine Klasse wünschen, die genuht wird. Und zu einem Überfluss darf man dem New auch noch Parameter übergeben. Also das ist ideal.

Ja, also das ist eigentlich genau das, was man braucht. Gibt es auch so ein bisschen komplizierter oder einfacher. Also hier ohne Parameter kann man nicht so ganz viel machen. Da muss man jetzt eine Klasse finden, die einem Code Execution ermöglicht. Ohne da jetzt noch einen String hin zu übergeben.

Rails, wenn das so läuft, hat das über 2000 Klassen, die man sich aussuchen kann. Muss man dann vielleicht ein paar Tage suchen, bis man eine hat. Hier der zweite ist halt wieder schön, weil er halt wieder an das New übergibt. Und gut sind immer diese Fälle, wo das so zusammenhängt mit Yammel. Also wo man vielleicht sogar noch Yammel aus den Parametern nimmt

und das dann einfach hier mit Load baut. Dann kann man sich natürlich wieder beliebige Klassen wünschen. Ja, es war eigentlich gleich so eine Folie kommen. Hier ist auch so ein, ja das ist, schade.

Das ist die Folie, also das hier ist der Payload von CVE 2013 033. Das sind diese Deserialisierungslücken, über die ich vorhin geredet habe. Und da hat man also tatsächlich ungefähr eineinhalb Tage gesucht im Internet, bis die Community eine Klasse gefunden hatte, die Code Execution ermöglicht. Und das ist Action Dispatch Routing Root Set.

Ihr kriegt hier so einen Payload mitgegeben. Der geht hier in das New, aber geht ja nicht. Also sie wird gemute und dann wird die Array-Operation aufgerufen mit dem Payload. Und damit es läuft, brauchen wir aber hier noch so ein Objekt, das auf default antwortet.

Deshalb dieser Struct, der dahinter gehängt wird, gibt einfach einen Ash zurück. Und das gibt so eine halbe Execution, aber am Ende wird hier Put As Evil ausgeführt. Das ist tatsächlich das Jammel, das dabei erzeugt wird. Also das, was wir gerade als Code gesehen haben, entspricht ungefähr diesem Jammel.

Hier, also hier kann man sich Ruby Hash, kann man sich dann die Klasse wünschen. Und die kriegt dann hier diesen Payload zugewiesen als Hash Key mit Wert hier von diesem Open Struct. Ja, das musste man jetzt nur noch so encoden, dass es durch die Parameter durchkommt. Und dann hatte man Code Execution.

Also nicht ganz trivial, finde ich. Cross-Site Scripting-Lücken. Habe ich wenig gefunden, sind auch extrem schwer zu identifizieren, ohne sie auszuprobieren. Ich glaube, das ist etwas, was man tatsächlich besser mit so einem Application Scanner hinbekommt.

Aber in Linked To gibt es immer wieder so Probleme. Dann kann man sich dann hier über die Params Merge. Wenn man jetzt die Params kontrolliert, könnte man da was Böses reinschreiben. Oder hier so Params Redirect URL oder Params Web To ist häufig, dass da so ein bisschen man sich aussuchen kann, zu welcher Seite man zurückkommt.

Und was jetzt hier halt passieren kann, ist, dass jemand in die Params reinschreibt JavaScript Alert. Und wenn das am Anfang von der URL rauskommt, also das erste hier ist ja der Titel des Links. Und das zweite ist die URL, wo der hinlinkt. Wenn das am Anfang ist, hat man plötzlich, wenn man den Link klickt, JavaScript, das ausgeführt wird.

Kann jetzt sein, dass da irgendwie gefiltert wird. Dann kann man sich mit Data behelfen statt JavaScript. Also dieses Data hier ist auch wieder ein JavaScript Alert, nur encoded als Base64. Und dann hat man Cross-Site Scripting.

Ich habe tatsächlich mal selber einen komplizierteren Fall von Cross-Site Scripting gehabt. Der ist jetzt auch nicht von Breakman gefunden worden, sondern den habe ich jetzt mal da reingetan. Da habe ich Jake für den Pop-Over benutzt. Hier in meinem Hammel habe ich hübsche irgendwie aus Jammel Paper Trail irgendwas geladen. Hier ist auch schon wieder so eine komische Syntax. Hätte man auch gleich schreiben können. Dann kommt das da rein, wird von Rails automatisch escaped.

Schutz vor Cross-Site Scripting. Und ich wollte so kurz fragen, hier, bei dem, eins vorher, weil das in den Link for Helper geht.

Das ist ja auch kein HTML, das ist ja nur ein String. Also das ist ja eine gültige URL im Grunde. Also nur weil da jetzt nicht HTTP vorsteht, sondern JavaScript. Man könnte auch Gopher da hinschreiben oder FTP oder so.

Ach so, ja. Ich habe die Frage nicht geholt. Also die Frage war, warum das überhaupt hier geklappt hat. Ja, und hier steht also jetzt escaped ist HTML drin. Aber dann geht Jack für den Pop-Up hin. Und da wurde auch noch so nett gesagt HTML true. Und in dem Moment wird natürlich jedes HTML, was da drin ist, ausgeführt.

Also auch JavaScript. Ja, CSS, XSS muss man zwei Sorten unterscheiden. Das ist einmal dieses Reflektive. Das ist immer, wenn man sich das über so einen Link einfängt. Also das muss irgendeine Seite geben, irgendeinen Mechanismus geben, die dem User diesen schadhaften Link unterjubelt. Und schlimmer ist, persistent ist XSS.

Also wenn wir User-Import entgegennehmen, den in unserer Datenbank speichern und nachher wieder ausspielen. Also Klassiker sind da Gästebücher. Ja, Session-Settings finde ich besonders gut. Das sind diese ganzen Secret-Token-Geschichten. Also man kann in Production davon ausgehen,

dass die Leute den Secret-Token, den sie in GitHub gefunden haben, nicht ändern. Wenn der Secret-Token aber bekannt ist, hat man eigentlich Code-Execution, falls der Cookie-Store verwendet wird und nicht eine Datenbank. Also falls eine Datenbank verwendet wird, natürlich nicht. Sondern nur bei Cookie-Store. Ja, das gehört da eigentlich nicht hin.

Das verletzt so ein bisschen das Need-to-Know-Prinzip. Gehört eigentlich in die Konfiguration, so ein Setting. Ich habe hier auch so ein Metasploit-Beispiel. Das spare ich mir mal aufgrund der Zeit. Das ist auch so ein bisschen langweilig anzugucken. Funktioniert aber einwandfrei. Also sobald man diesen Session-Key kennt,

kann man halt in dem Cookie-Code unterbringen, der ausgeführt wird. Denial-of-Service-Angriffe, 14.950. Das entsteht halt auch immer dann, wenn der User sich zum Beispiel eine Regex wünschen darf. Also hier gibt es so eine Regex. Da gibt es auf Wikipedia eine Liste gefährlicher Regexes.

Diese Regex dauert auf meiner i7-CPU fast drei Sekunden. Aber wenn so ein User das jetzt irgendwie 1000-mal pro Sekunde abfeuert, habe ich meinen Webserver ein Problem. Genau dasselbe, wenn wir aus Benutzer-Input Symbole machen, weil die Garbage-Collection-Symbole nicht freigibt.

Also kriegt man halt auch schnell einen Memory-Leak in seiner Applikation. Und dann crasht die. Und da gibt es halt auch in den gescannten Anwendungen immer wieder so Fälle, wo hier also hübsch die Parameter direkt in so einen regulären Ausdruck eingehen. Vielleicht hat man hier gehofft, dass ID ein String ist, ein Integer. Ich weiß es nicht.

File-Access ist nicht so oft angemahnt worden. Ist aber meiner Ansicht nach eine der problematischeren Lücken, wo glaube ich auch viel zu holen ist. Also das sind immer diese Fälle, wo hier aus den Parametern nehme ich irgendeinen String und dann sende ich den einfach.

Also hier kann ich jetzt auch Punkt, Punkt, Punkt unterbringen, bis ich bei etc-pass-wd bin oder bei config-database-yaml oder so. Und dann wird die geschickt, wenn auch mit dem falschen Mime-Type. Gibt es in allen möglichen Variationen. Den hier fand ich besonders schön. File-Open ist ja genau dasselbe. Da wird also erst aus den Parametern ein Fad geholt.

Mit der Hoffnung, dass er da ist. Da wird er zum Lesen geöffnet. Dann wird er hier in die Datenbank gespeichert auf so einem GPG-Key. Jetzt anschließend schaffe ich diesen GPG-Key mir anzeigen zu lassen. Der Content ist hoffentlich der Inhalt der Datei. Ich muss hier hinweisen auf Kernel-Open.

Kernel-Open ist so die mächtigere Open-Routine von Ruby. Die kann auch OIs öffnen unter Umständen. Und vor allem kann sie mit dieser Pipe-Syntax auch Befehle öffnen. Also wenn ich hier bei Kernel-Open irgendwie einen Param rein kriege, kann ich auch beliebige Befehle ausführen. Ja, Redirects sind also Situationen, wo Angreifer ihre Original-URL verstecken können.

Also wenn ich hier so Redirect to Param, Merge Action Home. Ich will einfach jetzt auf Home redirecten, aber die Parameter behalten. Dann könnte jetzt ein Angreifer hingehen und sagen, ja, ich tu dir da noch einen Host rein in die Param. Dann redirecte ich nämlich nach extern.

Ja, gibt es halt recht oft auch hier so völlig ungeschützte Redirects oder die Hoffnung, dass das nicht auffällt, wenn die Base64-Encodes sind. Format-Validation ist so ein bisschen der Bereich, den ich vorhin geredet habe. Da warnt Raymond meistens wegen regulären Ausdrücken.

Also das sind alle Situationen, wo das Format dann nicht so genau überprüft wird. Also hier dieses HTTPS kann irgendwo auftauchen. Und hier wird zwar so ein Dach benutzt, um auf den Anfang zu testen, aber das ist jetzt leider nicht der Anfang des Strings,

also der gesamten Zeichenkette, die ich übergebe, sondern es ist der Anfang der Zeile. Also dieser Ausdruck hier sucht nach irgendeiner Zeile, die mit HTTPS anfängt. Das hier wäre so ein Beispiel, okay, jetzt mit HTTPS. Also JavaScript exploit, alert oder sowas. Und dann matche ich hier auf die zweite Zeile, aber der Link zeigt nachher hier auf den JavaScript-Teil.

Passiert ist das GitHub. Das war bei denen ein Problem. Das ist ja aus diesem Hommakauf Blockspot. Ich glaube, der hat das entdeckt oder publiziert oder so. Auf jeden Fall hat das dokumentiert, deshalb habe ich hier mal das Bild genommen und dann hat man es halt geschafft, plötzlich auf GitHub sein eigenes JavaScript auszuführen.

Command-Injection mag ich auch mal gerne. Das sind also alle Situationen, wo hier die Parameter am besten in Backticks eingehen. Also dieses Programm hier hat tatsächlich erst mit C irgendetwas kompiliert und hat es dann ausgeführt und hier irgendwie Input ID reingeschrieben. Ich kann hier jetzt natürlich in ID einfach einen String schreiben,

Semikolon, mein eigener Befehl. Und dann geht es weiter. Hier hat jemand System benutzt. Da sind wir ja wieder bei Staplerfahrer Klaus. Das ist schon die richtige Idee, System zu benutzen, aber dann auch mit einem Array und nicht wieder mit String-Addition, weil so hat System halt keine Chance, den Befehl zu bereinigen.

Ja, Baby-Orientication sind alle Fälle, wo Passwörter im Code gespeichert werden. Ich habe den Eindruck, die meisten Passwörter sind eher so Entwickler-Passwörter. Alien129. Das häufigste Passwort ist Secret.

Asmin. Das waren wirklich viele Passwörter. Ich konnte nicht alle nehmen. Ich nehme mal Test123. Und hier habe ich mal so ein paar von den exotischeren. Also hier hat sich jemand tatsächlich Mühe gegeben, glaube ich. Manchmal weiß man ja auch nicht, was da so für ein Schema hinterliegt. Brocoli finde ich gut.

Change Me Forever ist auch nicht schlecht. Strong Password ist unknackbar, klar. Aber vielleicht The Best Password ist vielleicht besser. Also da sind immer so die Hoffnungen, dass das dann beim Deployment auch geändert wird.

Diese Folie ist überraschenderweise leer. Ich hoffe, da fehlt jetzt nichts, sonst gucke ich gleich mal nach. Ja, also als Fazit würde ich sagen, macht Updates, benutzt automatisierte Scanner. Das geht wirklich ganz einfach und hilft einem, glaube ich, viel weiter.

Guckt zu, ob ihr irgendwie Raum findet für Code Reviews, auch speziell Security Code Reviews, nicht nur Code Qualität. Und wenn es eine kritische Applikation ist, würde ich halt so punktuell mal Meditation Tests empfehlen. Aber im Grunde ist Sicherheit halt ein Prozess. Da ist man nie mit fertig, da kann man dran bleiben.

Dann danke und hier sind noch so ein paar Quellen. Und wenn ihr Fragen habt, bitte.

Also ich finde es okay. Ich muss ehrlich sagen, ich bin mit der ganzen Präsentation von den Sicherheitslücken und so bin ich sehr zufrieden.

Ich habe, wie gesagt, das ist jetzt nicht vergleichende Programmierwissenschaften hier. Viele von diesen Fehlern sind auch eigentlich so nach Ruby, nach Rails importiert worden. Also dieser Psyc-Yaml-Parser hat einfach keinen Safe Mode. So und sicherlich, also ich kann mir vorstellen, dass die Security-Researcher

sich in Beeren gefreut haben, als sie diese Regex-Geschichte entdeckt haben, die ja wohl auch schon so ein älteres Problem ist. Also ich habe mir sagen lassen, Pearl hatte das auch schon mal in den 90ern. Nee, mit dem Dach, also mit dem Anfang und dem Ende von dem String. Und das ist halt, wenn man sowas findet, macht man halt so eine ganze Fehlerklasse auf. Ja und trotzdem finde ich, sieht es gut aus.

Ich habe natürlich auch mal so ein bisschen bei CVI Details nach anderen Frameworks geguckt. Bei PAP ist immer alles denial of service. Also die haben gar keine exploits, ist so mein Eindruck. Und bei Rails ist es natürlich immer viel.

Aber das liegt auch daran, dass es ein riesiges Framework ist. Also da müsste man wahrscheinlich Django mit 20 Libraries nehmen, um irgendwie so denselben Funktionsumfang überhaupt zu vergleichen. Das ist schwierig.

Ja, also die großen PAP Frameworks haben auch Sicherheitslücken, sagt er. Ja, das ist halt einfach so. Also alle haben Sicherheitslücken und auch Java hat Sicherheitslücken. Also ich erinnere mich, dass es dabei Spring auch in der URL-Probleme gab

mit irgendwelchen Features, die wahrscheinlich auch keiner benutzt, aber wo es dann genauso zu Code Execution kommt. Ja, ich habe auch das Gefühl, das ist da schwieriger zu finden. Da ist auch eher so eine, also die Java Leute reden nicht so oft über Security Issues,

war so der Verdacht. Ich finde auch eher von der Kultur her habe ich sehr viele Projekte gesehen, wo einem so bei Beginn die Heiligen Jar Files übergeben wurden, mit denen läuft das Projekt und dann wurde nicht geupdatet. Das stimmt natürlich von modernen Java Entwicklungen so auch nicht mehr. Die benutzen mittlerweile Maven und so und das ist halt irgendwie,

also da ist halt genau wie Gems vielleicht besser. Ja, das ist ja, ja, dieses Big Cooperative Enterprise updated nicht. Da hinten erst.

Ja, also Rails, viele Sicherheitslücken sind in so Nischen-Features und es würde wahrscheinlich wirklich helfen, da modularisiert davor zu gehen,

aber wie er sagt, wird das glaube ich im Moment gemacht. Also viele Komponenten werden ja jetzt auch einzelne Gems. Aber es ist auch, also hier war auch einiges bei, was so in der Standard Funktionalität war. Also so der richtige Kracher, diese Desirealisierungslücken. Gut, vielleicht hätte man die XML-Parameter früher rauswerfen müssen.

Ich weiß es nicht, aber naja, da hat man halt.

Also war das alles in aktiven Projekten oder mehr in Forks die Lücken, die ich gefunden habe? Also mein Eindruck ist, dass es schon auch aktive Projekte waren, die aber dann nicht die Größe haben von bekannten Rails-Projekten.

Das sind so Ein-Mann-Projekte oder sowas, die einfach auch dann nicht so die Reife haben. Was ich auch gefunden habe, sind Sicherheitslücken in Forks, die dann im Hauptzweig sozusagen schon korrigiert waren. So wenn man sich dann über GitHub zum eigentlichen Repo durchklickt,

merkt man, dass die das vor zwei Jahren schon gefixt haben und da hat einfach jemand seinen Fork nicht aktualisiert, weil der, weiß ich nicht, man forkt ja oft einfach so bei GitHub. Also ansonsten, da sind halt viele so Hobbyprojekte bei, die jetzt wahrscheinlich auch nicht so viele User haben, wo auch einfach keiner nach guckt.

Oder wo Leute einfach üben, anfangen Rails zu programmieren. Anfängerprojekte hat man viele. Und ich meine, das ist ja auch okay, da macht man halt Fehler.

Ja, es gibt mehrere, also gibt es andere Datenquellen, die zu einer besseren Grundgesamtheit führen? Ja, wahrscheinlich schon. Also man hätte irgendwie Projekte nehmen müssen, die bei GitHub irgendwie Daten nochmal in veredelter Form bereitstellen.

Da habe ich aber leider nicht schnell genug die Zugangsdaten bekommen. Und dann hätte man halt sagen können, was sind wirklich oft gedownloadete Projekte oder sowas. Andererseits ist mir auch so ein bisschen mulmig dabei, hier im Rahmen von dem Vortrag jetzt irgendwelche Zero Days in Applikationen bekannt zu geben. Das ist eigentlich auch kein guter Stil. Und also ich hoffe, wenn ihr jetzt gleich googelt, in welcher Software diese Lücke vorkam.

Also ich vermute, dieser GPG-Key ist identifizierbar. Seid so nett und macht da Responsible Disclosure drauf. Und hackt den nicht einfach. Tatsächlich war es auch wirklich schwer, in 26.000 Projekten sinnvollen Analyse zu machen.

Die Datenmenge ist einfach viel zu groß. Also ich würde das nicht nochmal machen. Ich würde mir irgendwie eine kleinere Grundgesamtheit aussuchen. Irgendwie eine andere Fragestellung aussuchen. Man hätte zum Beispiel sagen können, wie steht es so um Rails 3.2.21 Projekte oder sowas. Aber wie findet man die? Das ist auch nicht so leicht.

Tatsächlich wäre es, also wenn ich den Vortrag nochmal halten würde, würde ich wahrscheinlich immer so, so macht man es richtig. Und so macht man es nicht auf die Folien schreiben. Weil ich glaube, das wäre so ein größerer Gewinn auch für die Zuschauer, gerade für Anfänger.

Ich habe mir das ehrlich gesagt nicht so genau angeguckt. Das sind so Gems, die kann man einfach installieren.

Und mein Eindruck ist, also ob die jetzt einen Bezug zu Firmen haben, weiß ich nicht. Das sind Community, das sind Open Source Projekte. Die haben eine GitHub-Seite. Dawnscanner ist so ein bisschen langsamer vom Entwicklungstempo. Bei Breakman ist wirklich auch viel los. Also die machen viel und macht auf mich einen sehr guten Eindruck.

Erstmal von der Funktionalität muss ich auch sagen. Da war ich überrascht. Also das habe ich bei anderen Programmiersprachen nicht gesehen, dass ein statischer Security-Scanner so gut arbeitet.

Ja, dann wenn es keine weiteren Fragen mehr gibt, danke. Und dann machen wir den Raum frei für den nächsten Vortrag.