Obwohl Kyle Fennells Antwort sehr gut ist, möchte ich einen Grund nennen, warum es empfohlen wird, interne Anwendungen sicher zu gestalten.

Eine große Anzahl von Angriffe betreffen interne Akteure

Es gibt viele verschiedene Versionen dieses Faktoids. "50% aller erfolgreichen Angriffe beginnen intern", "Zwei Drittel aller Datenverletzungen betreffen interne Akteure" usw.

Eine Statistik, die ich finden konnte, war Verizons DBIR 2019 in was sie behaupten:

34% [der analysierten Datenverletzungen] betrafen interne Akteure

Unabhängig von der genauen Anzahl sind erhebliche Angriffe erforderlich interne Akteure. Daher ist es eine schlechte Idee , Ihr Bedrohungsmodell auf "es ist intern, daher ist es sicher" zu stützen.

Sichere Softwareentwicklung verhindert nicht nur Missbrauch, sondern auch Missbrauch

• Missbrauch: Der Benutzer tut etwas Bösartiges zu seinem eigenen Vorteil.
• Missbrauch: Der Benutzer tut etwas Bösartiges, weil er es nicht tut weiß es besser

Der Grund, warum ich Missbrauch anspreche, ist, dass nicht alles, was dem Unternehmen Schaden zufügt, absichtlich getan wird. Manchmal machen Menschen Fehler, und wenn Menschen Fehler machen, ist es gut, wenn Maschinen verhindern, dass diese Fehler weitreichende Konsequenzen haben.

Stellen Sie sich eine Anwendung vor, in der alle Benutzer alles tun dürfen (da das Einrichten von Berechtigungen lange dauert , wurde während der Entwicklung nicht gedacht, etc.). Ein Benutzer macht einen Fehler und löscht alles. Dies bringt die gesamte Abteilung zum Erliegen, während die IT einen Herzinfarkt bekommt und mit dem Backup der letzten Woche in den Serverraum sprintet.

Stellen Sie sich nun dieselbe Anwendung vor, jedoch mit einem genau definierten Berechtigungssystem. Der Benutzer versucht versehentlich, alles zu löschen, löscht jedoch nur die eigenen zugewiesenen Aufgaben. Ihre eigene Arbeit kommt zum Stillstand und die IT führt die Daten aus dem Backup der letzten Woche mit den aktuellen Daten zusammen. Zwei Mitarbeiter konnten heute keine produktive Arbeit leisten, anstatt 30. Das ist ein Gewinn für Sie.

"Intern" bedeutet nicht, frei von böswilligen Akteuren zu sein.

Einige Unternehmen sind technisch gesehen ein Unternehmen mit mehreren Teams, aber sie sind so zerbrochen, dass Teams miteinander konkurrieren, anstatt zusammenzuarbeiten. Sie denken vielleicht, dass dies nicht der Fall ist, aber Microsoft war lange Zeit so.

Stellen Sie sich vor, Sie schreiben eine Anwendung, die von allen Teams intern verwendet wird. Können Sie sich vorstellen, was passieren würde, wenn ein Mitarbeiter herausfindet, dass Sie andere Mitarbeiter für 30 Minuten aussperren könnten, indem Sie ein von ihm erstelltes Skript ausführen? Mitarbeiter von "diesem anderen Team" würden ständig von der Anwendung ausgeschlossen. Der Helpdesk war diese Woche zum fünften Mal beschäftigt, um herauszufinden, warum manchmal Leute von der Anwendung ausgeschlossen werden.

Sie denken vielleicht, dass dies weit hergeholt ist , aber Sie wären überrascht, wie weit einige Leute gehen würden, um diesen süßen Bonus am Ende des Jahres für eine bessere Leistung als "das andere Team" zu erhalten.

"Intern" bleibt nicht "Intern"

Jetzt, im Jahr 2020, wird Ihre Anwendung nur noch von einer kleinen Gruppe von Personen verwendet. Im Jahr 2029 wird die Anwendung von einigen internen Personen, einigen Anbietern und auch von Auftragnehmern verwendet. Was ist, wenn einer Ihrer Anbieter einen Fehler in Ihrer Anwendung entdeckt hat? Was wäre, wenn sie sehen könnten, dass einer ihrer Konkurrenten viel bessere Bedingungen hat?

Dies ist eine Situation, in der Sie nicht sein möchten und die Sie hätten verhindern können.

