PHP & INSERT INTO mySQL ne radi :(

[LiquidBrain]

Pozdrav ljudi, eto da i ja imam jedan problem pa mi treba mala pomoc :(
Problem je u sledecem:

$query = "INSERT INTO Client (fname, lname, email, address, tel, country, zip)
VALUES ($custom_First_Name, $custom_Last_Name, $from, $custom_Address,
$custom_Phone_Number, $custom_Country, intval($custom_Post_Code)";

$result = mysql_query($query) or die(mysql_error());

jednostavno nece da upishe podatke u tabelu :(

nije problem oko dozvola jer user koji se konektuje na bazu ima sve privilegije. A i sem toga cudno mi je jer SELECT query radi bez problema.
A shto je najveci problem ne vraca nikakav error. Zbunjen sam skrozz:1050: :1092:

Da li znate shta bi mogao da bude problem, poshto mi je to veoma neophodno, a nece da radi.

Unapred hvala.

[BluesRocker]

Može biti da imaš više polja u tabeli nego što si uključio u query.

[dinke]

Pa nije ni cudo da ti ne radi kad nisi stavio nijdno string polje unutar navodnika. Dakle, treba:


$query = "INSERT INTO Client (fname, lname, email, address, tel, country, zip)
VALUES ('$custom_First_Name', '$custom_Last_Name', '$from', '$custom_Address',
'$custom_Phone_Number', '$custom_Country', '$custom_Post_Code' ";

[LiquidBrain]

Da, hvala. to je u sushtini bio problem.

[jablan]

Samo pripazi šta će da se desi ako u samim vrednostima promenljivih imaš apostrof... ;)

[LiquidBrain]

Da znam, provereno vec ;) ako bude imalo onda je SQL injection ;)

[cvele]

Da znam, provereno vec ;) ako bude imalo onda je SQL injection ;)

function escape_sql($text) {
// return $text;
$text = str_replace("\\", "\\\\", $text);
return str_replace("'", "''", $text);
}

function escape_sql($string) {
return get_magic_quotes_gpc() ? $string : addslashes($string);
}

i jos hiiiiiiljade varijanti :)

[LiquidBrain]

To plus regularni izrazi da se uverim da neko nije pokushao neshto... Ako jeste odma logujem IP :)

[Ilija Studen]

Samo par tipova, možda nekom bude koristilo:


Stripovanje slasheva treba odraditi odmah, negde u headeru. Samo stripovanje pri interakciji sa bazom može doveste da se (nepravilni) stringovi sa slashevima sačuvaju u neki drugi "izvor" (fajl, pošalju nekom web servisu or whatever). Strip odmah pa ni ne razmišljaš o tome.
Umesto da koristiš sopstvene funkcije za escapeovanje bolje je da koristiš stvari koje ti PHP i MySQL daju, pre svega mysql_real_escape_string (http://www.php.net/function.mysql_real_escape_string).
Imati neku prepare funkciju nije nimalo loša stvar. Spašava glavu jer ne moraš da razmišljaš o escapevoanju, samo korstiš gotovu funkciju. Ono što ja koristim je ušnirano na par nivoa pa je jako teško izvući konkretan kod, ali bi izgledalo nešto ovakvo:


<?php

function prepare_string() {
$arguments = func_get_args();
if(is_array($arguments) && count($arguments) > 0) {
$sql = array_shift($arguments);
foreach($arguments as $argument) {
$sql = str_replace_first('?', "'" . mysql_real_escape_string($argument) . "'", $sql);
} // foreach
return $sql;
} // if
return false;
} // prepare_string

function str_replace_first($search_for, $replace_with, $in) {
$pos = strpos($in, $search_for);
if($pos === false) {
return $in;
} else {
return substr($in, 0, $pos) . $replace_with . substr($in, $pos + strlen($search_for), strlen($in));
} // if
} // str_replace_first

print prepare_string("SELECT * FROM users WHERE id = ?", 12) . '<br />';
print prepare_string("SELECT * FROM users WHERE id = ? AND name = ?", 12, 'Ilija') . '<br />';
print prepare_string("SELECT * FROM users WHERE id = ? AND name = ?", 12, 'Now with \ slash') . '<br />';

?>

Output:

SELECT * FROM users WHERE id = '12'
SELECT * FROM users WHERE id = '12' AND name = 'Ilija'
SELECT * FROM users WHERE id = '12' AND name = 'Now with \\ slash'

Možemo se ovde još igrati (npr, meni spremi i nizova za IN, prepoznaje neke moje tipove kao DateTime objekte itd), ali poenta je jednostavna i ovo je dovoljno za većinu stvari.

To plus regularni izrazi da se uverim da neko nije pokushao neshto... Ako jeste odma logujem IP :)

