Beiträge von cottton

Ich fang jetzt nicht wieder mit Prepared Statements an. Das solltest Du nun kennen.

Aber

SELECT * FROM login WHERE username = '$username'

Wenn im Moment, und|order in der Zukunft ein Fehler passiert,

bei dem der username nicht (mehr) unique ist,

dann kannst Du mehr als 1 user laden.

Der code lässt dann auch noch zu, dass Du solange läufst, bis Du den letzten möglichen user eingeloggt hast.

Pseudo code Vorschlag:

result = SELECT * FROM login WHERE username = :username LIMIT 1;
if result.count === 1
    row = result->fetchOne() // you expect one, so get one
    if password_verify(password, row.password)
        // all fine
elseif result.count > 1 
    // error handling for unexpected multiple users on same username
else
    // error handling for user not found by username

Zitat von basti1012

Vieleicht sollte man solche Antworten das ( ich falsch liege ) dann anders Formulieren weil falsch scheint meine ausage ja nicht gewesen zu sein.

Ja, ich geb zu, dass war wohl too much von mir, sorry.

Werde das in dem Post editieren|markieren|notieren.

timtim

Zitat von romae

Ich hätte mir gedacht dass ich Password_verify() im Anschluss an die SQL-Abfrage (hier Zeile-Nr. 20) schreiben müsste?

"WHERE username=? AND password=?"

^ das funktioniert nicht.

Du bekommst das plain text (klartext) Passwort.

Du hast (in Deiner db) den hash des Passwortes.

Du lädsts den User bei username oder email.

Findest Du ihn, dann nimmst Du den zugehörigen hash und nutzt password_verify() um den das Passwort mit dem Hash zu vergleichen.

Du bekommst:

username

password

Du suchst in der db nach dem username, der unique sein muss. Oder Du geht nach email, die ja auch unique sein muss.

Findest Du den User, dann prüfst Du das password gegeb den hash.

Pseudo code:

user = "select ... from user where username = :username"
if ! user
    // fehler - user nicht gefunden
else
    // check input vs db users hashed pw
    if password_verify(password, user.hash)
        // ok
    else
        // nicht ok

Siehe auch Loginpasswort richtig hashen - password_hash() & password_verify()

Zitat von timtim

Dein Beispiel ist mir schon bewusst, aber da sind wieder injections möglich, weil das Prepare das nicht abfängt, deswegen brauchst du ja eine WhiteList und da kommt das escapen bzw. anderweitige validieren ins spiel, was du ja machst. *_real_escape_string wäre zum prüfen ebenfalls möglicht.

Könnte man sich streiten. Ich vertraue da einer whitelist (viel) mehr.

Zitat von timtim

mein "da draußen" läuft über skalierbare Cloud Anwendungen,

Naja, das wird dann wohl doch ein bissl zu viel für das Forum, oder?

Zitat von timtim

Hier nur der bezug auf deine Aussage Sicherheit > "speed" Ja, aber nicht über PreparedStatements weil der Sicherheitsaspekt zu den Prepared Statements kleiner ist als der Overhead.

Für Anfänger, die hier im Forum lernen? Ach komm.

Das bischen overhead ... wenn überhaupt.

Ich hab das nicht getestet, aber die real escape Funktion nutzt das db handle,

also wird die auch beim MySQL Server anfragen. Und das per call (value).

Zitat von timtim

Prepared Statements schützen nur vor first-order injections nicht second-order

Bin mir fast ganz sicher, das die Aussage falsch ist.

Wenn ich second order injection richtig verstanden habe, dann kann*1 beim Verwenden der Daten aus der db

in einer Query die (2nd order) injection möglich werden.

*1 Aber dann eben nicht. Denn da nutzten wir doch auch wieder Prepared Statements.

Wer sowas schreibt ... WHERE foo = {$row['foo']} ... gehört ... belehrt

Und genau das is es btw, was ich immer sage: alle Daten sind böse. Selbst die in der eigenen db.

Und daher gilt doch, was ich am Anfang sagte: die Daten gehen so wie sie sind in die db.

