website lädt oft ewig

Silas6473

Silas6473

New Member
Hallo, habe eine kleine Website erstellt mit php Scripts und Datenbank Verbindungen wo man punkte sammelt ... seit dem es etwas komplexer an Code wurde , was wie ich finde aber immer noch sehr wenig ist , ist oft das problem dass die Seite einfach nicht mehr lädt, z.b. nach dem einloggen ... nach 1-2 Minuten ist man plötzlich eingeloggt. warte ich nicht und lade einfach neu passiert auch nichts , gehe ich auf die Startseite das selbe . habe das ganze inkongnito gemacht , schließe ich den Tab und gehe neu inkognito drauf lädt die Startseite wieder und beim einloggen hängts wieder ...

Was mir aber auch aufgefallen ist : wenn es ewig lädt und ich auf X.de/GibtsNicht gehe lädt dieser tab auch ewig obwohl er dann auf die startseite weiterleiten soll, aber bestimmt lädt die auch nur ewig weil er eben nicht weiterleiten kann auf die index... leere ich den Inhalt der index und drücke f5 lädt es plötzlich.

Was kann das sein ?? bzw. kann ich irgendwie rausfinden warum es so ewig lädt ?
 
Meine sagt:
• falsches PHP verwendet
• ineffizient programmierte PHP-Programme
• ineffizientes Javascript
• Programmfehler
• Datenbank-Server nicht optimal konfiguriert
• Webserver überlastet
• Speichermangel
• überlasteter Server (CPU-Leistung, Verbindungen)
usw.

Das kann man so nicht sagen woran es liegt.
Ezähl’ halt, was du verwendest (Server/PHP/Webserver etc)?
 
Last edited by a moderator:
melde dich bei mir mal via PM mit Kontaktdaten dan kann man sich das ggf mal anschauen ;)

Aufgrund von fehlenden infos über das System kann man sonst nur seine Classkugel benutzen :)

lieben gruß
 
Als Entwickler kann man problemlos die eigenen Anwendungen profilen, was sehr primitiv z.B. mit Timestamps passieren kann.
Dann hat man zumindest schon mal einen guten Anhaltspunkt, wo es hakt.

So deckt man auch Probleme mit der Umgebung an sich auf, da man gut einordnen kann, was zu diesem Zeitpunkt im Code passiert und dann schnell raus findet, ob es am eigenen Algorithmus liegt oder ob etwas in der Umgebung zu Problemen führt.

Ps: am besten schon beim Design der Anwendung solche Möglichkeiten mit Bedenken, weil das später oft eine elendige Fummelei wird und u.U. dann zu Spaghetticode und anderen Unschönheiten führt.
 
Last edited by a moderator:
Alternativ kann man bei eigenen Server die PHP-Erweiterung xdebug benutzen und die generierte Profiliing-Datei mit Cachegrind-Clients auslesen - was zumal für fremden Code Wunder wirken kann.
GET-Anfragen kann man oft auch über strace debuggen was aber nur Hänger im PHP-Skript aufweist.
 
also ich habs jetzt mal einfach gemacht und teilweise code-stücke rausgenommen, und ich glaube es liegt daran...

PHP: 
<?php
session_start();
if(isset($_SESSION['nickname'])) {
	$id=$_SESSION['id'];
	$pdo=new PDO('mysql:host=localhost;dbname=XX', 'XX', 'XX');

	$sql="SELECT punkte FROM users WHERE id=$id";
	foreach ($pdo->query($sql) as $row) {
		$punkte=$row['punkte'];}
	$sql="SELECT email FROM users WHERE id=$id";
	foreach ($pdo->query($sql) as $row) {
		$email=$row['email'];}}?>


denn hängt es und nehme das raus, speichere, drücke f5 lädt es direkt, 5x getestet.

habe noch mehr da raus genommen, und entferne ich das session_start lädt es immer ... aber was bringt den da zum hängen??
 
Zudem es recht unsinnig ist 2 Mal die gleiche Tabelle mit der gleichen WHERE-Klausel abzufragen, nur um im Anschluss eine Schleife über die Ergebnisse zu drehen.

Eine Abfrage mit "punkte, email" würde es auch tun...

Ohne auf die Laufzeit zu schauen und ggf. mal die Logfiles der Datenbank zu durchsuchen wirst du hier nicht weiterkommen.

Weiterhin kenn ich mich zwar nicht zu 100% mit PHP->MySQL aus, könnte mir aber gut vorstellen, dass du durch deine Abfrage einer SQL-Injection alle Türen öffnest...

Gruß
Markus
 
Uiihh, unserialize. Wenn du dem Content entfernter Seiten so vertraust. :eek:
Warning
Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes. Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user.
Click to expand...
http://php.net/manual/en/function.unserialize.php

Was hast du gegen eine sicherere Methode?
Man sollte niemals so einfach den angelieferten Daten trauen ohne sie zu validieren. PHP erzeugt nicht automatisch Sicherheit für dich. :confused:

Und was war das Problem genau? Das Deserialisieren kaputter Daten oder den Content entfernt abholen oder wie?
 
