Erkennt jemand hier wie man ein XSS auslösen kann:
foo;alert('xss')
Ich glaube die Anführungszeichen werden escaped, und die Variablenreihenfolge ist falsch.
Erkennt jemand hier wie man ein XSS auslösen kann:
foo;alert('xss')
Ich glaube die Anführungszeichen werden escaped, und die Variablenreihenfolge ist falsch.
foo;alert('xss')
Ich glaube die Anführungszeichen werden escaped, und die Variablenreihenfolge ist falsch.
Funktioniert noch nicht:
Das ist code von Response (die ich bis jetzt übersehen )
<?php
if (isset($_GET["q"])) {
$par = $_GET["q"];
} else {
$par = "";
}
print "{'response':'$par'}";
?>
Hab es hinbekommen - musst man wirklich in der reponse Funktion sehen - hatte die eval falsch interpretiert, aber wenn man ein wenig überlegt - ist es logisch das man Zuweisung nicht manipulieren kann, sondern den übergeben Code
Hand auf Herz! Wer kannte die Frage „Muss man Dir immer alles dreimal sagen?“ als Kind nicht?
Heute geht Thunderbird auf Nummer sicher:
Hand auf Herz! Wer kannte die Frage „Muss man Dir immer alles dreimal sagen?“ als Kind nicht?
Heute geht Thunderbird auf Nummer sicher:
Tja, geheim ist eben geheim! Da könnte ja jeder kommen!
Manche Websites / Anbieter sind echt selten dämlich…
Fehler: keine Großbuchstaben im Passwort.
Ok, habs geändert.
Fehler: keine Sonderzeichen im Passwort.
Ok, habs geändert.
Fehler: Keine Zahlen im Passwort.
Ok, habs geändert.
Zehn Minuten später:
Fehler: Das Passwort darf maximal 16 Zeichen lang sein.
EDIT: Was ich auch nie verstehe ist, warum manche Websites, wenn ich ein 32 Zeichen langes Passwort mit Sonderzeichen, Groß-/Kleinbuchstaben und Zahlen benutze, die sagen "Sehr sicheres Passwort". Aber wenn ich dann noch meinen Benutzernamen zusätzlich hinten dranhänge, dann ist es plötzlich ein "Sehr unsicheres Passwort". Wieso sollte denn das ZUSÄTZLICHE ANHÄNGEN des Benutzernamens das Passwort unsicherer machen? o0
Wenn man keine Sonderzeichen nutzen darf werd ich immer wild bei sowas lol
Tja, geheim ist eben geheim! Da könnte ja jeder kommen!
Ich habe doch nicht Informatik studiert, um mich von solchen Fehlermeldungen von der Sichtung des geschützten Inhalts abhalten zu lassen …
Was ich auch nie verstehe ist, warum manche Websites, wenn ich ein 32 Zeichen langes Passwort mit Sonderzeichen, Groß-/Kleinbuchstaben und Zahlen benutze, die sagen "Sehr sicheres Passwort".
Weil die Websites exakt das tun, wie sie programmiert wurden.
Wenn string.contains(username) auslöst, dann ist das ein harter Ablehngrund, statt einer Bewertung die nacher aufsummiert wird.
Und der Rest ist halt prozedural. Vieles kann man aber im Frontend bereits abfangen.
Wenn man keine Sonderzeichen nutzen darf werd ich immer wild bei sowas lol
Oder nur bestimmte Sonderzeichen (Looking at you, Deutsche Post DHL).
! ist in Ordnung, aber # ist in unserem System nicht erlaubt. WTF?
Weil die Websites exakt das tun, wie sie programmiert wurden.
Wenn string.contains(username) auslöst, dann ist das ein harter Ablehngrund, statt einer Bewertung die nacher aufsummiert wird.
Ja, aber das ist doch dämlich. Die könnten doch besser den Usernamen entfernen und dann prüfen, ob es ein sicheres Passwort ist.
Wenn string.replace(username, "") sicher ist, ist es auch mit angehängtem Usernamen mindestens genau so sicher
Hab ich jetzt auch schon häufiger gesehen, speziell bei Webseiten von Spielen oder ähnliches, dass die nur Passwörter von 8 bis 10 Zeichen zulassen. Stimmt mich immer etwas traurig.
Ja, aber das ist doch dämlich. Die könnten doch besser den Usernamen entfernen und dann prüfen, ob es ein sicheres Passwort ist.
Das würde aber mehr Arbeit bedeuten
des einen Freud des anderen Leid;
ich habs nicht so mit Sonderzeichen;
das erhöht mir die Sicherheit zu wenig als deren Zwang sie verwenden zu müssen einen Sinn geben würde ...
Das würde aber mehr Arbeit bedeuten
Naja, geht. Mal als Beispiel in Java, weil ich PHP nicht mag:
Anstatt dem:
public boolean isSecureEnough(String password, String username) {
if(!containsSpecialChars(password)) return false;
if(!containsUppercase(password)) return false;
if(!containsLowercase(password)) return false;
if(!containsNumber(password)) return false;
if(password.contains(username)) return false;
return true;
}
einfach folgendes:
public boolean isSecureEnough(String password, String username) {
password = password.replace(username, "");
if(!containsSpecialChars(password)) return false;
if(!containsUppercase(password)) return false;
if(!containsLowercase(password)) return false;
if(!containsNumber(password)) return false;
return true;
}
Wäre jetzt also nicht soooo aufwendig
Wäre jetzt also nicht soooo aufwendig
Der 08/15 Programmierer verwendet dafür doch bestimmt eine Library.
(a) if ( !isSecureEnough( password, username ) )
im Vergleich dazu
(b) if ( !isSecureEnough( password ) )
ich würd ma bei (a) denken: "was ist das für ein Pfusch?"
Alles anzeigenManche Websites / Anbieter sind echt selten dämlich…
Fehler: keine Großbuchstaben im Passwort.
Ok, habs geändert.
Fehler: keine Sonderzeichen im Passwort.
Ok, habs geändert.
Fehler: Keine Zahlen im Passwort.
Ok, habs geändert.
Zehn Minuten später:
Fehler: Das Passwort darf maximal 16 Zeichen lang sein.
Ja, so mache ich den Nutzern auch immer das Leben schwer:
(a) if ( !isSecureEnough( password, username ) )
(b) if ( !isSecureEnough( password ) )
Logischerweise benötigt die Funktion unabhängig davon aber vollen Zugriff auf die Passworttabelle, um sinnvolle Fehlermeldungen wie „Dieses Passwort wird bereits von Nutzer 'mainziman' verwendet, bitte wählen Sie ein anderes!“ ausgeben zu können …
(Totschlagargument gegen die Verwendung von Nicht-Klartext-Speicherung)
Wäre jetzt also nicht soooo aufwendig
Du hast den Job!