Sicherheitsbedenken Kommunikation mit Datenbank usw.

[Kurzer]

Moin Kollegen,

ich bin noch nicht sehr erfahren was die Programmierung mit SpiderBasic angeht, habe mir aber dennoch vorgenommen ein "mittel-kleines" Projekt mit Spider umzusetzen. Daher werde ich diese Rubrik des Forums in Zukunft vermutlich etwas öfter bemühen.

Bei einigen Themen kann ich nicht einschätzen, ob meine Herangehensweise in Ordnung ist oder ob man das anders besser machen kann.

Worum geht es genau?
Es geht um eine Webanwendung die per Login geschützt sein soll und die über mehrere PHP Module per HttpRequest() kommuniziert, um mit einer Datenbank und dem Filesystem zu interagieren.

Ich habe also einen Programmteil der auf dem Clientbrowser läuft und in Spiderbasic geschrieben sein wird (bzw. nach dem compilieren in JavaScript). Hier ist die gesamte GUI, deren Logik und die Erfassung, Verarbeitung und Anzeige von Daten realisiert.

Der andere Programmteil liegt auf dem Server und wird vom SpiderBasic aktiv aufgerufen. Die Parameter werden per POST übergeben.

Bei folgenden Punkten weiß ich noch nicht wie ich es am besten angehe:

1) Thema Login und Berechtigung, um die SpiderBasic Anwendung überhaupt benutzen zu dürfen.

Wenn ich die Webanwendung in reinem PHP/HTML schreiben würde, dann würde ich einen Login-Screen programmieren und die Berechtigungen des Users nach erfolgreichem Login in einer Sessionvariable speichern. Beim Aufruf von anderen PHP-Seiten, die zu der Anwendung gehören, würde ich dann jeweils die Sessionvariable mit dem Berechtigungslevel auslesen und entsprechend im PHP Skript reagieren (entweder das Skript weiter ausführen oder halt mit einer Hinweismeldung abbrechen, wenn die Berechtigung nicht ausreicht).

Aber wie mache ich das innerhalb von SpiderBasic?
a) Ich könnte den Login-Screen direkt in der SpiderBasic Anwendung realiseren, so dass ich auch direkt in SpiderBasic entscheide, ob der User weiter mit der Anwendung arbeiten darf oder sofort wieder rausgeschmissen wird.

Nun ist SpiderBasic letztendlich JavaScript und läuft auf dem Browser des Anwenders. Wäre es dem Anwender hier nicht möglich den JavaScript Code zu analysieren und zu verändern, um die Login-Prüfung zu umgehen? Das wäre ein Sicherheitsrisiko. Leider kenne ich mich mit JavaScript eher äh nicht aus.

b) Ich könnte den Login-Screen in PHP realisieren, danach direkt die Sessionvariablen mit der Berechtigung des Users füllen und bei erfolgreichem Login zur SpiderBasic Anwendung weiterleiten.

Hier stellt sich trotzdem ein ähnliches Problem. Die Spiderbasic Anwendung wird ja letztendlich durch einen Aufruf der betreffenden *.html Datei gestartet. Die URL der SpiderBasic Anwendung kann man dann entweder direkt in der Adresszeile des Browser sehen oder aber mit Hilfe der Developertools des Browsers. Wenn man diese URL weiß, könnte man sie auch direkt ohne den Loginprozess aufrufen. Dann wäre die Login-Prüfung völlig umgangen.

b2) Ich könnte von der SpiderBasic Anwendung heraus eine Abfrage an den Webserver senden, ob der aktuelle Benutzer die passende Berechtigung hat (HttpRequest() an ein PHP-Skript, welches die Authentifizierung regelt). Aber auch hier gilt wieder: JavaScript läuft auf dem Browser und ich weiß nicht, ab man auch diesen Aufruf bzw. deren Rückgabe als Angreifer kompromittieren könnte.

