Security Quiz

Hallo erstmal.
Ich hatte heute beim morgendlichem Urinieren eine Idee:

Ein 'simples' kleines Quiz.
Ich werde hier ein Paar Codestückelchen(Lulz ;D) die vulnerable sind reinstellen. Aber auch URLs und alles Andere.
Ich bitte die Antworten/Ideen/Whatever´se(ich wieder ._.) nur per PM an mich zu senden. UND NICHT HIER REIN ZU SCHREIBEN!!!
Falls ihr Ideen habt für weitere Aufgaben, vielleicht etwas schwerere ;), dann PM an mich. Werde das hier so gut wie möglich up to date halten.
Fangen wir mal simple an :D
Antwortet einfach mit den Angriffen die möglich sein könnten. Wenn dir das zu leicht ist kannst du versuchen noch einen Fix zu finden ;).

Aufgabe 1:

Code:

---

<?php
if (isset($_GET['page'])){
    include("pages/{$_GET['page']}");
}
?>

---

Aufgabe 2:

Code:

---

<?php
if (isset($_GET['file'])){
    echo "<h3>Inhalt der Datei 'pages/{$_GET['file']}.txt'</h3>";
    include("pages/{$_GET['file']}.txt");
}
?>

---

Aufgabe 3:

Code:

---

<script>
function prot() {
    pass = prompt("Passwort eingeben", "password");
    document.location.href="http://gesichert_durch_javascript.com/user/"+pass+".html";
}
</script>

---

Aufgabe 4:

Code:

---

http://example.com/foobar.html?arg=ROFLROFLROFL

---

So ... mehr (und möglichst schwerere)werden kommen, wahrscheinlich schon morgen :D, ...Habe jetzt grade keine Lust weiter zu schreiben da es schon recht spät ist. Falls ihr Typos bemerkt dann mir bitte melden ZzZzZz.
Nett wäre ein Feedback was ihr von meiner Idee hier haltet. ;)
Möglicherweise verpacke ich das dann später in eine kleine Website.

EDIT:
Erstmal danke für das Feedback. Da es aber ziemlich negativ war, habe ich mich entschlossen das Ganze lieber privat zu basteln und dann später hier zu updaten.
Ich persönlich finde meine Idee ganz nett, nur bin ich zu dumm richtig Fragen bzw. Aufgaben zu stellen.
Wer sich trotzdem für die Lücken interessiert. Hier sind 1 und 2 mit möglichem Fix:

1: File inclusion vulnerability
Hier sieht mal gleich: Alles lässt sich includen.
Beispielsweise mit ?page=/../../../../../../etc/passwd lassen sich Informationen des Servers aus der passwd datei auslesen.
Aber nicht nur das, es lässt sich auch beliebiger PHP-Code ausführen. Dazu muss der PHP-Code einfach als parameter
übergeben werden: ?page=<?php phpinfo(); ?> Da die meisten Server eine Log-File besitzen. Und in diese
auch die URL keinplan.de/fuckoff.php?page=<?php phpinfo(); ?> geschrieben wurde, kann der Angreifer durch
'includen' der Log-File diesen php-code ausführen. Die Log-File kann dabei vollgestopft mit anderem Müll sein, spielt
ja keine Rolle :)

Hier mal ein möglicher Fix:

Code:

---

<?php

$pages = scandir('pages');
unset($pages[0], $pages[1]);


if (isset($_GET['page']) && in_array($_GET['page'], $pages)){
    include("pages/{$_GET['page']}");
}else{
    echo 'Die Seite konnte nicht gefunden werden!'
?>

---

2: Null-Byte vulnerability

Diesmal könnte man denken es sei sicher, da nur TXT-Files included werden. Das täuscht.
Durch anhängen eines Nullbytes lässt sich das leicht umgehen.
Warum? ... Da wir alle wissen ist der PHP-Compiler in c geschrieben. Dort wird das
Ende eines Strings mit einem Nullbyte markiert.
Das hat zufolge das der PHP-Code die Endung '.txt' ganz einfach weglässt. FAIL!

Fix: Genau wie bei 1. adden wir eine Whitelist:

Code:

---

<?php


$pages = scandir('pages');
unset($pages[0], $pages[1]);


if (isset($_GET['file']) && in_array("{$_GET['file']).txt", $files)){
    echo "<h3>Inhalt der Datei 'pages/{$_GET['file']}.txt'</h3>";
    include("pages/{$_GET['file']}.txt");
}
?>

---

Sind beides keine wirklich guten Fixes, insbesondere falls nen Angreifer irgendwas in /pages schreiben koennte. Sei es ein Bild oder sonst was. Ausserdem fehlt der strict-Parameter beim in_array, sonst ist der Vergleich zu lax. Der Nullbyte Trick funktioniert seit 2010 nicht mehr, da File-Funktionen in PHP eine gesonderte Parameterabfrage machen um Pfade zu beschreiben und die duerfen kein Nullbyte enthalten. Der Check im Code:

Code:

---

static const char *zend_parse_arg_impl(int arg_num, zval *arg, va_list *va, const char **spec, char **error, int *severity) /* {{{ */{
    const char *spec_walk = *spec;
    char c = *spec_walk++;
    int check_null = 0;
    zval *real_arg = arg;


    /* scan through modifiers */
    ZVAL_DEREF(arg);
    while (1) {
        if (*spec_walk == '/') {
            SEPARATE_ZVAL_NOREF(arg);
            real_arg = arg;
        } else if (*spec_walk == '!') {
            check_null = 1;
        } else {
            break;
        }
        spec_walk++;
    }


    switch (c) {


        case 'p':
            {
                char **p = va_arg(*va, char **);
                size_t *pl = va_arg(*va, size_t *);
                if (!zend_parse_arg_path(arg, p, pl, check_null)) {
                    return "a valid path";
                }
            }


static zend_always_inline int zend_parse_arg_path_str(zval *arg, zend_string **dest, int check_null)
{
    if (!zend_parse_arg_str(arg, dest, check_null) ||
        (*dest && UNEXPECTED(CHECK_NULL_PATH(ZSTR_VAL(*dest), ZSTR_LEN(*dest))))) {
        return 0;
    }
    return 1;
}


#define CHECK_NULL_PATH(p, l) (strlen(p) != l)

---

CHECK_NULL_PATH checkt dann ob die ZVAL Laenge gleich der Stringlaenge ist. Wenn ungleich dann ist da nen Nullbyte drinne und der Pfad wird nicht akzeptiert.

Lustig das du selbst nur Lösungen für 1 & 2 hast, was eigtl. die selbe Lücke darstellt.
UserInput traut man nicht und das ist wirklich Websecurity Kindergarten Stoff.

#3 Also wer sowas schreibt sollte lieber Metzger oder so werden, "authentication" in JS lulz...
#4 Rall ich einfach komplett nicht. Kann mir einer mal auf die Sprünge helfen wo hier Lücke sichtbar sein soll (ohne zu raten wie das Handling dazu im BE ausschaut)?