Peter Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 Ikke minst regenerer sessionID på hver request. Lenke til kommentar
qualbeen Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 1: sjekke mot IP er svært slitsomt for folk som har en fluktig IP. Nå er det jo en temmlig liten andel som måtte ha det problemet, men bytter man ofte trådløse nett kan det jo være plagsomt å bli logget av. Noen som vet om man beholder IP'en ved roaming på 3G-nettene? 2: Ja, bytte sessionid vil hjelpe mot manuelt nedhenting og besøk av sider. Men jeg regner jo med at script som sitter å tar imot sessionid gjerne automatisk bruker den nye sessionid-en millisekundet sendere. Da gjerne for å prøve å opprette nye brukere, endre passord, eller hva det nå måtte være. Men såklart: Den egentlige brukeren vil jo bli tvunget til å foreta en ny pålogging - og dermed logge av igjen Mr. Evil. Men ang. IP-sjekk og regenerering av session-id: dette har jo svært liten hjelp mot CSRF. Men her kan jo kanskje unike tilleggs-srenger følge med i GET eller POST i hver eneste request - og dermed sjekke at korrekt unik-id er oppgitt. Finnes det flere smarte sikkerhetstiltak man kan gjøre? La oss si at en side hadde alt dette på plass: Hvordan kan man nå finnes svakheter, og komme seg inn? (Jeg antar såklart at SQL-injections ikke fungerer) Lenke til kommentar
Ernie Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 Vel, session-basert innlogging er ganske usikkert uannsett hva du finner på så lenge det foregår ukryptert. Hvis man føler for å bruke mye energi på å sikre det så er SSL et åpenbart «must». Veit ikke helt hvilke innstillinger PHP bruker på «session-cookie», men hvis man setter det hele manuelt kan du sette både parametrene 'secure' og 'httponly' (som egentlig bare betyr ikke tilgjengelig for JS) til true. Det er ikke alle nettlesere som støtter det, men IE gjør det. Faktisk var MS først ute med httponly og har hatt det siden IE6 SP1 eller noe i den duren, så IE er ikke bare negativt. Uannsett, det hjelper litt på når «cookie», iallfall for en større andel brukere, ikke er 100% tilgjengelig i javascript og i tillegg bare blir overført via en kryptert kobling. Lenke til kommentar
qualbeen Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 takker for inspill Ernie. Vet ikke hvor jeg fikk det fra, men jeg fryktet at de fleste nettleserne lot seg lure av JS når det kommer til utlevering av cookie. Tror jeg smeller opp noen tester for å verifisere senere, men du har sikkert rett. Selv forstår jeg ikke hvorfor 'httponly' ikke er satt til true som default, men men .. PHP har jo mange snodige krumspring Hvis man ikke vil bruke session-styrt pålogging: hvordan skal man da gjøre det? Serveren trenger jo hele tiden en verifikasjon på at du er deg, og å sende over brukernavn/pwd i hvert eneste kall kan da ikke være så mye lurere.. IP-filtrering er såklart en mulighet, men IP'er er gjerne flyktige og lite til å stole på mener nå jeg. Spesielt med alle disse trådløse nettene man nå kan komme seg inn på, og dermed ha korrekt IP. Støtter helt klart opp om kryptert overføring, gjerne vha TLS/SSL. Lenke til kommentar
Ernie Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 Vel, det har vært forsøk på å droppe cookie, og lagre det v.hj.a andre metoder, deriblant javascript av alle ting. Uannsett, det meste har irriterende nok mer ulemper enn fordeler i forhold til cookie. Det mest realistiske er den innebyggede auteniseringen i HTTP, og da fortrinnsvis digest. Problemet der er utlogging og «man in the middel»-angrep (noe cookie også er utsatt for, og løsning for begge er SSL/TLS). Dessverre så mangler det en ordentlig sikker metode for å logge inn brukere via HTTP. Hovedgrunnen er at HTTP er «stateless» og vil derfor i utgangspunktet ikke koble en tidligere tilkobling mot den nåværende og ta vare på data mellom de. Det noen skulle gjort er å lage et «challenge respons»-system mellom server og klient hvor passordet aldri trenger å forlate nettleseren og er sikkert lagret i begge ender. Gjennomført ordentlig får man en dramatisk økt sikkerhet uten noe behov for kryptering. Hvis man i tillegg krever at linker fra eksterne sider medfører at man ikke er innlogget (mao. klient sender ikke noen repons på utfordringen) fjerner man også CSRF-faren. Da er det i praksis veldig lite som kan gå galt. Problemet er bare å få gjennomført det. Det kan se ut som at kryptering løser litt for mye av problemet til at det er motivasjon for å gjennomføre noe slikt. I tillegg er det en aldri så liten utfordring å tillate flere faner og tilnærmet parallelle tilkoblinger uten at det medfører at blir utlogget og samtidig som man beskytter mot replay-angrep. PS: At PHP ikke setter httponly til true pr. default har nok noe med bakoverkompatibilitet, og det ble innført så seint som PHP 5.2.0. Lenke til kommentar
rødøye Skrevet 25. desember 2008 Del Skrevet 25. desember 2008 Det noen skulle gjort er å lage et «challenge respons»-system mellom server og klient hvor passordet aldri trenger å forlate nettleseren og er sikkert lagret i begge ender. Det har man jo allereede gjennom for eksempel kerberos. Lenke til kommentar
OIS Skrevet 21. januar 2009 Del Skrevet 21. januar 2009 httponly kan selvfølgelig ikke settes på som default. Mange vil lure fælt når AJAX ikke funker med sessions på siden deres lengre. Lenke til kommentar
hakonvl Skrevet 31. januar 2009 Del Skrevet 31. januar 2009 AJAX er det sånn at siden oppdaterer seg selv uten at hele siden refresher seg? Lenke til kommentar
Jonas Skrevet 31. januar 2009 Del Skrevet 31. januar 2009 http://en.wikipedia.org/wiki/Ajax_(programming) Lenke til kommentar
hakonvl Skrevet 31. januar 2009 Del Skrevet 31. januar 2009 Er det vanskelig eller kan en som ikke kan så mye klare det hvis han vil det? Lenke til kommentar
qualbeen Skrevet 31. januar 2009 Del Skrevet 31. januar 2009 Man trenger forsåvidt ikke ha store forkunnskaper for å lage enkle ajax-applikasjoner, men det hjelper nok.. Det finnes gode rammeverk for å leke med ajax og javascript-effekter: http://en.wikipedia.org/wiki/Comparison_of...ript_frameworks (jQuery, Prototype og YUI er vel de mest brukte?). Antar du kan litt PHP også, siden du poster i denne kategorien. Så du kan leke deg med å sette opp en funksjon som returner ulikt svar basert på POST eller GET-parametre, også bruker du ajax til å jobbe mot denne funksjonen. Men enda mer nyttig er det muligens å google seg frem til noen gode ajax-tutorialer? Lenke til kommentar
tickinghd Skrevet 31. januar 2009 Del Skrevet 31. januar 2009 (endret) 1: sjekke mot IP er svært slitsomt for folk som har en fluktig IP. Nå er det jo en temmlig liten andel som måtte ha det problemet, men bytter man ofte trådløse nett kan det jo være plagsomt å bli logget av. Noen som vet om man beholder IP'en ved roaming på 3G-nettene? Jeg er ikke så dypt inne på forskjellige nettverk, men så lenge mobilnettverk støtter roaming skal IP'en ikke endre seg siden internett-laget ligger over link-laget i TCP/IP modellen. IP er derfor en god indikator ved midlertidig autentisering, sammen med cookies for eksempel. og å sende over brukernavn/pwd i hvert eneste kall kan da ikke være så mye lurere.. Nei, det har du rett i. Innlogging (autorisering/autentisering) og gjenkjenning (autentisering) bør gjøres med forskjellige metoder fordi sensitive data ikke bør sendes på usikre nettverk flere ganger enn strengt nødvendig. Autentisering deles opp i tre kategorier. Noe du vet, har eller er. Ved innlogging bruker man passord fordi dette er en praktisk metode for innlogging på nettsider (noe du vet). Deretter brukes to andre metoder, cookie (noe du har) og IP (noe du vet - ok, det høres rart ut). Så langt det er praktisk bruker man alltid to eller tre autentiseringsmetoder samtidig, fordi disse er usikre hver for seg men mange ganger sikrere om de kombineres. Beklager om det synes som om jeg bare briefer med dette, det er bare at spørsmålene qualbeen tok opp inspirerte meg til å hente fram gammelt skolemateriale som jeg burde kunne bedre sjøl. Repetering er bra. Takk. Endret 31. januar 2009 av tickinghd Lenke til kommentar
hakonvl Skrevet 31. januar 2009 Del Skrevet 31. januar 2009 Man trenger forsåvidt ikke ha store forkunnskaper for å lage enkle ajax-applikasjoner, men det hjelper nok.. Det finnes gode rammeverk for å leke med ajax og javascript-effekter: http://en.wikipedia.org/wiki/Comparison_of...ript_frameworks (jQuery, Prototype og YUI er vel de mest brukte?). Antar du kan litt PHP også, siden du poster i denne kategorien. Så du kan leke deg med å sette opp en funksjon som returner ulikt svar basert på POST eller GET-parametre, også bruker du ajax til å jobbe mot denne funksjonen. Men enda mer nyttig er det muligens å google seg frem til noen gode ajax-tutorialer? Ok, bare lurte på om det var veldig vanskelig. Kan en del PHP men er forhåndsvis fersk, men skal google litt på det. Lenke til kommentar
Magnus Holm Skrevet 22. februar 2009 Del Skrevet 22. februar 2009 Ang. backslash som namespace-seperator, så er det kun fordi PHP-parseren er et clusterfuck som ikke klarer å skille to like tegn i to forskjellige sammenhenger De andre alternativene de vurderte: ** ^^, %% :> :) ::: Syns de burde gått for smilien, jeg Lenke til kommentar
SPRCO Skrevet 23. februar 2009 Del Skrevet 23. februar 2009 Tenkte å kjøpe meg en sånn en php-bok for nybegynnere. Sett litt rundt på amazon.com og sånt, men er jo så mye å velge i. Er det noen spesielle bøker som anbefales? Jeg har ikke så mye erfaring innen koding, men kan basics av html og css. Har drevet med det noen måneder nå. Vil det bli vanskelig for meg å få noe ut av en php beginnerbok? Har fått anbefalt denne, men vil gjerne ha flere anbefalinger og Lenke til kommentar
OIS Skrevet 23. februar 2009 Del Skrevet 23. februar 2009 (endret) Har fått anbefalt denne Du burde kanskje prøve fjerde utgave av boken. Du linker til tredje. Ellers har eg vel kun en bok om PHP, som absolutt ikke anbefales noen. Skal lime inn tittel når eg kommer hjem. Edit: Boken heter "Advanced PHP Programming". Kjøpte den egentlig pga kapitlene om å utvide/lage extensions til PHP. Men de var ikke så bra. Endret 26. februar 2009 av OIS Lenke til kommentar
hakonvl Skrevet 23. februar 2009 Del Skrevet 23. februar 2009 Webprogramering i PHP av Svend Andreas Horgen er en go nybegynner bok. Du lærere en del PHP og MySQL en liten innføring i objektorientert PHP, men har ikke sett delen enda. Nesten alle kodesnutter kan lastes ned fra nettet o.s.v Lenke til kommentar
tickinghd Skrevet 23. februar 2009 Del Skrevet 23. februar 2009 Enig med Rockie, veldig grei introduksjonbok. Jeg kunne programmere litt i andre språk før jeg leste denne og det gikk kjemperaskt å komme igang med php siden boken er så lettlest. Tut og kjør. Lenke til kommentar
hakonvl Skrevet 24. februar 2009 Del Skrevet 24. februar 2009 (endret) Enkelt og greit språk. Forståelig selv for en 13 åring (er det selv), og det er ikke alle databøker som er det Har lest en del annen norsk datalitteratur og er ikke alt som er så forståelig Skjønte ikke helt det med arrays men har ikke satt meg mer inn i det enn og lese introduskjsonen og første kodesnutt Endret 24. februar 2009 av Rockie Lenke til kommentar
Gjest Slettet+6132 Skrevet 24. februar 2009 Del Skrevet 24. februar 2009 Arrays er jo ikke vanskelig, tenk på det som ei hylle med merkelapper på hver hylle, hvor du legger du ting du skal bruke senere. $hylle = array(); $hylle['øverst til venstre'] = 'bøker'; $hylle['midten høyre'] = 'brev og papir'; Eller, et annet eksempel; $kake = array(); $kake['navn'] = 'Sjokoladekake'; $kake['form'] = 'Rund'; $kake['steketid'] = '30 min.'; $kake['ingredienser'] = array('Mel', 'Kakao', 'Margarin', 'Sukker'); Så, for å si det enkelt, et array er en samling av variabler. Jeg er ikke spesielt god til å forklare ting, men jeg håper hvertfall at jeg ikke forvirrer deg enda mer Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå