Variaben an Script übergeben

[suleiman]

Hallo,

ich zerbreche mir noch den Kopf, weil ich einfach keine gute Lösung für mein Problem finde. Ich habe einen LAMB aufgesetzt (Linux Apache MySQL Bash). Nun versuche ich rund 50 Abfragen zu erstellen die über verschiedene Scripts aufgerufen werden. Jedes Script erstellt eine neue Abfrage.

<input type=number name=field1>.

Jetzt muß man aber jedes mal alle 50 Daten mit übergeben, wenn ich hin und her wandern möchte zwischen den Seiten. Mit dem submit button habe ich das nicht hin bekommen. Keine Ahnung ob ich was übersehen habe. Momentan versuche ich es mit einem einfachen Link.

echo "<input type=number name=\"new_value\">"
echo "<a href=\"../cgi-bin/mysql1.sh?1&2&3&${VARIABLE}&6&7\">"

Der Erzeugte Code sieht dann wie folgt aus...

<input type=number name="new_value">
<a href="../cgi-bin/mysql1.sh?1&2&3&&6&7">

Wie bekomme ich new_value.value in VARIABLE rein ? Geht das überhaupt ? Gibt es noch andere Möglichkeiten ? Vielleicht geht es ganz anders und man kann z.B. irgendwie Environment-Variablen erstellen.

Ich wäre für jeden Tip dankbar.

[TS]

Hallo und guten Tag,

wenn Du schon unbedingt den Wald mit der Steinkeilklinge fällen willst, dann bau dir ein Sessionmanagement, so wie es fertige Interpretersysteme, wie Perl oder PHP eingebaut haben.

Liebe Grüße
TS

[suleiman]

Das ist wohl genau das wo ich brauche. Danke vielmals, für diesen Hinweis.

Wenn ich es richtig interpretiere dann muß ich nur mod_sessions aktivieren und kann dann in den header die Daten anhängen.

#!/bin/bash
echo "Content-Type: text/plain"
echo "X-Replace-Session: key1=foo&key2=&key3=bar"
echo
env

Perl, Python, Java, und wie se nicht alle heisen, sind nur weitere Geschütze die man auf den Server installieren kann, und ich will nicht noch eine Programmiersprache lernen. Es langt schon das ich den Server um konfigurieren muss.

Danke nochmals!

[Rolf b]

Eine Website als Bash-Scriptsammlung. Die einen kratzen sich am Kopf, die anderen sagen: RRRRESPEKT!

Hoffentlich kriegst Du damit auch alle Anforderungen an Kontextwechsel erfüllt und kannst Dich hinreichend gegen Injektionsattacken absichern. Und dein nächstes Projekt machst Du hiermit?

Scherz beiseite, ich verstehe das so, dass mod_session dir die serverseitige Infrastruktur bereitstellt, um eine Session-ID zu erhalten und Daten als Key-Value Paare von einem Webrequest zur nächsten zu übertragen. Die Übertragung aus dem Session-Speicher (in deinem Zitat als Cookie) in dein HTML musst Du aber immer noch programmieren; von alleine passiert das wohl nicht.

Ein weiteres Problem ist noch, dass Du die Benutzereingabe aus dem Input-Element an den Server senden willst. Dafür brauchst Du keinen Link, sondern ein Form. Das hat standardmäßig die methode "get", hängt Dir also die input-Werte als Query-Teil in die URL. Alternativ kannst Du auch method="post" angeben, musst dann aber den Request-Body auslesen und decodieren. Solange dein Form klein ist, kannst Du get nehmen. Aber URLs sollte man nicht zu lang machen; das Erfahrungslimit ist 2000 Zeichen.

Und wenn du die Eingabe aus der URL oder den Formdaten extrahiert hast, musst Du sie wieder in die Session schreiben, damit sie für die nächste Seite bereitstehen.

Ob Du tatsächlich die Eingaben als Cookie speichern willst, hängt von deinen Anforderungen ab. Normalerweise überträgt man die Session-Daten nicht unverschlüsselt als Cookie zwischen Browser und Server, weil der User nach belieben daran herumfummeln kann. Wenn das für Dich kein Problem darstellt, ok. Wenn doch, dann musst Du die Sessiondaten anders halten. Entweder im ASP.NET Stil, über ein input-Element im Form mit type="hidden", worin ein sogenannter viewstate verschlüsselt abgelegt ist, oder über eine serverseitige Speicherung der Sessiondaten. Entweder im Apache, oder Du brauchst ein Sessionmodul dass die die Sessiondaten im Dateisystem oder in einer Datenbank speichert. Hängt alles von deinen Security-Anforderungen ab und davon, ob du 3 oder 30000000 User hast (facebook.sh, DAS wär mal 'ne Challenge :) ).

Rolf

[suleiman]

Ist auch viel umständlicher als ich mir erdacht hatte.

Joa, mit der angedeuteten Programmiersprache setz ich mich schon lange und gern auseinander. Ich sag dazu immer Text-Adventure ;)

Ich habe durch Zufall was gefunden das kannte ich garnicht ...

versteckte_Elemente

DAS würde mir viel Arbeit abnehmen und das Sicherheitsrisiko ist geringer.

[Matthias Apsel]

Hallo suleiman,

