mboost-dp1
unknown
tja... så burde de mange webhoteller nok også snart begynde at stramme sig op, så den ikke automatisk konverterer alle POST, GET, COOKIE og SESSION data til variable... Dette er fandme en sikkerhedsrisisko, hvis man ikke beskytter sine variable ordentligt ved fx at nulstille dem i startet af scrptet...
Jeg læste en del af deres PHP Security Guide i går, og jeg finder det lidt komisk, at de tager sikkerhed så seriøst, og alligevel navngiver eksempel-includefiler <filnavn>.inc. Vil man give eksempler på hvordan man opnår høj sikkerhed, skal man ikke lave den slags bummerter, der giver risiko for, at brugeren kan downloade ens filer uden at PHP-parseren har behandlet dem.
#1: Netop initialisering af variable i toppen af scriptet, er noget de gennemgår. De anbefaler dog også at register_globals slåes fra og at error_reporting sættes til E_ALL, så man også får notices om variable, der ikke er initialiseret, så man ikke glemmer nogen. Initialisering af alle vars betragter jeg som værende overkill, men register_globals skal helt klart slåes fra.
Jeg syntes det er et lækkert initiativ
Jeg ledte selv efter noget lignende for ½ års tid siden, men det var noget sporadisk, det jeg fandt...
Jeg ledte selv efter noget lignende for ½ års tid siden, men det var noget sporadisk, det jeg fandt...
Jeg syntes det er et lækkert initiativ.
Håber bare de har mere held end W3 har haft med at påvirker webmastere rundt omkring ;)
Håber bare de har mere held end W3 har haft med at påvirker webmastere rundt omkring ;)
#4: De lægger op til at inc-filerne lægges i et subdir til webroot. Det kræver blot en forglemmelse fra administrator før hele dir'et er tilgængeligt for alle. Jeg har set lignende ting ske før, så jeg ville ikke sætte min webapplikations sikkerhed på, at det ikke sker igen. :)
Det var da et fantastisk initativ, bare synd at de fleste webhoteller, som andre også er inde på, ikke se ud til at være interesseret i PHP sikkerhed. Jeg ved godt hvorfor at mange af dem ikke har register_global slået fra, og hvorfor nogen sikkert overvejer om safe_mode nu også er nødvendigt. Svar er at der simpelthen er for mange spader der tror de kan skrive PHP kode. Web10 satte regisiter_global til "on" efter at en masse mennesker havde brokket sig over at de ikke kunne få deres kode til at virke. Fremfor bare svare folk at de er nogle spader der burde læse PHP manualen, så vælger man den nemme løsning og fjerner noget af sikkerheden.
Angående inkludering, hvorfor benytter man, som #6, ikke bare .php filer. Hvis man har noget der helst skulle holdes hemligt for andre (usernames og passwords er det eneste jeg lige kan komme på). Alternativt kan man jo bare konfigurere sin webserver til at .inc filer, eller hvad man nu vælger, også skal parse af PHP. At placere filerne uden for sin documentroot, er selvfølgelig også en løsning, det kan bare ikke altid lade sig gøre, f.eks i nogen situationer hvor webserveren er chrooted.
PHPs største sikkerheds problem er at det er for nemt at gå til og vi ender med for mange PHP programmører der tror de ikke behøver at tænke på sikkerhed.
Angående inkludering, hvorfor benytter man, som #6, ikke bare .php filer. Hvis man har noget der helst skulle holdes hemligt for andre (usernames og passwords er det eneste jeg lige kan komme på). Alternativt kan man jo bare konfigurere sin webserver til at .inc filer, eller hvad man nu vælger, også skal parse af PHP. At placere filerne uden for sin documentroot, er selvfølgelig også en løsning, det kan bare ikke altid lade sig gøre, f.eks i nogen situationer hvor webserveren er chrooted.
PHPs største sikkerheds problem er at det er for nemt at gå til og vi ender med for mange PHP programmører der tror de ikke behøver at tænke på sikkerhed.
stop nu den diskussion om hvorvidt man skal include .inc eller ej, bare man viser en 403 i det dir de ligger i, eller får php til at parse dem er det jo et fedt.
#2:
Som kan læses i Databases and SQL her burde måske nok stå nævnt første gang .inc bliver nævnt men det står der da trods alt.
If you have no choice in the placement of your modules, and they must be within document root, you can put something like the following in your httpd.conf file (assuming Apache):
<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>
Som kan læses i Databases and SQL her burde måske nok stå nævnt første gang .inc bliver nævnt men det står der da trods alt.
Hvis de så kunne få den del af php-folket, der så inderligt søger at gøre php til et egentligt scripting/programmerings-sprog, til at joine dem. Der i det "projekt", ligger massere af spildte ressourcer. De forstår åbenbart ikke at der er mere end rigeligt med scripting sprog på "markedet".
Generelt er det dog /brugeren/ af sproget der er skyld i fejlene. De fejl han laver, ville ikke findes hvis han havde læst HELE 'bogen'(/tutorial/whatever).
Selvfølgelig findes der også bugs/exploits i selve php parser, men de opdateres globalt hver gang der kommer en update, såfremt admin sørger for det.
At tro endnu et sikkerheds-konsortium vil gøre at uvillige folk begynder at læse mere end de i forvejen gider om sikkerhed, er da at skyde forbi. At tvinge folk til det, altså implementere det i selve sproget så det ikke kan omgåes, såsom at /tvinge/ tainted data i at blive checked, er umiddelbart den eneste løsning.
Ellers kan man selvfølgelig gøre syntaksen så svær at man skal sætte sig rigeligt ind i det før det giver mening, men så bliver det måske også svært at gøre det sikkert ;)
Udover det, så bestemt et godt initiativ, sikkerhed frem for alt - er bare ikke sikker på at det vil gøre megen forskel, udover at skabe et samlingsted for dem der allerede interesserer sig for sikkerheden i php.
Generelt er det dog /brugeren/ af sproget der er skyld i fejlene. De fejl han laver, ville ikke findes hvis han havde læst HELE 'bogen'(/tutorial/whatever).
Selvfølgelig findes der også bugs/exploits i selve php parser, men de opdateres globalt hver gang der kommer en update, såfremt admin sørger for det.
At tro endnu et sikkerheds-konsortium vil gøre at uvillige folk begynder at læse mere end de i forvejen gider om sikkerhed, er da at skyde forbi. At tvinge folk til det, altså implementere det i selve sproget så det ikke kan omgåes, såsom at /tvinge/ tainted data i at blive checked, er umiddelbart den eneste løsning.
Ellers kan man selvfølgelig gøre syntaksen så svær at man skal sætte sig rigeligt ind i det før det giver mening, men så bliver det måske også svært at gøre det sikkert ;)
Udover det, så bestemt et godt initiativ, sikkerhed frem for alt - er bare ikke sikker på at det vil gøre megen forskel, udover at skabe et samlingsted for dem der allerede interesserer sig for sikkerheden i php.
#16 du har nogle gode pointer...
men ok det er jo nok de samme folk som kun koder til IE, og generelt springer over hvor gærdet er lavest, som også skodder når de laver PHP.
Og ja, hvis disse folk har noget kode som virker i IE og ikke andre steder, benytter de selvfølgelig IE, og hvis deres webhotel ikke understøtter register_globals, flytter de selvfølgelig til et sted der kan køre deres slamkode!!!
men ok det er jo nok de samme folk som kun koder til IE, og generelt springer over hvor gærdet er lavest, som også skodder når de laver PHP.
Og ja, hvis disse folk har noget kode som virker i IE og ikke andre steder, benytter de selvfølgelig IE, og hvis deres webhotel ikke understøtter register_globals, flytter de selvfølgelig til et sted der kan køre deres slamkode!!!
#17
Synes ikke at du skal have lov til at tale så negativt om fritidsprogrammører der ikke har den nødvendige kendskab til PHP til at kunne kode efter sikkerhedsprincipperne.
Den bedste måde at lære PHP på er at prøve sig frem, sådan har jeg lært og jeg vil da gerne erkende at min kode var et stort sikkerhedshul i starten, men ikke destro mindre, så lærte jeg det, kiggede efter hvad andre lavede og så begyndte at tænke mere på sikkerheden.
Synes ikke at du skal have lov til at tale så negativt om fritidsprogrammører der ikke har den nødvendige kendskab til PHP til at kunne kode efter sikkerhedsprincipperne.
Den bedste måde at lære PHP på er at prøve sig frem, sådan har jeg lært og jeg vil da gerne erkende at min kode var et stort sikkerhedshul i starten, men ikke destro mindre, så lærte jeg det, kiggede efter hvad andre lavede og så begyndte at tænke mere på sikkerheden.
#18 (per-d):Den bedste måde at lære PHP på er at prøve sig frem (...)
Det tror jeg simpelthen ikke på! Jeg vil til en hver tid påstå, at det er langt mere effektivt at gå ned og låne/købe en bog og skimme den igennem, og derefter nærlæse den og lave opgaver/udforske mens man læser.
Det tror jeg simpelthen ikke på! Jeg vil til en hver tid påstå, at det er langt mere effektivt at gå ned og låne/købe en bog og skimme den igennem, og derefter nærlæse den og lave opgaver/udforske mens man læser.
#21 - Manden har jo lidt ret.
Betragt det som at køre bil. Du lærer det grundlæggende, men det er da først når du har fået kørekort at du rigtig lærer at kører bil.
Hvis du kan det grundlæggende i php, så er det med at prøve sig frem, og så ellers oparbejde flere og flere rutiner.
Og til Jer der ikke har kørekort... Farmand bliver nok ikke så glad hvis I bare "prøver Jer frem" :-)
Betragt det som at køre bil. Du lærer det grundlæggende, men det er da først når du har fået kørekort at du rigtig lærer at kører bil.
Hvis du kan det grundlæggende i php, så er det med at prøve sig frem, og så ellers oparbejde flere og flere rutiner.
Og til Jer der ikke har kørekort... Farmand bliver nok ikke så glad hvis I bare "prøver Jer frem" :-)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund