Zusammenfassung der PHP-Sicherheitsprobleme

                                                       

1-XSSoCross-Site Scripting (Cross-Site-Script-Angriff), auch XSS genannt, ist ein Code-Injection-Angriff. Angreifer schleusen bösartige Skripte in die Zielwebsite ein, damit sie im Browser des Benutzers ausgeführt werden können. Mithilfe dieser bösartigen Skripte können Angreifer an vertrauliche Informationen der Benutzer wie Cookies, SessionID usw. gelangen und so die Datensicherheit gefährden.

Quelle

UGC-Informationen von Benutzern

• Links von Dritten

• URL-Parameter

• POST-Parameter

• Referer (kann aus nicht vertrauenswürdigen Quellen stammen)

• Cookie (kann von anderen Subdomains injiziert werden)

• Escape, Filter, Länge begrenzen

2-SQL-InjectionDurch SQL-Anweisungen können Sie sich ohne Konto anmelden und sogar die Datenbank manipulieren.

Angriffsbeispiele

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…

Wie man sich gegen SQL-Injection verteidigt

　1. Überprüfen Sie den Datentyp und das Format der Variablen

　2. Filtern Sie spezielle Symbole

　3. Binden Sie Variablen und verwenden Sie vorkompilierte Anweisungen 3-CSRF
CSRF nutzt durch getarnte Anfragen von vertrauenswürdigen Benutzern vertrauenswürdige Websites aus. Ein Angreifer stiehlt Ihre Identität und sendet in Ihrem Namen böswillige Anfragen an Websites Dritter. CRSF kann unter anderem Ihre Identität nutzen, um E-Mails und Textnachrichten zu versenden, Transaktionsübertragungen durchzuführen usw. und sogar Ihr Konto stehlen.

Zum Beispiel:

Wie folgt: Web A ist eine Website mit einer CSRF-Schwachstelle, Web B ist eine bösartige Website, die von einem Angreifer erstellt wurde, und Benutzer C ist ein legitimer Benutzer der Website von Web A

3-1 CSRF-Angriffsprinzip und -prozess Wie folgt:

1. Benutzer C öffnet den Browser, besucht die vertrauenswürdige Website A, gibt den Benutzernamen und das Passwort ein, um die Anmeldung bei Website A anzufordern

2. Website A generiert Cookie-Informationen und gibt sie an den Browser zurück. Zu diesem Zeitpunkt meldet sich der Benutzer erfolgreich bei Website A an und kann normal Anfragen an Website A senden.

3 Bevor der Benutzer Website A verlässt, öffnet er eine TAB-Seite derselbe Browser, um Website B zu besuchen; Der Browser überträgt das Cookie entsprechend der Anfrage von Website B ohne Wissen des Benutzers und stellt eine Anfrage an Website A. Website A weiß nicht, dass die Anfrage tatsächlich von B initiiert wurde, daher verarbeitet sie die Anfrage mit den Berechtigungen von C basierend auf den Cookie-Informationen von Benutzer C, wodurch der Schadcode von Website B ausgeführt wird.

3-2 Abwehr von CSRF-Angriffen

Derzeit gibt es drei Hauptstrategien zur Abwehr von CSRF-Angriffen: Überprüfen Sie das HTTP-Referer-Feld; fügen Sie ein Token zur Anforderungsadresse hinzu und passen Sie es an Überprüfen Sie es.

1-Überprüfen Sie das HTTP-Referer-Feld

Gemäß dem HTTP-Protokoll gibt es im HTTP-Header ein Feld namens Referer, das die Quelladresse der HTTP-Anfrage aufzeichnet. Unter normalen Umständen kommt die Anfrage zum Zugriff auf eine sichere, eingeschränkte Seite von derselben Website. Wenn Sie beispielsweise auf http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory zugreifen müssen, muss sich der Benutzer zuerst anmelden zu bank.example und gehen Sie dann durch. Klicken Sie auf eine Schaltfläche auf der Seite, um das Übertragungsereignis auszulösen. Zu diesem Zeitpunkt ist der Referrer-Wert der Übertragungsanforderung die URL der Seite, auf der sich die Übertragungsschaltfläche befindet, normalerweise eine Adresse, die mit dem Domänennamen bank.example beginnt. Wenn ein Hacker einen CSRF-Angriff auf die Website einer Bank durchführen möchte, kann er nur eine Anfrage auf seiner eigenen Website erstellen. Wenn ein Benutzer eine Anfrage über die Website des Hackers an die Bank sendet, verweist der Referrer der Anfrage auf die eigene Website des Hackers . Um sich gegen CSRF-Angriffe zu schützen, muss die Website der Bank daher nur ihren Referrer-Wert für jede Übertragungsanfrage überprüfen. Wenn es sich um einen Domainnamen handelt, der mit bank.example beginnt, bedeutet dies, dass die Anfrage von der Website der Bank selbst stammt und legal ist. Handelt es sich bei dem Referrer um eine andere Website, handelt es sich möglicherweise um einen CSRF-Angriff eines Hackers und die Anfrage wird abgelehnt.

