Fünf Fragen, die Sie sich vor dem Erstellen eines Webprojekts stellen sollten

Es gibt eine Million Gründe für das Scheitern von Technologieprojekten. Falsch kalkulierte Geschäftsmodelle, überschätzte Nachfrage oder explodierende Kosten, Sie nennen es. Aber im Laufe meines Berufslebens habe ich so manches Projekt mit brillanten Ideen und großem Potenzial an scheinbar kleinen Fehlern und Versehen scheitern sehen. Und ich denke, dieser Grund ist der bitterste von allen, zumindest für mich als Entwickler. In diesem Artikel möchte ich meine Erfahrungen teilen und die Probleme und Herausforderungen analysieren, mit denen Backend-Entwickler bei der Arbeit an Webanwendungen konfrontiert sind. Ich werde wichtige Punkte hervorheben, die oft übersehen werden, und erklären, wie man diese Hindernisse mit maximaler Effizienz angeht. Ich bin sicher, dies wird Ihnen helfen, Risiken zu minimieren und die Erfolgschancen Ihres Projekts deutlich zu erhöhen.

1. Sind in Ihrem Code irgendwelche Geheimnisse gespeichert?

So offensichtlich es auch klingen mag, dieser Punkt ist entscheidend: Speichern Sie niemals vertrauliche oder sensible Informationen in Ihrem Quellcode. Verstöße können zu finanziellen Verlusten und anderen schwerwiegenden Problemen führen. Zu den sensiblen Informationen, die niemals im Code gespeichert werden sollten, gehören:

• API-Schlüssel und Zugriffstoken für interne oder externe Dienste
• Passwörter und Kontodaten, einschließlich Passwörter für Datenbanken und Administratorsysteme
• Verschlüsselungsschlüssel
• Konfigurationsdateien mit sensiblen Daten
• Antworten auf Sicherheitsfragen wie Mädchenname der Mutter oder Name des Haustiers

Anstatt solche Informationen in Ihrem Projektcode zu speichern, verwenden Sie Umgebungsvariablen. Für sicherere Systeme sollten Sie robuste geheime Speicherlösungen verwenden wie HashiCorp Tresor . AWS Secrets Manager oder GitHub-Geheimnisse kann ebenfalls nützlich sein. Die Wahl der geheimen Speichertools hängt von Faktoren wie Projekttyp und -größe, der Erfahrung des Teams und dem Technologie-Stack ab.

Wenn Sie denken, dass das Speichern vertraulicher Informationen im Anwendungscode kein ernstes Problem darstellt, bedenken Sie Folgendes: Allein im Jahr 2022 entdeckte GitHub über 1,7 Millionen potenzielle Geheimnisse in öffentlichen Repositorien offengelegt. Stellen Sie sich vor, wie viele solcher Daten in privaten Projekten existieren könnten, bei denen die Entwickler potenzielle Lecks erst bemerken, wenn sie auftreten.

Lösung: Prüfen Sie Ihr Projekt gleich jetzt

Wenn Sie bereits ein Projekt haben und sich nun Sorgen um Geheimnisse in Ihrem Code machen, gibt es praktische Lösungen, die Ihnen Sicherheit geben können. Manuelle Überprüfungen können zeitaufwändig sein, daher ist Automatisierung der Schlüssel. Nützliche Tools sind:

• TrüffelSchwein : Sucht nach Geheimnissen in Git-Repositorys, indem der Commit-Verlauf nach API-Schlüsseln und anderen vertraulichen Daten durchsucht wird.
• GitLeaks : Erkennt fest codierte Geheimnisse wie Passwörter, API-Schlüssel und Token in Git-Repositorys.
• GitGuardian : Funktioniert in Ihrer lokalen oder CI-Umgebung, um über 350 Arten von Geheimnissen und andere Sicherheitslücken zu finden.
• Erweiterte Sicherheit für GitHub : Durchsucht Repositories automatisch nach bekannten Geheimnistypen und benachrichtigt Sie, wenn welche gefunden werden.

Diese Tools sind nur einige Beispiele. Weitere beliebte Optionen sind SonarQube Und Checkmarx . Beide bieten kostenpflichtige und kostenlose Lösungen für unterschiedliche Anforderungen und Budgets. Das Ziel hier ist nicht, alle verfügbaren Tools aufzulisten, sondern die Existenz dieser Probleme und mögliche Lösungen hervorzuheben. Das Problem zu erkennen ist die halbe Miete. Jetzt ist es wichtig, Zeit einzuplanen, um es anzugehen und die geeigneten Tools für Ihre Anforderungen auszuwählen.

2. Was wissen Sie über Ihre Bibliothekslizenzen?

Überraschenderweise wird dieses Thema selten diskutiert, und einige Entwickler sind sich nicht einmal bewusst, dass die Verwendung von Drittanbieterlösungen zu rechtlichen Problemen und erheblichen Problemen für ihr Unternehmen führen kann. Sie glauben mir nicht? Stellen Sie sich dieses Szenario vor: Ein Entwickler in einem kleinen Unternehmen integriert eine Bibliothek, die unter dem GNU Affero General Public License (AGPL) in einem kommerziellen Webprodukt. Als Copyleft-Lizenz erfordert AGPL, dass jede Software, die unter ihr veröffentlichten Code verwendet, unter denselben Bedingungen verbreitet wird. Das bedeutet, dass der gesamte Code Ihrer Webanwendung, einschließlich einzigartiger Entwicklungen, offen und für die freie Nutzung und Änderung verfügbar sein muss. Da unser Beispielprodukt kommerziell ist, könnte die Bereitstellung des Quellcodes den Wettbewerbsvorteil und das Geschäftsmodell des Unternehmens erheblich beeinträchtigen.

Ernsthafte Probleme können auch bei Projekten auftreten, die Bibliotheken mit Lizenzen verwenden, die eine kommerzielle Nutzung ausdrücklich verbieten. Und wenn überhaupt keine Lizenz vorhanden ist, wird es nicht viel besser: Tatsächlich stellt das Fehlen einer Lizenz ein erhebliches Problem dar, da jeder Code standardmäßig urheberrechtlich geschützt ist. Lizenzen gewähren Benutzern das Recht, den Code unter bestimmten Bedingungen zu verwenden. Ohne Lizenz gibt es jedoch keine Rechtsgrundlage, den Code überhaupt zu verwenden, selbst wenn er öffentlich zugänglich ist.

Beachten Sie, dass Lizenzierungsprobleme Sie je nach Ihrer Gerichtsbarkeit auf unterschiedliche Weise betreffen können: Diese Angelegenheit ist besonders relevant für Länder, die internationale Urheberrechtsabkommen unterzeichnet haben. Beispielsweise hat die Berner Übereinkunft zum Schutz von Werken der Literatur und Kunst, einer der wichtigsten internationalen Verträge in diesem Bereich, derzeit rund 180 Mitgliedsländer. Daher würde die Verwendung von Code ohne ausdrückliche Genehmigung einen Verstoß gegen Urheberrechtsgesetze bedeuten und könnte an vielen Orten weltweit zu Rechtsstreitigkeiten führen. Dies bedeutet jedoch nicht, dass Sie in ein „bequemes“ Land ziehen sollten, nur um alle geschriebenen und ungeschriebenen Regeln zu verletzen. Lassen Sie uns einander respektieren, und wenn jemand nicht möchte, dass seine Entwicklung für bestimmte Zwecke verwendet wird, ist es schon aus menschlicher Sicht am besten, dies nicht zu tun.

Lösung: Verwenden Sie automatisierte Prüfungen und Updates

