Meine Foren software

Hallo liebe Freunde,

ich habe nun 2 Wochen an meiner Forensoftware gearbeitet und möchte natürlich das alle Sicherheitsaspekte berücksichtigt werden.

XSS und Sql injections habe ich nach meinen Wissensstand eigentlich alle beseitigt. Könnte aber durch aus sein das ich Faselfehler drin habe.

Deswegen meine erste Frage.. Könnt ihr bei Interesse mal das Forum
http://www.poisbb.net unter die Lupe nehmen. Aber nix kaputt machen ;)
Das ich der eigentümer bin soll die Zeile
<meta name="HABO" content="Try hack">

beweißen. Die findet ihr im Quellcode. Und sonst würde ich mich über Feedback freuen.
Wenn jemand Lust hat mit zu entwickeln dann kann er das ruhig machen.

Danke und LG
 
Hallo,

Hast du z.B. schon skipfish[1] probiert? Damit kannst du die "Basics" schonmal abdecken. Ausserdem gibts Listen mit Bekannten Injections bei anderen System. Die kannst du mit einem einfachen Script auch bei dir prüfen bzw. die Schemen vergleichen[2].

Ob die Forensoftware wirklich sicher ist, könnte man wohl nur mit einem richtigen Security Audit prüfen. Kostet ne Stange Geld sowas "richtig" machen zu lassen.

[1] http://code.google.com/p/skipfish/
[2] http://blog.freewords.in/2010/03/rfi-remote-file-including-moeglichkeiten/

f.
 
Hallo,

Danke für die Antwort. Nein hatte ich noch nicht gemacht. Werde ich dann testen müssen wenn mein PC wieder läuft, gerade ist sein Mainboard kaputt. :rolleyes:

lg
 
Ach, was mir so beim durchschauen der Webseite und deiner Postings auffällt:

Nimm dir doch ein bischen mehr Zeit als zwei Wochen und feil noch ein wenig an deiner Software. Du deckst mit deiner Software zwar die Standardfunktionen ab, übergehst aber dafür andere Themen. Sprich, der User hat gar keinen Grund deine Forensoftware zu verwenden, weil es ausgereiftere und "bessere" Programme gibt.

Nur so eine kleine Anregung.

f.
 
Gefällt mir ziemlich gut, aber die Template Funktion solltest du stark überarbeiten. Was da alles an php-code in den Template Dateien ist ist der Hammer.... du bearbeitest nen Haufen sql Abfragen und Einfügungen in den Templates. Damit sind die so speziell, dass wohl nur noch du durchblickst und kein anderer eins erstellen kann :wink:
Achso.. und ich wurde nach der Registration nicht weitergeleitet. Es stand nur irgendwann da, dass ich mich einloggen kann, gesehen habe ich aber noch das Registrationsformular.

Das wären so die 2 Dinge die ich bis jetzt am kritischsten sehe. Wenn die erledigt sind, könnte man sich ernsthaft überlegen das Forum weiter zu benutzen. Hör auf jeden Fall nicht jetzt auf daran zu arbeiten.

Grüße, Maulwurf
 
Also der Code sieht in meinen Augen wirklich sehr sehr unsicher aus.... oO

-Filter Funktionen fehlen komplett(!!)
-Nach jedem Aufruf der Funktion "header($foo);" fehlt ein "exit;"
-CSRF-Schutz einbauen*1
-Statt $_COOKIE, besser $_SESSION benutzen + Session Fixation*1
-Statt MySQL, besser MySQLi benutzen denn das i steht nicht ohne Grund für Improved(Prepared Statements) :)
-Statt den ersten 6 Zeilen in der functions.inc.php könntest du die htaccess erweitern und so dieses Problem lösen ;)

*1: Zusammenhängende Dinge

Allet im Schnelldurchlauf :P

MfG
Keci
 
Hey danke für die Antworten,

Ich habe gerade kein Geld um Bücher zu kaufen.

-Filter Funktionen fehlen komplett(!!)
-Nach jedem Aufruf der Funktion "header($foo);" fehlt ein "exit;"
-CSRF-Schutz einbauen*1
-Statt $_COOKIE, besser $_SESSION benutzen + Session Fixation*1
-Statt MySQL, besser MySQLi benutzen denn das i steht nicht ohne Grund für Improved(Prepared Statements) :)
-Statt den ersten 6 Zeilen in der functions.inc.php könntest du die htaccess erweitern und so dieses Problem lösen