c) Für zusätzliche Sicherheit könnte ich wie unter b2) vorgehen und mir vom PHP-Authentifizierungsmodul bei ausreichender Berechtigung ein Token zurückgeben lassen. Dieses Token müsste dann bei sämtlicher Kommunikation mit dem Server mitgesendet werden. Also jedes mal, wenn die SpiderBasic Anwendung Dateisystem- oder Datenbankanfragen an den Webserver sendet. Nur, wenn das mitgesendete Token mit dem Token des erfolgreich angemeldeten Benutzers identisch ist, wird die Anfrage ausgeführt.

So könnte ein unberechtigter User zwar die GUI der SpiderBasic Anwendung sehen und teilweise benutzen, aber alles was mit der Serverkommunikation zu tun hat, würde fehlschlagen.

Ob das dann alles ausreichend sicher ist, kann ich nicht beurteilen.

Über Hinweise von Experten zu dem Thema würde ich mich sehr freuen.


2) Parameterübergabe zu einer Spiderbasic Anwendung.
Man kann einem PHP Script per POST oder GET Parameter übergeben. Einem PureBasic Programm kann man auch Parameter übergeben, die man mittels ProgramParameter() abrufen kann.

Für SpiderBasic habe ich so etwas noch nicht gefunden.

Dabei wäre es auch im Hinblick auf die Login-Thematik evtl. sinnvoll, wenn ich der SpiderBasic Anwendung bei deren Aufruf auch gleich mitteilen könnte, dass der User eine ausreichende Berechtigung hat (dass man das als Angreifer evtl. aushebeln könnte mal beiseite gelassen).


3) Sichere Datenbankabfragen
Auch hier habe ich wieder die Befürchtung, dass man den JavaScript Code verändern kann, um Unfug zu treiben oder unberechtigt an Daten zu gelangen.

Es geht um die sichere Kodierung von Datenbankanfragen in Spiderbasic.

Realisiert wird das Ganze ja über den HttpRequest() Aufruf eines PHP Scripts, welches dann die eigentliche Kommunikation mit der Datenbank übernimmt und das Ergebnis der Abfrage an die SpiderBasic Anwendung zurückgibt.
Vermutlich wurde so ein Modul schon tausend mal entwickelt (CRUD-Modul), nur leider stecke ich da nicht weiter im Thema.

a) Vom logischen Menschenverstand her, würde ich erstmal sagen, dass es hochgradig gefährlich ist die gesamte SQL-Abfrage innerhalb der SpiderBasic Anwendung vorzuhalten und diese an das PHP Modul zu senden. Also z.B. "Select id_user From users Where name = "Meier" and PasswordHash = "blahblah". Man könnte die Abfrage als Angreifer sicherlich manipulieren, um Schaden in der Datenbank anzurichten.

b) Man könnte die Funktionalität abstrahieren.
Das PHP Modul bekäme folgende Parameter übermittelt:
- Command (also ein Kennzeichen, ob ein Select, Delete, Update oder Insert ausgeführt werden soll)
- Table (Kennzeichen welches angibt welche Tabelle gemint ist - Dabei gilt: Das Kennzeichen soll nicht so lauten wie der Tabellenname!)
- Values (Welche Datenfelder sollen zurückgeliefert werden)
- Clause (Einschränkungen, also quasi die Where-Klausel des SQL Statements)

Das ganze ist vermutlich exakt so unsicher wie a), nur dass man als Angreifer kurz länger drüber nachdenken muss.

c) Man könnte die gesamte Funktion und das gesamte SQL ins PHP-Modul stecken und dort alle Commandos bzw. Abfragen programmieren, die das SpiderBasic Programm insgesamt benötigt.

Dann würde man dem PHP Modul nur noch folgendes übermitteln:
- Command (gibt an was gewünscht ist)
- Values[] (die Werte die bei einem Update oder Insert Command in die Tabelle eingetragen werden sollen)

Das PHP Modul müsste dann leider reichlich redundanten Code enthalten, weil für jedes Command eine eigene Funktion geschrieben werden müsste.