Wie Sie sehen, sind Lizenzierungs- und Urheberrechtsfragen komplex. Um sich und Ihr Unternehmen im Vorfeld zu schützen, prüfen Sie am besten die Lizenzen der von Ihnen verwendeten Bibliotheken und Software. Bei Bibliotheken ist dies nicht allzu schwierig; moderne Paketmanager verfügen bereits über Tools dafür. In PHP Composer können Sie dies beispielsweise mit dem Befehl ` Komponisten-Lizenzen `, in Python pip durch ` Pip-Lizenzen `, und in Golang können Sie diese Informationen erhalten durch ` go-lizenzen `.

Und vergessen Sie nicht, diese Befehle aufzurufen, wenn Sie Abhängigkeiten aktualisieren (es ist sogar noch besser, diese Überprüfungen zu automatisieren), da sich die Lizenz einer verbundenen Bibliothek in neuen Versionen ändern kann.

3. Ist der Zugriff auf Ihre Entwicklungsversion eingeschränkt?

In der Webentwicklung gibt es häufig mehrere Versionen eines Projekts, z. B. Entwicklungsversion (Dev), Qualitätssicherungsversion (QA), Stagingversion und Produktionsversion. Ich bin häufig auf Szenarien gestoßen, in denen Dev/QA- und Stagingversionen einer Site oder eines Webprojekts für jeden im Internet zugänglich waren. Beunruhigenderweise können Testversionen manchmal von Suchmaschinen effektiver indexiert werden als die Primärversion, was dem Produkt normalerweise schadet.

Das Hauptproblem hierbei ist, dass Testversionen Fehler oder vertrauliche, möglicherweise sogar kompromittierende Informationen enthalten können. Darüber hinaus sind Betaversionen in der Regel anfälliger für Hackerangriffe als die endgültige Produktion. Dies bedeutet, dass ihre Verfügbarkeit das Risiko erhöht, dass ein Angreifer Zugriff auf vertrauliche Daten, internen Code oder sogar den Server selbst erhält. Dies gilt insbesondere, wenn Sie ein Backend für etwas wie eine mobile Anwendung entwickeln, da ein unbefugter Zugriff auf Testversionen der API äußerst gefährlich sein kann.

Abgesehen von Sicherheitsrisiken können doppelte Webseiten sich negativ auf das Ranking in Suchmaschinen auswirken. Suchmaschinen wie Google betrachten diese Duplikate möglicherweise als unerwünschten Inhalt und senken möglicherweise das Ranking der Originalseiten Ihres Projekts oder entfernen sie sogar ganz aus dem Index.

Lösung: Entwickeln Sie Ihre Sicherheitsstrategie von Anfang an

Sparen Sie nicht an Domänen. Wenn Sie eine online zugängliche Testversion benötigen, kaufen Sie eine separate Domäne speziell dafür. Diese einfache, aber effektive Maßnahme verringert Sicherheitsrisiken, da Angreifer normalerweise zuerst Subdomänen überprüfen. Wenn Sie Ihre Testversion auf einer beliebigen Subdomäne der Hauptressource hosten, wird sie zu einem leichten Ziel.

Beschränken Sie den Zugriff auf alle Testversionen. Stellen Sie sicher, dass Dev-, QA-, Staging- und andere Versionen nicht öffentlich zugänglich sind. Konfigurieren Sie sie beispielsweise so, dass sie nur über ein VPN zugänglich sind. Dadurch verringert sich die Wahrscheinlichkeit eines unbefugten Zugriffs, selbst wenn die Testdomäne böswilligen Akteuren bekannt wird.

Schützen Sie Testversionen vor der Indizierung. Auch wenn Ihre Testversionen nur über VPN zugänglich und auf separaten geheimen Domänen gehostet sind, schützen Sie sie mit einer `robots.txt`-Datei oder `noindex`-Meta-Tags vor der Indizierung durch Suchmaschinen. Dieser Schritt ist entscheidend, da Suchmaschinen diese Seiten manchmal auf unerwartete Weise finden und indizieren können.