Der offensichtliche Vorteil dieser Methode besteht darin, dass sie einfach und leicht zu implementieren ist. Normale Website-Entwickler müssen sich keine Sorgen über CSRF-Schwachstellen machen. Sie müssen lediglich am Ende alle sicherheitsrelevanten Anforderungen überprüfen der Referrer-Wert. Insbesondere für das aktuell vorhandene System besteht keine Notwendigkeit, den vorhandenen Code und die Logik des aktuellen Systems zu ändern, es besteht kein Risiko und es ist sehr praktisch.

Diese Methode ist jedoch nicht narrensicher. Der Wert von Referer wird vom Browser bereitgestellt. Obwohl das HTTP-Protokoll klare Anforderungen hat, kann jeder Browser unterschiedliche Implementierungen von Referer haben, was nicht garantiert, dass der Browser selbst keine Sicherheitslücken aufweist. Die Methode zur Überprüfung des Referrer-Werts hängt von der Drittpartei (d. h. dem Browser) ab, um die Sicherheit zu gewährleisten. Theoretisch ist dies nicht sicher. Tatsächlich gibt es für einige Browser wie IE6 oder FF2 bereits einige Methoden, um den Referr-Wert zu manipulieren. Wenn die bank.example-Website den IE6-Browser unterstützt, kann ein Hacker den Referrer-Wert des Browsers des Benutzers auf eine Adresse setzen, die mit dem Domänennamen bank.example beginnt, damit er die Überprüfung bestehen und einen CSRF-Angriff durchführen kann.

Auch wenn Sie den neuesten Browser verwenden, können Hacker den Referrer-Wert nicht manipulieren, diese Methode weist jedoch immer noch Probleme auf. Da der Referrer-Wert die Zugriffsquelle des Benutzers aufzeichnet, glauben einige Benutzer, dass dies ihre eigenen Datenschutzrechte verletzt. Einige Organisationen befürchten insbesondere, dass der Referer-Wert bestimmte Informationen im Intranet der Organisation an das externe Netzwerk weitergibt. Daher können Benutzer selbst ihre Browser so einstellen, dass sie beim Senden von Anfragen keinen Referrer mehr angeben. Wenn sie die Website der Bank normal besuchen, betrachtet die Website die Anfrage als CSRF-Angriff, da die Anfrage keinen Referrer-Wert hat, und verweigert legitimen Benutzern den Zugriff.

2-Token in der Anfrageadresse hinzufügen und überprüfen

Der Grund, warum der CSRF-Angriff erfolgreich sein kann, liegt darin, dass der Hacker die Anfrage des Benutzers vollständig fälschen kann. Alle Benutzerüberprüfungsinformationen in der Anfrage sind im Cookie vorhanden Hacker Sie können das eigene Cookie des Benutzers direkt verwenden, um die Sicherheitsüberprüfung zu bestehen, ohne diese Überprüfungsinformationen zu kennen. Der Schlüssel zum Widerstand gegen CSRF besteht darin, Informationen in die Anfrage einzufügen, die Hacker nicht fälschen können und die in Cookies nicht vorhanden sind. Sie können der HTTP-Anfrage ein zufällig generiertes Token als Parameter hinzufügen und auf der Serverseite einen Interceptor erstellen, um das Token zu überprüfen. Wenn in der Anfrage kein Token vorhanden ist oder der Token-Inhalt falsch ist, wird davon ausgegangen, dass dies der Fall ist ein CSRF-Angriff und die Anfrage wird abgelehnt.

Diese Methode ist sicherer als die Überprüfung des Referrers. Der Token kann dann bei jeder Anfrage aus der Sitzung entfernt und mit dem Token in der Anfrage verglichen werden Die Schwierigkeit bei dieser Methode besteht darin, das Token in Form eines Parameters zur Anforderung hinzuzufügen. Bei GET-Anfragen wird das Token an die Anfrageadresse angehängt, sodass die URL zu http://url?csrftoken=tokenvalue wird. Fügen Sie bei POST-Anfragen am Ende des Formulars hinzu, damit das Token als Parameter zur Anfrage hinzugefügt wird. Es gibt jedoch viele Stellen auf einer Website, an denen Anfragen akzeptiert werden können. Es ist sehr mühsam, jeder Anfrage ein Token hinzuzufügen, und es ist leicht zu übersehen. Die häufig verwendete Methode besteht darin, jedes Mal, wenn die Seite aufgerufen wird, Javascript zu verwenden Für den gesamten Dom-Baum werden Token nach allen a- und form-Tags im Dom hinzugefügt. Dies kann die meisten Anfragen lösen, aber für HTML-Code, der nach dem Laden der Seite dynamisch generiert wird, hat diese Methode keine Auswirkung und erfordert, dass Programmierer beim Codieren manuell Token hinzufügen.

