|BRAINSTORMING| Sicherheit bei Usereingaben

[Hopka]

Man muss sich bei allen Scripten, die Formulardaten verarbeiten sollen Gedanken drüber machen, was das Script machen soll, wenn keine Daten abgeschickt wurden (z.B. das Script direkt im Browser aufgerufen würde).

Außerdem ist es relativ wichtig, sich vor SPAM zu schützen, also darauf zu achten, dass nicht ein User mehrere 1000 Einträge in kürzester Zeit erstellen kann.

Was auch wichtig ist, in der Ausgabe Dinge wie WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
zu trennen, sonst sieht's hinterher ziemlich schlecht aus

EDIT:

---

Habs aus dem genannten Grund mal umgebrochen
TobiaZ

---

[Coragon Rivito]

also bei include dateien etc ..
ich hab meine namenskonventionen und dann genügt eine .htaccess ..

<FilesMatch "\.(cfg|class|inc|mod|lng|tpl)$">
  Order allow,deny
  Deny from all
</FilesMatch>

egal wo ich sie ablege .. sie sind sicher .. in oder unterhalb dem verzeichnis wo ich die .htaccess ablege (=

[Ryback]

Sicherheitshinweise zur php Programmierung

Auch wenn Javascript Teilthema maines Beitrages ist , denke ich gehört er dennoch in diese Rubrik,
da es alle php-Programmierer interessieren dürfte.

Gehen wir davon aus sie hätten folgendes Formular in ihrer HTML - Seite :

<form action="myScript.php" method="post">
<input name="myName" type="hidden" value="myValue">
<input name="Submit" type="submit" value="Submit">
</form>

Der Inhalt des hidden Field wurde wahrscheinlich auf der vorangehenden Seite geprüft,
also werden viele davon ausgehen daß dieser Wert nicht nochmal geprüft werden muß.
Dies ist aber ein Irrtum.
Nur alzu leicht kann man alle Elemente einer HTML-Seite (also auch von Formularen) beeinflussen.
Und zwar mit Javascript.:
Geben sie in der URL-Leiste folgendes ein:

javascript:alert(document.forms(0).elements(0).value="newValue")

Und schon ist der Wert im "hidden field" verändert.
Mit Code Injection kann ein Hacker sie jetzt angreifen wenn der Wert im hidden field nicht überprüft wird.
Wenn sie in einem Textfeld eine maxlength gesetzt haben, muß diese serverseitig nochmal geprüft werden.
Sie haben bestimmt schon erraten wie ich diese im Formular verändern kann:

javascript:alert(document.forms(0).elements(0).maxlength=100)

Benutzen sie immer if(strlen($_POST['myName'])<value) ... um sicher zu gehen daß alles korrekt ist.

Lustig wird es auch wenn man folgendes versucht :

javascript:alert(document.forms(0).elements(0).size=100)

Den type kann man verändern, die action, und so die Daten auf ein anderes Script umleiten.
Das ganze wird noch besser : Man kann Javascript Funktionen überdefinieren.
Wenn sie zum Beispiel onSubmit="return mailtesten()" haben une mailtesten überdefeinieren ...
Mein Tip: Machen sie alle überprüfungen für sämtliche Daten serverseitig mit php, niemals mit Javascript,
nicht einmal als Zusatz.

[TobiaZ]

Da wir aber Sessions benutzen, ist das ja eigentlich kein Problem!

[Coragon Rivito]

tobiaz, du solltest nicht von dir auf andere schließen (=
zwar verwende ich auch sessions, der beitrag ist dennoch wertvoll, soweit hääte ich - zugegeben - ned mal im ansatz gedacht ..

kann man das teil zum brainstorming anhängen ? damits da ist wos hingehört

[TobiaZ]

Naja, ich änder selbst schon mal gerne die ein oder andere Seite um, um den Programmierern mal zu zeigen wos langgeht.

wird zusammengeführ!

[Abraxax]

Original geschrieben von TobiaZ
wird zusammengeführ!

OffTopic:

---

habe ich gerade gemacht...

---

[TobiaZ]

ich weiß, du warst mal wieder schneller!

[rythms]

Original geschrieben von Moqui
@CannabisCow

man legt wenn möglich include Dateien außerhalb des WWW-Root-Verzeichnisses, um zu vermeiden, dass der User sensible Daten aus der Include Datei erfährt, wenn z. B. der PHP interpreter mal ausfällt....

Angenommen du hast eine Datei, in der du eine andere Datei includest. In der Include-datei stehen deine Zugangsdaten für MySQL.
-> PHP fällt aus...
der User sieht PlainText und sieht, dass du die und dieDatei includet hast...er sieht auch den Pfad...

nun kann er sich die Include Datei genau so anschaun...und deine Zugangsdaten sehen...

wenn du jetzt aber die Include Datei in einem ganz anderen Order hast, der außerhalb von der WWW-Root liegt, hat der User keine Möglichkeit sich die Include Datei anzuschauen.

soviel zur Theorie

ich denke in der Prxis funktionierts auch, nur ist man bei Providern leider stark eingeschränkt, was das angeht....

ich denke, einfacher ist es bei mysql nur connections von "localhost" zuzulassen.
um dem einzelnen aufruf von zu includenden seiten vorzubeugen, sollte man im "index", bzw der datei wo diese included werden eind efine setzen ..
z.B: wie phpBB das macht:
index.php:
define('IN_PHPBB', true);
und dann in der zu includenden datei:
if ( !defined('IN_PHPBB') )
{
die("Hacking attempt");
}

[TobiaZ]

Naja, konstanten sind nicht schlecht. vorrausgesetzt die db ist nicht auf localhost geschaltet (was bei vielen Webspaceangeboten ja nicht möglich ist), dann hilft ein Define nicht unbedingt, da man es evtl herausbekommen könnte.

ein speichern außerhalb des root halte ich für sehr empfehlenswert.

[BloodReaver]

naja also ich leg meine .inc sachen immer schön in unterordner und versteck gleich die ganzen ordner...

zusetzlich hamse auch noch die endung php und ich bin der meinung wenn die htaccess funktion ausfällt, dann is der apache kabudd... und dann sieht von dem eh keiner mehr was...


weiterhin denk ich sollte man logischerweise auch die daten immer per post senden... und dann schaun ob da was böses drin is, und einfach in html code umwandeln lassen bevor man irgendwas damit macht dann is das doch gut... weil was like: "&amp;quot;" macht keinen schaden mehr...

^^auch net wenn ichs 100 mal ausles und neu speicher...

[niknormal]

Was haltet ihr von dem Apachemodul Mod_rewrite??? Ich denke damit ist es einem user unmöglich an die eigentlichen dateien zu gelangen. alles hinter der tld wird als variable angesehen wenn man die .htaccess im root hat.

[TobiaZ]

naja, je nach dem, wie man die rewrite einsetzt, kann es wie du beschrieben hast aber auch enschränken. viel schlimmer ist jedoch das sicherheitsrisiko, wenn deine datei (die die vars verarbeitet) nunsauber programmiert ist. und das ist bei ca 70% der Fall. Vorallem, weil NewBees da gerne mal was auf die leichte Schulter nehmen-

[niknormal]

Würdest du das ein wenig weiter ausführen? Wo drin sind da die gefahren zu sehen und was bezeichnest du als unsauber? Der nachteil das auch als admin nicht mehr an die files rankommt hab ich umgangen in dem ich eine "bezeichner,dateiname" angeben kann und dann die file vom script ausgeben lasse.

[TobiaZ]

Angenommen du nutzt die RWE mit folgendem Pattern: /intern/kontakt/

dann kann bei einem File welches so arbeitet: include ($1."/".$2.".ph2);

auch ...de/config/datenbank/ aufgerufen werden. Angenommen man hat die Strucktur herausgefunden.