addslashes i logg inn-skjema?

[Ma]

Jeg bruker addslashes når noe legges inn i databasen av brukeren og stripslashes når noe hentes ut. Men trenger jeg ha det i de formfeltene som ikke skrives direkte inn i databasen, som f.eks logginn-skjema der jeg bare bruker select setning for å finne match?

[arnizzz]

Jeg bruker addslashes når noe legges inn i databasen av brukeren og stripslashes når noe hentes ut. Men trenger jeg ha det i de formfeltene som ikke skrives direkte inn i databasen, som f.eks logginn-skjema der jeg bare bruker select setning for å finne match?

5951053[/snapback]

 

 

Det vil jeg absolutt tro. Hvis ikke så kan jo hackere utnytte det til å hente ut informasjon som de ikke burde ha. Noen andre kan sikkert utdype. Men jeg vet aldri noe, jeg tror.

[Ma]

Det vil jeg absolutt tro. Hvis ikke så kan jo hackere utnytte det til å hente ut informasjon som de ikke burde ha. Noen andre kan sikkert utdype. Men jeg vet aldri noe, jeg tror.

5951295[/snapback]

 

Ja, er sikkert lurt. Noen andre som har noe å komme med?

[allyse]

For å si det enkelt bør du escape alt som du skal behandle fra brukeren (mao alt brukeren skriver/script sender som kan manipuleres enn bør escapes)

[Ma]

For å si det enkelt bør du escape alt som du skal behandle fra brukeren (mao alt brukeren skriver/script sender som kan manipuleres enn bør escapes)

5961355[/snapback]

 

Holder det med htmlspecialchars og addslashes, eller er det andre ting som også bør brukes?

[Ernie]

Nope, det skal være god nok beskyttelse mot både sql-injections og XSS.

 

Skal man beskytte seg mot andre svakheter som kan oppstå har man CSRF, men det er en del verre. Primært gjør man det ved at enhver GET-link aldri endrer noe. Skal man gjøre det bør det skje over POST(merk at det også finnes andre grunner til at GET aldri skal endre noe, så selv om man beskytter seg mot CSRF skal man aldri ha GET som endrer). Dog er det ingen optimal løsning siden CSRF fortsatt er mulig, men noe bedre siden man ikke åpenbart lengre kan gjennomføre CSRF. Skal man faktisk beskytte seg godt mot CSRF må man bygge inn en tilfeldig streng i alle linker (f.eks http://dome.net/fil.php?t=a7be236c92cc4a9dad373ee6d36b70411) og samtidig lagre den strengen i en SESSION for deretter å sammenligne ved sidevisning. Optimalt bør denne strengen endres for hver sidevisning, men siden det vil skape problemer hvis bruker går tilbake og klikker på en annen link hvor strengene ikke lengre passer sammen, så holder det med en gang pr. innlogging. Det er verdt å merke seg at man fortsatt teoretisk sett kan klare å gjennomføre CSRF, men jeg tviler på at noen her inn er såpass mye verdt ...

 

Mye av prinsippet bak CSRF ligger forøvrig også til grunn når man lager automatisk scripts som spam-er ned forum, gjestebøker o.l. Løsningen som mange benytter seg for å benytte seg mot slikt (bilde med tilfeldig tekst eller tall) er prinsippielt det samme.

 

Nå har jeg vel helt sikkert brukt 2 forkortelser ikke alle kjenner til. Vel:

XSS = Cross site scripting

CSRF = Cross-site request forgery

Edit:

Ja, og for de som ikke veit hva det er snakk om når jeg skriver det fult ut har jeg lagt til linker Ja, også gjelder det er her et godt stykke utover innloggingsprosessen.

Endret 21. april 2006 av Ernie

[trondes]

Fint skrvet, fikk meg til å tenke...

 

Vil ikke dette kunne løses med å sjekke:

$_SERVER['REQUEST_URI'] : om denne er satt til rett server, joda. denne kan også forandres i browseren og noen ganger ikke stemme. Men dette kan bli brukt som første sjekk.

 

Sjekk hvor lenge det var siden brukeren sist var aktiv på siden, med feks å slette noe kan han ikke ha idlet i mere enn 10 minutt, denne sjekken blir bare utførte med kritiske valg.

 

En annen ting er å lagge en liten "historie" over sidene han har vært inne på. Har han vært inn på siden der han fikk muligheten til å slette den han prøver å slette nå? ikke? vel da kan vi ikke slette den.

 

Eller som du sa legge med en uniq_id i hver link, en som blir forandret hver 5 minutt. Joda, da tenker du: Hva om bruker går inn på en side kl 12:00 og den uniq_id blir forandret. Så velger han å gå tilbake til en side som han var inn på kl 11:59 ? Enkelt, løses med å heletiden også ha den gamle uniqe id'n til gjengelig. slik at du har uniq_id og uniq_id_old. Da har brukern muligheten til å gå tilbake til en side som han var inne på for 9 minutt og 59 sekunder siden og trykke på en link der.

 

En annen ting jeg gjør, samme hva jeg registere, er å opprette en uniq_id på Posten i databasen. Denne blir bare til i lagt linken når brukeren skal forandre noe

på den posten, ingen andre enn den som her lov til å forandre den som får tilgang til den. Det holder ikke med å skrive inn ?slett_id=10 du må ha med ?slett_id=10&uniq_id=kjhduin3dcre8nhdce

 

Men dette er bare noe tanker, kanskje andre har noen flere innspill på dette?

Endret 22. april 2006 av trondes

[Ernie]

Fint skrvet, fikk meg til å tenke...

5965269[/snapback]

 

Vil ikke dette kunne løses med å sjekke:

$_SERVER['REQUEST_URI'] : om denne er satt til rett server, joda. denne kan også forandres i browseren og noen ganger ikke stemme. Men dette kan bli brukt som første sjekk.

5965269[/snapback]

Vel, den er ikke sikker i det heltatt. Den kan mangle og den kan eksistere men være faket.

 

Sjekk hvor lenge det var siden brukeren sist var aktiv på siden, med feks å slette noe kan han ikke ha idlet i mere enn 10 minutt, denne sjekken blir bare utførte med kritiske valg.

5965269[/snapback]

Problemet her er at det ikke er noe problem å sende 2 forespørsler etter hverandre, en helt ufarlig en og en farlig.

 

En annen ting er å lagge en liten "historie" over sidene han har vært inne på. Har han vært inn på siden der han fikk muligheten til å slette den han prøver å slette nå? ikke? vel da kan vi ikke slette den.

5965269[/snapback]

Igjen, ikke noe problem å sende flere forespørsler og dermed generere historie.

 

Eller som du sa legge med en uniq_id i hver link, en som blir forandret hver 5 minutt. Joda, da tenker du: Hva om bruker går inn på en side kl 12:00 og den uniq_id blir forandret. Så velger han å gå tilbake til en side som han var inn på kl 11:59 ? Enkelt, løses med å heletiden også ha den gamle uniqe id'n til gjengelig. slik at du har uniq_id og uniq_id_old. Da har brukern muligheten til å gå tilbake til en side som han var inne på for 9 minutt og 59 sekunder siden og trykke på en link der.

5965269[/snapback]

Hjelper meget lite siden vi fort kan snakke om opp mot en time. Dessuten, å legge seg på en unik id pr. session fungerer greit siden det er små sjanser for at noen plukker den opp mens man er logget inn. Primært vil det være begrenset til sikkerhetshull i JS som tillater en å hente ut innhold fra andre sider som er oppe.

 

En annen ting jeg gjør, samme hva jeg registere, er å opprette en uniq_id på Posten i databasen. Denne blir bare til i lagt linken når brukeren skal forandre noe

på den posten, ingen andre enn den som her lov til å forandre den som får tilgang til den. Det holder ikke med å skrive inn ?slett_id=10 du må ha med ?slett_id=10&uniq_id=kjhduin3dcre8nhdce

5965269[/snapback]

Vel, JS kan gjøre masse rart, blant annet hente innhold fra en ny side, og da er det ikke mye problem å hente ut den unike IDen.

 

Men dette er bare noe tanker, kanskje andre har noen flere innspill på dette?

5965269[/snapback]

Noen innspill hadde vært noe. Skal man faktisk beskytte seg helt mot det her så må hver bruker skru av JS.

[trondes]

Noen innspill hadde vært noe. Skal man faktisk beskytte seg helt mot det her så må hver bruker skru av JS.

5965953[/snapback]

 

Hmm.. forstår, det eneste sikre er vel hvis du selv ringer opp han som skal forandre på siden og spørrer om det virkelig er han. Men så igjen så kan jo noen ha stjelt mobilen hans og utgir seg for å være han

 

Igrunn er det vel ikke noe du kan gjør for at det skal bli 100% sikkert. Det er nå mulig å legge inne slik at det blir vist et bilde med tall og bokstaver på som du må trykke inn i et felt før forandringene skal gjøres, men dette vil bli sett på som at det sinker arbeidet til de som skal gjør det.

 

Men det som er fint når jeg skriver system for mine kunder er at da blir systeme uniq, og for at noen skal klarer å lure systemet er dette vanskeligere uten å ha en vis kjenskap til koden å se på. Derfor er feks populære system som feks Mambo mer utsatt for hacking hvis webadmin ikke passer på å heletiden oppgradere systemet til siste versjoner.

 

Jeg sier ikke mine system er perfekt, men jeg har også gjort det jeg kan for å lukke alle sikkerhetshull. Jeg bruker blant annet en uniq_id på hver Post i databasen og den kommer bare frem hvis det er noe som skal forandres på den. Da bli det generert en ny, som er hemmelig til neste gang noen skal forandre på den. Dermed har ingen mulighet til å bruke feks CSRF på dem. Da de ikke vet den uniq_id. Og hvis noen vet den har de alt tilgang til systemet

 

Hadde nå vært gøy å høre hvordan du beskytter deg mot slik angrep, fortell

[Ernie]

Blææææ ... kom på en ting akkurat nå. Å legge til en unik streng gjør det bare verre å angripe, men så langt fra umulig. Er jo bare å hente ut en side så har man jo strengen Æsj, nå må jeg i tenkeboksen igjen

 

Uannsett, vanligvis bare legger jeg til strengen som hidden input der det trengs.

[trondes]

Blææææ ... kom på en ting akkurat nå. Å legge til en unik streng gjør det bare verre å angripe, men så langt fra umulig. Er jo bare å hente ut en side så har man jo strengen Æsj, nå må jeg i tenkeboksen igjen

 

Uannsett, vanligvis bare legger jeg til strengen som hidden input der det trengs.

5966087[/snapback]

 

hehe.. nei, jeg viser aldri den uniq_id til noe andre enn de som har rett til å forandre posten. Dermed er det ingen andre en de som har mulighet til å gjøre dette via systemet som vet den. Og hvorfor skulle de prøve seg på et angrip når de alikavel kan slette den