Ein weiterer Nachteil dieser Methode besteht darin, dass es schwierig ist, die Sicherheit des Tokens selbst zu gewährleisten. Insbesondere in einigen Foren und anderen Websites, die Benutzer bei der Veröffentlichung eigener Inhalte unterstützen, können Hacker die Adresse ihrer eigenen persönlichen Websites veröffentlichen. Da das System nach dieser Adresse auch einen Token hinzufügt, können Hacker diesen Token auf ihrer eigenen Website abrufen und sofort einen CSRF-Angriff starten. Um dies zu vermeiden, kann das System beim Hinzufügen des Tokens eine Beurteilung hinzufügen. Wenn der Link zu Ihrer eigenen Website führt, fügen Sie ihn später nicht hinzu. Auch wenn der CSRFtoken nicht in Form eines Parameters an die Anfrage angehängt ist, kann die Website des Hackers dennoch den Tokenwert über den Referrer erhalten, um einen CSRF-Angriff zu starten. Dies ist auch der Grund, warum einige Benutzer die Referrer-Funktion des Browsers gerne manuell deaktivieren.

3-Attribute im HTTP-Header anpassen und überprüfen

Diese Methode verwendet auch ein Token und überprüft es. Anders als bei der vorherigen Methode wird das Token nicht in Form eines Parameters in die HTTP-Anfrage eingefügt es im benutzerdefinierten Attribut im HTTP-Header. Über die XMLHttpRequest-Klasse können Sie das HTTP-Header-Attribut csrftoken allen Anforderungen dieses Typs gleichzeitig hinzufügen und den Token-Wert darin einfügen. Dies beseitigt die Unannehmlichkeiten beim Hinzufügen des Tokens zur Anforderung in der vorherigen Methode. Gleichzeitig wird die über XMLHttpRequest angeforderte Adresse nicht in der Adressleiste des Browsers aufgezeichnet und es besteht kein Grund zur Sorge, dass das Token an andere weitergegeben wird Websites durch den Referrer.

Diese Methode weist jedoch große Einschränkungen auf. Die XMLHttpRequest-Anforderung wird normalerweise für die teilweise asynchrone Aktualisierung der Seite in der Ajax-Methode verwendet. Nicht alle Anforderungen sind für die Initiierung mit dieser Klasse geeignet, und die durch diese Klassenanforderung erhaltene Seite kann vom Browser nicht aufgezeichnet werden, sodass vorwärts und rückwärts , und Aktualisierung kann durchgeführt werden, Sammlung und andere Vorgänge bringen Unannehmlichkeiten für Benutzer mit sich. Darüber hinaus müssen bei Altsystemen ohne CSRF-Schutz alle Anfragen in XMLHttpRequest-Anfragen geändert werden, wodurch fast die gesamte Website neu geschrieben wird

4-CC Angriff

4-1 Das Prinzip des CC-Angriffs:

Das Prinzip des CC-Angriffs besteht darin, dass der Angreifer einige Hosts so steuert, dass sie kontinuierlich eine große Anzahl von Datenpaketen an den Server der anderen Partei senden, wodurch die Serverressourcen beansprucht werden erschöpft sein, bis es abstürzt. CC wird hauptsächlich verwendet, um Serverressourcen zu verbrauchen: Wenn viele Leute eine Webseite besuchen, simuliert CC den unbegrenzten Zugriff mehrerer Benutzer Auf Seiten, die viele Datenvorgänge erfordern (d. h. viel CPU-Zeit), werden Serverressourcen verschwendet. Die CPU ist lange Zeit auf 100 % ausgelastet und es gibt immer unvollendete Verbindungen, bis das Netzwerk überlastet und normal ist Der Zugriff ist gesperrt.

4-2 Arten von CC-Angriffen:

Es gibt drei Arten von CC-Angriffen:

• Direkter Angriff
• Proxy-Angriff
• Botnet-Angriff

