Sikkerhet med AJAX og PHP

[idos]

Holder på å ferdigstille en AJAX basert CMS med PHP serverscript.

 

Det jeg er usikkerpå er :

 

Hva skal til for at sikkerheten er god nok.

 

Dette har jeg gjort:

 

1 Sikre alle filer med if($_SERVER['HTTP_REFERER'] != $referer){die...};

edit Har tatt bort dette..

 

2 Index.html i alle mapper som redirekter tilbake til mittdomene.com

3 Kjører html_entities/preg_match/addslashes.. på inn data.. ( alt ettersom hva som er påkrevd.

4 Bruker post til sensitive data (brukernavn,passord) pluss sikring av data.

 

å skrive username'; -- for å kommentere ut passordsjekken gå ikke...

 

 

5 sjekker $_SESSION[tilgangsverdier] på alle sider som er begrenset

 

 

 

hva mer bør/ kan jeg gjøre...

Endret 21. august 2007 av idos

[Ernie]

Dropp å bruk $_SERVER['HTTP_REFERER'], det er ikke alltid den er satt og siten vil isåfall ikke fungere. Blant annet i Opera kan den slås av svært enkelt. Videre er det i bunn og grunn det du gjør med session og dataene som faktisk er viktig. Absolutt all input fra bruker må valideres eller ufarliggjøres, dette selv om det stammer fra et js-kall i nettleseren. Utover det er det ikke så mye man umiddelbart kan få gjort. Er du på en delt server kan det dog være greit å titte litt på session_save_path(...) siden alle på serveren kan "se" dine sessions (alternativet er database-basert).

[idos]

ok ..

 

..

 

Grunnen til HTTP_REFERER er at jeg ikke kan bruke define og defined ( som joomla gjør, ikke at joomla fremstår som kongen av sikkerhet.. ),for å unngå derekte tilgang..

 

 

ved å skrive: www.mittdomene.com/stil/tilscript/script.php?diverse=data&mer=data

 

vil output av skriptet vises.

 

Dette vil kanskje ikke være så farlig om jeg sikrer inndata, men jeg liker det ikke.. en liten blunder og vips.. .. så får kunden opp "You have been hacked by :. " eller noe i den duren.. kanskje er det bare jeg som er paranoid.. ..

[Ernie]

... og HTTP_REFERER skal da magisk hindre folk i å alikevel gjøre det? Så lenge inndataene enten blir validert eller ufarliggjort har du absolutt ingenting å bekymre deg for. Det du gjør nå er å hindre amatøren. Jeg personlig driter i hva amatører klare og ikke klarer. De jeg vil hindre er de som faktisk kan en ting og to om sikkerhet, de som kan blackbox-testing og finner sårbarheter gjennom å nettopp manipulere input. Å sette HTTP_REFERER til en spesifikk adresse er svært enkelt for disse og er i praksis ikke et hinder. Så det du altså gjør er å hindre enkelte i å vise siden din med begrunnelsen at det gir deg sikkerhet. Faktum er at det er falsk sikkerhet og gir irritasjon overfor brukere.

[idos]

OK .. takk for tilbakemelding..

 

da blir HTTP_REFERER fjernet. ..

[magikern]

$_POST er ikke spesielt sikkert så bruk f.eks sha1 på passord.

[Martin A.]

Og koblingen mellom $_POST[] og sha1/md5 er hvor?

To vidt forskjellige ting som ikke har noen ting med hverandre å gjøre.

[Crowly]

Er nok en henvisning til dette

4 Bruker post til sensitive data (brukernavn,passord)

 

Det er ikke nok å bruke kun post på slike ting. Man er nødt til å validere dataene, evt bruke hashing og forskjellige escape funksjoner som f.eks mysql_real_escape_string (ved sql kall mot en database).

Regner med at det var noe i denne "duren" det ble siktet til.

[idos]

Er nok en henvisning til dette

4 Bruker post til sensitive data (brukernavn,passord)

 

Det er ikke nok å bruke kun post på slike ting. Man er nødt til å validere dataene, evt bruke hashing og forskjellige escape funksjoner som f.eks mysql_real_escape_string (ved sql kall mot en database).

Regner med at det var noe i denne "duren" det ble siktet til.

9322808[/snapback]

 

jo, men slik jeg forstod det ut fra enkelte artikler om sikkerhet det er det lettere å sniffe GET .. .. men er ikke helt sikker på dette..

 

men dersom brukernavn og passord står i url'en vil enhver som bruker dataen etterpå kunne lese brukernavn og passord rett ut fra historien til nettleseren..

 

 

jeg kjører uansett validering.. ( dette er bare for at andre ikke skal stjele passord så lett.. for å være enda sikrere bør en vel bruke SSL))