Wiederverwenden von Code aus Ihrer "internen" Anwendung

Sie schreiben eine interne Anwendung, die Datenbankzugriff erledigt. Es funktioniert seit Jahren gut und niemand hat sich jemals beschwert. Jetzt müssen Sie eine Anwendung schreiben, die auf dieselben Daten zugreift, jedoch extern. "Einfach!", Denkt der Anfänger. "Ich werde den bereits vorhandenen Code einfach wiederverwenden."

Und jetzt stecken Sie in einer externen Anwendung fest, in der Sie SQL-Injektionen durchführen können. Denn plötzlich wird der Code, der "nur für den internen Gebrauch" erstellt wurde und kein Wortspiel beabsichtigt ist, extern verwendet. Vermeiden Sie dies, indem Sie den internen Code zunächst in Ordnung bringen.

Wird es ausreichen, OWASP zu folgen?

Die Antwort auf diese Frage ist eine andere Frage "Genug für was?". Dies mag zunächst pingelig klingen, veranschaulicht jedoch das Problem. Was genau möchten Sie schützen?

Definieren Sie ein Bedrohungsmodell für Ihre Anwendung, das beinhaltet, wer Ihrer Meinung nach möglicherweise auf welche Weise eine Bedrohung für Ihre Anwendung darstellt, und finden Sie dann Lösungen für diese einzelnen Bedrohungen. OWASP Top 10 kann für Sie ausreichen oder auch nicht.

Ja, interne Anwendungen sollten mit der gebotenen Sorgfalt gesichert werden, und ja OWASP kann ein guter Leitfaden für die Sicherung Ihrer Anwendung sein. Sehen Sie sich auch den Security Development Lifecycle (SDL) von Microsoft an. Es handelt sich um einen Sicherheitssicherungsprozess, der sich auf die Softwareentwicklung konzentriert.

Warum?

• Tiefenverteidigung . Ein Angreifer könnte die Netzwerkverteidigung verletzen. Stellen Sie mehr Schutzschichten zwischen sie und Ihre Daten.
• Externe Bedrohungen sind nicht die einzigen. Anwendungsschwachstellen können auch von internen Bedrohungen ausgenutzt werden.

Andere erwähnten bereits einige gute Punkte über böse Angestellte, Infiltration, Tiefenverteidigung ... aber es ist viel praktischer. Ich kann Ihre interne Intranet-Anwendung von einer zufälligen Webseite aus angreifen.

Die Leute klicken den ganzen Tag auf Links. Manchmal, weil ein Kollege etwas gesehen hat, das er teilen möchte, manchmal aus Suchergebnissen (oder Anzeigen), manchmal aus einem niedlichen Katzenbild mit tausend positiven Stimmen von einer Website wie reddit, manchmal aus Phishing-E-Mails.

Es gibt eine Viele Möglichkeiten, wie ein Angreifer Sie dazu bringen kann, auf einen Link zu klicken. Lassen Sie uns das Katzenbild auswählen: Für die tausend anderen Leute, die das süße Katzenbild positiv bewertet haben, war es harmlos. Bis jemand klickt, dessen Unternehmen die erstaunliche Intranet-Website verwendet, die nicht den OWASP-Richtlinien entspricht.

Das Klicken auf Links zu schädlichen Seiten sollte größtenteils harmlos sein: Die regelmäßigen Updates für Ihren Browser bleiben erhalten Es ist sicher und erlaubt der Website nicht, auf den Rest Ihres Computers zuzugreifen. Deshalb ist es so einfach, einen Link anzuklicken, weil er "größtenteils harmlos" ist. Dies bedeutet jedoch nicht, dass eine Seite, auf der JavaScript-Code ausgeführt wird, im Netzwerk des Zielunternehmens für den Angreifer kein Vorteil ist.

Die Seite mit dem Katzenbild kann Folgendes enthalten:

  1. <img src = cute_cat.jpg>2. <iframe name = hiddenframe style = 'display: none'>< / iframe>3. <form action = 'http: //intranet.local/addUser.php? Username = joseph&password = 123456' id = myform target = 'hiddenframe'>4. <input type = submit style = 'display: none'>5. < / form>6. <script> document.getElementById ('myform'). Submit () < / script>  

