Beiträge von cottton

transition wird nur auf dem "Hauptelement" benötigt.
Soll heißen:
wenn auf #element{} ein transition: all drauf ist,
dann wird ja bei #element:hover sicherlich "etwas" geändert (zB background)
Da transition (zu dt. übergang) ja auf dem #element angegeben wurde, wird es bei hover genutzt.

Naja, demnach, was Du vorhast, würde ich dann weg von shared Hosting. Aber schon klar, dass man erstmal irgendwo anfangen muss.

Alles, was Du im verlinkten Post geschrieben hast, benötigt ja kein Framework.
Zum Thema Sicherheit kann man sich (sehr) streiten.
Auf der einen Seite ist das eigene Framework (was ja letz endlich deine "Codesammlung" darstellt) sicher durch uneinsehbarkeit. Auf der anderen Seite ist ein public Framework, wie Du schon sagtest, durch viele Hände/Köpfe gegangen.

Wenn wir mal annehmen, dass wir heute starten würden, dann wären ja die ersten Fragen:
- wohin mit der Seite (webserver/-space, ...)
- Aussehen (frontend)
- Abläufe (backend)
- welches DBMS (database management sys...) usw

Dann würde ich "einfach anfangen". Und dafür hab ich mein Tool geschrieben (was jeder mal machen sollte - man lernt einfach viel dabei).
Und ich will jetzt nicht mein framework vorstellen oder was auch immer. Aber jedes Projekt dieser Art braucht grundlegende Dinge:
- Speichern (mysql zb)
- Pagerouting
- Loginablauf ect
- Userpermissions
- ...
Das sind alles Sachen, die wir inzw kennen/können. Dazu brauchen wir kein Zend oder was auch immer, welches wir erstmal Monate lang lernen müssen, damit wir es beherrschen.
btw: kein normaler Mensch wird verstehen was in Zend und co genau abläuft. Die Verschleierung ist einfach zu groß. Und mit "normaler Mensch" meine ich jemand, der die Zeit besser nutzt, als eine "ToolSprache" zu lernen (auch Streitthema).

Also mMn fängt man (simple) an:
- konzept
- ablauf
- coden, ABER immer mit dem gedanken "hier baue ich das so auf, dass es später einfach zu ändern ist aber dennoch NICHT verschleiert was hier passiert"

Ich weiß, ich schreib schon wieder zu viel.
Kurz: kein framework. einfach anfangen =)

Ich nutze keins, schreibe mir aber (seit Monaten :D) ein eigenes.
Kommt drauf an was Du vorhast. (MoL sagt mir nix)
Ich finde die bekanntesten (Yii oder Zend) einfach zu unübersichtlich. Bei denen musst Du deren "Sprache" erstmal lernen. Und das ist mMn nicht wirklich Sinn der Sache.
Der komplette Code ist voll von Verschleierungen. Der Ablauf ist einfach nicht gut erkennbar.
Natürlich ist es für größere Firmen sinnvoll, da dort alle Mitarbeiter den gleichen Standards unterliegen sollten.

Ich finde das beste Framework ist Dein eigenes =)

EDIT: was ich hier vorher gepostet hatte war falsch - daher gelöscht.
Ich hatte das mal von einer Seite im Netz aufgeschnappt ... man sollte doch intensiver googlen wenns um Sicherheit geht =)

Also - SESSIONS. Wo landen die Daten?
Antwort: Serverseitig! Der User kommt also nicht an die Daten ran. Es wird nur eine SESSION-ID beim User hinterlegt*, welche dann zur Identifizierung genutzt wird.
* entweder per SESSION-Cookie (Cookies müssen akzeptiert werden), oder per URL (?PHPSESSID=...)

Was kann also passieren?
Antwort: Man kann die SESSION stehlen, indem man die SESSION-ID hat/klaut/kennt/...

Was sollte man bei seinen Tools/Scripten für SESSION-Einstellungen nutzen?
Antwort:

ini_set('session.use_cookies','1');  
ini_set('session.use_only_cookies','1');  
ini_set('session.use_trans_sid','0'); 
ini_set('session.cookie_httponly','1'); 
session_start(); 
session_regenerate_id(true);

Was bedeutet das im Detail?
Antwort:
Sehr gut erklärt: http://www.d-mueller.de/blog/php-sessi…ement-erklaert/
session.use_cookies() http://www.php.net/manual/de/sess…ion.use-cookies
session.use_only_cookies() http://www.php.net/manual/de/sess…se-only-cookies
session.use_trans_sid() http://www.php.net/manual/de/sess…n.use-trans-sid
session.cookie_httponly() http://www.php.net/manual/de/sess…cookie-httponly
session_regenerate_id() http://www.php.net/manual/de/sess…cookie-httponly