Zum Beispiel:
Command = "CHECKUSER"
Value1 = "Meier"
Value2 = "blahblah"
-> Prüfe, ob der User mit dem Namen "Meier" und dem PasswortHash "blahblah" in der Tabelle user vorhanden ist und die Berechtigung hat die Anwendung zu nutzen. Gibt 0/1 zurück, wenn dem so ist.

Command = "GETPRODUCT"
Value1 = "1309"
-> Gib den Datensatz des Produktes mit der ID 1309 aus der Tabelle products zurück. Die Übergabe an Spider dann als JSON String.

Command = "UPDATEUSEREMAIL"
Value1 = "3"
Value2 = "meineemail@gmx.de"
-> Updatet das Feld Email des Users mit der ID 3 in der Tabelle user mit dem Wert 'meineemail@gmx.de'. Gibt je nach Erfolg der Aktion 0 oder 1 zurück.


Wie unter 1c) schon angesprochen, könnte man hier zur besseren Sicherheit bei jedem Aufruf des PHP Datenbank-Moduls zwangsweise einen Token-Parameter mit übergeben. Das Token enthält eine zufällige Zeichensequenz oder eine Checksumme, welche vorher vom Authentifizierungsmodul nach dem erfolgreichen Login erzeugt wurde.

Aber wie gesagt, das ist alles nur Menschenverstand und gefährliches Halbwissen.
Wenn hier einer so richtig Ahnung von dem Zeug hat, dann bin ich für Links oder Hinweise echt dankbar.

Ach so, da fallen mir noch zwei Sachen ein:

4) Im Dialog "CreateApp" gibt es im Reiter "Web" unten den Bereich "Post processing:".
Ist das sowas wie ein IDE Werkzeug, welches nach dem Compilieren gestartet wird? Also könnte man hier zum Beispiel eine Batch angeben, die einem das Compilat direkt auf den Webserver schiebt?

5) Ich stelle fest, dass bei der Erzeugung einer Web-Anwendung der Ordner mit den SpiderBasic Libraries immer gleich groß ist. Das heißt dann wohl, dass Spider es nicht so macht wie PureBasic und nicht nur die vom Programm benutzten Libs kopiert, sondern immer alle Libs?

Gruß Kurzer

[NicTheQuick]

Zu einzelnen Punkten kann ich dir antworten:

Aber wie mache ich das innerhalb von SpiderBasic?
a) Ich könnte den Login-Screen direkt in der SpiderBasic Anwendung realiseren, so dass ich auch direkt in SpiderBasic entscheide, ob der User weiter mit der Anwendung arbeiten darf oder sofort wieder rausgeschmissen wird.

Nun ist SpiderBasic letztendlich JavaScript und läuft auf dem Browser des Anwenders. Wäre es dem Anwender hier nicht möglich den JavaScript Code zu analysieren und zu verändern, um die Login-Prüfung zu umgehen? Das wäre ein Sicherheitsrisiko. Leider kenne ich mich mit JavaScript eher äh nicht aus.

Die Prüfung, ob bestimmt Aktionen ausgeführt werden dürfen, müssen immer im Backend geschehen, spricht auf der Seite von PHP. Vorher sollte die Spiderbasic also auch nicht mal Daten erhalten, die sie clientseitig zurückhält. Denn wie du schon richtig gesagt hast, kann man das einfach umgehen. Man muss eigentlich sogar nur in den Netzwerkmonitor des Browsers schauen und sich damit womöglich nicht mal mit Javascript herumschlagen.

b) Ich könnte den Login-Screen in PHP realisieren, danach direkt die Sessionvariablen mit der Berechtigung des Users füllen und bei erfolgreichem Login zur SpiderBasic Anwendung weiterleiten.

Hier stellt sich trotzdem ein ähnliches Problem. Die Spiderbasic Anwendung wird ja letztendlich durch einen Aufruf der betreffenden *.html Datei gestartet. Die URL der SpiderBasic Anwendung kann man dann entweder direkt in der Adresszeile des Browser sehen oder aber mit Hilfe der Developertools des Browsers. Wenn man diese URL weiß, könnte man sie auch direkt ohne den Loginprozess aufrufen. Dann wäre die Login-Prüfung völlig umgangen.