Zitat von timtim

Lange muss nicht richtig heißen. Pauschal aussagen bekommen pauschal antworten.

Hehe, you got me there. Naja, Wochen, Momante. Weiß nicht mehr.

Aber ich bin keiner, der code kopiert. Ich will (so weit möglich) wissen wie und warum etwas funktioniert.

Gehört auch bissl Glück dazu. Einfach weiter machen!

Achtung - Lebensgeschichte

Ich komme vom Bau. Hatte dort keine Zukunft. Langzeitarbeitsloser ... .

Wollte was anderes machen.

Hab PHP als Hobby gelernt (kein OOP).

Hab mich beworben. Keine Antwort.

Auf Nachfrage: OOP muss schon sein.

OOP gelernt.

Immernoch kein Glück.

Jeden "Mist" mitgemacht:

- Fernstudium bei ILS (ich halte mich mit meiner Meinung dazu mal zurück)

- Selbststudium

- ...

- bis hin zum Bewerbungstraining, wo die mich gefragt haben, was ich eigtl. hier will

aber die waren echt nett =)

Aber jetzt kommts: beim Bewerbungstraining sollten wir uns um ein Praktikum bemühen.

Und ich hab Nummern angrufen, bei denen ich dachte "da kommt eh nichts".

Und BAM - Rückruf von meinem (seit 2016) neuen Boss =)

Und ab dann, wenn Du drin bist, lernst Du erst richtig.

Also einfach alles mitnehmen. Auch wenn es total sinnlos scheint.

Man weiß nie ...

Zitat von timtim

wie ich z.B. vom User sowohl die abzufragenden Felder + dynamische wehre Bedingungen in ein Prepaid Statement setze

Perfekt: hab das gerade geposted.

Prepared Statements (PDO) copy|paste Beispiele.

Zitat von timtim

der overhead von PreparedStatements zu Verschwendung von Ressourcen führt

Glaub mit - da draußen ist das das geringste Problem.

Sicherheit > "speed".

Zitat von timtim

wirkt auf mich auch eher als wolle man sich nicht mit der sache beschäftigen.

Ich hab mich lange damit beschäftigt.

Das Problem ist, dass man das nicht so einfach runterschreiben kann.

Es würde einfach so lang werden, dass es keiner liest.

Aber es gibt vieles im Netz dazu. Was ich hier versucht ist, den Leuten klar zu machen, dass es "da was gibt" - Problem und Lösung.

Generell: auf SQL-Injections hinweisen. Alle Daten sind böse.

Im Detai: in Richtung Prepared Statements lenken, damit die Leute sich damit beschäftigen.

Zitat von timtim

Und ebenfalls verschleiert es für Anfänger die eigentliche Problematik: die Wichtigkeit der Validierung der eingaben

Du prüftst, ob die email zu lang ist.

Du prüfst, ob der nickname legal, nicht leer, und nicht schon vergeben ist.

...

Aber Du kannst nicht alle Injections der Welt kennen.

Das, also das Thema Sicherheit, überlassen wir dem MySQL Server (bei richtiger Bediehnung).

Warum Prepared Statements und was ist das: Sichere Programmierung mit PHP

Beispiele, die (hoffentlich) für sich selbst sprechen,

und eigtl. auf jedem System laufen sollten:

Kommentare nur in englisch.

/**
 * We are using a simple user table.
 * (This table is not mean to make sense.)
 *
 * CREATE TABLE `user` (
 *     `id` int(6) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY,
 *     `firstname` varchar(30) NOT NULL,
 *     `lastname` varchar(30) NOT NULL,
 *     `email` varchar(50) NOT NULL
 * );
 * INSERT INTO `user` (`firstname`, `lastname`, `email`)
 * VALUES ('hans', 'foo', 'hans@host.de'),
 *        ('joe', 'bar', 'joe@host.de'),
 *        ('peter', 'baz', 'peter@host.de');
 *
 * SELECT * FROM `user`;
 * +----+-----------+----------+---------------+
 * | id | firstname | lastname | email         |
 * +----+-----------+----------+---------------+
 * |  1 | hans      | foo      | hans@host.de  |
 * |  2 | joe       | bar      | joe@host.de   |
 * |  3 | peter     | baz      | peter@host.de |
 * +----+-----------+----------+---------------+
 */