Last edited by a moderator:
Wooohoooo!!!! Keine prepared statements sondern lieber String-concatenation mit Variablen, die potenziell ungewünschten Inhalt haben können. Auch wenn man sich 100% sicher ist im Gesamtkonstrukt - wenn es an der Stelle nicht untainted aussieht, dann ist es als tainted zu behandeln.

Was ist so verdammt schwer daran, einen numerischen Wert zu erzwingen, wenn man schon den Query selber zusammen bauen muss?
Code: 
$query = sprintf("SELECT whatever FROM table WHERE id=%d", $id)
Dieser Code garantiert, dass im Query _immer_ nur ein Integer landen kann. Und so viel mehr Tastendrücke sind das ja nun wirklich nicht... Oder doch?

Und remote content 1:1 als query-string verwenden - keine weiteren Fragen...


Und als kleiner Bonus: PDO unterstützt nativ prepated statements. Es gibt also keine Entschuldiging für zusammengepfriemelte Queries. Mein oben stehendes Beispiel ist also legacy (ja, ich habe seit PHP5 nicht mehr ernsthaft neuen Code geschrieben) und was man eigentlich machen will ist prepated Statements zu verwenden.
 
Last edited by a moderator:
Ich kann nur hoffen, dass so ein Code nicht so auf einem von Außen erreichbaren Server liegt und es nur ein Test auf einem lokalen Entwicklungsrechner ist.
Ansonsten bietet nämlich so ein PHP-Code genügend Einfallstore für Einbrüche und Datenveränderung. :cool:

SQL aus von Außen gelieferten Daten und Variablen in Strings zusammen zu basteln ist riskant.
http://bobby-tables.com/

Betrachte alle Variablen und Daten von Außen als tainted (unsicher, "verschmutzt").
Deswegen ist es sinnvoll die Daten zu prüfen und auszuschließen.

Benutzte Prepared Statements bei SQL.
https://www.php-einfach.de/mysql-tutorial/php-prepared-statements/

Benutze LIMIT bei SQL-Abfragen damit nur eine bestimmte Anzahl von Ergebnissen geliefert wird. So vermeidest du mögliche Speicherengpässe und lahmende Abfragen.
 
Ich kenne es von Pyhon. Never trust userinput, NEVER. Dort wird z.B. das MySQL Statement getrennt von den Daten als Argument übergeben. Das Escaping übernimmt dann der Treiber. Somit können schon mal keine Daten durchkommen, die als MySQL Statement interpretiert werden könnten, durchrutschen. Das ist aber nur die halbe Miete. Davor muss auch die Eingabe validiert werden, ob diese Gültig ist und nicht irgend einen Mist enthält, der Später als Code an anderer Stelle ausgeführt werden könnte. So könnte jemand z.B. JavaScript mit einfügen, der dann später beim Client ausgeführt wird oder halt anderer Code der sogar vom Server ausgeführt werden könnte.


Das gilt nicht nur für Datenbanken, sondern auch für Serialisierungsformate wie z.B. JSON. JSON ist gültiger JavaScript-Code und wer das so direkt übergibt und es vorher nicht parst, hat ein dickes Problem.

Bei XML geht es weiter. Viele wissen gar nicht, was das Format so alles kann (Schleifen z.B.). Die Parser müssen dümmer gemacht werden, sofern man mit Daten aus externen Quellen arbeitet.

YAML ist auch so ein Kandidat. In diesem Serialisierungsformat kann man Statements/Code verschiedener Sprachen implementieren. Bei Python ist es sogar so schlimm, dass der Parser so lieb ist und für einen die Module automatisch importiert, wenn z.B. aus einer externen Quelle etwas heruntergeladen werden sollen. Ganz böse. Viele der Implementierungen haben bereits einen safe_parser, der das nicht macht.

Das alles muss man einfach wissen, damit einem das nicht um die Ohren fliegt. Die meisten Tutorials weisen auf die Probleme nicht hin. Die Neulinge erfahren das erst, wenn die Kacke so richtig am dampfen ist. Lieber immer vorher Gedanken machen, wie etwas gebrochen werden kann, sobald man Daten akzeptiert, parst und weiterverarbeitet.

Ein anderes sehr einfaches Beispiel sind z.B. HTML-Formulare. Akzeptierst du die Eingaben des Nutzers ohne die zu validieren, hast du eine Sicherheitslücke. Dann kamen welche auf die Idee die Daten auf dem Client mit JavaScript zu validieren. Was passiert, wenn den Request direkt sendet? Richtig, dann ist kein JavaScript da, was die Daten validieren kann. D.h. auf dem Server müssen die Daten nochmals validiert werden. Sonst rutscht das einfach so durch.


Die Entwickler der Bibliotheken machen aber auch den Fehler, dass sie dem Endanwender meist zuerst die unsichere Lösung liefern und genau ein Absatz darunter steht dann die sichere Version mit dem Hinweis. So weit kommt der Anfänger aber gar nicht. Er freut sich die Lösung schnell gefunden hat und liest gar nicht mehr weiter. Zu allen meinen genannten Beispielen wirst du reale Lücken im Netz finden. Die Datenbanken sind voll damit. Du als Entwickler hast immer das Problem, dass du ALLE Angriffsvektoren kennen musst. Hast du nur eine ausgelassen, finden die anderen das auch.
 
You must log in or register to reply here.
Back
Top