Zu session_regenerate_id():
Man sollte session_regenerate_id(true) (also boolean true) mitgeben, damit die "alten" SESSIONs gelöscht werden.
Sonst sammeln sich sinnlos veraltete, nicht mehr verwendete SESSSIONs auf dem Server.

Weiteres zum Thema SESSION:
http://www.php-kurs.com/session-hijacking.htm
http://www.php.net/manual/de/intro.session.php
http://www.php.net/manual/de/session.security.php

The Scout
Man kann also die SESSION['login'] = true nicht manipulieren. Es sei denn jemand hat Zugriff auf die Server-Files. Aber dann ist es ja sowieso zu spät (und der Angreifer braucht die SESSIONs nicht mehr =).

Die function würde so wohl nicht funktionieren.
So wie ich es verstanden hab, kann man diesen Operator nur einmal nutzen.
Denn alles war an "dieser Stelle und danach" reinkommt, kommt ins Array.
Es würde also alles in $input landen.

So soll es wohl nutzen bringen:

function myFunc($id, ...$para) {
    if($id == 3 and $para[0] = 'xyz'){
        // ...
    }
}
// call
myFunc(3,'yxz','bla','undso');

und so sehe ich es viel nützlicher an:

function myFunc($id, $para) {
    if($id == 3 and $para['name'] = 'xyz'){
        // ...
    }
}
myFunc(3, array('name' => 'yxz', 'text' => 'bla', 'ect' => 'undso') );

ich sehe außen wie innen "mehr" und habe sogar keys.

Jetzt stelle man sich einfach mal vor, dass die Parameter durch einen Dritten verändert werden müssen (Wartung, ect).
Der passt nicht auf und denkt sich:

myFunc(3,/*'yxz',*/'bla','undso'); // xyz brauchn wa net mehr

und in der func wird der egtl 2te ([1]) para als 1ster ([0]) genutzt.
Das kann mit nem ordentlichen Array (keys!) nicht passieren

http://phpmagazin.de/artikel/PHP-56-Splat-Async-Baem-172067
https://wiki.php.net/rfc/variadics

function fn($reqParam, $optParam = null, ...$params) {
    var_dump($reqParam, $optParam, $params);
}
 
fn(1);             // 1, null, []
fn(1, 2);          // 1, 2, []
fn(1, 2, 3);       // 1, 2, [3]
fn(1, 2, 3, 4);    // 1, 2, [3, 4]
fn(1, 2, 3, 4, 5); // 1, 2, [3, 4, 5]

Kurz: Durch den Operator "..." kann man in "variadic functions" ein Array erwarten.

Was zur Hölle ist falsch daran ein Array dynamisch, oder von mir aus manuell, außen zu erstellen?!
Das einzige, was mir auf Anhieb einfällt ist: Verschleierung.

Der Progger überfliegt den Code und sieht wie in eine funciton mehrere Parameter mitgegeben werden.
Ihm wird aber in dem Moment vorgegaukelt, dass in der funciton diese Parameter auch so zu erwarten sind.

Für mich schreit das nur wieder nach:
1. "ich bin cool, ich nutze variadic functions
und bei IF-Abfragen nutze ich keine Klammern,
aber dafür glaub ich das das Paket 16 Byte groß ist und prüfe nicht die tatsächliche Größe
und goto ist sowieso voll gut"

2. Bugs, weil jemand nicht aufgepasst hat, was in der function denn nun wirklich erwartet wird.

Die genaue Zeit bekommst Du noch einfacher:
$_SESSION['created'] = time();

Zitat von The Scout

Dadurch hat man eine Idee, wann die Session gestartet wurde, und aknn zB nach 2 Std Inaktivtaet rausschmeissen

Standard ist 1440 sec (24 min) session life time. Aber klar - kann man ja ändern.

Zitat von The Scout

Einziges Problem: Wo speichern, damit die Abfrage moeglichst schnell geht, da ja immer noch auf jeder Seite gefragt werden muss?

DB =) Dafür is die ja nun mal da. Und im normal Fall um die 0.005 Sec (bei persistant Verbindung, sonst evtl ne halbe Sec connection time bei jedem Seitenaufruf).

Ich weiß auf was Du hinaus willst. Mir fehlt bei der ganzen Server/PHP/Client-Sache auch irgendwie der "Laufende Betrieb".
Bei jedem Seitenrefresh ist ja nun mal der User ganz am Anfang des Scripts praktisch unbekannt/neu/...
Aber das wird sich nicht ändern. Man wird immer wieder aufs neue prüfen müssen, wer (und was) da reinkommt

siehe: http://www.heise.de/security/artik…it-2168010.html