/**
 * Simulate some user input via POST.
 */
$_POST['offset'] = 1;
$_POST['limit'] = 100;
$_POST['email'] = 'somebody@host.de';
$_POST['table'] = 'user';
$_POST['columns_to_select'] = ['firstname', 'lastname', 'email'];


/**
 * Info: "what means $dbh, $sth or $stmt?"
 *
 * $dbh = "Database Handle"
 * $stmt = "Statement"
 *
 *
 * Note:
 * Using exception error mode.
 *
 * @link See https://www.php.net/manual/de/pdo.error-handling.php.
 */

/**
 * Connect.
 *
 * @link https://www.php.net/manual/de/pdo.connections.php
 */
$host = '';
$port = 3306;
$database = '';
$user = '';
$password = '';
$options = [
    /**
     * Request a persistent connection, rather than creating a new connection.
     *
     * @link http://php.net/manual/en/pdo.constants.php
     */
    \PDO::ATTR_PERSISTENT         => true,
    /**
     * Command to execute when connecting to the MySQL server.
     *
     * @link http://php.net/manual/en/ref.pdo-mysql.php
     *
     * Info: with sql_mode STRICT_ALL_TABLES you f.e. cannot accidentally insert 'abcd' into VARCHAR(3) column.
     *       MySQL would return an error like "Data too long ...".
     *       Without this mode you would inset i.e. 'abc', which is imo wrong.
     */
    \PDO::MYSQL_ATTR_INIT_COMMAND => "SET CHARSET 'utf8', NAMES 'utf8', sql_mode = 'STRICT_ALL_TABLES';",
];
try {
    $dbh = new \PDO(
        "mysql:host={$host}:{$port};dbname={$database}",
        $user,
        $password,
        $options
    );
    /**
     * Set exception error mode. @link https://www.php.net/manual/de/pdo.error-handling.php.
     *
     * @link http://php.net/manual/en/pdo.constants.php
     */
    $dbh->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
} catch (\PDOException $e) {
    // Error handling. In example echo and exit.
    echo "Cannot connect to database. Error: {$e->getMessage()}\r\n";
    exit(1);
}

/**
 * Query with placeholder.
 *
 * @link https://www.php.net/manual/de/pdo.prepared-statements.php
 */
$stmt = $dbh->prepare("SELECT * FROM `user` WHERE `email` = :email;");
$params = [
    // Note: you can use ':email' or 'email' as key. This does not matter.
    'email' => $_POST['email'],
];
$stmt->execute($params);
$stmt->setFetchMode(\PDO::FETCH_ASSOC);
if ($stmt->rowCount()) {
    // Found one or more rows.
    while ($row = $stmt->fetch()) {
        // Do something with the row. In example echo.
        echo var_export($row, true) . PHP_EOL;
    }
} else {
    // No row found.
    // ...
}

/**
 * Example: offset, limit
 *
 * LIMIT and OFFSET values MUST be placed as integer into the query (-template).
 * Therefor we need to use bindValue() to "tell" the MySQL server to use those values as int.
 */
$stmt = $dbh->prepare("SELECT * FROM `user` LIMIT :offset, :limit;");
$stmt->bindValue('limit', $_POST['limit'], PDO::PARAM_INT);
$stmt->bindValue('offset', $_POST['offset'], PDO::PARAM_INT);
$stmt->execute();
$stmt->setFetchMode(\PDO::FETCH_ASSOC);
if ($stmt->rowCount()) {
    // Found one or more rows.
    while ($row = $stmt->fetch()) {
        // Do something with the row. In example echo.
        echo var_export($row, true) . PHP_EOL;
    }
} else {
    // No row found.
    // ...
}

