Stellen Sie sich das folgende Szenario vor:
Du arbeitest bei Big Co. und deine Kollegen in der Halle sind im Web-Entwicklungsteam für Big Co's öffentliches Blog-System, das viele Big Co-Mitarbeiter und einige öffentliche Leute benutzen. Das Blog-System erlaubt jedes HTML und JavaScript, und Ihnen wurde gesagt, dass es eine Wahl war (nicht zufällig), aber Sie sind nicht sicher, ob sie die Implikationen davon verstehen.
Sie wollen sie also überzeugen, dass dies eine schlechte Idee ist. Sie schreiben einen Democode und fügen ein XSS-Skript in Ihrem eigenen Blog ein und schreiben dann einige Blogposts. Bald darauf besucht der Chef-Blog-Administrator (im Flur) Ihren Blogpost und das XSS sendet Ihnen seine Cookies. Sie kopieren sie in Ihren Browser und Sie sind jetzt als er eingeloggt.
Okay, jetzt bist du als er eingeloggt ... Und du fängst an zu erkennen, dass es vielleicht keine so gute Idee war, weiterzumachen und das Blog-System zu "hacken". Aber du bist ein guter Typ! Du berührst sein Konto nicht, nachdem du dich angemeldet hast, und du planst definitiv nicht, diese Schwäche zu veröffentlichen; Sie möchten ihnen vielleicht nur zeigen, dass die Öffentlichkeit in der Lage ist, dies zu tun, damit sie es beheben können, bevor jemand böswilliges das Gleiche realisiert!
Was ist der beste Weg von hier?
Das hängt wirklich von Ihrer Position in der Firma ab, von der Art der Leute in der Halle, usw. etc ...
Um eine Option zu präsentieren:
Gehen Sie zu ihnen hinüber, beschreiben Sie die Bedrohung in abstrakten Begriffen ("jemand könnte Ihre Kekse entführen, die wiederum ..."), und fragen Sie sie, ob sie eine Demonstration sehen möchten? Wenn große Egos im Spiel sind und Sie wirklich wollen, dass sie es beheben, sprechen Sie nicht mit dem ganzen Team, sondern nur mit dem Teamleiter.
Wenn sie einverstanden sind, warten Sie ein paar Stunden, und melden Sie sich als "ihn" eingeloggt zurück und tun Sie etwas nicht destruktives, aber auffälliges im System - Sie haben das mit ihrer Erlaubnis getan. Sie werden wahrscheinlich beeindruckt sein und dafür sorgen, dass das Loch repariert wird.
Wenn sie nicht zustimmen und Ihnen sagen, dass Sie weggehen sollen, dann müssen Sie Ihre Möglichkeiten abwägen: Entweder nehmen Sie es irgendwo höher oder Sie begraben es. Wenn Sie das Problem erwähnen, haben Sie alle Möglichkeiten aufgegeben, es anonym zu senden.
Wenn Sie nicht 100% sicher sein können, dass jeder in der Entscheidungskette vernünftig ist und vollkommen versteht, was Sie tun, und dass es zum Wohle der Firma ist, würde ich kein Rogue "hacken" - immer sprechen Sie zuerst darüber, besonders in einer großen Unternehmensumgebung. Dieses Zeug ist zu leicht zu missverstehen, als bösartig an Ihrem Ende - vor allem, wenn es jemanden gibt, dem es peinlich ist, dieses Sicherheitsloch zu bauen, und jemand anderen die Schuld geben möchte.
Jeder konzentriert sich darauf, das Problem der Website zu beheben, und vielleicht bin ich nur ein kleiner Machiavellianer, aber ich würde auch darüber nachdenken, ob meine Einwände schriftlich festgehalten werden; Ich würde eine E-Mail an einige meiner Vorgesetzten schreiben.
Das letzte, was Sie brauchen, ist die Seite, die ausgenutzt werden soll, und der Entscheidungsträger, der darauf besteht, dass es Ihr Job (oder der Ihres Kumpels) ist, diesen technischen Aspekt zu berücksichtigen, und Sie niemanden finden, an den Sie sich erinnern / p>
Ich denke, Sie haben Ihre Rolle überschritten. Während XSS-Schwachstellen ein ernsthaftes Problem darstellen, haben Sie, wenn Sie nicht in der Rolle der Informationssicherheit in Ihrer Organisation tätig sind, wirklich keinen Einfluss darauf, wie die Entwicklungsorganisation in der Halle funktioniert.
Es gibt keine absolute Sicherheit, aber ich kann mir vorstellen, dass die Leute, die das Blog-Projekt beaufsichtigen, in der Nacht ruhig bleiben, denn wenn Mitarbeiter die Technologie missbrauchen, können sie durch Protokolle verfolgt und entsprechend behandelt werden.
Wenn Sie bösartigen Code geschrieben haben, "um dies zu demonstrieren", ohne deren Zustimmung, ist dies eine ziemlich ernste Aktion ohne Genehmigung und ich könnte mir vorstellen, dass Ihre Vorgesetzten das genauso sehen würden.
Immer wenn ich ein Sicherheitsproblem gesehen habe, das von unserem internen IT-Team in der Vergangenheit behandelt werden musste, sage ich ihnen einfach, was das Problem ist und was getan werden kann, um es zu nutzen.
Je nachdem, wie sensibel sie sind und welche Bedeutung sie bei Ihnen / Ihrer Firma haben, kann der Konzeptnachweis eine gute Idee sein oder auch nicht. Wenn sie Grund zu der Vermutung haben, dass Sie es böswillig benutzen, würde ich es für mich behalten. Andernfalls, wenn sie es zu schätzen wissen, teilen Sie es.
Das ist der einzige sensible Bereich. Kommuniziere das Thema verantwortungsbewusst, so dass klar ist, dass du dich nur um Sicherheitsprobleme sorgst und nicht darauf ausgibst, sie auszunutzen.
Das ist alarmierendes Verhalten. Wenn sie die einfachsten Sicherheitslücken wie XSS nicht verstehen, müssen sie gefeuert sein. Dies liegt nicht an einer einzelnen Sicherheitslücke, das ist einfach albern. Sie sollten gefeuert werden, weil sie die Sicherheit nicht verstehen und ich habe keinen Zweifel, dass sie für serösere Schwachstellen in das System eingeführt haben. Wenn sie diese Textbuch XSS-Ausgabe nicht bekommen, was ist mit CSRF? Sie werden denken, du bist verrückt!
Das Verständnis der Auswirkungen Ihres Codes auf die Sicherheit ist eine absolute Voraussetzung. Ohne dies ist dann der Programmierer nur eine Haftung.