Welche Filterfunktionen genau? Also mit mysql_real_escape_string() wird bei jeden Schreiben in die Datenbank der String maskiert und bei der Ausgabe mit htmlspecialchars gegen XSS geimpft.

Mit dem Header muss ich mal googlen habe keine Ahung was gemeint ist.

CSRF abwehr ist eingebaut. Alle wichtigen Funktionen wie Beiträge schreiben oder Profileinstellungen sind mit einer "DRH" Postvariable belegt die sich am Anfang der Seite ändert md5(rnd(microtime)) und am ende in die session geschrieben wird.. so kann man bei einem Forenpost zb sicher sein, dass die Form zum Posten auch vom Forum gestellt wurde.

Mysqli auch keine Ahung -> google meinerseits :)

Komplett .htaccess ist aber nicht gut wegen ISS Servern z.B. Das Entwicklerboard z.B. läuft auf einem ISS.


Edit:
Ach du meinst bei einer Weiterleitung bei Location z.B. dass man die Ausführung beendet damit der Content nicht mitgesendet wird?

Ich weiß leider schon nicht mehr wo ich header() verwendet habe.
Kannst du mir die Codestelle sagen?

Und nochmal zum Filter.
$s_exist=$sql->query("SELECT fid FROM foren WHERE fid='$fid';");
z.B. Bei $fid bin ich mir sicher das es keine Injection enthält das ganze Board stirbt wenn da Plunder drin steht $fid muss ein int() sein. Bei anderen Abfragen ist es das gleiche. Ja das sieht auf dem ersten Blick sehr nachlässig aus, hoffe eben auch das ich nicht irgendwo etwas vergessen habe.
 
Zuletzt bearbeitet:
Wer ISS benutzt braucht eigentlich auch keine sicheren PHP Apps schreiben /dummer_spruch

Apache2 ist der Standard, wenn der ISS sich nicht dran halten kann und auch keinen alternativen Mechanismus bietet :rolleyes:
 
Durch Maskieren hast du wohl ein "MUSS" erfüllt, aber das Filtern der unerwünschten Sachen fehlt.

MySQLi=> http://de.wikipedia.org/wiki/MySQLi

MD5 ist unsicher, nutz lieber SHA1 und zudem ist deine Lösung in Sachen CSRF keine Lösung, weil du erfassen musst von wem die Nachricht/Post kommt.

PHP:
function GetIP(){return  isset($_SERVER['HTTP_X_FORWARDED_FOR'])&&$_SERVER['HTTP_X_FORWARDED_FOR']!='127.0.0.1'?$_SERVER['HTTP_X_FORWARDED_FOR']:$_SERVER['REMOTE_ADDR'];}  

function GenSessionHash(){
return sha1($_SERVER['HTTP_ACCEPT_CHARSET'].$_SERVER['HTTP_ACCEPT_ENCODING'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$_SERVER['HTTP_USER_AGENT'].GetIP());
}
Du brauchst Sicherheiten wieso der Client der tatsächliche Client ist und mit diesen Funktionen erreichste etwas mehr Identifikation.
Du gleichst einfach - den nach Login erstellten Hash - bei jedem Browser-Request mit dem Hash in der Datenbank ab ;)

Für das Suchen der header Funktionen kannste mit STRG + F die Suche schnell aufrufen und einfach so suchen ;)

Zudem musst aufpassen, dass dein Board nicht mit Request-Floods durchgespamt wird. $_GET kann schnell inne Hose gehen. Sicher. $_POST ist genau so betroffen wegen cURL aber dennoch gehen die meisten Angriffe auf GET-Variablen.

Falls die GET-Variable einen Int enthalten soll solltest du folgende Funktion noch zusätzlich einbauen:

PHP:
function CheckNum(&$n){return preg_match('/^[0-9]+$/D',$n);}
Zudem solltest du aufjedenfall immer auf Zeichencodierungen "utf-8" setzen.

PHP:
function Esc(&$h){return htmlentities($h,ENT_QUOTES,'UTF-8');}
 
Hallo,

MD5 ist unsicher, nutz lieber SHA1