/**
 * Example: table and column names
 *
 * Table and column names CAN NOT be placed via placeholders.
 * If you MUST create a query dynamically then its the most secure way is to use
 * a whitelist.
 * Do NOT use a blacklist or any "filter bogus".
 * Just accept what you know, and deny anything else.
 *
 * Note: key is table|column name, values indicates if this active.
 *       From my tests isset() is faster than in_array(),
 *       you cannot add the same key more than once,
 *       and you can disable offsets (f.e. by other conditions).
 *
 * IMPORTANT: those whitelists MUST NOT be created dynamically.
 *            In best case they should be defined as constant in your config.
 */
const TABLE_WHITELIST
= [
    'user' => true,
];
const COLUMN_TO_SELECT_WHITELIST
= [
    'id'        => false,
    'firstname' => true,
    'lastname'  => true,
    'email'     => true,
];

// Validate table name.
if (!isset(TABLE_WHITELIST[$_POST['table']])) {
    // Error handling. In example echo and exit.
    echo "Invalid table '" . htmlspecialchars($_POST['table']) . "' given.\r\n";
    exit(1);
}
$tableName = $_POST['table'];

// Validate column names.
foreach ($_POST['columns_to_select'] as $columnName) {
    if (!isset(COLUMN_TO_SELECT_WHITELIST[$columnName])) {
        // Error handling. In example echo and exit.
        echo "Invalid column to select '" . htmlspecialchars($_POST['column'])
            . "' given.\r\n";
        exit(1);
    }
}
$columnsString = '`' . implode('`, `', $_POST['columns_to_select']) . '`';

// Using pre-validated vars for table name and column names in query.
$stmt
    = $dbh->prepare("SELECT {$columnsString} FROM `{$tableName}` WHERE `email` = :email;");
$params = [
    'email' => $_POST['email'],
];
$stmt->execute($params);
$stmt->setFetchMode(\PDO::FETCH_ASSOC);
if ($stmt->rowCount()) {
    // Found one or more rows.
    while ($row = $stmt->fetch()) {
        // Do something with the row. In example echo.
        echo var_export($row, true) . PHP_EOL;
    }
} else {
    // No row found.
    // ...
}

Naja, ist doch richtig, was er da sagt.

Zitat von https://stackoverflow.com/a/51777516/3411766

basically mysqli_real_escape_string will take out the junk in the user input according to a defined character set while prepared statements will make sure if there be any junk in the user input it will be only interpreted as you want it to be interpreted which is usually as user junk

Grob gesagt: mysqli_real_escape_string den "Müll" zu entfernen (maskieren).

Prepared statements ist der "Müll" egal, da eh nichts passieren kann, da (by default) als string in das Template eingefügt.

Ich sehe da jetzt kein Gegenargument oder irgandwas, da meine Aussage jetzt als falsch dastehen lässt.

Zitat von Arne Drews

Richtig, man braucht es nicht zwingend, i.d.R. könnte das sogar kontraproduktiv sein.

Das gilt allerdings nur solange, wie Du als Entwickler den Aufbau Deiner Queries 100% unter Kontrolle hast. Arbeitest Du mit dynamisch generierten Queries, kann es durchaus sinnvoll und besser sein, eine escape_string Funktion einzusetzen.

Auf jeden Fall empfehlenswert, ja.

Es wird häufig behauptet, beide Funktionen machen das selbe, das ist aber nur die halbe Wahrheit.

In der Kurzfassung kann man sagen: Eine escape_string Funktion versucht den kompletten String zu maskieren ( in den meisten Fällen also die komplette Query ), während sich die Prepared Statements "nur" um die Werte kümmern.

Daher ist es einfach falsch zu sagen: nutz es am besten nie wieder!

Wie man sieht und Du ja ehrlicher Weise zugegeben hast, verwirrt das die Leute, die dann denken, diese escape_string Funktionen seien veraltet o.ä.

Alles anzeigen

Sorry, aber das ist viel Quatsch.

Zu viel, um es hier richtig zu stellen.

Alleine Das hier:

Zitat von Arne Drews