Mal ganz generell: Ein Login funktioniert immer so, dass jemand einen Nutzernamen und Passwort eingibt, beides wird verschlüsselt über einen POST-Request und HTTPS zum Server übertragen. Dieser prüft die Logindaten und wenn alles passt, liefert er mit der Antwort einen Set-Cookie-Header an den Browser mit. Der Browser merkt sich nun, dass der Cookie zu dieser Domain gehört und sendet ihn bei den nächsten Zugriffen immer automatisch mit. Die Spiderbasic-Anwendung wird ja vermutlich auf der selben Domain laufen, somit wird bei jeder Anfrage an den Server um z.B. HTML oder Javascript nachzuladen, dieses Cookie immer mitgesendet. Auf der Serverseite kann ja ein PHP-Skript prüfen, ob das Cookie gesetzt ist und ob es überhaupt zu einer Session passt, die noch gültig. Falls ja, liefert es HTML und Javascript zurück, falls nicht, sendet es einen Redirect zum Login zurück.

Sprich, statt domain.de/app.html kannst du einfach domain.de/index.php?module=app oder sowas aufrufen. Und das index.php-Skript liest den Parameter module und weiß, dass es das Cookie prüfen soll und dann app.html zurückliefern soll. Mit ein bisschen Rewrite-Voodoo auf Seiten des Webservers, kann man das sogar komplett transparent machen. Das heißt du lädst zwar app.html, aber im Hintergrund wird eigentlich index.php?module=app aufgerufen.

b2) Ich könnte von der SpiderBasic Anwendung heraus eine Abfrage an den Webserver senden, ob der aktuelle Benutzer die passende Berechtigung hat (HttpRequest() an ein PHP-Skript, welches die Authentifizierung regelt). Aber auch hier gilt wieder: JavaScript läuft auf dem Browser und ich weiß nicht, ab man auch diesen Aufruf bzw. deren Rückgabe als Angreifer kompromittieren könnte.

Den könnte man kompromittieren. Aber das ist ja egal. Eigentlich sollten in der App selbst eh keine Daten vorhanden sein. Die soll sie sich erst vom Server laden. Also deine Spiderbasic-App darf zwar starten, aber nicht schon sinnvollen Inhalt haben. Den sollte sie erst vom Webserver nachladen. Und dieser kann ja entscheiden, ob sie das darf.

c) Für zusätzliche Sicherheit könnte ich wie unter b2) vorgehen und mir vom PHP-Authentifizierungsmodul bei ausreichender Berechtigung ein Token zurückgeben lassen. Dieses Token müsste dann bei sämtlicher Kommunikation mit dem Server mitgesendet werden. Also jedes mal, wenn die SpiderBasic Anwendung Dateisystem- oder Datenbankanfragen an den Webserver sendet. Nur, wenn das mitgesendete Token mit dem Token des erfolgreich angemeldeten Benutzers identisch ist, wird die Anfrage ausgeführt.

So könnte ein unberechtigter User zwar die GUI der SpiderBasic Anwendung sehen und teilweise benutzen, aber alles was mit der Serverkommunikation zu tun hat, würde fehlschlagen.

Ob das dann alles ausreichend sicher ist, kann ich nicht beurteilen.

Über Hinweise von Experten zu dem Thema würde ich mich sehr freuen.

Das ist ja sozusagen das, was ein Cookie schon regelt. Da musst du nichts mehr selbst mitschicken. Das macht dein Browser ganz automatisch mit jedem Request an den Server bis es automatisch abläuft nach einer festgelegten Zeit, jemand den Tab schließt oder die Browserdaten löscht.
Aber als ich jetzt Dateisystem- und Datenbankanfragen gelesen habe, wurde ich stutzig. Wie genau machst du das? Ich hoffe du sendest keine kompletten SQL-Anfragen direkt an den Server, der diese dann ausführt. Oder Dateibefehle wie Erstellen, Löschen, Umbenennen mit beliebigen Pfaden. Denn das könnte ja dann jeder eingeloggte Nutzer auch beliebig manipulieren und mit deinem DROP DATABASE dann mal eben die Datenbank löschen oder sowas. Das darf man nicht tun. Ich hoffe das tust du auch nicht.