Mudro! Sad mi reci šta konkretno imaš od toga? ;)

[LiquidBrain]

Mudro! Sad mi reci šta konkretno imaš od toga? ;)


Pa ukoliko dodje do kompromisovanja baze, eventualno cu da imam IP (sem ukoliko ne ide preko proksija) A btw, logujem ceo query, tako da ukoliko imam propust, mogu da ispravim odmah, jer znam gde je :)

[Ilija Studen]

Pa ukoliko dodje do kompromisovanja baze, eventualno cu da imam IP (sem ukoliko ne ide preko proksija) A btw, logujem ceo query, tako da ukoliko imam propust, mogu da ispravim odmah, jer znam gde je :)

To je pointless IMO. Šta misliš i ideji da napraviš tako priču da jednostavno koje god parametre da proslediš ti dobiješ ispravan SQL na kraju, pravilno escapeovan? Tako nešto radi kod gore - greška neće biti uzrokovana vrednostima parametara, već samo ako pogrešno formiraš upit (a to nije security risk).

PHP je na lošem glasu baš zato što su rešenja koja "loguju IP adrese kada nešto pođe loše" i rade slične mađijanja koja nemaju previše smisla rasprostranjenija od rešenja koja ne dozvoljavaju da injectiona dođe.

My $0.02

[ivanhoe]

To je pointless IMO. Šta misliš i ideji da napraviš tako priču da jednostavno koje god parametre da proslediš ti dobiješ ispravan SQL na kraju, pravilno escapeovan? Tako nešto radi kod gore - greška neće biti uzrokovana vrednostima parametara, već samo ako pogrešno formiraš upit (a to nije security risk).

PHP je na lošem glasu baš zato što su rešenja koja "loguju IP adrese kada nešto pođe loše" i rade slične mađijanja koja nemaju previše smisla rasprostranjenija od rešenja koja ne dozvoljavaju da injectiona dođe.

My $0.02


Ne slazem se. Po meni je vrlo smisleno da ako upit nije dobar lepo napises kulturnu poruku o gresci i logujes dogadjaj u neki fajl, a ukoliko je ocigledno da se radi o napadu, onda ne samo da logujes IP, nego i blokiras doticnog smaraca na 10-15 minuta, ili ga posaljes na laznu stranu gde moze da se igra pokusavajuci da nesto uhakuje (takozvani "tar hole")

Ukoliko se radi o napadacu koji pokusava da te uhakuje, sta ima njemu da popravljas sql, koji je smisao toga, samo se povecava sansa da pronadje neku rupu (jer mu dajes feedback, za razliku od genericke poruke o gresci)

A ukoliko imas bug u aplikaciji onda je bolje da upit pukne, pa da tokom testiranja mozes lepo da vidis da nesto ne valja, nego da skripta trosi procesorsko vreme da popravi pogresan upit, potencijalno sireci bug kroz aplikaciju i otezavajuci debug.

Ok naravno, postoje neki primeri gde ne treba biti extreman, tipa unos broja telefona ili broja kreditne kartice, logicno da treba pokusati da popravis pogresno formatirane podatke, a ne da smaras korisnika..

[LiquidBrain]

