PelleP Skrevet 6. februar 2011 Del Skrevet 6. februar 2011 Jeg er i ferd med å lage et passordbeskjyttet fotogalleri. Det er mest for privat bruk og vil bli veldig lite besøkt (kun venner og familie). Brukere kan registrere seg og logge inn med et md5-kryptert passord. Er det noen som kan fortelle meg hva jeg trenger av sikkerhetstiltak mot sql/html injection o.l. før jeg kan legge ut siden? Lenke til kommentar
BlueEAGLE Skrevet 6. februar 2011 Del Skrevet 6. februar 2011 "Sikkerhetstiltak", "passordbeskyttet", "md5" er ikke kryptering. Du bør ha mysql_real_escape_string på all data som skal brukes i forbindelse med en database. Hvis brukere skal legge inn ting som kan vises på siden så er html_entities fint. Det viktigste er egentlig å validere $_GET-variablene brukt under navigering slik at søppel her blir håndtert på en fornuftig måte. Lenke til kommentar
xqus Skrevet 6. februar 2011 Del Skrevet 6. februar 2011 Når det gjelder SQL foreslår jeg du tar en titt på PDO. Jeg vet det kan se veldig komplisert ut, men et raskt søk på Google gir deg nok noen enkle guider. Med PDO sinne "prepeared statements" trenger du ikke beskymre deg for SQL injections. Når det gjelder XSS eller html injection kan jo titte på mitt bibliotek som kan beskytte deg både mot XSS og mye annet snax. Hvis ikke er det viktig å escape eller strippe _ALT_ som kommer fra $_POST, $_GET, $_REQUEST, $_COOKIE osv. variablene. Enten med strip_tags() eller htmlentities() eller tilsvarende. Her må du også tenke på tegnsett. Lenke til kommentar
PelleP Skrevet 6. februar 2011 Forfatter Del Skrevet 6. februar 2011 (endret) Takk dere! Jeg bruker mysql_real_escape_string, strip_tags() og htmlentities(). Skal sjekke igjen om jeg har vært konsekvent. Har også tenkt å se på POD og jeg har lastet ned xqus pibliotek og skal se litt på det. Samtidig så har jeg ikke lust å gjøre det mer komplisert enn nødvendig. Jeg er så å si ferdig med mitt fotogalleri, det eneste som hindrer meg fra å legge det ut er at jeg er engstelig for sikkerheten. Men hvor utsatt kan jeg egntlig være når vi snakker om en side med ca et besøk om dagen? Det vil neppe være noen som har interesse av å hakke den? Hva er det, helt konkret, som jeg rissikerer dersom jeg slurver med sikkerheten? Endret 6. februar 2011 av PelleP Lenke til kommentar
greygenic Skrevet 8. februar 2011 Del Skrevet 8. februar 2011 Du risikerer at hackere herper sida di, og i tillegg legger inn politiske / religiøse budskap, og/eller kode/program som sørger for å laste ned dritt til maskina til alle de som besøker sida di.. Gøy, ikke sant? Slapp av, det hele er faktisk ganske enkelt: Benytt deg av 'whitelist'-prinsippet, der du "slipper" igjennom kun når teksten (f.eks. passord) matcher "mønsteret" du har bestemt deg for å tillate (f.eks. kan du velge å godta kun tegn mellom a-Z, A-Z, 0-9) Så lenge du sørger for å bruke funksjonalitet der hvert enkelt tegn blir sjekket vil det være umulig å 'escape' seg ut.. Feilen mange nybegynnere gjør er å hive på en masse funksjoner som er ment for å "renske" teksten for mulige ulumskheter, uten helt å forstå hva som egentlig foregår.. ELLER ...så kan du satse på ferdiglagde og gode script som du finner på Internett. Helst noen som blir anbefalt, og som man vet helt sikkert fungerer godt. Et eksempel vil være script for å verifisere gyldige epost-adresser, som gjerne også sjekker at det oppgitte domenet faktisk eksisterer. 1 Lenke til kommentar
PelleP Skrevet 20. februar 2011 Forfatter Del Skrevet 20. februar 2011 Du risikerer at hackere herper sida di, og i tillegg legger inn politiske / religiøse budskap, og/eller kode/program som sørger for å laste ned dritt til maskina til alle de som besøker sida di.. Gøy, ikke sant? Joda, jeg skjønner jo det, men jeg tviler på at noen vil kaste bort tiden på å hakke min side ettersom det kommer til å være veldig få som besøker den. Slapp av, det hele er faktisk ganske enkelt: Benytt deg av 'whitelist'-prinsippet, der du "slipper" igjennom kun når teksten (f.eks. passord) matcher "mønsteret" du har bestemt deg for å tillate (f.eks. kan du velge å godta kun tegn mellom a-Z, A-Z, 0-9) Så lenge du sørger for å bruke funksjonalitet der hvert enkelt tegn blir sjekket vil det være umulig å 'escape' seg ut.. Skal se litt på det. Tror det står noe i boken min. Feilen mange nybegynnere gjør er å hive på en masse funksjoner som er ment for å "renske" teksten for mulige ulumskheter, uten helt å forstå hva som egentlig foregår.. Ja, det var det jeg vill unngå. ELLER ...så kan du satse på ferdiglagde og gode script som du finner på Internett. Helst noen som blir anbefalt, og som man vet helt sikkert fungerer godt. Et eksempel vil være script for å verifisere gyldige epost-adresser, som gjerne også sjekker at det oppgitte domenet faktisk eksisterer. Å bruke ferdiglagede script uten å forstå dem vil jeg helst ikke gjøre, i hvert fall ikke før jeg har lert meg å forstå i hvert fall det grunnleggende. Lenke til kommentar
PelleP Skrevet 20. februar 2011 Forfatter Del Skrevet 20. februar 2011 Jeg fulgte xqus råd og ha endret koden slik at jeg bruker PDO og prepeared statements. I tillegg skal jeg vallidere all brukerinnput og $_GET-variabler med strip_tags og stripslashes. Er det forsvarlig å legge ut nettstedet snart, eller må jeg i tillegg bruke whitelistprinsippet? Noe annet? Lenke til kommentar
Jonas Skrevet 21. februar 2011 Del Skrevet 21. februar 2011 (endret) strip_tags og stripslashes er ikke validering. Whitelistingprinsippet som greygenic er ikke annet enn irriterende for brukere som faktisk ønsker et passord bestående av rare tegn og har ingen ting med sikkerhet å gjøre. Sikkerhet på web, i den forstand vi prater om her, handler om escaping. Validering er applikasjonsspesifikt. Endret 21. februar 2011 av Jonas Lenke til kommentar
PelleP Skrevet 21. februar 2011 Forfatter Del Skrevet 21. februar 2011 strip_tags og stripslashes er ikke validering. Whitelistingprinsippet som greygenic er ikke annet enn irriterende for brukere som faktisk ønsker et passord bestående av rare tegn og har ingen ting med sikkerhet å gjøre. Sikkerhet på web, i den forstand vi prater om her, handler om escaping. Validering er applikasjonsspesifikt. Jeg er og vil alltid være en amatør når det gjelder PHP. Jeg vil ha tisltrekkelig sikkerhet på enklest mulig måte slik at jeg kan få lagt ut mitt bildegalleri uten å først ta doktorgraden i informatikk. Brukerne skal registrere seg og logge inn og logge ut ikke noe mer (intill videre). E-postadresse brukes som "brukernavn" ved innlogging. Brukerinputt blir følgende: passord, e-postadresse, fornavn og etternavn. I tillegg har jeg en $_GET-variabel. Passord: Jeg bruker md5 på passordet og da formoder jeg at det ikke trengs noen escaping av det. (ev. ondsinnet kode blir vell vare "hashet" sammen med resten?) Fornavn-, etternavn og e-postadresse: Her trengs ikke noen rare tegn. PDO med prepared statements, og escaping med med strip_tags og stripslashes. Gir det nok sikkehet? $_GET-varibalen: Escapes med strip_tags og stripslashes. Er dette nok? Lenke til kommentar
EvenAug Skrevet 22. februar 2011 Del Skrevet 22. februar 2011 Når du er så opptatt av sikkerheten kan det være greit å si at md5 er langt fra sikkert. Den har gått bort som standard for mange år siden da den har flere sikkerhetsfeil. Folk har gått over til SHA hasing. SHA1 er sikkert per dags dato, men det finnes teoretiske måter å knekke den på, så om noen år når datakraften har stor nok, vil SHA1 knekkes. SHA256 med salt er hva jeg anbefaler. Selv bruker jeg Sha256 med 2 salter (en statisk som gjelder alle og en dynamisk som er unik for hver enkelt bruker). Men hvor stor interesse folk skulle ha av å hacke bildene dine er usikkert. Med mindre du er kjendis eller har intime bilder på serveren^^ Lenke til kommentar
PelleP Skrevet 22. februar 2011 Forfatter Del Skrevet 22. februar 2011 Når du er så opptatt av sikkerheten kan det være greit å si at md5 er langt fra sikkert ... Men hvor stor interesse folk skulle ha av å hacke bildene dine er usikkert. Med mindre du er kjendis eller har intime bilder på serveren^^ Strengt tatt er jeg ikke så veldig opptatt av sikkerheten og jeg tror ikke at noen har interesse av å hakke mitt bildegalleri. Jeg er litt redd for at noen skal gjøre det for morros skuld og at det kan føre til problemer for dem som besøker siden. Det høres ikke så veldig sannsynlig ut, men jeg vet jo ikke nok om slike ting til å gjøre en kvallifisert rissikovurdering. Derfor så vil jeg gjerne beskytte siden så godt jeg kan. Jeg tror jeg har tilstrekkelig grad av sikkerhet nå, bortsett fra at jeg gjerne skulle ha forhindret direkte tilgang til bildene ved å taste URL-en http://www.minside.no/bildenavn.jpg. Men når det er så mange som legger ut bilder på sine og andres unger uten noen som helst tilgangsbegrensning så tror jeg det kan være forsvarlig å ta den biten litt senere. Lenke til kommentar
EvenAug Skrevet 23. februar 2011 Del Skrevet 23. februar 2011 For et privat galleri som du snakker om her ville jeg løst det enkelt med htaccess til mappa bildene lå i. Da er det gjort på 20 sekunder og bildene er sikre nok etter min mening. Lenke til kommentar
PelleP Skrevet 23. februar 2011 Forfatter Del Skrevet 23. februar 2011 For et privat galleri som du snakker om her ville jeg løst det enkelt med htaccess til mappa bildene lå i. Da er det gjort på 20 sekunder og bildene er sikre nok etter min mening. Takk for tipset, jeg skal undersøke det! Lenke til kommentar
Terrasque Skrevet 23. februar 2011 Del Skrevet 23. februar 2011 Når du er så opptatt av sikkerheten kan det være greit å si at md5 er langt fra sikkert. Den har gått bort som standard for mange år siden da den har flere sikkerhetsfeil. Folk har gått over til SHA hasing. SHA1 er sikkert per dags dato, men det finnes teoretiske måter å knekke den på, så om noen år når datakraften har stor nok, vil SHA1 knekkes. SHA256 med salt er hva jeg anbefaler. Selv bruker jeg Sha256 med 2 salter (en statisk som gjelder alle og en dynamisk som er unik for hver enkelt bruker). Bare sånn for moro skyld, kan du forklare meg hvorfor MD5 for passord hashing er så mye mindre sikkert enn f.eks SHA1, og hva det i praksis vil si for sikkerheten på en side? Lenke til kommentar
Jonas Skrevet 23. februar 2011 Del Skrevet 23. februar 2011 Du kan lese om MD5 og dets svakheter til du blir grønn på Wikipedia og alle kildehenvisningene. Lenke til kommentar
Terrasque Skrevet 23. februar 2011 Del Skrevet 23. februar 2011 (endret) Du kan lese om MD5 og dets svakheter til du blir grønn på Wikipedia og alle kildehenvisningene. Har faktisk lest igjennom det, og etter det jeg ser så er MD5 preimage attack ganske sikkert (2^123.4 istedet for 2^128 som er teoretisk maks). Ganske upraktisk, med andre ord. Så lenge passordet har lavere entropi enn 124 gjør det kake forskjell. Til sammenligning, for å få 128bit entropi i passord, med [a-zA-Z0-9], og det er helt random, så trenger du et 23 chars langt passord. Når det gjelder passord mennesker lager, er det enda verre: NIST suggests the following scheme to estimate the entropy of human-generated passwords: * the entropy of the first character is four bits; * the entropy of the next seven characters are two bits per character; * the ninth through the twentieth character has 1.5 bits of entropy per character; * characters 21 and above have one bit of entropy per character. This would imply that an eight-character human-selected password has about 18 bits of entropy. Mer info på http://en.wikipedia.org/wiki/Password_strength Og nei, salting vil ikke hjelpe så mye der, siden man allerede har salt verdiene.. Hvis man vil gjøre ting virkelig vanskelig så fokuserer man også på ting som hvor lang tid det tar å generere hver hash. Mange hash'er er laget for å være så rask som mulig, noe som gjør dem mindre egnet for passord hashing. Man har f.eks bcrypt og scrypt, pluss forskjellige triks som Key Stretching. Men til syvende og sist så vil dette bare være relevant hvis en angriper allerede har tilgang til databasen.. Edit: Så... Venter fremdeles på et svar på spørsmålet mitt Endret 23. februar 2011 av Terrasque Lenke til kommentar
EvenAug Skrevet 24. februar 2011 Del Skrevet 24. februar 2011 Tja, et kjapt søk på google gir deg mange trekk. F.eks kan en svakhet i md5 gjøre at en kan forfalske SSL sertifikater (ref: http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/). Men vi har også sett at flere md5 hasher er knust. Blant annet ble vel phpbb sin offensielle side hacket for et par år siden, der de hentet frem passord i klartekst utfra md5 hasher. Alt kommer jo an på. Med riktig lengde på md5 er det nok sikkert, men hvorfor ta en sjanse når det er så enkelt å bruke en "sikrere" standard? Alle andre har begynt å gå bort fra md5, så hvorfor skulle ikke vi gjøre det og? Jeg har ikke spesielt interesse av å lese meg grønn på hvorfor md5 er usikkert. For meg holder det med beviser at det blir knust, og at eksperter ber oss bruke andre standarer. Jeg er helt sikker på at du kan motbevise min påstand om at Md5 er usikkert ved å lage så så lange passord osv. Men det avhenger jo av hvordan passordet genereres. Og salter har sikkerhet jo. Slik som jeg har en salt i databasen og en salt i php filene som kreves. Den statiske i php fila får de ikke tilgang til om de hacker db og omvendt. Lenke til kommentar
Ernie Skrevet 24. februar 2011 Del Skrevet 24. februar 2011 Nå er det ingen automatikk i at en svakhet gjør en hash-funksjon uegnet for alle bruksområder. At det har blitt funnet svakheter som medfører dårligere «collition resistance» i MD5 har mye å si for bruksområder som SSL-sertifikater, mens det for passord ikke har like stor innvirkning, spesielt hvis man legger inn salt i passordet før det hashes. I siste fall har «collition attack» mikroskopisk innvirkning pga. at du må ha en gitt bytesekvens i det som blir hashet, og det er det små sjanser for at man får den korrekte sekvensen tilbake. At MD5-hasher blir «knekt» pga. «bruteforce» og «rainbow table» er ikke noe nytt, og noe den deler med alt annet av algoritmer. Her har lengden på passordet alt å si, og det ganske så uavhengig av hash-funksjonen. Dvs. det er jo forsåvidt en faktor til, tilgjengelig regnekapasitet hos angriper, og sånn sett vil jo en tyngre algoritme være bedre. Når det kommer til «preimage attack» så har Terrasque allerede forklart hvorfor dette ikke er noe problem enda for MD5. Lenke til kommentar
greygenic Skrevet 12. mars 2011 Del Skrevet 12. mars 2011 [...] Whitelistingprinsippet som greygenic er ikke annet enn irriterende for brukere som faktisk ønsker et passord bestående av rare tegn og har ingen ting med sikkerhet å gjøre. Det kommer helt an på konteksten. Å benytte seg av whitelist-prinsippet for å sikre seg passer utmerket i dette tilfellet, siden det kun er snakk om et lite bildegalleri som vil ha svært få besøkende, og som viktigst av alt; skal administreres og vedlikeholdes av en som ikke har kjempegod greie på webkoding. Passord, og f.eks. enkel tekst ment som kommentar til et bilde, vil da slippe igjennom, uten at det blir altfor vanskelig for trådstarter å videreutvikle galleriet senere. [...] Sikkerhet på web, i den forstand vi prater om her, handler om escaping. Validering er applikasjonsspesifikt. Så enig så enig. Lenke til kommentar
PelleP Skrevet 12. mars 2011 Forfatter Del Skrevet 12. mars 2011 [...] Whitelistingprinsippet som greygenic er ikke annet enn irriterende for brukere som faktisk ønsker et passord bestående av rare tegn og har ingen ting med sikkerhet å gjøre. Det kommer helt an på konteksten. Å benytte seg av whitelist-prinsippet for å sikre seg passer utmerket i dette tilfellet, siden det kun er snakk om et lite bildegalleri som vil ha svært få besøkende, og som viktigst av alt; skal administreres og vedlikeholdes av en som ikke har kjempegod greie på webkoding. Passord, og f.eks. enkel tekst ment som kommentar til et bilde, vil da slippe igjennom, uten at det blir altfor vanskelig for trådstarter å videreutvikle galleriet senere. Fint med en pragmatisk tilnærming, det er det jeg trenger. Det er ikke så interessetant på det nåværende tidspunkt å diskutere hvordan proffene gjør det. 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å