Endret 20. august 2007 av idos

[Crowly]

jo, men slik jeg forstod det ut fra enkelte artikler om sikkerhet det er det lettere å sniffe  GET ..  .. men er ikke helt sikker på dette..  

Det vet jeg ingenting om, men jeg tror de som ønsker å snappe opp ett passord ved hjelp av sniffing ikke har noe større problem å gjøre det om det blir sendt via get eller post.

 

men dersom brukernavn og passord står i url'en vil enhver som bruker dataen etterpå kunne lese brukernavn og passord rett ut fra  historien til nettleseren..

Har man først tilgang til maskinen/nettleseren, så er det fult mulig personen har brukt nettleserens funksjon til å lagre brukernavn og passord, og da hjelper ingen sikkerhetstiltak man måtte ha på plass. Eller man kan installere en key logger (uten at jeg vet helt hvordan de fungerer) til å snappe opp ønsket informasjon.

Men det mest ryddig er å sende brukernavn og passord med post.

 

jeg kjører  uansett validering.. ( dette er bare for at andre ikke skal stjele passord så lett.. for å være enda sikrere bør en vel bruke SSL))

Ett tips jeg plukket opp fra ett annet php forum, "aldri stol på brukeren". Brukere er forskjellig og de kan finne på mye rart Så validering er veldig kjekt hvis man ikke ønsker for mange overraskelser ...

Vet ikke så mye om SSL, men det krypterer vel bare informasjon som blir sendt mellom klient og server, det fjerner ikke behovet for validering.

Endret 20. august 2007 av crowly

[PHPdude]

Som det allerede er nevnt her: ALLTID tro det verste om brukeren! Sørg for å ha bombesikre rutiner for filtrering av all input! Det letteste er nok å sende alt på riktig måte gjennom et filtersystem ala ext/filter eller Zend_Filter_Input

 

En annen høyaktuell risiko som blir farlig mye oversett er XSS. ALL output må også formateres på en trygg måte. Utrolig hvor effektivt man kan skade en side ved å trikse med HTML-koden.

 

Måten du i den første posten spesifiserer at du spesielt har sikret login-SQL'n din, får meg til å lure på hvordan du sender spørringene dine. Det er en måte å sette en effektiv stopper for SQL-injections på og det er å bruke prepared statements. Alt annet blir stort sett bare halv-gode løsninger sikkerhetsmessig (og iblant også ytelsesmessig...).

 

Viss disse punktene er på plass samt en noenlunde trygg server å kjøre koden på, bør du ikke bekymre deg med mindre siden din er et super-lukrativt mafia-mål. Selv om det finnes andre måter å angripe en webside på har du da vertfall gjort det så vanskelig at noen neppe tar seg bryet.

[idos]

Må ikke serveren kjøre php5 for å bruke mysqli og dermed prepared statements.. eller er jeg helt på jordet.. ??

[Martin A.]

Nope.

Note: The mysqli extension is designed to work with the version 4.1.3 or above of MySQL. For previous versions, please see the MySQL extension documentation.

Krever bare at --with-mysqli=mysqli_config er med i ./configure.

[idos]

Nope.

Note: The mysqli extension is designed to work with the version 4.1.3 or above of MySQL. For previous versions, please see the MySQL extension documentation.

Krever bare at --with-mysqli=mysqli_config er med i ./configure.

9328836[/snapback]

 

 

ok.. takker.. da blir det litt omskriving i helgen..

[Gjest Slettet+142]

omskriving fra mysql_ til mysqli_ er et hel**te :/

[idos]

omskriving fra mysql_ til mysqli_ er et hel**te :/

9328969[/snapback]

 

 

jaja.. .. får bruke høsten til omskriving da..

[Crowly]

Sikkert flere enn meg som lurer på hva mysqli er for noe. Denne siden syntes jeg ga en grei forklaring Converting to MySQLi. Regner med at det er en haug med andre også

[Martin A.]

Derfor foretrekker jeg en DB-klasse. Gjerne en for mysqli og en for mysql. Hvor begge "extender" samme "inkluderingsklasse", om du skjønner. Inkluderingsklassen sjekker om MySQLi er tilgjengelig, og velger den klassen fremfor MySQL. På denne måten er det enkelt å konvertere til msSQL og pgSQL om nødvendig.

Både mysqli- og mysqlklassen bruker samme funksjonsnavn. $db->query, $db->fetch_row, $db->connect for eksempel.

 

Samme gjelder validering av input. Om du bruker en klasse som er tilgjengelig overalt, lag et array som looper gjennom $_POST og $_GET, og samler alt i samme array. Så kjører man selvfølgelig valideringen før man putter det i arrayet. Evt $db->real_escape

Endret 21. august 2007 av M4rTiN