Er sikkerheten på uniweb.no bra ?

[willbend]

Uniweb.no hoster en webside jeg har. Jeg lasta opp et php shell(samme som ssh tilgang) og fant ut at jeg kunne bla meg oppover ../ og ned igjen til andre hjemmesider. Jeg fant ut at bl.a. http://xxxxx.com/administrator/ også var hostet av uniweb.no, og jeg kunne bare skrive "cat configurasjon.php", så så jeg passordet til databasen.

 

Hva er dette forno ?

[Vindstille]

Vis dette er tilfellet er sikkerheten absolutt ikke bra.

Prøv å varsl Uniweb.no om sikkerhetshullet. Vis feilen ikke blir rettet opp i løpet av en dag bør du vurdere å bytte leverandør.

[willbend]

Her fant jeg noe som forklarer hva som er problemet http://lkonsult.no/artikler/php-delte-servere

De må i såfall aktivere safe_mode, og det er jo egentlig ganske drastisk.

Endret 7. juli 2006 av willbend

[xqus]

Vel, man MÅ ikke aktivere safe_mode. PHP har noe som heter base_dir også, som begrenser tilgangen for PHP filer, slik at man ikke kan gå uten for sit eget hjemmeområde.

[AudunSæther]

Uniweb.no hoster en webside jeg har. Jeg lasta opp et php shell(samme som ssh tilgang) og fant ut at jeg kunne bla meg oppover ../ og ned igjen til andre hjemmesider. Jeg fant ut at bl.a. http://xxxxx.com/administrator/ også var hostet av uniweb.no, og jeg kunne bare skrive "cat configurasjon.php", så så jeg passordet til databasen.

6449284[/snapback]

Uniweb burde straks varsles, men jeg anbefaler deg at du fra nå av ikke poster ut her nøyaktig hvilke sikkerhetshull du har funnet. Den eneste som trenger å vite det er Uniweb, ikke hele HW.no.

[uniweb]

Uniweb.no hoster en webside jeg har. Jeg lasta opp et php shell(samme som ssh tilgang) og fant ut at jeg kunne bla meg oppover ../ og ned igjen til andre hjemmesider. Jeg fant ut at bl.a. http://xxxxx.com/administrator/ også var hostet av uniweb.no, og jeg kunne bare skrive "cat configurasjon.php", så så jeg passordet til databasen.

6449284[/snapback]

Uniweb burde straks varsles, men jeg anbefaler deg at du fra nå av ikke poster ut her nøyaktig hvilke sikkerhetshull du har funnet. Den eneste som trenger å vite det er Uniweb, ikke hele HW.no.

6464371[/snapback]

 

Vi kan ikke gjøre annet enn å beklage det inntrufne på det sterkeste. Feilen ble imidlertid tettet etter svært kort tid og var for øvrig temporær (oppstod i forbindelse med diverse omlegginger på én av våre webservere).

[xibriz]

Jeg puster liv i denne tråden pga. at jeg ikke er overbevist om at sikkerheten til Uniweb er holdbar.

 

Jeg har nettopp lagt merke til at hvis man bruker "Glemt passord"-funksjonen på hjemmesidene deres sender de meg mitt selvlagde passord i klartekst. De genererer altså ikke noe nytt passord.

 

I kontrollpanelet på hjemmesiden står også passordet mitt i klartekst.

 

Da er det 2 alternativer:

1. Det er ikke kryptert

2. Det er en toveis kryptering

 

Hvis punkt 1. stemmer bytter jeg leverandør ASAP.

 

Hvis punkt 2. stemmer burde de ikke vise passordet i tide å utide.

 

Jeg har sendt de en forespørsel på e-post om dette, og hvis jeg ikke får noe tilfredstillende svar bytter jeg domeneleverandør i løpet av neste uke.

[Gjest Slettet+432]

Skandale! Aner du hvor mange som gjør det? Inkludert systemer som phpBB... Det er bare å la være å glemme passordet, det.

[nomore]

Problemet er ikke bare at passordet blir sendt til deg i klartekst, men at passordet blir lagret i klartekst i databasen. Eg for min del er veldig klar over hvor vanlig det er, og er utrolig skuffet over utviklere som ikke tar seg tiden til noe så enkelt som MD5(passord). Eller SHA1(passord). Nå er eksemplene mine rettet mot PHP, men det har blitt, i de siste 5-6 årene, minst like enkelt i de fleste språk.

[xibriz]

Skandale! Aner du hvor mange som gjør det? Inkludert systemer som phpBB... Det er bare å la være å glemme passordet, det.

 

Det er faktisk skandale når noen jeg betror passordet mitt til ikke tar vare på det å lagrer det i klartekst.

 

Fikk foresten svar:

 

Du har rett, dette er ukurant håntering av passord, og vi kan bare beklage dette. Deler av kundesystemet vårt er av eldre dato og vi jobber med å bytte ut og forbedre bl.a. passordhåntering på dette, og vil naturligvis benytte oss av md5 eller liknenede kryptering av passord når vi får byttet denne koden ut.

 

Blir ikke imponert om de slenger en MD5 hash på passordet heller.