versteckte_Elemente

und das Sicherheitsrisiko ist geringer.

Nein, das versteckte Eingabefeld steht im Quelltext und ist für bots oder Bösewichte genauso sichtbar wie jedes andere Element.

Bis demnächst
Matthias

[suleiman]

Sind nur Zahlen die ich in die Datenbank aufnehmen will, da kann man gern sich alles angucken. Irgend welche Texte kann ich verschlüsseln, das sollte kein Problem sein.

Mir hätte es mehr Sorgen gemacht wenn ich mod_session aktiviert hätte, weil damit auch die Authentifizierung und Autorisierung mit verbunden wird. Ob man jetz für mein Projekt über Cookies oder GET oder der Server selber mit einer Datenbank die Daten vermerkt ist mir egal. Solange man nicht sensible Informationen auslesen kann.

An die Skripte kommen nur ausgewählte Leute ran! Lässt sich einfach mit Apache regeln. Kompliziert wird es dann erst wieder mit einer zentralen Benutzerverwaltung. Deswegen bin ich froh nicht eine Session aufbauen zu müssen und damit anfälliger werde gegen Attacken.

[TS]

Hallo und guten Morgen,

mir dünkt, dass hier überhaupt noch keine Übersicht über übliche und erprobte Methoden und Systeme besteht?

Ich erfinde ja auch immer gerne das Rad neu; man weiß ja vorher nie, ob nicht doch ein fliegender Teppich dabei heraus kommt. Aber solche Erfindungsversuche darf man gerade im Webumfeld nicht in die öffentlichkeit entlassen, bevor sie auf Härte getestet wurden.

Im Prinzip könnten hir ja unsere "Perlies" mal aus ihren Kindertagen erzählen, wie das mal alles begann mit der CGI-Entwicklung. Man könnte die Backendmodule schöießlich auch in C oder TP schreiben und Binaries daraus machen...

Liebe Grüße
TS

[Rolf b]

Sind nur Zahlen die ich in die Datenbank aufnehmen will, da kann man gern sich alles angucken. Irgend welche Texte kann ich verschlüsseln, das sollte kein Problem sein.

Die Frage ist: müssen diese Zahlen irgendwie eine Plausibilität aufweisen, gibt es eine logische Abhängigkeit dazwischen, kann der Anwender durch Manipulation des hidden-Elements etwas erreichen, was er über normale Eingaben auf deinen HTML Seiten nicht erreichen kann?

Wenn das unproblematisch ist, dann kannst Du sicherlich nach jedem submitteten Form die eingebenen Werte in einem hidden Element sammeln und durchschleifen. Auf der letzten Seite prüfst Du dann nochmal, ob es wirklich noch alles Zahlen sind, und schreibst sie dann in deine DB. Aber mit einem musst Du jederzeit rechnen: dass jemand das hidden-Element manipuliert, dir irgendwelche Anführungszeichen oder sonstige String-Terminatoren hineinschreibt (gerne auch mit HTML-Symbolen oder Hex-Sequenzen) und dir damit dein Script basht. Dagegen musst Du Dich gründlich zur Wehr setzen.

Und du sagst, du willst keine Authentication haben. Unter welchem Schlüssel schreibst du denn dann die Zahlen weg? Einfach irgendwie? Normalerweise sollten diese Zahlen doch irgendeine Semantik haben und mit demjenigen in Bezug stehen, der sie eingegeben hat.

Rolf

[suleiman]

Sorry, weil ich erst jetzt Antworte. Ich habe diesen Post nicht weiter verfolgt, weil für mich die Sache geklärt war.

Gute Fragen hast du da Rolf!

Zur Vervollständigung, ich baue mir einen privaten Server für verschiedene Dinge, wie z.B. DB-Anbindung. Apache (Web-Server) mutz ich nur als Frontend und dabei wird das SSL-Protokoll erzwungen.

Ob man was erreichen kann mit XSS glaube ich nicht, aber dafür habe ich einen Post im anderem Forum . Was mir auffällt ist dass man eine Variable (welche mit submit abgesendet wird) manipulieren kann und ein paar Abfragen somit überspringen kann. Dies muß ich noch Adressieren!

Hacken wird schwer, ATM bin ich nur für bestimmte MAC-Adressen im LAN erreichbar. Wenn ich für die Öffentlichkeit eine zweite Domain erstellen sollte, dann über eine andere Adresse.

Ihr habt ich zum Grübeln gebracht. Ich habe mir noch nicht genug Gedanken zum Thema Authentifizieren gemacht. Passwortschutz ist via Apache aktiv, aber wo parkt man am sinnvollsten eine ID vom Benutzer hin ? Der dunkle Weg wäre übern Apache. Apache kann Cookies Verwalten, dann brauch ich nur noch die IDs aus den Cookies mit Java auslesen. Alternative wäre gleich eine Datenbank anlegen z.B. via OpenLDAP. Leider kaum gute LDAP-Anleitungen im Netz. Da ich aber gern LDAP nutzen möchte, habe ich alles noch hinten angestellt und mich nur mit der Autorisierung befasst. Noch kann ich es verkraften in der Testphase/Aufbau. Aber aus langer Sicht werde ich nicht um eine Datenbank für die Benutzerverwaltung rum kommen.