2) Parameterübergabe zu einer Spiderbasic Anwendung.
Man kann einem PHP Script per POST oder GET Parameter übergeben. Einem PureBasic Programm kann man auch Parameter übergeben, die man mittels ProgramParameter() abrufen kann.

Für SpiderBasic habe ich so etwas noch nicht gefunden.

Dabei wäre es auch im Hinblick auf die Login-Thematik evtl. sinnvoll, wenn ich der SpiderBasic Anwendung bei deren Aufruf auch gleich mitteilen könnte, dass der User eine ausreichende Berechtigung hat (dass man das als Angreifer evtl. aushebeln könnte mal beiseite gelassen).

Hier geht es auch ein bisschen um Komfort. Du kannst entweder die HTML-Seite der App durch PHP manipulieren und darin einen kurzen Javascript-Block einfügen, der Variablen enthält, die die Spiderbasic-App direkt beim Start auswerten kann. Oder du lässt die App eben beim Server anfragen, ob eine Session existiert. Oder falls noch gar kein Cookie existieren sollte, dann weißt es ja eh schon.

3) Sichere Datenbankabfragen
Auch hier habe ich wieder die Befürchtung, dass man den JavaScript Code verändern kann, um Unfug zu treiben oder unberechtigt an Daten zu gelangen.

Es geht um die sichere Kodierung von Datenbankanfragen in Spiderbasic.

Realisiert wird das Ganze ja über den HttpRequest() Aufruf eines PHP Scripts, welches dann die eigentliche Kommunikation mit der Datenbank übernimmt und das Ergebnis der Abfrage an die SpiderBasic Anwendung zurückgibt.
Vermutlich wurde so ein Modul schon tausend mal entwickelt (CRUD-Modul), nur leider stecke ich da nicht weiter im Thema.

Das PHP-Skript, das für die Datenbankinteraktion verantwortlich ist, muss natürlich immer alle erhaltenen Parameter auf Plausibilität überprüfen und gegenchecken, ob der aktuell eingeloggte User mit seiner Session diese Daten überhaupt abfragen oder ändern darf. Deswegen ist es auch so wichtig dem PHP-Skript nicht einfach SQL-Code hinzuwerfen, den es einfach an die Datenbank weitergibt. Auch müssen einzelne Werte sauber escaped werden, bevor sie in eine SQL-Anfrage eingebaut werden. Stichwort SQL-Injection.

a) Vom logischen Menschenverstand her, würde ich erstmal sagen, dass es hochgradig gefährlich ist die gesamte SQL-Abfrage innerhalb der SpiderBasic Anwendung vorzuhalten und diese an das PHP Modul zu senden. Also z.B. "Select id_user From users Where name = "Meier" and PasswordHash = "blahblah". Man könnte die Abfrage als Angreifer sicherlich manipulieren, um Schaden in der Datenbank anzurichten.

Richtig erkannt, und habe ich jetzt ja sogar schon angesprochen.

b) Man könnte die Funktionalität abstrahieren.
Das PHP Modul bekäme folgende Parameter übermittelt:
- Command (also ein Kennzeichen, ob ein Select, Delete, Update oder Insert ausgeführt werden soll)
- Table (Kennzeichen welches angibt welche Tabelle gemint ist - Dabei gilt: Das Kennzeichen soll nicht so lauten wie der Tabellenname!)
- Values (Welche Datenfelder sollen zurückgeliefert werden)
- Clause (Einschränkungen, also quasi die Where-Klausel des SQL Statements)

Das ganze ist vermutlich exakt so unsicher wie a), nur dass man als Angreifer kurz länger drüber nachdenken muss.