Eine escape_string Funktion versucht den kompletten String zu maskieren ( in den meisten Fällen also die komplette Query ),

Ist schwammig und einfach falsch.

Siehe einfach meinen Post vorher.

Oder such im Netz. Stack ist schon eine ganz gute Quelle, da dort sehr viele sofort reagieren würden, wenn jemand Mist erzählt.

"mysql prepared statements vs mysqli_real_escape_string"

Zitat

Should I use mysqli_real_escape_string or should I use prepared statements?

Zitat von https://stackoverflow.com/a/15786451/3411766

Prepared statements only. Because nowhere escaping is the same thing. In fact, escaping has absolutely nothing to do with whatever injections, and shouldn't be used for protection.

While prepared statements offer the 100% security when applicable.

Also zu Deiner Frage: das erste ist richtig

Zitat von basti1012

Wenn man PreparedStatements verwendet brauch man kein mysqli_real_escape_string

Zitat von m.scatello

Was hätte man an der Aussage falsch verstehen können?

Zitat von cottton

Du hast es evtl nicht verstanden.

Es sollte so aussehen:

insert into tabelle set abc = :placeholder;

Du hast ja nichtmal das verstanden. Was is los mit Dir?

Zitat von m.scatello

Nein, auf keinen Fall! Du wirst spätestens dann ein Problem bekommen, wenn ein User sowas eingibt:

Code

Mike's eMail

Durch das einfache Hochkomma zerdrischt du das insert, weil du dann ungefähr sowas in String stehen hast

Code

insert into tabelle set abc='Mike's eMail'

Das scheppert dann. Und SQL-Injektions sind sonst auch möglich.

Du hast es evtl nicht verstanden.

Es sollte so aussehen:

insert into tabelle set abc = :placeholder;

Zitat von https://www.php.net/manual/de/pdo.prepared-statements.php

Die Parameter für Prepared Statements müssen nicht maskiert werden. Der Treiber übernimmt das automatisch. Wenn eine Anwendung ausschließlich Prepared Statements benutzt, kann sich der Entwickler sicher sein, dass keine SQL-Injection auftreten wird. (Wenn aber trotzdem andere Teile der Abfrage aus nicht zuverlässigen Eingaben generiert werden, ist dies immer noch möglich.)

Versuch doch mal eine SQL-Injection mit Platzhaltern.

---

Wenn jetzt hier mysql values escapen und vars in die Query schreiben (fast schon) empfohlen wird,

dann werd ich mich wohl verabschieden.

Seit Jahren versuch ich den "neuen" mitzugeben, damit es irgendwann mal allgemein bekannt sein wird.

Jetzt gehts auf einmal vollgas rückwärts - als wäre ich heute aufgestanden, und es ist 5 Jahre zurück

Zitat von basti1012

Wofür sind den die Punkte und " in deine query String ? Bist du sicher das es so sein muß ?

Das ist normale PHP string-Verkettung.

Zitat von basti1012

$_POST wird nicht ungefiltert in der Datenbank geschrieben.

Zitat von basti1012

escapen nicht vergessen.

NEIN., Falsch. (EDIT: ich hab hier übertrieben reagiert. Sorry.)

romaeVergiss mysqli_real_escape_string. Die Funtion solltest Du nie wieder nutzen. (EDIT: ich hab hier übertrieben reagiert. Sorry.)

Die Daten werden so wie sie sind in die db geschrieben.

Außer Passwörter. (Loginpasswort richtig hashen - password_hash() & password_verify())

Du musst aber alle Daten als nicht vertrauenswürdig ansehen.

Bei der Ausgabe im (zB) Browser nutzt Du htmlspecialchars() order htmlentities().

Welche Daten sind nicht verstrauenswürdig?

Alle!

Inputeingaben via POST order GET,

Dateien (csv, txt, json, ... ALLE),

Eingaben aus der console,

Daten bezogen von einer API,

...,

und selbst die Daten, die Du in Deiner db stehen hast.

Zur db: Wer sagt, dass die sicher sind? Hat da nie nie niemals jemand was geändert? 100% sicher? NEIN.