4. Ist Ihre echte IP-Adresse verborgen? Sind Ihre ungenutzten Ports geschlossen?

Es gibt Sicherheitsregeln, die viele Entwickler gerne übersehen, obwohl sie von entscheidender Bedeutung sind und durch harte Arbeit erlernt wurden. Eine solche Regel besteht darin, die echte IP-Adresse Ihres Projekts immer zu verbergen. Wenn die IP-Adresse Ihrer Server über den Domänennamen ermittelt werden kann, kann dies zu mehreren Problemen führen, beispielsweise:

• DDoS-Angriffe: Angreifer, die die echte IP-Adresse Ihres Projekts kennen, können einen Distributed Denial of Service (DDoS)-Angriff auf Ihren Server starten. Beispielsweise ein DNS-Reflexionsverstärkung Ein Angriff könnte Ihren Server mit einer enormen Menge an Antworten von öffentlichen DNS-Servern überlasten, sodass Ihr Dienst für Benutzer nicht mehr verfügbar wäre und erhebliche finanzielle Verluste entstehen.

  
  

• Identifizieren potenzieller Schwachstellen: Ernsthafte Hacker, nicht nur Amateure, können offene Ports und netzwerkexponierte Software scannen, um Schwachstellen zu finden und auszunutzen. Selbst bei bekannten Diensten wie MongoDB kam es aufgrund von Fehlkonfigurationen zu erheblichen Datenlecks. Viele dieser Probleme könnten durch einfaches Verbergen der echten IP-Adresse vermieden werden.

Lösung: Potenziellen Angreifern das Leben schwerer machen

Indem Sie die echte IP-Adresse Ihres Servers verbergen, machen Sie es Angreifern viel schwerer, Ihr System anzugreifen. Die Verwendung eines Content Delivery Network (CDN) oder von DDoS-Schutzdiensten kann hier sehr effektiv sein. Beliebte Optionen sind CloudFlare , das sowohl CDN-Funktionen als auch DDoS-Schutz kostenlos anbietet, sowie Dienste wie Imperva (vormals Incapsula) mit ähnlichen Funktionen und QRator , das auf den Schutz von Webanwendungen mit einer Web Application Firewall spezialisiert ist. Dies kann jedoch mit Kosten verbunden sein.

Diese Tools können die Sicherheit zwar deutlich verbessern, es sind jedoch noch weitere Aspekte zu berücksichtigen:

• IP-Leck im E-Mail-Header: Wenn Sie Ihren Hauptserver zum Senden von E-Mails verwenden, kann die echte IP-Adresse in den E-Mail-Headern offengelegt werden, was Ihre Sicherheitsbemühungen zunichte macht.

  
  

• IP-Verlauf und Whois-Anfragen: Dienste wie DNS-Verlauf oder Whois-Anfrage kann die historischen IP-Adressen anzeigen, die mit einer Domain verknüpft sind. Wenn Ihre echte IP jemals mit Ihrer Arbeitsdomain verknüpft war, sollten Sie sie ändern.

  
  

• DDoS-Schutz und API-Endpunkte: Seien Sie vorsichtig, wenn Sie DDoS-Schutz für Domänen verwenden, die als API-Endpunkte dienen. Schutzsysteme können Schritte zur Benutzerüberprüfung einführen, die die Funktion Ihrer clientseitigen Anwendungen stören könnten, indem sie JSON/XML-Antworten durch HTML-Code ersetzen.

  
  

• Ausgehende API-Anfragen: Wenn Ihr Server Anfragen an APIs von Drittanbietern sendet, kann er versehentlich seine IP-Adresse preisgeben. Die Verwendung von Proxyservern für solche Anfragen kann hilfreich sein, da das Ändern eines Proxys einfacher ist, als sich mit den Folgen eines Angriffs auseinanderzusetzen.