Direkter Angriff zielt hauptsächlich auf WEB-Anwendungen mit schwerwiegenden Programmfehlern ab Im Allgemeinen tritt diese Situation nur dann auf, wenn beim Schreiben des Programms ein Problem vorliegt, was relativ selten vorkommt. Botnet-Angriffe ähneln in gewisser Weise DDOS-Angriffen. Sie können nicht von der WEB-Anwendungsebene aus abgewehrt werden, daher handelt es sich bei Proxy-Angriffen um CC-Angreifer. Im Allgemeinen betreiben Angreifer eine Reihe von Proxy-Servern, beispielsweise 100 Proxys, und dann stellt jeder Proxy 10 Anfragen aus gleichzeitig, sodass der WEB-Server 1.000 gleichzeitige Anfragen empfängt und nach dem Senden der Anfrage sofort die Verbindung zum Proxy trennt, um zu verhindern, dass die vom Proxy zurückgegebenen Daten seine eigene Bandbreite blockieren und keine weitere Anfrage initiieren können Zu diesem Zeitpunkt werden die Prozesse, die auf diese Anfragen reagieren, in die Warteschlange gestellt, und das Gleiche gilt für den Datenbankserver. Auf diese Weise werden normale Anfragen am Ende verarbeitet, genau wie wenn Sie in die Kantine gehen Zum Essen stehen heute normalerweise weniger als zehn Personen in der Schlange. Wenn tausend Personen vor Ihnen stehen, ist die Wahrscheinlichkeit, dass Sie an der Reihe sind, sehr gering leer.

4-3 Der Unterschied zwischen CC-Angriffen und DDOS

DDoS ist ein Angriff auf IP, während CC Serverressourcen angreift.

5-DOS-Angriff

DOS: Der chinesische Name ist Denial of Service. Alle Angriffe, die DOS-Verhalten verursachen können, werden als DOS-Angriffe bezeichnet. Die Wirkung dieses Angriffs besteht darin, dass der Computer oder das Netzwerk nicht in der Lage ist, normale Dienste bereitzustellen. Zu den häufigsten DOS-Angriffen gehören Angriffe auf die Bandbreite und Konnektivität des Computernetzwerks. DOS ist ein eigenständiger Angriff zwischen eigenständigen Computern.

Das Prinzip des DOS-Angriffs: Zunächst sendet der Angreifer eine große Anzahl gefälschter IP-Anfragen an den angegriffenen Server. Der Angreifer sendet nach Erhalt der Anfrage Bestätigungsinformationen zurück und wartet auf die Bestätigung durch den Angreifer (Protokollarbeitsmethode und Grundkenntnisse des TCP-Drei-Wege-Handshakes) Dieser Prozess erfordert den Drei-Wege-Handshake von TCP. Da die vom Angreifer gesendeten Anforderungsinformationen falsch sind, kann der Server die zurückgegebenen Bestätigungsinformationen nicht empfangen befindet sich im Wartezustand und ist zugewiesen. Die diesmal angeforderte Ressource wurde nicht freigegeben. Wenn der Angreifer eine bestimmte Zeit lang wartet, wird die Verbindung aufgrund einer Zeitüberschreitung getrennt. Zu diesem Zeitpunkt sendet der Angreifer erneut eine neue Anforderung mit falschen Informationen, sodass die Serverressourcen schließlich erschöpft sind, bis sie lahmgelegt werden.

6-DDOS-Angriff

DDoS-Angriff ist ein verteilter Denial-of-Service-Angriff. Die DDoS-Angriffsmethode ist eine Art Angriffsmethode, die auf einem herkömmlichen DoS-Angriff basiert. Ein einzelner DoS-Angriff wird im Allgemeinen eins zu eins durchgeführt. Mit der Entwicklung der Computer- und Netzwerktechnologie hat die Schwierigkeit von DoS-Angriffen zugenommen. Der DDoS-Angriff ist also sehr einfach: Die Rechenleistung von Computern und Netzwerken hat sich verzehnfacht. Der Angriff mit einer Angriffsmaschine funktioniert nicht mehr, indem man das Opfer angreift in einem größeren Maßstab als zuvor. Zu den häufig verwendeten DDoS-Software gehören: LOIC.
Zwei Punkte sind hier hinzuzufügen: Erstens können DDOS-Angriffe nicht nur Computer, sondern auch Router angreifen, da Router eine besondere Art von Computern sind. Zweitens bestimmt die Netzwerkgeschwindigkeit, wie gut und schnell der Angriff ist In einer Umgebung mit begrenzter Netzwerkgeschwindigkeit ist ihre Angriffswirkung nicht sehr offensichtlich, aber eine schnelle Netzwerkgeschwindigkeit ist im Vergleich effektiver.

Das obige ist der detaillierte Inhalt vonZusammenfassung der PHP-Sicherheitsprobleme. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!