Naravno da prvo impementiram reshenje koje proverava ispravnost parametara prosledjenih u query. A ako taj query nije ispravan i ima znake pokushaja napada, onda mi je logicno da u fajl strpam podatke koje ce mi pomoci da vidim shta je doticni pokushao, i da li mu je uspelo. Svi znamo da ne postoji bug free kod. A to je pogotovu slucaj sa AJAX-om, koji je implementiran u projekat iz price. Poshto su zahtevi na skripte "maskirani" i obican korisnih ih ne vidi, a javascript radi proveru podataka, ako dodje do nekog "cudnog" querija bolje mi je da logujem celu pricu jer je jasno da to nije neki obican korisnik uradio, vec neko ko je analizirao javascript.

Naravno ista provera parametara se vrshi i u php skriptama... Shto je sigurno sigurno je ;)

[Ilija Studen]

Pogrešno sam se odrazio. Ne popravljanje nego pravilno escapeovanje. Ako su podaci pravilno escapeovani, a programer je napisao pravilan upit jedina situacija kada će tako nešto da pukne je ako server baze počne da brlja, a to se ne dešava tako često.

Znači ne popravljanje nego prosleđivanje uvek pravilno formatiranog upita sa escapeovanim parametrima.

Da li će neko da se igra sa parametrima ili ne apsolutno te ne zanima pošto šta god da uradi to će biti sačuvano u bazi kao string (tu uvek važi pravilo i escapeovanja outputa).

[bojan_bozovic]

Ne slazem se. Po meni je vrlo smisleno da ako upit nije dobar lepo napises kulturnu poruku o gresci i logujes dogadjaj u neki fajl, a ukoliko je ocigledno da se radi o napadu, onda ne samo da logujes IP, nego i blokiras doticnog smaraca na 10-15 minuta, ili ga posaljes na laznu stranu gde moze da se igra pokusavajuci da nesto uhakuje (takozvani "tar hole")

Ukoliko se radi o napadacu koji pokusava da te uhakuje, sta ima njemu da popravljas sql, koji je smisao toga, samo se povecava sansa da pronadje neku rupu (jer mu dajes feedback, za razliku od genericke poruke o gresci)

A ukoliko imas bug u aplikaciji onda je bolje da upit pukne, pa da tokom testiranja mozes lepo da vidis da nesto ne valja, nego da skripta trosi procesorsko vreme da popravi pogresan upit, potencijalno sireci bug kroz aplikaciju i otezavajuci debug.

Ok naravno, postoje neki primeri gde ne treba biti extreman, tipa unos broja telefona ili broja kreditne kartice, logicno da treba pokusati da popravis pogresno formatirane podatke, a ne da smaras korisnika..

To je bespotrebno komplikovanje.

1.Proveris da li je URI enkodiran ispravno
2. Uvek proveris tip i opseg svakog podatka koji korisnik moze poslati (je li alfanumericki npr. ili broj, dobar i enkodiran URI itd. Tu spada svaki GET i POST parametar, kao podaci cookija)
3. Dodeli inicijalnu vrednost svakoj promenjljivoj koju ces koristiti.

Zato je lose i meni se ne svidja sto PHP nije strongly-typed,mnogo stosta bi interpreter automatski proveravao, ne bih to morao sam raditi. Provera je jednostavna, samo greska i izostavljanje iste moze da bude problem.

EDIT: evo primera:
http://maestitia.net/index.php?u=116

SQL :: 4 queries were made.

http://maestitia.net/index.php?u=116z

SQL :: No queries were made.

[Ivan]

O ovome moze da se prica ceo dan ali da sumiram:

Nije dovoljno zastiti se samo od SQL injectiona jer postoji jos puno vrsta napada koji na kraju cak mogu da naprave SQL propuste koji se mogu iskoristiti.

Printanje detaljnih poruka o greskama je dobra praksa pri developingu a logovanje pri samom radu aplikacije.

E sad, ako ce da pricamo o vrstama zastita i mestima gde se greske prave, onda da lepo otvorimo novu temu ;)