Also das hätte ich nicht erwartet. Dass man so stupide glaubt was da so reinkommt.
Klar - ist kein Kleinkram was die da zusammen geschrieben haben. Aber wenn man am Proggn ist und an die Stelle kommt an der man etwas von Außen erwartet,
dann macht man doch mal nen Schritt langsamer und prüft ein bischen mehr -.-

Das ist mMn noch peinlicher als der "goto fail"-bug.

<span id="Versandkosten">

#versandkosten

V und v - ist nicht das Gleiche =)

Die isset() Afragen müssen bei der Zuweisung der $_POSTs hin. Die Eingabefelder sollten zwar immer da sein, aber ... =)
Also if(isset($_POST['user'])){$user = ...}
Und ab hier ist ja $user immer gesetzt. Wäre dann also nur noch das prüfen auf $user == "" $pass == ""

Das mit der id war nur ein Bsp. Kann ja sein, dass jemand noch `zuletzt_gesehen` usw speichern (und gleich mit auslesen) will.

Zwecks SESSION:
die wird nicht ausgeführt, solange Du nicht $_SESSION['login'](); aufrufst (mit den Klammern).
btw: der Fatal Error ist ein Bug: https://bugs.php.net/bug.php?id=64168 - wieder einen gefunden.

Bei einem if($_SESSION['login']) wird also nur der Zustand geprüft.
Allerdings - wenn nun jemand die SESSION bearbeiten könnte, dann bräuchte er in dem Script nur "login" auf true setzen und wäre eingeloggt.
Und beim wiederaufrufen der Page würde ja nun via SESSION geprüft werden, ob denn User eingeloggt ist ($_SESSION['login'] === true) -- aber es sind keine Daten gelesen/vorhanden.
Der eingeloggte User ist also ein Ghost
Es muss also min. eine id in die SESSION.

Ich behandle SESSION genauso wie Cookies. Heißt: da ist (u.a.) die id und pwhash des Users drin. Sind beide korrekt ($dbhash == $hash), ist user eingeloggt.
Wenn denn nun User die SESSION bearbeiten kann (mir unbekanntes Land), dann kann er nur das gleiche machen wie auf der Seite selbst: username und pw raten/bruteforcen/ect.
(Daher auch falsche SESSION und Cookie als falschen Loginversuch zählen)

Zeile 11: jo, hab ich vergessen sorry: am besten das gute alte

if($user == '' || $pass == '')

oder (was ich besser finde)

if(strlen($user) < *mindestWertUser*) {...} 
if(strlen($pass) < *mindestWertPass*) {...}

Ich glaub ich hab vorhin $pdo->commit() übersehen sorry.

Zeile 46: was ich meinte ist: wenn jemand sich zusätzlich noch die (SELECT ... ) `id` holt, dann würde die $data['id'] auch mit bei $pdo->execute($data) auftauchen.
Dadurch werden 2 Werte (pwhash, username) erwartet, aber 3 reingeschickt. Also wäre nur fürs Verständnis das hier einfacher:

$parameter = array(
 'pwhash' => $data['pwhash'],
 'username' => $data['username']
);
$query->execute($parameter);

Zitat

aber sobald man werte prüfen will, müssen diese auch sanitized werden. Oder habe ich da nen Denkfehler?

Die Werte kannst Du so, wie sie in der SESSION liegen, nutzen. Oder verstehe ich jetzt was mit sanitize falsch?

Ne function in einer SESSION?
Du meinst sowas?:

session_start();
if(!isset($_SESSION['a'])){
    $_SESSION['a'] = function(){
        echo '<br>in function';
    };
}
if($_SESSION['a']){ # die function wird hier nicht ausgeführt
}
echo '<br>call $_SESSION[\'a\']();';
$_SESSION['a']();

output:

Zitat

call $_SESSION['a']();
in function
Fatal error: Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not allowed' in [no active file]:0 Stack trace: #0 {main} thrown in [no active file] on line 0

Ich versteh grad nich, was Du mit der SESSION anstellen willst =)

Ich dachte schon Du willst jetzt hier ein kompletten Login posten
... das wäre bissl viel (also mit komplett meine ich forgot-pw-function, register, ect ect)

Zeile 11 - kein Fehler, aber wenn User 0 eingibt, dann bekommt er den Fehler "nix eingegeben", obwohl ja eine 0 kam.
Für empty() ist eine 0 leer - gibt also true zurück.

Zeile 25 - ich mag die "?"-Platzhalter nich (musste raus :p )

Zeile 28 - Im catch-block kommt nix an wenn User nicht existiert. Da kommt eher was an, wenn die Query einen Fehler hat (syntax ect).

btw - warum ist es schlimm, wenn in einer SESSION Daten sind?

