zaštititi MySQL od injection

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

I ja naučih nešto novo. Ovo do sada nisam koristio i želim da unapredim ovu skriptu ali za sada ne shvatam kako.

Kod izgleda ovako:
$name = $_GET['username']; $password = $_GET['password'];   if ($stmt = $mysqli->prepare("UPDATE tbl_users SET password = ? WHERE name = ?")) {       // Bind the variables to the parameter as strings.     $stmt->bind_param("ss", $password, $name);       // Execute the statement.     $stmt->execute();       // Close the prepared statement.     $stmt->close();   }
a ja za sada radim ovako:
function edit($table, $array_cell_and_value, $array_where)    {       if($array_cell_and_value && $array_where)       {          foreach($array_cell_and_value as $y=>$x){$value[] = "`".trim($y)."` = '".$this->mysql->real_escape_string(trim($x))."'";}          foreach($array_where as $s=>$d){$where[] = "`".trim($s)."` = '".$this->mysql->real_escape_string(trim($d))."'";}          $edit=$this->mysql->query("UPDATE `".$table."` SET ".join(', ',$value)." WHERE ".join(' AND ',$where)." LIMIT 1");          return $edit ? true : false;       } else return die('PHP Error: <strong>$array_cell_and_value</strong> and <strong>$array_where</strong> is empty!<br />-Data not edited in MySQL!');    } $array=array( 'password' => $_GET['password'] ); $where=array( 'name' => $_GET['username'] ); edit('tbl_users', $array, $where);
Zanima me kao prepared statement da ubacim u moju funkciju. Stao mi malo mozak zbog $stmt->bind_param("ss", $password, $name); jer on miksuje stringove a ne prima array.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Mislim da prepared statements već imaju svoju vlastitu zaštitu od SQL injections... nije im potrebno escape-ovanje.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Ex taj DEPENDENCY INJECTION

Sad ti vidi sta ces dalje, dao sam ti 99% resenje a ti vidi kako ces da iskoristis zavisnost ubrizgavanja.
Jako dobar pattern DI.

A mozes da iskoristis malo stariji princip (pattern) poznat kao Hollywood principle.
Njegova teorija je : don't call us, we'll call you

• 1Ovo se svidja korisniku: Peca
  
  Registruj se da bi pohvalio/la poruku!

http://php.net/manual/en/pdo.prepared-statements.php
ovde kazuCitat:
The parameters to prepared statements don't need to be quoted; the driver automatically handles this. If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur (however, if other portions of the query are being built up with unescaped input, SQL injection is still possible).

• 1Ovo se svidja korisniku: E.L.I.T.E.
  
  Registruj se da bi pohvalio/la poruku!

To i pričam.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Da shvatam... Nikada nisam radio sa prepared statements pa me zanimalo koliko ima smsla da ga koristim i koliko je dobar. Ovu stranicu koju si |_MeD_| poslao nisam video. Onda mi je jasno šta da radim. Hvala svima!

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Potpuno je bezbedan. Stim što imaj u vidu da ne možeš "LIMIT" deo upita parametrizovati koliko se ja sećam, tako da pazi kada praviš paginaciju ili tako nešto sprečiš injection na tom delu

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

igorpan ::Potpuno je bezbedan. Stim što imaj u vidu da ne možeš "LIMIT" deo upita parametrizovati koliko se ja sećam, tako da pazi kada praviš paginaciju ili tako nešto sprečiš injection na tom delu

Da taj deo je najbolniji. Ja inače čistim GET i POST funkcije, (negde sam to u forumu naveo) dodao sam i neke regular expression za database injection ako se prepozna neki upit da izbaci null tako da mislim da će to da zaštiti. Jedna klasa mi sve proverava pa sam tako uspeo kroz razne eksperimente da uradim "bezbednim". Hvala mnogo.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Ako sam dobro razumeo ako koristimo prepared statements nisu nam potrebne sledece "mere zastite" od sql injectiona:
- real_escape_string
- Htmlentities
- addslashes
- trim

?

• 2Ovo se svidja korisnicima: m4rk0, E.L.I.T.E.
  
  Registruj se da bi pohvalio/la poruku!

ako koristiš prepared statements - nije ti potreban mysql_real_escape_string i addslashes.

htmlentetities ti je potreban za zaštitu od ubacivanje malicioznog javasvcripta ili HTML-a - prepared statements te NE štite od toga.

trim nema nikakve veze sa merom zaštite - ta funkcija samo briše blanko/tab/enter na početku i na kraju stringa.