DevProTalk - PHP & INSERT INTO mySQL ne radi :(

DevProTalk (http://www.devprotalk.com/index.php)

- PHP (http://www.devprotalk.com/forumdisplay.php?f=9)

- - PHP & INSERT INTO mySQL ne radi :( (http://www.devprotalk.com/showthread.php?t=1502)

LiquidBrain

15. 09. 2006. 16:59

PHP & INSERT INTO mySQL ne radi :(

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

Kôd:

        $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

15. 09. 2006. 17:47

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

dinke

15. 09. 2006. 17:52

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

Kôd:

$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

15. 09. 2006. 18:56

Da, hvala. to je u sushtini bio problem.

jablan

15. 09. 2006. 19:11

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

LiquidBrain

15. 09. 2006. 19:15

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

cvele

13. 10. 2006. 13:58

Citat:

Originalno napisao LiquidBrain

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

PHP kôd:


		
			
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

13. 10. 2006. 15:47

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

Ilija Studen

13. 10. 2006. 17:11

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.
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 kôd:


		
			
<?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:

Kôd:

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.

Citat:

Originalno napisao LiquidBrain

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

13. 10. 2006. 18:12

Citat:

Originalno napisao Ilija Studen

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

13. 10. 2006. 18:27

Citat:

Originalno napisao LiquidBrain

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

13. 10. 2006. 18:47

Citat:

Originalno napisao Ilija Studen

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

13. 10. 2006. 19:01

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

13. 10. 2006. 19:13

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

13. 10. 2006. 21:49

Citat:

Originalno napisao ivanhoe

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

Citat:

SQL :: 4 queries were made.

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

Citat:

SQL :: No queries were made.

Ivan	13. 10. 2006. 23:32

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

14. 10. 2006. 00:28

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

Ilija Studen

14. 10. 2006. 00:34

Citat:

Originalno napisao bojan_bozovic

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

14. 10. 2006. 00:44

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:

" [img] http://maestitia.net/stats/ar.png [/img] "

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	14. 10. 2006. 01:08

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

14. 10. 2006. 01:13

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	14. 10. 2006. 01:13

Citat:

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	14. 10. 2006. 01:16

Citat:

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 ...

Citat:

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

14. 10. 2006. 01:22

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

14. 10. 2006. 03:56

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

Vreme je GMT +2. Trenutno vreme je 13:37.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.