[bojan_bozovic]

XSS? Naravno. Opet se zastita svodi na proveru ulaznih podataka.

[Ilija Studen]

XSS? Naravno. Opet se zastita svodi na proveru ulaznih podataka.

Ne nužno. Postoje aplikacije kojima je normalno da im podaci budu potencijalno opasni ako se ne esacapeuju pravilno. Primera radi, neki korisnik activeCollaba postuje JS snippet u poruci ili komentaru - to je skroz OK, ali moglo bi biti potancijalan propust da ga activeCollab ne escapuje.

Za ovo je bitno escapeovanje podataka pri printanju. Ulaz može da bude "zagađen".

[bojan_bozovic]

JS snippet nije opasan. Moguc je injection JS ali opet ako ne proveris ulazne podatke idemo ovako http://www.google.com" onload='alert(document.cookie)'></a>

Fala bogu ovo samo na najgorem mogucem radi - pa sa window.open otvorimo url na nasem serveru i logujemo cookije.

Evo ga:

" http://maestitia.net/stats/ar.png "


Ne mislim da phishujem ovde. Ovo admin da vidi.

Busno je ovo da ga nema gde.

I samo se u log pogleda, nego sta. neko ce da naleti.

[Ivan]

Da, sto se tice XSS tu je bitno kako printamo output. Tj prilikom projektovanja aplikacije prvo treba videti sta ona treba da radi i na koji nacin a onda odluciti koju tehniku koristiti za zastitu od navedenih propusta. Najbolje je razdvojiti funkcije koje sluze za prevenciju ulaznih i izlaznih podataka.

Nije preterano komplikovano napraviti ni neku univerzalnu funkciju kojoj mozemo zadavati parametre koje zelimo tj sta i kada zelimo da radi ali opet to je sve stvar potrebe ...

[bojan_bozovic]

Video sam tvoj sajt, je li, sta kazes za ovo (slika u password zasticenom direktorijumu) , to sam video prvi put na gaiaonline. A onaj ko ne zna dovoljno moze da se prevari i ukuca username i pass.

Dalje, primetio sam da se img procesira i u code i u quote tagu na ovom forumu. Zato sam morao da zbunim bbcode parser.

[Ivan]

Busno je ovo da ga nema gde.

Video sam sta si probao i da jeste busno ;) To je glavna fora kod CSRF napada, npr: Ja sam ulogovan na nekom levom sajtu a ujedno citam ovde nesto, ti postavis link u nekom postu ka tom sajtu sa nekim paremetrima u url-u koji npr sluze da obrisu nesto. Ja otvorim taj post i automatski posetim i taj url sa tim parametrima i obrisem nesto sto nisam zeleo ...

[Ivan]

Video sam tvoj sajt, je li, sta kazes za ovo (slika u password zasticenom direktorijumu) , to sam video prvi put na gaiaonline. A onaj ko ne zna dovoljno moze da se prevari i ukuca username i pass.

Da, nije losa fora ...

Dalje, primetio sam da se img procesira i u code i u quote tagu na ovom forumu. Zato sam morao da zbunim bbcode parser.

Hm, to nije bug vise je feature ... ?

[bojan_bozovic]

Ako korisnik moze da da url mora (sa curl ili socketima) da se posalje HEAD zahtev za URL pa ako vrati 200 OK - prikazuj.

;)

Ni to nije bezbedno od gadnog cloakinga (npr. targetujemo samo IE user-agent) auuu....

Moze isto da se izvede ako je npr. jpg ekstenzija server-parsed sa php i sadrzi skriptu koja ce da vraca 401 - uz nesto levo takodje - pa mozemo da targetujemo kako volimo (po IP opsegu, user-agentu, rDNS). Mnogo nezgodna stvar. Misklim da dosta toga moze da se postigne i sa .htaccess i .htpasswd parom u direktorijumu.

[LiquidBrain]

gde nadje ovoliko neshvacenih devojaka???? :) ;)