Was du beschreibst ist einfach nur "Security by Obscurity", also Sicherheit durch Verschleierung. Das darf man natürlich auch nicht nutzen. Am besten abstrahierst du alles immer möglichst stark vom Clienten. Das heißt du baust dir deine eigene kleine API mit Befehlen wie "checkLogin?username=bla&password=bla" oder "getinfo?article_id=12345". Und diese Befehl wissen dann welche Spalten sie aus welcher Tabelle herauslesen oder gegenchecken sollen.

c) Man könnte die gesamte Funktion und das gesamte SQL ins PHP-Modul stecken und dort alle Commandos bzw. Abfragen programmieren, die das SpiderBasic Programm insgesamt benötigt.

Dann würde man dem PHP Modul nur noch folgendes übermitteln:
- Command (gibt an was gewünscht ist)
- Values[] (die Werte die bei einem Update oder Insert Command in die Tabelle eingetragen werden sollen)

Das PHP Modul müsste dann leider reichlich redundanten Code enthalten, weil für jedes Command eine eigene Funktion geschrieben werden müsste.

Zum Beispiel:
Command = "CHECKUSER"
Value1 = "Meier"
Value2 = "blahblah"
-> Prüfe, ob der User mit dem Namen "Meier" und dem PasswortHash "blahblah" in der Tabelle user vorhanden ist und die Berechtigung hat die Anwendung zu nutzen. Gibt 0/1 zurück, wenn dem so ist.

Command = "GETPRODUCT"
Value1 = "1309"
-> Gib den Datensatz des Produktes mit der ID 1309 aus der Tabelle products zurück. Die Übergabe an Spider dann als JSON String.

Command = "UPDATEUSEREMAIL"
Value1 = "3"
Value2 = "meineemail@gmx.de"
-> Updatet das Feld Email des Users mit der ID 3 in der Tabelle user mit dem Wert 'meineemail@gmx.de'. Gibt je nach Erfolg der Aktion 0 oder 1 zurück.


Wie unter 1c) schon angesprochen, könnte man hier zur besseren Sicherheit bei jedem Aufruf des PHP Datenbank-Moduls zwangsweise einen Token-Parameter mit übergeben. Das Token enthält eine zufällige Zeichensequenz oder eine Checksumme, welche vorher vom Authentifizierungsmodul nach dem erfolgreichen Login erzeugt wurde.

Aber wie gesagt, das ist alles nur Menschenverstand und gefährliches Halbwissen.
Wenn hier einer so richtig Ahnung von dem Zeug hat, dann bin ich für Links oder Hinweise echt dankbar.

Ach, jetzt habe ich ja schon wieder gesagt, was du eh schon geschrieben hast. Ich hätte deinen Text mal lesen sollen bevor ich antworte.
Aber hier nochmal zur Sicherheit: Du musst keinen eigenen Token erfinden. Du musst PHP-seitig nur die Session auf ihre Gültigkeit überprüfen. Dafür wird das Cookie benutzt, das der Nutzer nach dem erfolgreichen Login erhielt.

Noch eine Sache bezüglich der Passwortüberprüfung. Normalerweise musst das eingegebene Passwort nicht vorher hashen, sondern einfach nur an den Server übertragen. Wenn du HTTPS nutzt, ist das eh verschlüsselt. Und falls nicht, dann bringt dir das vorherige Hashen auch nichts, da ein Angreifer, der den Datenverkehr mitschneidet, ja einfach den Hash mitschneiden kann, wenn er sich später mal selbst einloggen wollte. Das Hashen darf also serverseitig passieren und ist somit auch nicht manipulierbar oder gar abhängig vom Browser. Und wenn du es noch eine Nummer sicherer haben willst, dann kannst du noch Salt benutzen. Oder ein etabliertes Passworthashverfahren nutzen, das schon in PHP integriert ist. Da gibt es ja schon genügend Informationen dazu.

Ach so, da fallen mir noch zwei Sachen ein:

4) Im Dialog "CreateApp" gibt es im Reiter "Web" unten den Bereich "Post processing:".
Ist das sowas wie ein IDE Werkzeug, welches nach dem Compilieren gestartet wird? Also könnte man hier zum Beispiel eine Batch angeben, die einem das Compilat direkt auf den Webserver schiebt?

5) Ich stelle fest, dass bei der Erzeugung einer Web-Anwendung der Ordner mit den SpiderBasic Libraries immer gleich groß ist. Das heißt dann wohl, dass Spider es nicht so macht wie PureBasic und nicht nur die vom Programm benutzten Libs kopiert, sondern immer alle Libs?

Gruß Kurzer

Hiervon habe ich leider keine Ahnung.

[Kurzer]

Nic,
vielen Dank für deine ausführliche Antwort.

Mit dem SetCookie-Header muss ich mich noch beschäftigen, den Rest deiner Ausführungen habe ich verstanden und gänzlich nachvollziehen können. Du hast viele sinnvolle Hinweise gegeben.

Gruß Kurzer

PS: Bzgl. der Verschlüsselung des Passworts vor dem Senden an das PHP Skript. Ist das üblich?
Bisher (anderes Projekt) habe ich das so geregelt, dass die Logindaten aus einem HTML Formular die Daten per POST an das login.php sendet. Da wird nix verschlüsselt. Was anderes habe ich bei diversen Login-Templates im Netz auch nicht finden können.

Code: Alles auswählen

    <form name="login" method="POST">

      <!-- Login-Felder -->
      <input type="text" name="email" placeholder="Ihre Emailadresse"/>
      <br><br>
      <input type="password" name="password" placeholder="Ihr Passwort"/>
      <br><br>

      <!-- Scriptaufruf -->
      <input type="submit" value="Anmelden" formaction="login.php"/>

      <!-- Hinweistext -->
      <br><br>
        <hr>
        Bitte geben Sie hier Ihre Logindaten ein.
        <hr>
    </form>

[NicTheQuick]

PS: Bzgl. der Verschlüsselung des Passworts vor dem Senden an das PHP Skript. Ist das üblich?
Bisher (anderes Projekt) habe ich das so geregelt, dass die Logindaten aus einem HTML Formular die Daten per POST an das login.php sendet. Da wird nix verschlüsselt. Was anderes habe ich bei diversen Login-Templates im Netz auch nicht finden können]

Das hast du falsch verstanden. Du musst nichts aktiv verschlüsseln. Aber wenn deine Webseite über HTTPS läuft, ist die Verbindung von Browser zum Server automatisch verschlüsselt. Wenn sie nur über HTTP läuft, du also nicht das kleine Schloss oben neben deiner Adresszeile hast, dann wird immer alles im Klartext übertragen, d.h. andere im selben Netzwerk oder allen Knoten dazwischen, könnten das mitschneiden. Aber das weißt du wahrscheinlich.

[Kurzer]

Nic, danke für die Klarstellung. Ja das Thema HTTP / HTTPS ist mir geläufig, ich war halt nur etwas verdutzt, da ich dachte man verschlüsselt das standardmäßig (wie auch immer) noch vor dem login. Aber nun sind alle Klarheiten beseitigt.

Parameterübergabe zu einer Spiderbasic Anwendung.
Man kann einem PHP Script per POST oder GET Parameter übergeben. Einem PureBasic Programm kann man auch Parameter übergeben, die man mittels ProgramParameter() abrufen kann.

Für SpiderBasic habe ich so etwas noch nicht gefunden.

Das hat sich gerade dank Paul aus dem SpiderBasic Forum erledigt. Ich hatte danach nur in der Hilfe gesucht (und nicht gefunden). Im Gegensatz zu PureBasic ist der Befehl "ProgramParameter" bei SpiderBasic in der Rubrik "System" zu finden und nicht in der Rubrik "Process". Ich hätte also lieber mal die Volltext-Suchfunktion in der SB Hilfe bemühen sollen.