7
Upload von Dateien per Batch, cURL und PHP auf einen Webserver (ohne FTP)
Nachfolgend stelle ich eine Möglichkeit vor, wie man per Batchscript, dem Kommandozeilen Programm cURL und PHP Dateien auf einen Webserver hochladen kann.
Hallo zusammen,
Benutzung dieses Scriptes momentan auf eigene Gefahr (bzgl. Sicherheitsaspekten)!
Solange dieser Absatz hier steht, wird der Quellcode/das Tutorial gerade überarbeitet. Ich bitte um Verständnis...
ich möchte gerne eine Möglichkeit vorstellen, wie man mit einfachsten Mitteln eine Datei OHNE FTP-ZUGANG uploaden kann.
Besonders zu erwähnen hierbei ist, dass hier "fast" keine Programmiererfahrung vonnöten ist.
Wichtige Bemerkung am Rande: Mein Tutorial verwendet die NICHT-SSL Version von cURL, weshalb der Datentransfer grundsätzlich unverschlüsselt stattfindet!
Eine SSL-Version gibt es, jedoch wird -der Einfachkeit halber- hier bei diesem Tutorial darauf verzichtet!
Der initiierende Grund für dieses Tutorial war der Wunsch nach einem Upload der Firefoxbookmarks auf den eigenen Webserver, da ich persönlich meine privaten Daten nur ungern und so spärlich wie nur möglich an fremde Anbieter gebe.
Gesagt getan und so hab ich schnell ein PHP-Script erstellt, was mir diese Funktion zur Verfügung stellte. (inklusive Upload der JSON-Datei / Suche etc.)
Schnell kam der Wunsch auf, diese JSON-Datei automatisiert per Batch upzuloaden, weil man meistens nicht daran denkt, jeden Tag eine Sicherungskopie zu erstellen.
Nur wie um Himmels willen löst man einen HTTP-POST per Batch aus??? Also schööön weiterlesen...
Webserver mit PHP, Batch und PHP Scripting Kenntnisse - kein GURU Wissen erforderlich 
(Hauptseite Direkte Downloadseite)
Kurze Beschreibung: Kommandozeilentool, um HTTP, FTP und anderen Internetverkehr hier drüber abzuwickeln.
Einmalig die Möglichkeit das Upload-Script auf den Webserver z.B. per FTP zu positionieren.
(jaja... ich weiss... "ohne FTP-Zugang" geht halt doch net )
Jetzt haben wir die Zutaten und gehen an den Herd und probieren das Rezept aus :-P
Der Ablauf gestaltet sich so, dass per Batchscript eine Datei mittels cURL an das Upload.php Script auf eurem Webserver übergeben wird. Dieses Script legt die Datei dann schön artig im Verzeichnis eures Scriptes ab.
Schnippeln wir die Zutaten alias "upload.php" und "upload.bat" mit der Prise "curl.exe" mal zusammen. (Würzen im Nachhinein auf eigene Gefahr und nur für erfahrene Script-Köche und Küchen :P)
(Wie Ihr die Datei weiterverarbeitet oder ob ihr das Script irgendwo einbettet, bleibt euch überlassen)
Die Erläuterungen sind jeweils unterhalb bzw. innerhalb des Codes.
Durch dieses Script wird die per HTTP-POST übermittelte Datei auf dem Webserver in das Verzeichnis hochgeladen, wo auch eure upload.php sich befindet.
Um eventuellen Störenfrieden die Luft aus den Segeln zu nehmen, gibt es in dem Script einen Benutzernamen und ein Passwort, die in der Batchdatei GENAUSO eingetragen werden müssen.
Ohne diese geposteten Authentifizierungsmerkmale kann man euer Upload Skript nicht benutzen. Also UNBEDINGT ÄNDERN!!!
Standardmäßig ist es so eingestellt, dass der Zieldateiname auf dem Webserver zieldatei.txt lautet.
Ausstellen kann man dies durch den Punkt $zieldateinameverwenden=false;
Möchtet Ihr sogar die Debugmeldungen unterdrücken, könnt Ihr sie synonym durch $debug=false ausstellen.
(Falls das Script partou nicht laufen will, prüft die Berechtigungen auf eurem Webserver für diese Datei.)
Bitte gebt den gleichen Benutzernamen und Passwort wie in der upload.php an.
Mit "File" ist der Datei gekennzeichnet, die im gleichen Verzeichnis wie die curl.exe liegt.
Die websiteURL kennzeichnet den Lagerort eurer upload.php auf eurem Webserver.
Die letzte Zeile ist das eigentlich Wichtige. Hier wird die Datei auf euren Webserver hochgeladen.
Wenn Ihr euch fragen solltet, warum ich "Send=1" mit übermittle, schaut bitte in die upload.php Kommentare.
Diese Batch Datei kann man jetzt nutzen, um zeitgesteuert per "Geplante Tasks" oder Ähnlichem Dateien hochzuladen.
Es wäre denkbar, dass man in dieser Batchdatei mit %1, %2, %3 ... bzw mit dem Befehl "shift" arbeitet, um einen Stapel an Dateien auf den Webserver hochzuladen.
Somit könnte man dieses Verfahren sicherlich noch weiter optimieren.
Bitte beachten: Dateien, die hochgeladen werden, jedoch schon auf dem Webserver existieren, werden gnadenlos überschrieben
Ich wünsche euch allen viel Spaß mit dem Tutorial und wenig Bauchschmerzen mit diesem Rezept
Gruß
Markus (Problemsolver)
Hallo zusammen,
Benutzung dieses Scriptes momentan auf eigene Gefahr (bzgl. Sicherheitsaspekten)!
Solange dieser Absatz hier steht, wird der Quellcode/das Tutorial gerade überarbeitet. Ich bitte um Verständnis...
Inhaltsverzeichnis
Der Anfang:
ich möchte gerne eine Möglichkeit vorstellen, wie man mit einfachsten Mitteln eine Datei OHNE FTP-ZUGANG uploaden kann.Besonders zu erwähnen hierbei ist, dass hier "fast" keine Programmiererfahrung vonnöten ist.
Wichtige Bemerkung am Rande: Mein Tutorial verwendet die NICHT-SSL Version von cURL, weshalb der Datentransfer grundsätzlich unverschlüsselt stattfindet!
Eine SSL-Version gibt es, jedoch wird -der Einfachkeit halber- hier bei diesem Tutorial darauf verzichtet!
Buchklappentext:
Der initiierende Grund für dieses Tutorial war der Wunsch nach einem Upload der Firefoxbookmarks auf den eigenen Webserver, da ich persönlich meine privaten Daten nur ungern und so spärlich wie nur möglich an fremde Anbieter gebe.Gesagt getan und so hab ich schnell ein PHP-Script erstellt, was mir diese Funktion zur Verfügung stellte. (inklusive Upload der JSON-Datei / Suche etc.)
Schnell kam der Wunsch auf, diese JSON-Datei automatisiert per Batch upzuloaden, weil man meistens nicht daran denkt, jeden Tag eine Sicherungskopie zu erstellen.
Nur wie um Himmels willen löst man einen HTTP-POST per Batch aus??? Also schööön weiterlesen...
Zutaten im Überblick:
1. Webserver:
Webserver mit PHP, Batch und PHP Scripting Kenntnisse - kein GURU Wissen erforderlich 2. ...und ihr benötigt cURL...
(Hauptseite Direkte Downloadseite)Kurze Beschreibung: Kommandozeilentool, um HTTP, FTP und anderen Internetverkehr hier drüber abzuwickeln.
3. ... und einen FTP Client
Einmalig die Möglichkeit das Upload-Script auf den Webserver z.B. per FTP zu positionieren.(jaja... ich weiss... "ohne FTP-Zugang" geht halt doch net
)Jetzt haben wir die Zutaten und gehen an den Herd und probieren das Rezept aus :-P
Rezept:
Der Ablauf gestaltet sich so, dass per Batchscript eine Datei mittels cURL an das Upload.php Script auf eurem Webserver übergeben wird. Dieses Script legt die Datei dann schön artig im Verzeichnis eures Scriptes ab.Schnippeln wir die Zutaten alias "upload.php" und "upload.bat" mit der Prise "curl.exe" mal zusammen. (Würzen im Nachhinein auf eigene Gefahr und nur für erfahrene Script-Köche und Küchen :P)
Fangen wir also mit der upload.php Datei an:
(Wie Ihr die Datei weiterverarbeitet oder ob ihr das Script irgendwo einbettet, bleibt euch überlassen)Die Erläuterungen sind jeweils unterhalb bzw. innerhalb des Codes.
<?php
/*
* Dateiname: upload.php
*
* Kurze Beschreibung
* Zuerst werden Benutzername und Password, die hardgecoded ;) hier im Script liegen, überprüft.
* Dann wird gecheckt, ob der Request Send mitgeliefert worden ist. (Für die, die eventuell hier noch ein Formular drumherum bauen möchten, um auch einen manuellen Upload über ein Formular in dieser Datei zu ermöglichen ;-) )
* Dann wird die Datei auf dem Webserver in das Verzeichnis des Scriptes geschoben. $zieldateiname wird verwendet, wenn es entsprechend unten konfiguriert ist (standard)!
* Bitte achtet auch Groß und Kleinschreibung des Benutzernamen und des Passwortes im Batch Script, da diese case-sensitive hier im PHP Script verwendet werden.
*/
// Benutzername, der durch CURL per POST übergeben wird. UNBEDINGT ÄNDERN!!!
$username="GeheimerUser";
// Passwort, das durch cURL per POST übergeben wird. UNBEDINGT ÄNDERN!!!
$password="GeheimesPasswort";
// Will man sicherstellen, dass vorhandene Dateien auf dem Webserver nicht überschrieben werden, kann man einen Zieldateinamen vorgeben.
$zieldateinameverwenden=true;
$zieldateiname="zieldatei.txt";
// Debugmeldungen ausgeben..., die dann bei cURL sichtbar sind...
$debug=true;
// Ab hier gibt es nichts mehr zu ändern!!!
if (($_POST['username']==$username) && ($_POST['password']==$password)) {
if ($debug) echo "Username und Password = OK<br />\n";
if(isset($_REQUEST['Send']))
{
if($_FILES['Datei']['tmp_name'])
{
if ($debug) echo "Ihre Datei (",
$_FILES['Datei']['name'],
") hat ",
$_FILES['Datei']['size'],
" Bytes.<br />\n";
if ($zieldateinameverwenden) {
move_uploaded_file($_FILES['Datei']['tmp_name'], $zieldateiname);
if ($debug) echo "Die Datei wurde nach - " . $zieldateiname . " - umbenannt!";
} else {
move_uploaded_file($_FILES['Datei']['tmp_name'], $_FILES['Datei']['name']);
}
}
else
{
if ($debug) echo "Bitte geben Sie eine Datei an!";
}
}
} else {
if ($debug) echo "Fehler! vergleiche bitte die Authentifizierungsmerkmale in beiden Scripten!!!";
}
?>Erläuterung von upload.php:
Durch dieses Script wird die per HTTP-POST übermittelte Datei auf dem Webserver in das Verzeichnis hochgeladen, wo auch eure upload.php sich befindet.Um eventuellen Störenfrieden die Luft aus den Segeln zu nehmen, gibt es in dem Script einen Benutzernamen und ein Passwort, die in der Batchdatei GENAUSO eingetragen werden müssen.
Ohne diese geposteten Authentifizierungsmerkmale kann man euer Upload Skript nicht benutzen. Also UNBEDINGT ÄNDERN!!!
Standardmäßig ist es so eingestellt, dass der Zieldateiname auf dem Webserver zieldatei.txt lautet.
Ausstellen kann man dies durch den Punkt $zieldateinameverwenden=false;
Möchtet Ihr sogar die Debugmeldungen unterdrücken, könnt Ihr sie synonym durch $debug=false ausstellen.
(Falls das Script partou nicht laufen will, prüft die Berechtigungen auf eurem Webserver für diese Datei.)
Jetzt machen wir mit der upload.bat weiter:
@echo off
set "username=GeheimerUser"
set "password=GeheimesPasswort";
set "file=test.json"
set "websiteURL=http://www.deineseite.de/problemsolver/upload.php"
"%~dp0curl" -F "username=%username%" -F "password=%password%" -F "Datei=@%~dp0%file%" -F "Send=1" %websiteURL% Erläuterung von upload.bat
Bitte gebt den gleichen Benutzernamen und Passwort wie in der upload.php an.Mit "File" ist der Datei gekennzeichnet, die im gleichen Verzeichnis wie die curl.exe liegt.
Die websiteURL kennzeichnet den Lagerort eurer upload.php auf eurem Webserver.
Die letzte Zeile ist das eigentlich Wichtige. Hier wird die Datei auf euren Webserver hochgeladen.
Wenn Ihr euch fragen solltet, warum ich "Send=1" mit übermittle, schaut bitte in die upload.php Kommentare.
Diese Batch Datei kann man jetzt nutzen, um zeitgesteuert per "Geplante Tasks" oder Ähnlichem Dateien hochzuladen.
Final Notes und Denkansätze:
Es wäre denkbar, dass man in dieser Batchdatei mit %1, %2, %3 ... bzw mit dem Befehl "shift" arbeitet, um einen Stapel an Dateien auf den Webserver hochzuladen.Somit könnte man dieses Verfahren sicherlich noch weiter optimieren.
Bitte beachten: Dateien, die hochgeladen werden, jedoch schon auf dem Webserver existieren, werden gnadenlos überschrieben
Der Schluß...
Ich wünsche euch allen viel Spaß mit dem Tutorial und wenig Bauchschmerzen mit diesem Rezept Gruß
Markus (Problemsolver)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 98399
Url: https://administrator.de/tutorial/upload-von-dateien-per-batch-curl-und-php-auf-einen-webserver-ohne-ftp-98399.html
Ausgedruckt am: 25.12.2024 um 13:12 Uhr
7 Kommentare
Neuester Kommentar
Hmja, genauso anfällig wie jedes andere Upload-Script auch.
Würde ich nicht verwenden...
Lonesome Walker
Würde ich nicht verwenden...
Lonesome Walker
Hallo Lonesome Walker,
danke für Dein Kommentar. Würde es Dir etwas ausmachen, deine Äußerungen ein wenig zu konkretisieren?
Warum ist das Upload-Script unsicher?
Wie könnte man es besser machen?
Ein Beispiel wäre zum Beispiel, dass man das Überschreiben von vorhandenen Dateien zusätzlich noch durch ein weiteres Passwort absichert.
Ich bin grundsätzlich für jede Kritik dankbar - positive wie auch negative.
Gruß
Markus
danke für Dein Kommentar. Würde es Dir etwas ausmachen, deine Äußerungen ein wenig zu konkretisieren?
Warum ist das Upload-Script unsicher?
Wie könnte man es besser machen?
Ein Beispiel wäre zum Beispiel, dass man das Überschreiben von vorhandenen Dateien zusätzlich noch durch ein weiteres Passwort absichert.
Ich bin grundsätzlich für jede Kritik dankbar - positive wie auch negative.
Gruß
Markus
Bedaure, aber das würde den Rahmen sprengen, weil es da schon um die Basics geht, die fehlen...
Lonesome Walker
Lonesome Walker
Hallo LSW,
mag alles sein.
Basics ist natürlich ein sehr weitläufiger Begriff.
Aber da Du Dich ja offensichtlich SEHR gut auskennst, macht es Dir sicherlich nichts aus, (wenn Du schon gerade eh hier bist), eine Minute Deiner Zeit zu opfern, um hier 3 klare Stichpunkte zu nennen.
Einfach nur auflisten, um uns/mich hier glücklich zu machen
Gruß
Markus
mag alles sein.
Basics ist natürlich ein sehr weitläufiger Begriff.
Aber da Du Dich ja offensichtlich SEHR gut auskennst, macht es Dir sicherlich nichts aus, (wenn Du schon gerade eh hier bist), eine Minute Deiner Zeit zu opfern, um hier 3 klare Stichpunkte zu nennen.
Einfach nur auflisten, um uns/mich hier glücklich zu machen
Gruß
Markus
Eigentlich nein.
Andererseits bin ich ein Freund von Sicherheit...
1. Verzeichnis des Uploads liegt im www-zugänglichen Bereich
2. jeder kann die hochgeladene Datei überschreiben
3. klar, ohne Pwd geht für die normalen Script-Kiddies 2. nicht, aber dafür hast Du ja eine Batch-Datei, in der das Pwd im Klartext drin steht.
Wie oft Rechner ger00tet werden, muß ich Dir sicherlich nicht erklären;
nicht umsonst legen auch die meisten FTP-Programme die Zugangsdaten nicht unverschlüsselt ab...
Für mich ist dieses Script aber eher ein lustloser Versuch, da ich kein Passwort brauche, um da was hochzuladen...
Lonesome Walker
Andererseits bin ich ein Freund von Sicherheit...
1. Verzeichnis des Uploads liegt im www-zugänglichen Bereich
2. jeder kann die hochgeladene Datei überschreiben
3. klar, ohne Pwd geht für die normalen Script-Kiddies 2. nicht, aber dafür hast Du ja eine Batch-Datei, in der das Pwd im Klartext drin steht.
Wie oft Rechner ger00tet werden, muß ich Dir sicherlich nicht erklären;
nicht umsonst legen auch die meisten FTP-Programme die Zugangsdaten nicht unverschlüsselt ab...
Für mich ist dieses Script aber eher ein lustloser Versuch, da ich kein Passwort brauche, um da was hochzuladen...
Lonesome Walker
So, nachdem wir das ja jetzt per PN geklärt hätten *g*
Naja, lustig ist es für mich leider nicht, da ICH so ###e immer reparieren muß...
Gut, das ist ein erster Schritt, und wie ich gesehen habe, hast Du Dir dazu auch schon einige Gedanken gemacht.
Theoretisch ja, pratisch spricht aber eins dagegen:
htaccess hat nicht zwangsläufig jeder, der auch PHP hat (denk mal an die lieben IIS-Admins...)
Jein, würde schon reichen, wenn die Datei vorne eine Random-Kennung dran gesetzt bekommt, und eine Ordnerhierarchie tiefer (höher geht ja meist nicht...) abgelegt wird.
Somit muß man immer erst mal das Verzeichnis erraten, und dann zusätzlich noch den Dateinamen...
Ich setzte diese Priorität, da ich pro Woche mindestens 1-2 Server flicke, die durch so einen ### zerschossen wurden.
Ebenso schickt mein Server pro Woche mind. 100 Abuse-Meldungen an die jeweiligen Stellen, weil durch so ein Einfalltor ein Server übernommen wird, und dieser dann als weiterer Zombie nach anderen anfälligen Servern sucht; logischerweise trifft dieser dabei auch auf abgesicherte Server wie meine, und dann protokollier ich das, und tu was dagegen...
Jaein.
Mittlerweile ist dieses Thema zwar sehr breit getreten worden, aber das beste Beispiel was das Gmail-Widget für Apple.
Das war kein Rootkit, sodern einfach nur schlecht/zu gut programmiert...
Schwupps, konnte man (sofern man KnowHow hatte), jede Mail lesen...
Und Browser werden auch immer anfälliger, obwohl sie mittlerweile zum Allzweck-Tool mutieren.
Gar nicht? Pwd's speichert man NIRGENDS als Klartext.
(am besten ist die Erinnerungs-Funktion, wenn einem dann Mails zugesendet werden, in denen das Pwd im Klartext steht...)
Richtig. Keine Input-Validierung/-Bereinigung, die zuverlässig checkt.
Japp. Gib mir eine URL, und ich zeig Dir, wie schnell ich Deine Favoriten durch meine präparierten Favoriten ersetze...
(und da würde ich dann z.B. bei einigen Favoriten eine URL hinterlegen, die Schadcode herunterläd...)
Wie schon geschrieben, der Input kann alles sein, und somit kriege ich die beiden Werte IMMER auf "true"...
(Groschen gefallen...?)
Das ist der falsche Weg.
Richtig wäre es, sich einmalig mit dieser Thematik auseinanderzusetzen, damit so etwas in Zukunft nicht mehr so läuft.
(dann hat man das Ganze verinnerlicht und man macht sowas einfach automatisch...)
Genau, deswegen liebe ich auch diese Flash-Logins, die sind sooooooo herrrrrrrlich...
Ne
Lonesome Walker
Hi LSW,
erstmal wollte ich einfach mal Danke für deine Beiträge sagen.
Oft sieht man eigentlich nur die "ironische bzw sarkastische Art" bei
Deinen Kommentaren - bist auch schließlich lange schon hier dabei und -so
denke ich- auch ab und angenervt, wenn User immer wieder die gleichen Fragen
stellen bzw. die gleichen Fehler machen. Unter dem Gesichtspunkt kann ich das
ziemlich gut verstehen. Ist ja außerdem auch oft lustig zu lesen ;)
erstmal wollte ich einfach mal Danke für deine Beiträge sagen.
Oft sieht man eigentlich nur die "ironische bzw sarkastische Art" bei
Deinen Kommentaren - bist auch schließlich lange schon hier dabei und -so
denke ich- auch ab und angenervt, wenn User immer wieder die gleichen Fragen
stellen bzw. die gleichen Fehler machen. Unter dem Gesichtspunkt kann ich das
ziemlich gut verstehen. Ist ja außerdem auch oft lustig zu lesen ;)
Naja, lustig ist es für mich leider nicht, da ICH so ###e immer reparieren muß...
Hab überlegt, ob ich Dir schreibe und versucht mir vorher meine Gedanken
zu machen. Weil: Ich für meine Person versuche natürlich gerne aus
meinen Fehlern zu lernen.
zu machen. Weil: Ich für meine Person versuche natürlich gerne aus
meinen Fehlern zu lernen.
Gut, das ist ein erster Schritt, und wie ich gesehen habe, hast Du Dir dazu auch schon einige Gedanken gemacht.
> 1. Verzeichnis des Uploads liegt im www-zugänglichen Bereich
Punkt ist absolut verständlich. Ich denke hierbei an .htaccess und
.htpasswd . Du?
Punkt ist absolut verständlich. Ich denke hierbei an .htaccess und
.htpasswd . Du?
Theoretisch ja, pratisch spricht aber eins dagegen:
htaccess hat nicht zwangsläufig jeder, der auch PHP hat (denk mal an die lieben IIS-Admins...)
> 2. jeder kann die hochgeladene Datei überschreiben
mmmh. Sobald man $zieldateiverwenden=false; setzt., stimmt das absolut.
Würde das sogar fast so lassen, jedoch gegenprüfen, ob verbotene
Dateitypen hochgeladen werden und dementsprechend zu reagieren...
mmmh. Sobald man $zieldateiverwenden=false; setzt., stimmt das absolut.
Würde das sogar fast so lassen, jedoch gegenprüfen, ob verbotene
Dateitypen hochgeladen werden und dementsprechend zu reagieren...
Jein, würde schon reichen, wenn die Datei vorne eine Random-Kennung dran gesetzt bekommt, und eine Ordnerhierarchie tiefer (höher geht ja meist nicht...) abgelegt wird.
Somit muß man immer erst mal das Verzeichnis erraten, und dann zusätzlich noch den Dateinamen...
> 3. klar, ohne Pwd geht für die normalen Script-Kiddies 2. nicht,
> aber dafür hast Du ja eine Batch-Datei, in der das Pwd im
> Klartext drin steht.
> Wie oft Rechner ger00tet werden, muß ich Dir sicherlich nicht
> erklären;
> nicht umsonst legen auch die meisten FTP-Programme die Zugangsdaten
> nicht unverschlüsselt ab...
Da hast du auf jeden Fall wieder mal Recht. Hab überlegt, was ich besser
machen könnte.
Als Erstes den Datenverkehr verschlüsseln. Also nur SSL nutzen, da man
sonst eh einem Sniffer ausgeliefert wäre. (Setzt Du eigentlich
persönlich grunsätzlich Sicherheit vor Praxistauglichkeit? Ich finde,
dass Sicherheit ein grundsätzlicher Bestandteil von Datenverkehr sein
sollte. Aber nicht jeder kann mit SSL bei seinem Webspace aufwarten... )
> aber dafür hast Du ja eine Batch-Datei, in der das Pwd im
> Klartext drin steht.
> Wie oft Rechner ger00tet werden, muß ich Dir sicherlich nicht
> erklären;
> nicht umsonst legen auch die meisten FTP-Programme die Zugangsdaten
> nicht unverschlüsselt ab...
Da hast du auf jeden Fall wieder mal Recht. Hab überlegt, was ich besser
machen könnte.
Als Erstes den Datenverkehr verschlüsseln. Also nur SSL nutzen, da man
sonst eh einem Sniffer ausgeliefert wäre. (Setzt Du eigentlich
persönlich grunsätzlich Sicherheit vor Praxistauglichkeit? Ich finde,
dass Sicherheit ein grundsätzlicher Bestandteil von Datenverkehr sein
sollte. Aber nicht jeder kann mit SSL bei seinem Webspace aufwarten... )
Ich setzte diese Priorität, da ich pro Woche mindestens 1-2 Server flicke, die durch so einen ### zerschossen wurden.
Ebenso schickt mein Server pro Woche mind. 100 Abuse-Meldungen an die jeweiligen Stellen, weil durch so ein Einfalltor ein Server übernommen wird, und dieser dann als weiterer Zombie nach anderen anfälligen Servern sucht; logischerweise trifft dieser dabei auch auf abgesicherte Server wie meine, und dann protokollier ich das, und tu was dagegen...
Rootkits -> nunja... wenn das Kind in den Brunnen gefallen ist, ist's
eh für die meisten User zu spät, ne?
eh für die meisten User zu spät, ne?
Jaein.
Mittlerweile ist dieses Thema zwar sehr breit getreten worden, aber das beste Beispiel was das Gmail-Widget für Apple.
Das war kein Rootkit, sodern einfach nur schlecht/zu gut programmiert...
Schwupps, konnte man (sofern man KnowHow hatte), jede Mail lesen...
Und Browser werden auch immer anfälliger, obwohl sie mittlerweile zum Allzweck-Tool mutieren.
Ich frage mich außerdem, wie man die Passwörter verschlüsseln
könnte, um den Klartext in der Batch-Datei zu umgehen. (außer MD5
etc..., was das Problem grunsätzlich eh nicht lösen
würde...(Wiederverwendbarkeit/Rainbow Tables etc.))
könnte, um den Klartext in der Batch-Datei zu umgehen. (außer MD5
etc..., was das Problem grunsätzlich eh nicht lösen
würde...(Wiederverwendbarkeit/Rainbow Tables etc.))
Gar nicht? Pwd's speichert man NIRGENDS als Klartext.
(am besten ist die Erinnerungs-Funktion, wenn einem dann Mails zugesendet werden, in denen das Pwd im Klartext steht...)
> Für mich ist dieses Script aber eher ein lustloser Versuch, da
> ich kein Passwort brauche, um da was hochzuladen...
Ich vermute es hat etwas mit den Vergleichsoperatoren (=== oder == , die auch
gleichzeitig den Variablentyp mit vergleichen) zu tun.
> ich kein Passwort brauche, um da was hochzuladen...
Ich vermute es hat etwas mit den Vergleichsoperatoren (=== oder == , die auch
gleichzeitig den Variablentyp mit vergleichen) zu tun.
Richtig. Keine Input-Validierung/-Bereinigung, die zuverlässig checkt.
Hast Du das erfolgreich
getestet?
getestet?
Japp. Gib mir eine URL, und ich zeig Dir, wie schnell ich Deine Favoriten durch meine präparierten Favoriten ersetze...
(und da würde ich dann z.B. bei einigen Favoriten eine URL hinterlegen, die Schadcode herunterläd...)
Ich habe hier keinen Erfolg gehabt. Jegliche Tests mit verschiedenen
Werten, waren erfolglos und ich wurde vom Script abgewiesen. Für einen Tipp
wäre ich Dir wiiiirklich sehr dankbar, wie Du ohne BN und PW Uploads
durchführen willst...
Werten, waren erfolglos und ich wurde vom Script abgewiesen. Für einen Tipp
wäre ich Dir wiiiirklich sehr dankbar, wie Du ohne BN und PW Uploads
durchführen willst...
Wie schon geschrieben, der Input kann alles sein, und somit kriege ich die beiden Werte IMMER auf "true"...
(Groschen gefallen...?)
Na ich hab schon fast wieder Bock das Tutorial offline zu nehmen, da ich sehe,
dass es eigentlich doch zu unsicher ist...
dass es eigentlich doch zu unsicher ist...
Das ist der falsche Weg.
Richtig wäre es, sich einmalig mit dieser Thematik auseinanderzusetzen, damit so etwas in Zukunft nicht mehr so läuft.
(dann hat man das Ganze verinnerlicht
und man macht sowas einfach automatisch...)Es gibt -egal wie man es anstellt- immer Menschen, die an die Passwörter
kommen. Selbst wenn man es mit irgendeiner Programmiersprache die
Passwörter fest in einem Programm "reinkompiliert", sichere
Verbindungen benutzt, und das Programm sonst wie vor Reverse Engineering oder
ähnlichem schützt.
kommen. Selbst wenn man es mit irgendeiner Programmiersprache die
Passwörter fest in einem Programm "reinkompiliert", sichere
Verbindungen benutzt, und das Programm sonst wie vor Reverse Engineering oder
ähnlichem schützt.
Genau, deswegen liebe ich auch diese Flash-Logins, die sind sooooooo herrrrrrrlich...
Also von lustlos kann keine Rede sein, habe es aber auch nicht persönlich
genommen. Nur als Anreiz. Dafür nochmal ein Danke. Denn ein Danke tut ja
nicht weh, ne?
genommen. Nur als Anreiz. Dafür nochmal ein Danke. Denn ein Danke tut ja
nicht weh, ne?
Ne
Lonesome Walker
Hallo,
mich würde interessieren wie die folgenden Abfrage immer true sein kann, da die zweite Variable ja nicht durch das POST Request überschrieben werden kann? Oder ist das doch möglich?
if (($_POST['username']==$username) && ($_POST['password']==$password))
Vielen Dank für eine kuze Hilfestellung.
mich würde interessieren wie die folgenden Abfrage immer true sein kann, da die zweite Variable ja nicht durch das POST Request überschrieben werden kann? Oder ist das doch möglich?
if (($_POST['username']==$username) && ($_POST['password']==$password))
Wie schon geschrieben, der Input kann alles sein, und somit kriege
ich die beiden Werte IMMER auf "true"...
(Groschen gefallen...?)
ich die beiden Werte IMMER auf "true"...
(Groschen gefallen...?)
Vielen Dank für eine kuze Hilfestellung.