Zeile 36 - wäre noch angebracht zu Prüfen, ob denn Daten vorhanden sind. Wenn die Query kein Ergebnis bringt - also kein User findet - dann bekommst Du dort eine "undefined $data ..." e-msg

beginTransaction() - warum? Bei nur einer Query überflüssig. Und es erfolgt auch kein commit(). Und wieso $pdo = null; ?

Zeile 46 - $query->execute($data); :: kann schief gehen sobald sich jemand die SELECT query umbaut. Dann ist in $data mehr als nur die gebrauchten Platzhalter-Keys und Du bekommst eine e-msg like "wrong number of bound parameter ..."

Zeile 56 - "Falsches Passwort!" würde ich nicht preisgeben. Es ist denke ich besser mitzuteilen, dass "Benutzername und/oder Passwort falsch" ist.
^was uns wieder zum SELECT in der Usertbl bringt: wenn die SELECT query kein Ergebnis bringt, dann ist es mMn angebracht schon dem User mitzuteilen, dass "Benutzername und/oder Passwort falsch" ist.

So ein Login ist sehr viel Arbeit und wenn man erstmal zu forgot-pw und co kommt, dann kann schon mal die Rübe qualmen.
=)

EDIT: mein "on login submit"-ablauf: http://pastebin.com/RpB22PZS
viel Quark wegen nem kack Login =)

;D wie geil
Warum bin ich nicht drauf gekommen :p

ok, also Cookies in die Tonne und falscher Login +1
Das schöne ist, dass ich nur die logout-function ausführen muss, das ja dort Cookies bzw Sessions gelöscht werden =)

Steh gerade vor der Frage:
wenn user mit gefaktem Cookie reinkommt - also jemand "was versucht": soll ich das als falschen Loginversuch behandeln, oder einfach nur fallen lassen.
Und sollte ich das falsche Cookie löschen?

Wenn ich es als falschen Loginversuch sehen würde, dann wäre user via IP für x Minuten geblockt, wenn der WrongLoginCounter >= y ist.
Demnach müsste ich ja (wenn ich jetz kein Denkfehler hab) das Cookie löschen, weil der user nach x Seitenaufrufen geblockt werden würde.

Hoffe man versteht was ich will

neeee. Ist ne Combi aus allem. Also Sonderzeichen ect. Für manche Sachen braucht man schon was sicheres.

Zwecks sicherem Login:
habe festgestellt, dass man keine $_SESSION verwenden darf, um die Loginfehlversuche mitzuschreiben.
Das bring nämlich garnix, sobald da ein Tool (zB console) angreift.

Also: Loginfehlversuche immer auf die Platte schreiben. zB in einer Tabelle (SQL).

eins meiner Passwörter ist 24 Zeichen lang =)

siehe png: html-seminar.de/woltlab/attachment/554/

die ips:
72.14.238.44
209.85.251.178
72.14.235.17
209.85.251.48
72.14.232.71
209.85.241.43
209.85.240.228
209.85.249.37
209.85.255.35
209.85.251.237

sind wohl alle

Zitat von http://www.utrace.de/?query=209.85.251.237

IP-Adresse: 209.85.251.237
Provider: Google
Region: Mountain View (US)

grad voll der nerv!
Unsere Seite und einige andere die ich nutze sind sporadisch lahm oder down.

wollte ich gerade ... hab nach nem Bruteforce tool gesucht. Chrome meinte aber "finger wech! schädlich!" =)
Sicher nur, weil es halt zu den "unerwünschten Tools" gehört, wie zB Keygeneratoren ect.
Aber das hat mir wieder nen Wink gegeben: nööööööööööööööööö, lass mal. Muss nich sein.

Kennt jemand "harmlose" Tools mit denen man sich/seine Logins prüfen kann?

Nur zur Ergänzung: Passwortlänge / Limit
http://stackoverflow.com/questions/1879…password-length

aber

Zitat von http://blog.nic0.me/post/63180966453/php-5-5-0s-password-hash-api-a-deeper-look-under

A lot of people probably think there should be no maximum password length, but this is actually wrong. Calculating the hash of a normal password is fast, but attackers may send a large, multiple megabyte file as password, and this will take bcrypt (or any other hashing algorithm for that matter), a lot of time to calculate. This method can be used to DDoS your server. Since password_hash() allows any given length, you should absolutely check for it yourself.

Also richtig sicher bin ich mir nu nich, ob da eine Grenze bei der Funktion password_hash() existiert. Aber Fakt ist wohl: um so länger das zu prüfende Passwort, desto mehr Aufwand/Ressourcen.
Also tut man sich schon selbst einen Gefallen, wenn man von vorn herein Passwörter länger als (Bsp!) 30 Zeichen durchfallen läst (also NICHT in die Prüfung password_verify() schickt).
Natürlich muss man das dem Nutzer auch mitteilen =)