Also: alle Daten sind böse.

Und deswegen macht es erst gar keinen Sinn da was beim Speichern in der db zu "escapen" ect.

ABER: nutze Prepared Statements (PDO oder mysqli. Ich empfehle PDO).

https://www.php.net/manual/de/pdo.prepared-statements.php

https://www.php.net/manual/de/…t.prepared-statements.php

Zitat von m.scatello

Ich halte so Namen wie $na, $us, etc. für grausam.

Yap. Sowas geht gar nicht.

MySQL: https://dev.mysql.com/doc/refm…/en/pattern-matching.html

"Wildcard" nennt sich das.

Für ein Zeichen gibt es den Unterstrich "_".

Im Bsp:

Bananen

Bananes

Bananensaft

Suche: "Banane_"

SELECT * FROM `table_name` WHERE `column_name` LIKE 'Banane_';

Zitat von Arne Drews

ist das Lehrgeld,

Uff. Also da will ich nicht der sein, der die Query abgefeuert hat

Mir ist klar, was Du meinst. Und Du weißt, was ich meine.

Arne Drews

Du hast schon recht. Das db Design und|oder die Query sollte das schon klären.

Aber es kann vorkommen, das mal was geändert wird, und es bei Design nicht mehr geregelt wird.

ZB "ausversehen" den unique index ge-dropped, statt eines anderen.

Man kann also mit solchen einfachen Beschränkungen Fehler vorbeugen.

Auf dem live server schreib ich zB auch keine DELETE oder UPDATE query ohne LIMIT, wenn ich nur eine Zeile ändern will.

Einmal nicht aufgepasst, irgendwas in der Bedingung vergessen, und 100000 rows sind weg.

Warum nicht nutzen, was da ist?

Zitat von Arne Drews

Es ist nie gut, mögliche Fehler zu kaschieren!

Aber das ist eine DELETE query. Du willst doch nicht erst, wenn alles gelöscht ist, feststellen, dass da ein Fehler ist

Zitat von Arne Drews

wodurch die Ergebnisliste fehlerhaft sortiert sein kann und man ein falsches Ergebnis verarbeitet

Kommt evtl auf den Fall an.

Bsp user tbl.

Wenn Du nur einen user laden willst, der per query definition nur einmal vorkommen kann,

dann macht ORDER BY id ASC LIMIT 1 Sinn,

denn es kann kein nächster user selectiert werden. Es wird immer der "originale", erste user selectiert.

Zitat von RealHero014

$db->query("DELETE FROM Zuege WHERE Zugnummer = '$Nummer'");

Die Zugnummer wird sicherlich unique sein. Ich empfehle LIMIT 1 an die Query anzuhängen.

Und, wie schon erwähnt wurde, SQL-Injection fixen!

DELETE FROM `Zuege` WHERE `Zugnummer` = :train_id LIMIT 1;

Warum LIMIT 1:

Die Query funktioniert, alles i.O.

Aber mit der Zeit wird sie erweitert, wird immer komplizierter, und evtl passiert ein Fehler - die Bedingungen betreffen auf einmal mehrere oder alle Zeilen in der db.

Zitat von Karstin

$db = mysqli_connect("example.com", "example", "1234", "example");

"example.com"

Ich hoffe, die db ist nicht unnötig übers Internet erreichbar.

Dort steht dann hoffentlich "127.0.0.1" oder "localhost"

Und wie Stef schon sagte: Verzeichnisschutz ist einer SQL-Injection egal.

Entweder prepared statements via mysqli, oder PDO (ich empfehle PDO).

https://www.php.net/manual/de/pdo.prepared-statements.php

https://www.php.net/manual/de/…t.prepared-statements.php

Und vergiss strip_tags. Das bring keine Sicherheit. Prepared statements aber schon.

Zitat von https://www.php.net/manual/de/pdo.prepared-statements.php

Wenn eine Anwendung ausschließlich Prepared Statements benutzt, kann sich der Entwickler sicher sein, dass keine SQL-Injection auftreten wird.