Wenn Sie die Seite vollständig unsichtbar öffnen, können Sie die Seite addUser.php in Ihrer Intranetanwendung aufrufen. Wenn Sie angemeldet sind (wie normalerweise) Während der Arbeit) fügt der Browser gerne Ihr Anmelde-Cookie hinzu (das das Sitzungstoken enthält, anhand dessen das Intranet erkennt, dass Sie Sie sind). Der Angreifer hat jetzt ein Konto auf Ihrem System. Für Personen ohne Intranet-Anwendung wird einfach nichts unternommen.

Dies ist ein Beispiel für einen CSRF-Angriff (Cross-Site Request Forgery) (plus einige andere schlechte Praktiken), der den OWASP-Richtlinien folgt verhindern. Ein kurzer Überblick über die Funktionsweise dieses Codes:

1. Zeigen Sie das Katzenbild an, damit die Seite harmlos erscheint.
2. Fügen Sie einen ausgeblendeten Rahmen (Unterseite) hinzu, in dem sich die Intranetseite befindet wird geladen.
3. Fügen Sie ein Formular hinzu, das an Ihr Intranet gesendet wird, und rufen Sie die Seite addUser mit einem Benutzernamen und einem Kennwort auf, die vom Angreifer ausgewählt wurden.
4. Versteckt Die Schaltfläche zum Senden ist erforderlich, damit das Formular funktioniert.
5. Ende des Formulars.
6. Rufen Sie im Code submit () auf, damit die Schaltfläche zum Senden ausgelöst wird.
ol>

Wenn die Seite addUser.php keine Anti-CSRF-Token enthält (oder überprüft), ist dieser Angriff zu 100% möglich und viele Websites waren dafür anfällig in der Vergangenheit. Ein Beispiel? Das Intranet meiner Schule, in dem Noten registriert wurden. Ich hätte einem Lehrer einen Link zu einem digitalen Hand-In senden können, und die Seite hätte (abgesehen von meinem Hand-In) meine (oder die anderer!) Noten im Hintergrund ändern können.

Das ist es heute noch üblich. Hier ist ein weiteres, viel einfacheres (und weniger schädliches) Beispiel:

  1. <img src = 'cute_cat.jpg'>2. <img src = 'http: //intranet.local/logout.php'>  

Dies ruft nur die Abmeldeseite auf. Der Browser erwartet ein Bild von dieser logout.php -Seite. Wenn jedoch kein Bild vorhanden ist (da es sich um eine Abmeldeseite handelt), wird das Ergebnis nur verworfen. In der Zwischenzeit werden Sie von der Intranet-Anwendung abgemeldet. Wenn der Angreifer dies alle 2 Sekunden über eine Registerkarte auslöst, die Sie eine Weile geöffnet haben, können Sie das Intranet möglicherweise nicht verwenden, da Sie weiterhin abgemeldet sind.

Erinnern Sie sich an den riesigen Verstoß gegen Capital One im August 2019?

Die Hauptursache war eine Sicherheitsanfälligkeit in Bezug auf serverseitige Fälschungen (SSRF) in einer internen Capital One-App.

Ja, Sie müssen sich um das sichere Design interner Apps kümmern.

Welche Plattform? Bevor ich in den Ruhestand ging, musste ich sicherstellen, dass alles, was ich schrieb, nicht alle Ausnahmen nicht verarbeiten konnte. Jede nicht behandelte Ausnahme würde dem Benutzer ein Popup-Fenster anzeigen, in dem er aufgefordert wird, Daten an Microsoft zu senden, die persönliche Informationen enthalten könnten, deren Verwendung Microsoft verspricht.

Natürlich klicken die meisten Benutzer sofort auf OK, ohne sie zu lesen. Unabhängig davon, ob Microsoft dieses Versprechen einhält oder nicht, würde das Senden der Daten das Krankenhaus gemäß HIPAA strafrechtlich verfolgen. Laut HIPAA muss Microsoft uns melden, wenn Patienteninformationen erkannt werden.

MacOS verfügt über ein ähnliches Popup. Wenn der Benutzer es in den Einstellungen nicht im Voraus deaktiviert, sendet IOS die Daten ohne Aufforderung .

Und dann gibt es noch Android, das von einem der größten Konkurrenten der NSA codiert wurde.

Die Antwort lautet also "Ja" für jede dieser Plattformen.

Absolut 100% Ja .

