Das Kundenunternehmen nutzte eine Evaluierungssoftware, um unser Projekt zu bewerten, und fand mehrere Sicherheitslücken, darunter SQL-Injection und XSS-Angriffe. Ich habe mir den Serverprogrammcode angesehen, in dem die Sicherheitslücken auftraten ,Es wurde festgestellt, dass es grundsätzlich Schwachstellen gibt, bei denen die Seite Get- oder Post-Daten an den Server sendet. Das Backend verwendet die mit dem CI-Framework gelieferte Eingabeklasse, um die eingegebenen Informationen zu filtern vom Benutzer, und das Konfigurationselement csrf von CI wurde ebenfalls aktiviert
Testwerkzeuge:
Schwachstellenübersicht:
Es gibt ein paar Kopfschmerzen:
Der ursprüngliche Code zum Empfangen von get- und post-Daten wurde so geschrieben $this->input->get('section_id), und andere Stellen im Projekt empfangen ihn so. Es liegt auf der Hand, dass Filter- und Sicherheitsvorkehrungen getroffen wurden . Warum wird es noch solche Lücken geben?
Wenn es ein Problem mit dem Server gibt, der get、post Daten empfängt, sollten alle Stellen im Projekt, die diese Methode verwenden, Lücken aufweisen. Warum treten solche Lücken nur an wenigen Stellen auf?
Kunden sehen nur Testdaten, wie soll ich es ihnen erklären und mit ihnen kommunizieren?
Bitte geben Sie mir einen Rat~
Das Kundenunternehmen nutzte eine Evaluierungssoftware, um unser Projekt zu bewerten, und fand mehrere Sicherheitslücken, darunter SQL-Injection und XSS-Angriffe. Ich habe mir den Serverprogrammcode angesehen, in dem die Sicherheitslücken auftraten ,Es wurde festgestellt, dass es grundsätzlich Schwachstellen gibt, bei denen die Seite Get- oder Post-Daten an den Server sendet. Das Backend verwendet die mit dem CI-Framework gelieferte Eingabeklasse, um die eingegebenen Informationen zu filtern vom Benutzer, und das Konfigurationselement csrf von CI wurde ebenfalls aktiviert
Testwerkzeuge:
Schwachstellenübersicht:
Es gibt ein paar Kopfschmerzen:
Der ursprüngliche Code zum Empfangen von get- und post-Daten wurde so geschrieben $this->input->get('section_id), und andere Stellen im Projekt empfangen ihn so. Es liegt auf der Hand, dass Filter- und Sicherheitsvorkehrungen getroffen wurden . Warum wird es noch solche Lücken geben?
Wenn es ein Problem mit dem Server gibt, der get、post Daten empfängt, sollten alle Stellen im Projekt, die diese Methode verwenden, Lücken aufweisen. Warum treten solche Lücken nur an wenigen Stellen auf?
Kunden sehen nur Testdaten, wie soll ich es ihnen erklären und mit ihnen kommunizieren?
Bitte geben Sie mir einen Rat~
1 Die Beurteilung dieser Art von Testsoftware ist nicht unbedingt genau. Im Allgemeinen wird nur beurteilt, ob die Zeichenlängen der durch die Verbindung verschiedener Anweisungen zurückgegebenen Ergebnisse gleich sind, um festzustellen, ob eine Injektion vorliegt.
2 Nicht Vertrauen Sie zu sehr darauf, welches Framework oder welches Framework nicht sicher ist. Sie müssen die globale Filterung selbst durchführen
3 Die hier erkannten XSS sind keine Speichertypen, daher ist das Risiko nicht so hoch. Diese Art von Bericht wird am häufigsten als Sprungbrett verwendet.
4 Was der Kunde wünscht, ist die Gewissheit, dass der Bericht keine Lücken enthält.
5 Wenn Sie nur möchten, dass er die Schwachstelle nicht scannt. Schreiben Sie am Programmeintrag eine Protokolldatei und zeichnen Sie alle Anfragen und Parameter auf, um zu analysieren, wie die Scan-Software ermittelt, ob eine Schwachstelle vorliegt.
6 Ändern Sie die Schwachstelle im Bericht der Scan-Software. Aus persönlicher Erfahrung sollte dies so sein, dass die von Ihnen übergebenen Parameter kein Intervall haben.
7 MySQL-Fehleraufforderungen schließen, um eine Fehlerinjektion zu verhindern.
Vorbeugung
1 Fügen Sie dem Programm Word-Filterung den globalen SQL-Schlüssel hinzu
2 Aktivieren Sie PHP-Einzelanführungszeichen-Escape (ändern Sie php.ini magic_quotes_gpc).
3 Apache/nginx/iis ermöglichen Dienstprotokolle, MySQL-Protokolle für langsame Abfragen und Programmeintragsdatensatz-Anforderungsprotokolle
4 Der Server installiert Sicherheitssoftware für Webanwendungen wie SafeDog
5 Verwenden Sie UTF-8 für Datenbankverknüpfungen zu Verhindern Sie die doppelte GBK-Byte-Injektion
6 Erhöhen Sie die Komplexität des MySQL-Passworts, verbieten Sie externe MySQL-Links, ändern Sie die Standardportnummer
7 Reduzieren Sie die Rechte des Programm-MySQL-Kontos und gewähren Sie nur normales Hinzufügen, Löschen, Überprüfen und Ändern Berechtigungen. Es ist verboten, Dateioperationsberechtigungen zu erteilen
XSS-Cross-Site-Angriffslösung
1 Verwenden Sie htmlspecialchars, um zu maskieren, wo Text geschrieben wird.
2 Verwenden Sie SSL, um das Laden und Referenzieren externer JS zu verhindern.
3 Stellen Sie httponly ein, um den Erhalt von Cookies zu verhindern.
4 Bereits gepostet Stellen Sie sicher, dass keine Injektion erfolgt (falls vorhanden, können Sie hexadezimal verwenden, um HTML-Spezialzeichen zu umgehen und den Effekt eines XSS-Angriffs zu erzielen).
5 Es ist am besten, zwei Programmsätze mit unterschiedlichen Routing-Regeln für das Backend und das Frontend zu verwenden . Schlüsseloperationen im Backend (Backup-Datenbank) sollten ein sekundäres Passwort festlegen und die Komplexität der Anforderungsparameter erhöhen, um CSRF zu verhindern
PHP-Sicherheit
1 Fügen Sie beim Hochladen von Dateien eine Suffixfilterung hinzu und treffen Sie beim Filtern keine Urteile mit „logischer Negation“.
2 Es ist verboten, Dateien mit den Suffixen php und htaccess hochzuladen. Verwenden Sie nicht die vom Client übermittelten Daten, um das Suffix und den zufälligen Dateinamen hinzuzufügen Einheitliches Routing zur Begrenzung unbefugten Zugriffs. Das Webroot-Verzeichnis darf nur eine index.php (Eintragsdatei) für den externen Schutz haben. Alle anderen (hochgeladenen) Dateien werden mit der Anti-Leeching-Funktion in nginx hinzugefügt. 4. PHP-Dezentralisierungsverarbeitung . Das Webverzeichnis schränkt die Erstellung von Ordnern und Texten ein (mit Ausnahme der vom Programm benötigten Ordner gibt es normalerweise ein Cache-Verzeichnis, für das Schreibberechtigungen erforderlich sind)
5 Filtern Sie die Verwendung von IIS/nginx-Dateianalyse-Schwachstellen
6 Verwenden Zum Abrufen von Passwörtern, zum Abrufen von Bestätigungscodes für Mobiltelefone und zum Abrufen von E-Mails sollte ein zusätzlicher Server verwendet werden. (Verhindern Sie, dass die echte IP-Adresse über die Passwort-Abruffunktion abgerufen wird.) Der letzte Link zum Zurücksetzen des Passworts, der an die Mailbox des Benutzers gesendet wird, muss über komplexe Verschlüsselungsparameter verfügen
7 Das Benutzeranmeldesystem sollte über eine Single-Sign-On-Funktion verfügen. Wenn sich der Benutzer angemeldet hat, sollten andere Personen zur Anmeldung aufgefordert werden wieder.
8
1 Sicherheitskenntnisse
2 Wenn Sie eine integrierte Umgebung verwenden, sollten Sie die PHP-Probe, phpmyadmin, phpinfo (Probe) danach löschen Die Installation ist abgeschlossen. Die Nadel kann Ihren Webpfad überprüfen und phpmyadmin kann ihn mit Brute-Force knacken)
2 Es ist am besten, den MD5-Wert nach dem Passwort-Salting für das Benutzerpasswort zu verwenden
3 Fügen Sie einen Bestätigungscode hinzu Benutzer meldet sich an, wie man eine Begrenzung der Fehleranzahl hinzufügt, um Brute-Force-Cracking zu verhindern
4 Verwenden Sie die CDN-Beschleunigung, um die echte IP zu verbergen
5 Geben Sie beim Anmelden von Benutzern keine Klartext-Kontokennwörter weiter, um C. zu verhindern -seitiges Schnüffeln und Erhalten von Benutzer- und Administrator-Klartext-Kontokennwörtern durch ARP-Spoofing
6 Deaktivieren Sie PHP-Systembefehle. Anzahl der Zeilen exec, system usw.
7 Installieren Sie Sicherheitssoftware wie SafeDog auf dem Server
8 Die Im Webverzeichnis ist das Speichern von .rar- und zip-Dateien verboten
