Diskussion über die Sicherheitsprobleme der PHP-Schreib-APP-Schnittstelle

Bevor Sie dieses Problem besprechen, müssen Sie bestätigen, dass Sie als Internet-Programmierer, unabhängig davon, ob Sie ein Front-End oder ein Back-End sind, ein gewisses Verständnis für http-Anfragen haben und die Eigenschaften von http kennen müssen , und seien Sie klar: Verstehen Sie, was Anfrage und Antwort in http sind, warum es Cookies und Sitzungen gibt und welche Bedeutung und Notwendigkeit Verifizierungscodes auf Websites haben. Denn wenn es um die Sicherheit von APP-Schnittstellen geht, geht es um die Sicherheit von HTTP-Anfragen.

Ich teile APP-Schnittstellen im Allgemeinen in drei Kategorien ein: gewöhnliche Schnittstellen, Formularschnittstellen und Mitgliedsschnittstellen.

Gemeinsame Schnittstelle

ist im Allgemeinen eine GET-Anfrage, z. B. das Abrufen einer NachrichtenlisteGET http://Example.com/index.php?module=news&action=list Um eine Erfassung oder heftige Abfrage zu verhindern, führt unsere PC-Seite im Allgemeinen die folgende Verarbeitung durch:

1. Um zu verhindern, dass diese Site von anderen Sites file_get_contents wird, ist es notwendig, den user_agent zu identifizieren. Wenn er nicht über einen Browser aufgerufen wird, wird er nicht direkt angezeigt.
   
2. Wenn andere Benutzer durch Fälschung von user_agent besuchen, wird der Crawler durch die Anzahl der IP-Besuche pro Zeiteinheit gesteuert. Sie können eine Reihe von Algorithmen schreiben, wenn mehr als eine Minute zuvor eine andere IP vorhanden ist danach, wie viele Besuche zu bewältigen sind. Es kann jedoch vorkommen, dass eine bestimmte Community oder ein bestimmtes Unternehmen das externe Netzwerk einer bestimmten IP verwendet. Dies führt zu einer Sackgasse. Daher ist es erforderlich, mit dem Cookie im Browser zusammenzuarbeiten, um
   Zusammenfassung: Anfrage zu bearbeiten Der Header kann gefälscht, die IP-Adresse geändert und die Cookies gelöscht werden. Grundsätzlich ist es schwierig, dieses Problem auf der PC-Seite zu verhindern. Ich sammle beispielsweise häufig Daten von großen Websites wie Taobao und Dianping.

Wie geht die APP mit diesem Problem um? Wir können uns das http-Anforderungspaket der Dianping-APP schnappen und einen Blick darauf werfen:

<code>GET http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 HTTP/1.1
Host: 114.80.165.113
Accept: */*
pragma-appid: 351091731
pragma-newtoken: c2032338f6abf96c8e2984db1655f2bac73b88f799e49aab4a426d414f994b5f
pragma-token: 73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff
pragma-dpid: 9214560561001942797
pragma-device: 566fe5aeb75a827967fbad8356608134ba98a4a6
Proxy-Connection: keep-alive
pragma-os: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0)
Accept-Language: zh-cn
network-type: wifi
User-Agent: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0) Paros/3.2.13 </code>

Wenn Sie direkt auf http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 zugreifen, Blockieren Sie es direkt von der Serverseite und geben Sie einen 450-Fehler zurück.

Der PHP-Server ist im Allgemeinen Apache oder Nignx. Gemäß der Vereinbarung mit dem Client-Entwickler können wir auch einige benutzerdefinierte Anforderungen verwenden. Header-Informationen, wie z. B. parama-* oben, können Sie diese benutzerdefinierten Request-Header-Informationen in den Serverkonfigurationselementen abrufen und sie dann in 450 umschreiben, je nachdem, ob es sich um die vereinbarten Request-Informationen handelt

Aber wir können Erhalten Sie alle Anforderungsheaderinformationen, indem Sie das Paket erfassen, und dann können wir die Anforderungsheaderinformationen vollständig simulieren, um die Daten zu erhalten

Viele APPs können die API-Schnittstelle höchstens in diesem Schritt abrufen , und es liegt im JSON-Format vor, das sehr einfach zu verarbeiten ist, und die Dianping-APP gibt direkt eine Reihe verstümmelter Daten zurück, die aussehen, als wären sie komprimiert worden:

Dies ähnelt in gewisser Weise der PC-Seite gzip, Server Der Client gibt gzip-komprimierte Daten zurück, und der Browser dekomprimiert die gzip, um die echten Daten zu erhalten, und zeigt sie dann an.
Ich weiß nicht, ob die verstümmelten Daten in der Überprüfung ebenfalls auf diesem Prinzip basieren Ich muss also sagen, dass es wirklich „großartig“ ist, da der Dekomprimierungsalgorithmus in der APP selbst ausgeführt wird, was nicht nur die Datensicherheit gewährleistet, sondern auch Bandbreite spart und die Datenübertragung beschleunigt. Wie es gemacht wird, ist noch nicht bekannt;

Formularschnittstelle

ähnelt dem From-Formular in HTML, das hauptsächlich Daten an den Server übermittelt. Im Allgemeinen handelt es sich um eine Post-HTTP-Anfrage. Die Hauptgefahr besteht darin, HTTP-Anfragen zu erzwingen und die Datenbank zu platzen. Auf der PC-Seite lösen wir dieses Problem normalerweise durch Bestätigungscodes, aber auf der APP-Seite fällt mir nur Folgendes ein Die Weitergabe von Bestätigungscodes besteht lediglich darin, dass die PC-Seite den Bestätigungscode in der Sitzung speichert, während die APP-Seite ihn im Cache speichert. Wenn jedoch der Bestätigungscode hinzugefügt wird, wird dies definitiv stark beeinträchtigt Eine bessere Lösung dafür ist noch unbekannt.

Mitgliederschnittstelle

Die sogenannte Mitgliederschnittstelle ist eine Anfrage ähnlich zu http://Example.com/index.php?module=users&action=info&user_id=333 und dann direkt zum Server Führt den entsprechenden Mitgliedschaftsvorgang basierend auf der Benutzer-ID durch. Dies ist eine äußerst gefährliche Schnittstellenverarbeitung, die dem Offenlegen des gesamten aktuellen Mitgliedschaftssystems entspricht. Solange die andere Partei die Benutzer-ID ändert, können die allen Mitgliedern entsprechenden Schnittstellen betrieben werden.
Im Allgemeinen verwenden wir auf der PC-Seite verschlüsselte Cookies, um Mitglieder zu identifizieren und Sitzungen aufrechtzuerhalten. Cookies gehören jedoch zur lokalen Speicherfunktion des Browsers. Die APP-Seite kann nicht verwendet werden, daher müssen wir Mitglieder über Token-Parameter identifizieren. Wie gehen wir mit diesem Token um?

Lassen Sie mich zunächst über die vier Lösungen sprechen, die ich vor der Verschlüsselung dieser Schnittstelle durchlaufen habe:

Option 1
Vereinbaren Sie mit dem APP-Entwickler einen bestimmten MD5-Kombinationsalgorithmus und dann Vergleichen Sie die beiden Enden, wenn sie gleich sind, erlauben Sie sie, wenn nicht, verweigern Sie sie. Dies ist jedoch auch unsicher. Wenn das APP-Programm dekompiliert wird, werden diese vereinbarten Algorithmen angezeigt, insbesondere in Android-APPs , Sie können die Schnittstellenanforderung vollständig simulieren und die Überprüfung bestehen;

Option 2
Das Passwort in der Datenbankmitgliedschaftstabelle ist ein MD5-Wert mit zufälliger Verschlüsselung und doppelter Verschlüsselung. Wenn sich der Benutzer anmeldet, gebe ich die entsprechende UID und das Passwort des Mitglieds zurück , andere Sie können sich nicht anmelden, selbst wenn Sie es wissen. Jedes Mal, wenn Sie die Schnittstelle anfordern, können Sie das Token, das der aktuellen UID entspricht, schnell über die Primärschlüssel-UID finden Dann vergleichen Sie es;user_id=333&token=aa37e10c7137ac849eab8a2d5020568fAber diese Idee ist zu einfach. Obwohl sich die Person, die das Paket erfasst hat, nicht über das Chiffretext-Passwort beim Mitglied anmelden kann, kann sie es, sobald sie das Token kennt, es sei denn, der Benutzer ändert das Passwort Verwenden Sie immer das Token, um die zugehörigen Schnittstellen des Mitglieds zu betreiben. Option drei
verwendet einen symmetrischen Verschlüsselungsalgorithmus, der eine zeitkritische Verschlüsselung auf

durchführt und innerhalb eines bestimmten Zeitlimits verfügbar ist. Wenn sich das Mitglied erfolgreich anmeldet, verschlüsselt der Server die ID und gibt sie an den Client zurück. Der Client bringt diesen Parameter jedes Mal mit, wenn er die Schnittstelle anfordert, und der Server authentifiziert sich durch Entschlüsselung.

Dies ist jedoch ebenfalls unsicher. Denn um uns von außen zu schützen, können wir uns nicht von innen schützen. Ich habe gehört, dass der Ctrip-Ausfall dieses Mal auf die böswillige Vorgehensweise von zurückgetretenen internen Mitarbeitern zurückzuführen ist. Wenn interne böswillige Mitarbeiter die entsprechenden Algorithmusregeln kennen, können sie relevante Mitglieder über die Schnittstelle bedienen, auch wenn sie keine Datenbankberechtigungen haben.
uid 网站公钥Option 4
Wenn sich Mitglieder anmelden, fordern sie die Anmeldeschnittstelle an Dann wird vom Server ein Token an den Client zurückgegeben. Die Regel zum Generieren des Tokens ist

. Entscheiden Sie je nach Bedarf, ob das Token in den Cache gelegt werden soll, und warten Sie, bis es automatisch abläuft. oder legen Sie es in die Datenbank ab (wenn Sie es in die Datenbank einfügen möchten, ziehen Sie es separat heraus. Verwenden Sie eine Tabelle, um die Anmelde- und Abmeldezeit des Benutzers aufzuzeichnen) und ändern Sie es, wenn sich der Benutzer abmeldet, um sicherzustellen, dass das Token nur sein kann Wird zwischen der manuellen Abmeldung und der Anmeldung des Benutzers verwendet.

Um die Sicherheit zu gewährleisten, sollte es Benutzern möglich sein, sich innerhalb eines bestimmten Zeitraums automatisch abzumelden; diese Lösung kann in Kombination mit Linux und der Datenbank-Berechtigungsverwaltung sowohl externen als auch internen Schutz verhindern.
网站公钥 当前uid 当前时间戳 一段随机数Vorsichtsmaßnahmen für die Entwicklung anderer Schnittstellen

Es ist am besten, Daten im JSON-Format zu verwenden, da JSON eine bessere plattformübergreifende Leistung bietet. Bei der Generierung von JSON sollten Sie auf die beiden Formate von json achten: Objekt (Wörterbuch) und Array. In PHP gibt es kein ähnliches Foreach. Es kann keine Objekte durchlaufen, sondern nur Arrays Im Allgemeinen wird der Schlüsselwert über den Schlüsselnamen ermittelt.

1. Ob Erfolg oder Misserfolg. Die Schnittstelle muss eindeutige Datenstatusinformationen bereitstellen und kann nicht NULL zurückgeben. Wenn NULL zurückgegeben wird, stürzt sie auf der IOS-Seite ab.
   
2. Das Obige hat die erste Diskussion über die Sicherheitsprobleme beim Schreiben von APP-Schnittstellen in PHP eingeleitet, einschließlich Aspekten des Inhalts. Ich hoffe, dass es für Freunde hilfreich sein wird, die sich für PHP-Tutorials interessieren.