Aus allen angegebenen und einem sehr wichtigen praktischen Gründen: Sie wissen nie, an welchem ​​Tag sich jemand im Management entscheidet, das Ding auf den Tisch zu legen Internet. "Es funktioniert so gut, dass unsere externen Auftragnehmer es verwenden sollten." oder aus einem anderen Grund.

Sie möchten es in diesem Fall komplett umgestalten?

In einem Unternehmen kommt es häufig vor, dass Mitarbeiter ein internes Tool gerne verwenden, es einem Partner oder Kunden gegenüber erwähnen und dann verlangen, dass das Tool externen Benutzern zur Verfügung gestellt wird.

Ja, treffen Sie einige Sicherheitsvorkehrungen für das Tool und schließen Sie sich nicht aus, es in Zukunft zu sichern. Die einfachsten Dinge reichen weit, wie "Erstellen eines dedizierten Benutzers anstelle von root für diesen Prozess" und "Beschränken der Sichtbarkeit von Benutzer und Prozess nur auf Dinge, die das Tool benötigt"

Ich werde hier eine pauschale Erklärung veröffentlichen, aber wenn Ihre Bewerbung professionell codiert ist und den Best Practices folgt, sollte sie sofort ziemlich sicher sein. Zumindest die häufigsten Sicherheitslücken wie SQL Injection sollten nicht ausgenutzt werden können.

Und die heutzutage verfügbaren Entwicklungsframeworks erleichtern Ihnen die Arbeit tatsächlich. Wenn Sie andererseits der Entwicklungsgeschwindigkeit Vorrang vor der Qualität einräumen, wenn Sie sich an die Codierungsrichtlinie aus den 90er Jahren halten, wenn Sie keine parametrisierten Abfragen verwenden ... dann fragen Sie nach Problemen.

Zumindest sollten Sie Ihre Anwendung pentest, um sicherzustellen, dass die offensichtlichsten Fehler nicht in Ihrem Code enthalten sind und dass ein Skriptkind Ihr System nicht durch einen automatisierten Angriff gefährden kann.

Wie Tom sagt, Dinge, die heute isoliert sind, können morgen aufgrund einer Verwaltungsentscheidung oder einer Fehlkonfiguration von Router / Firewall im Internet verfügbar gemacht werden. Die Anwendung wird möglicherweise versehentlich angezeigt, ohne dass Sie es merken oder nachdem Sie das Unternehmen verlassen haben.

Und Sie wären überrascht, wie gelangweilt Mitarbeiter ihre Freizeit verbringen. Ich habe einmal einen Port-Scanner auf der Workstation eines Verwaltungsangestellten gefunden, der definitiv keine Computerkenntnisse besitzt. Das Werkzeug ist nicht zufällig dort gelandet. Zu oft sind Mitarbeiter das schwache Glied in jeder Organisation.

Dann hängt das angemessene Maß an Paranoia davon ab, auf welche Arten von Assets Ihr Intranet Zugriff gewährt. Wenn die Assets ziemlich sensibel sind und die Anwendung eines Tages gehackt wird, könnte Ihr Job in Gefahr sein, wenn die forensische Untersuchung ergibt, dass Ihr Code schlampig war und nicht den Mindeststandards für die Sicherheit entsprach. Das schlimmste Szenario ist, dass Sie von Ihrem Arbeitgeber / Kunden wegen Fehlverhaltens verklagt werden - es muss sicherlich von Zeit zu Zeit passieren.

Ich frage mich, was mit den IT-Mitarbeitern passiert ist, die bei Equifax gearbeitet haben?

Berücksichtigen Sie auch die Netzwerktopologie. Wenn das Intranet intern gehostet und direkt mit Ihrem LAN verbunden ist, ist es ein Gateway zu Ihrem LAN und anderen Ressourcen. Wenn ich ein Angreifer bin und in Ihr System eindringen möchte, werde ich nach Schwachstellen suchen, indirekten, aber übersehenen Routen.

Also würde ich die Frage folgendermaßen umformulieren: Unter welchen Umständen braucht man das nicht Sicheres Software-Design?

Denken Sie an Ihren Arbeitgeber / Kunden, aber auch an Ihren Ruf. Es besteht eine gute Chance, dass eines Tages jemand anderes Ihren Code überprüft. Zum Beispiel ein anderer IT-Mitarbeiter, der in Zukunft mit der Migration der Anwendung beauftragt ist. Jemand, der vielleicht besser informiert ist als Sie und nichts Nettes zu sagen hat, wenn Sie sich Ihren Code ansehen.