koenntest du das vielleicht begruenden? Ich weiss, dass es aufgrund des begrenzten Zeichenraums die Moeglichkeit von MD5-Kollisionen gibt, aber die gibt es bei SHA1 auch und ich habe noch nie von einem erfolgreichen Angriff in 'freier Wildbahn' gehoert. Grade bei Passwoertern ist es doch so, dass sie nur selten die Laenge eines Hashes erreichen. Die Anzahl der notwendigen Versuche um eine Kollision herbeizufuehren, ist da meines Wissens nicht geringer als bei Brute-Force. Rein rechnerisch ist sogar das Gegenteil der Fall.

Falls die GET-Variable einen Int enthalten soll solltest du folgende Funktion noch zusätzlich einbauen:

PHP:
function CheckNum(&$n){return preg_match('/^[0-9]+$/D',$n);}


PHP:
(int) $_GET['foo'];
Ist da etwas sparsamer. http://www.entwicklerblog.net/php/php-variable-in-integer-verwandeln-intfoo-oder-intvalfoo/

liebe Gruesse
dishix
 
du solltest, wenn du schon mal die hashfunktion änderst, auch gleich anfangen salts zu benutzen ... es würde sich beispielsweise anbieten jedesmal wenn ein passwort neu angelegt wird, ein neues salt für dieses passwort anzulegen

eliminiert defacto die möglichkeiten passwort tabellen effizient mit rainbowtables anzugreifen
 
@dishix

Es gab mal nen Bericht über russische Hacker, die die Leistungsfähigkeit von Grafikkarten für alle außergraphischen Berechnungen genutzt haben, MD5-Kollisionen mit inbegriffen und SHA-1 ist mit 192-Bit immernoch einbisschen sicherer.

http://de.wikipedia.org/wiki/GPGPU

Hier mal ein Snippet für Salted Hashes:

PHP:
<?php

static $salt=array(
                array(
             'VJE§49fj=$JKVJD89?§=$VJDK(JVK787LJSK%787)DVJKJ7878§)F78JISDJKJC)§kdfkg443784',
             'ab965d524ED9c6e38fdHJGF(§)da78884895§(%3a7e69fdDJ4679§$)%&=c7416d#b32%&erk99',
             '5jgfjMhEE:PD\uT2w\28ZS<Tf*sa.e?zms{+25Ov`vGfY;^PVw.+q!nc98%Zhdiapu7;z%Ai#^qT',
             'VF[T0]gCcCRapE0Q%)&Ew?f;v`?}qkq&b{[!q%0oa&te7oDV4K+(JNeLxAq`c?[R3yadn^U+H$.&'),
                array(
             '*jnZa7UG%5T/+?bM2z3Ww7Q-fIqsBaOJR&QN8ua+}VBDkHf$78W3GoAy"<%&:?bQ>2SmRK;lnd6R',
             'K2m/wAK)n*7e(}`==gwQ+DvXO8M9*f`73(YTy^/{<QtBgjO^*OcHm2q1BMAoGVn!QkN+%}BAJ}<5',
             'z!=fnWm%51Mn]6LffC7c$XBU9bVsG{g)}@9y;sdkOEhKx=us+O{Ki?aYEo8>KYWwI>C,BkXcUs^I',
             '97Q[d\CzS`=5r{u.fDmwnrDZN*0hxN/.,X;FDGIGYEQC)=4O@3O=qp]q$c1=>qCFbb}P$O<*oIm1')
             );
function GenSaltedHash($foo){ global $salt;
  $rnd0=mt_rand(0,count($salt[0])-1);
  $rnd1=mt_rand(0,count($salt[1])-1);
  return sha1($salt[0][$rnd0].$foo.$salt[1][$rnd1]);
}          

function CheckSaltedPW($loginpw,$salteddbpw){ global $salt;

  $rounds=pow(count($salt[0]),count($salt[1]));

    for($i=0;$i<$rounds -1;++$i){

      $rnd0=mt_rand(0,count($salt[0])-1);
      $rnd1=mt_rand(0,count($salt[1])-1);
      
      $rnd= sha1($salt[0][$rnd0].$loginpw.$salt[1][$rnd1]);
      if($salteddbpw===$rnd)return 1;
      
      unset($rnd);
    }
    return 0;
}
echo 'Erstelle Salted SHA-192 Hash: '.GenSaltedHash('kp');
echo '<br />';
echo 'Überprüfe den SaltedHash mit dem PW von der Datenbank: '.(CheckSaltedPW('kp','04d2ae37fd8705366d1e4fc77049df2507bc9796')?'Richtiges PW':'Falsches PW');
?>
 
Zurück
Oben