2009-06-23 5 views
1

hatte nur einen GedankenPhp Sicherheitsfrage

post.php

if (isset($_SESSION['id'])) { 

if (isset($_POST['comment'])) { 
insert() 
} 

<form method="post" action="post.php"> 

<textarea name="comment"></textarea> 

<input type="submit" class="btn" value="Submit"> 

</form> 

} 

$ _SESSION [ 'id'] eingestellt werden muss post.php zuzugreifen. Ist das sicher genug?

Nur denken vielleicht kann jemand einfach eine Sitzung auf ihrer Website erstellen und ihre eigene post.php machen und sie auf meine Seite umleiten? können Sie das tun?

<form method="post" action="http://mysite.com/post.php"> 

<textarea name="comment"></textarea> 


<input type="submit" class="btn" value="Submit"> 

</form> 

Exucse mein begrenztes Englisch

+0

$ _SESSION ['id'] wird auf dem Server erstellt, es ist nicht einfach zu fälschen –

+0

@haim evgi: es hängt vom Sitzungsspeichersystem ab. Einige Sitzungsspeichersysteme verwenden Cookies zum Speichern von Werten. – Salaryman

+0

@Salaryman so mit Cookies SESSION zu speichern bedeutet, sitzt nicht sicher genug, oder? – jrharshath

Antwort

0

Das eigentliche Problem ist, dass die Menschen das Paket midflight abfangen und die Werte der Form umschreiben zu sein, was auch immer sie wollen. Welche Sicherheitsziele versuchen Sie zu erreichen? Die Benutzer haben immer die vollständige Kontrolle über die vom Client gesendeten Werte. Stellen Sie sicher, dass Ihre Anwendung keine Daten zurückerhält.

Blick auf Tamper Data für Firefox: https://addons.mozilla.org/en-US/firefox/addon/966

+0

ich glaube nicht, dass es so kritisch ist, wenn Leute den Kommentar manipulieren können, den sie sich selbst gepostet haben (da Manipulationsdaten sie aktivieren würden). Das Problem hier ist, dass nur eingeloggte Personen in der Lage sind zu posten. dafür muss Session Id Hijacking stattfinden - und das ist ein anderes Problem. – stefs

+0

@stefan mai: ok, andere Leute, die Ihren Inhalt neu schreiben, indem sie Netzwerkverkehr entführen, können ein Problem sein, werden aber von https gelöst. – stefs

4

Wie allgemeine Hinweise gegeben, ich ziehe immer "bail-out-bald" über "if-if-if". Das heißt, die Oberseite sollte eher wie folgt aussehen:

if (!isset($_SESSION['id'])) { 
    // display_error(); 
    // redirect() 
    // whatever else needs to be done 
    exit; 
} 

// continue as planned 
0

ich kann kein unmittelbar bevorstehendes Problem sehen. Wenn es kritisch ist, stellen Sie sicher, dass die Daten über https gesendet werden, so dass Leute, die den Netzwerkverkehr kapern, diese nicht manipulieren können (wie es Stefan Mai vorgeschlagen hat). Ansonsten scheint es in Ordnung zu sein - solange niemand Ihren User Session-Cookies stiehlt.

Decezes-Methode ist nur eine andere Codierung Stil. es erhöht nicht die Sicherheit per se, aber schlampig Programmierer vor Fehlern in Form verhindern kann:

if (checkIfLoggedIn()) { 
    doPrivateThing(); 
} 

doAnotherPrivateThing(); // bug: the programmer should have 
          // put that into the if-conditional 

ansonsten sicher, dass der Session-ID in einem Cookie gespeichert wird, und nie transparent über die URL übergeben! Ich bin mir nicht sicher über die Standardeinstellungen in der php.ini heutzutage, aber es pflegte, URLs automatisch zu schreiben, wenn Cookies deaktiviert werden. prüfe das besser.

soweit ich mich erinnere, die ini-Option ist session.use_only_cookies (aktiviert werden soll)

php/session security

Update:

„Denken Sie einfach vielleicht jemand eine Sitzung nur erstellen können sich auf ihre site "

nein, das wird nicht funktionieren. Sitzungen werden auf session_start(); erstellt (oder manchmal automatisch). $_SESSION['id'] hat nichts mit der session_id(); zu tun, es ist nur eine Variable. obwohl es nicht sehr gut benannt ist, weil andere es tatsächlich verwechseln könnten (Wartbarkeit!). besser nennen Sie es $_SESSION['isUserLoggedIn']; oder so ähnlich.

+0

Ja stimmt, sicherheitshalber macht mein Vorschlag keinen Unterschied, wenn es keinen Fehler im Code gibt. Der Punkt ist, ein Programmierer ist sein eigener schlimmster Feind, also wollen Sie immer die Wahrscheinlichkeit verringern, dumme kleine Fehler einzuführen, die sich in einen Sicherheitsalbtraum verwandeln können. – deceze

+0

ja, ich schrieb genau das: "kann verhindern, dass schlampige Programmierer Fehler machen" :) – stefs