Denken Sie daran, dass das Verbergen der echten IP-Adresse Ihres Projekts kein Allheilmittel ist. Das Schließen der von Ihrer Software verwendeten Ports vom externen Netzwerk ist nach Möglichkeit unerlässlich. Das Ändern von Standardports ist eine umstrittene Vorgehensweise. Einige Experten argumentieren, dass es Ihr Setup komplizierter macht, ohne nennenswerte Vorteile zu bringen. Häufig ist es vorzuziehen, die Software so zu konfigurieren, dass sie über Unix-Sockets statt über Netzwerk-TCP-Verbindungen interagiert (wenn sowohl Ihr Projekt als auch die Software auf demselben Server laufen). Dieser Ansatz erhöht nicht nur die Interaktionsgeschwindigkeit, sondern verbessert auch die Sicherheit, da keine offenen Ports mehr erforderlich sind.

Stellen Sie bei Datenbankmanagementsystemen (DBMS) oder anderen internen Diensten auf separaten Servern sicher, dass der Zugriff auf bestimmte IP-Adressen beschränkt ist, die Sie streng kontrollieren. Diese Konfiguration verhindert unbefugten Zugriff auf kritische Systeme, fügt eine zusätzliche Sicherheitsebene hinzu und minimiert das Risiko externer Angriffe und Datenlecks.

5. Aktualisieren Sie Projektabhängigkeiten und Software?

Dieser Ratschlag ist ziemlich unkompliziert, wird aber dennoch oft übersehen: Aktualisieren Sie regelmäßig die Abhängigkeiten und die Serversoftware Ihres Projekts. Veralteter und anfälliger Code ist ein Traum für Angreifer, die ihn leicht ausnutzen können.

Lösung: Automatisieren Sie Ihre Updates

Sie müssen nicht alles manuell aktualisieren. Viele Automatisierungstools können Ihnen dabei helfen. Zum Beispiel: Abhängig auf GitHub erkennt automatisch veraltete oder anfällige Abhängigkeiten und schlägt Aktualisierungen vor.

Die Automatisierung der Erneuerung von Sicherheitszertifikaten ist ebenfalls von entscheidender Bedeutung. Wenn Sie Lass uns verschlüsseln Zertifikate können Sie deren Erneuerung automatisieren mit Certbot Abgelaufene Zertifikate können ein echtes Ärgernis sein, aber die Automatisierung ihrer Erneuerung ist eine einfache Aufgabe.

\Dasselbe Prinzip gilt für Serversoftware. Wenn Sie mit Linux arbeiten, insbesondere mit Debian/Ubuntu-basierten Distributionen, Unbeaufsichtigte Upgrades kann die Aufgabe problemlos bewältigen. Für größere Projekte mit vielen Servern können Tools wie Ansible , Koch , Marionette , oder Salz stehen zur Verfügung.

Abschließende Gedanken

Die hier bereitgestellten Tipps sind nur ein Bruchteil dessen, was Backend-Entwickler beachten müssen. Ich habe mich entschieden, wichtige, aber weniger häufig diskutierte Themen hervorzuheben, im Vergleich zu den üblichen, wie SQL-Injektion oder CSRF Anschläge.

Für ein tieferes Verständnis der Sicherheit von Webanwendungen sollten Sie sich die OWASP-Stiftung , eine gemeinnützige Organisation, die wertvolle Ressourcen anbietet. OWASP Top Ten Das auf ihrer Website verfügbare Dokument listet die häufigsten und kritischsten Sicherheitsrisiken für Webanwendungen auf. Sie finden dort auch Informationen zu weniger bekannten, aber ebenso gefährlichen Angriffen.

Ich bin der Meinung, dass die Entwickler-Community sowohl sachkundig als auch unterstützend sein sollte, wenn es darum geht, Erkenntnisse und Erfahrungen auszutauschen. Daher lade ich alle ein, ihre Beobachtungen und Kommentare zu teilen, die für alle, die in der Backend-Entwicklung arbeiten, wertvoll sind!