Archief - php: Help met security bug (beveiligde pagina als afbeelding)

Squealer · 27 jul 2004

Zit met soort security bug in mijn site

Ik heb een community site waar iedereen o.a. kan posten en reageren, en zijn eigen reacties kan wijzigen/deleten.

Tprobleem is:

als iemand de "reactie delete" link gebruikt als avatar of afbeelding ergens anders op internet, en de persoon die auteur van die reactie is, komt die afbeelding tegen, verwijdert hij zijn eigen reactie zonder dat hij het weet ..... De afbeelding zal dus niet gevonden worden, maar er zal wel een request gegenereerd worden naar de "reactie delete" pagina....

Hoe kan ik dit voorkomen?

edit: sorry voor eventueel verkeerde prefix, weet niet wat het juist moet zijn in mijn geval....

servi · 27 jul 2004

kan je dat eens met een gedetailleerd voorbeeld verduidelijken, want nu lijkt die vraag me heel bizzar.

/\quila · 27 jul 2004

Tis vrij duidelijk probleem hoor

.

Het probleem is dat iemand voor zijn avatar eender welk adres kan opgeven. Dit kan tot problemen l(ei/ij)den.

Dus heel makkelijk op te lossen, ge moet namelijk controleren dat het wel degelijk een afbeedling is. Ge moet dus maar bepaalde extenties toelaten, en zeker geen urls/exe's/scripts/...

Grtz

ps. Ge kunt u zelf toch wel schrijven hiervoor eh?

Squealer · 27 jul 2004

servi zei:
kan je dat eens met een gedetailleerd voorbeeld verduidelijken, want nu lijkt die vraag me heel bizzar.

Concreet voorbeeld:

op een post pagina staan meerdere reacties. 1 van die reacties is van mij. Ik kan mijn eigen reacties verwijderen als ik op de delete-knop duw. Die verwijst naar h ttp://www.teletet.org/post/reactieedit.php?RID=1000&PID=500&mode=delete

als IK daarop klik zal reactie 1000 verwijderd worden. Als iemand anders naar die pagina surft zal hij nen error krijgen.

Stel nu dat een kwaadwillend gebruiker die delete-link als avatar gebruikt op een forum. Telkens een topic van dat forum wordt bekeken waar die persoon zijn avatar te zien is, wordt die delete-pagina aangeroepen op de achtergrond.

Als IK nu dat topic zou bekijken, zou mijn reactie verwijderd worden, zonder dat ik het besef, want ik heb nooit op een delete-link geklikt.....

Squealer · 27 jul 2004

/\quila zei:
Tis vrij duidelijk probleem hoor .

Het probleem is dat iemand voor zijn avatar eender welk adres kan opgeven. Dit kan tot problemen l(ei/ij)den.

Dus heel makkelijk op te lossen, ge moet namelijk controleren dat het wel degelijk een afbeedling is. Ge moet dus maar bepaalde extenties toelaten, en zeker geen urls/exe's/scripts/...

Grtz

ps. Ge kunt u zelf toch wel schrijven hiervoor eh?

ja gij zit goed, maar ge begrijpt et toch nog niet helemaal

kzal strx verder replyen, mijn eten wordt koud

/\quila · 27 jul 2004

Ik denk dat het vrij simpel is.
Avatar kan (mag om beveiligingsredenen) nooit iets anders zijn als afbeelding. Dus hoe lossen we dat op, we zetten het in een if:

PHP:

if (file_exists($imgpath) && ($ext=="jpg" OR $ext=="jpeg" OR $ext=="png"))
	{

// Deze code moet ge wel aanpassen aan u behoeften... Ge moet nog $ext toewijzen en $imgpath

Squealer · 27 jul 2004

neenee tis dat niet

het gaat niet om mijn forum of mijn site, die heb ik idd beveiligd door enkel jpg,... als avatar of geposte afbeelding toe te laten.

Het gaat om andere forums/sites die een dergelijke beveiliging niet hebben ingebouwd. Als een kwaadwillend persoon mij zou vragen een pagina te bekijken en op die pagina staat in de bron code:

Code:

<img src="http://www.teletet.org/post/reactieedit.php?RID=1000&PID=500&mode=delete">

dan heb ik een van mijn eigen reacties verwijderd zonder dat ik dat wou.

Der zijn nog zo zaken op mijn site die op de zelfde manier kunnen misbruikt worden (bv: een moderator vragen een pagina te bekijken en hupla, ne hele post gedelete zonder dat de moderator het weet....)

servi · 27 jul 2004

dan moet je zelf een verdedigingsmechanisme uitbouwen hé.

je moet in reactieedit.php dan de referrer controleren, of je kan ook gewoon een eenvoudige confirmatiebox laten verschijnen, waardoor gebruikers dus wel weten dat ze iets zouden gaan verwijderen.

Squealer · 27 jul 2004

servi zei:
dan moet je zelf een verdedigingsmechanisme uitbouwen hé..

daarom dat ik hier hulp vroeg

servi zei:
je moet in reactieedit.php dan de referrer controleren, of je kan ook gewoon een eenvoudige confirmatiebox laten verschijnen, waardoor gebruikers dus wel weten dat ze iets zouden gaan verwijderen.

$HTTP_REFERER is niet altijd correct

die confirmatiebox:
in de code kunde gemakkelijk zien waar ge naartoe wordt gestuurd als ge op "OK" zou klikken. Die kwaadwillende persoon gebruikt dan gewoon die link als avatar..... zo wordt er geen confirmatie meer gevraagd.....

servi · 27 jul 2004

$HTTP_REFERER is niet altijd correct

moet je me toch eens een voorbeeld tonen waar het niet correct is,zelfs dan nog als het er niet goed uitzie weiger je dat gewoon.

Squealer · 27 jul 2004

servi zei:
$HTTP_REFERER is niet altijd correct

moet je me toch eens een voorbeeld tonen waar het niet correct is,zelfs dan nog als het er niet goed uitzie weiger je dat gewoon.

heb die methode al geprobeerd.

Iemand gaf als avatar de link op naar de pagina waar score's van een post worden verwerkt, met als score parameter in de url: 100%. Iedereen die die avatar zag, gaf automatisch die post een score van 100%.
Heb dat proberen oplossen door via $HTTP_REFERER te controleren of de gebruiker wel afkomstig was van de post pagina. Dat werkte bij mij, maar geleidelijk aan kwamen meldingen binnen van problemen met het rating-systeem. Na wat research kwam ik te weten dat $HTTP_REFERER problemen kan hebben met proxy's en clientside kan aangepast worden naar om het even welke waarde

=>> useless

/\quila · 27 jul 2004

Werken met temp cookies.

2 pagina's (desnoods laatste popup)
-----------------------------------
1 ste pagina bevat code om een cookie te setten en random string in database te zetten. In de/het cookie stopt ge overbodige rommel, bijvoorbeeld een random string van een bepaalde groote, en daarna stopt ge de random string die ook in de database komt.
2 de pagina bevat dan code om het cookie uit te lezen, en de waardevolle string eruit te halen (gewoon vanaf een bepaald teken de string verder gebruiken), en deze tevens te vergelijken met de db. Indien beide overeen komt, mag de post verwijderd worden, EN verwijdert ge u entry uit u database.

Pagina 1 mag dus ook geen redirecting doen.

Dit systeem zou bijna niet te kraken moeten zijn. Ge kunt het nog extremer gaan maken, ge kunt nog sessies en gets er bij gaan doen, maar dat kan wel overkill worden.

ps, is de spelling van verwijderen correct? d/t/dt?

Squealer · 27 jul 2004

/\quila zei:
Werken met temp cookies.

2 pagina's (desnoods laatste popup)
-----------------------------------
1 ste pagina bevat code om een cookie te setten en random string in database te zetten. In de/het cookie stopt ge overbodige rommel, bijvoorbeeld een random string van een bepaalde groote, en daarna stopt ge de random string die ook in de database komt.
2 de pagina bevat dan code om het cookie uit te lezen, en de waardevolle string eruit te halen (gewoon vanaf een bepaald teken de string verder gebruiken), en deze tevens te vergelijken met de db. Indien beide overeen komt, mag de post verwijderd worden, EN verwijdert ge u entry uit u database.

Pagina 1 mag dus ook geen redirecting doen.

Dit systeem zou bijna niet te kraken moeten zijn. Ge kunt het nog extremer gaan maken, ge kunt nog sessies en gets er bij gaan doen, maar dat kan wel overkill worden.

ps, is de spelling van verwijderen correct? d/t/dt?

ja uw spelling is goed

waarom mag pagina 1 geen redirecting doen?

Pagina 1 = bevestigings pagina: schrijft random string naar cookie en db.
Klik op "JA - verwijder deze post" => Pagina 2; verwijder query, delete cookie en db waarde, redirect naar post pagina
Klik op "Nee - ga terug" = > Pagina 2; maar zonder verwijder query

zoiets?

/\quila · 27 jul 2004

Pagina 1 vraagt voor bevestiging van de verwijdering. Ge moet dus zorgen dat de gebruiker op Ja klikt. (Anders heeft het geen nut, want dan zijn de strings natuurlijk overeenkomstig, daarom ook geen redirecting.)
Indien gebruiker op Ja klikt, gaat ge dus heel de bleh van db en cookie doen, MAAR er wordt niks verwijdert in de database.
De gebruiker wordt nu dus doorverwezen naar pagina twee, waar de strings worden gecontroleerd. (De string is enkel aanwezig beide in cookie en db indien de gebruiker pagina 1 heeft bezocht)
Indien strings db en cookie overeenkome, DAN pas verwijdering uit de db van string en van de post/... en het verwijderen van de cookie...

Duidelijk? Anders maak ik stroomschema of zow

Squealer · 27 jul 2004

/\quila zei:
Pagina 1 vraagt voor bevestiging van de verwijdering. Ge moet dus zorgen dat de gebruiker op Ja klikt. (Anders heeft het geen nut, want dan zijn de strings natuurlijk overeenkomstig, daarom ook geen redirecting.)
Indien gebruiker op Ja klikt, gaat ge dus heel de bleh van db en cookie doen, MAAR er wordt niks verwijdert in de database.
De gebruiker wordt nu dus doorverwezen naar pagina twee, waar de strings worden gecontroleerd. (De string is enkel aanwezig beide in cookie en db indien de gebruiker pagina 1 heeft bezocht)
Indien strings db en cookie overeenkome, DAN pas verwijdering uit de db van string en van de post/... en het verwijderen van de cookie...

Duidelijk? Anders maak ik stroomschema of zow

jama..... zit gij nu te zeggen dat de cookie en de waarde in den db pas mogen geplaatst worden NADAT de gebruiker op JA heeft geklikt??? Awel de enigste manier daarvoor is redirecten, want ge kunt niets meer naar uw database of cookie wegschrijven als ge al op de pagina zit....

/\quila · 27 jul 2004

My bad, slecht uigelegd. Ik bedoel dat de gebruiker input MOET geven, en dat er niet zomaar mag worden redirected.

Hopelijk verduidelijkt dit wat:
Stroomschema Dit is wel niet zoals het echt moet, maar heb mn best gedaan om het correct te doen.

Grtz
Nu ben ik slapen, moet morgen vroeg uit de veren.

Squealer · 27 jul 2004

/\quila zei:
My bad, slecht uigelegd. Ik bedoel dat de gebruiker input MOET geven, en dat er niet zomaar mag worden redirected.

Hopelijk verduidelijkt dit wat:
Stroomschema Dit is wel niet zoals het echt moet, maar heb mn best gedaan om het correct te doen.

Grtz
Nu ben ik slapen, moet morgen vroeg uit de veren.

thx, maar zoals ik al zei: gij wilt die random string laten aanmaken, in db en in cookie steken nadat de gebruiker op JA klikt, en nog voor de pagina redirect.
Dat gaat niet. Een klik op JA kan onmogelijk de database aansturen en hem een random waarde laten wegschrijven omdat db serverside is. Ook een cookie wegschrijven kan zo niet omdat de headers reeds verstuurd zijn naar de browser.
Dat kan pas als een nieuwe pagina wordt geladen: enkel tijdens de verwerking van de .php pagina op de server kan de php parser de database bezigen en enkel voor er output naar de browser wordt gestuurd, kunnen cookies geplaatst worden

servi · 27 jul 2004

dat kan je eenvoudig doen door gebruik te maken van javascript.
En als dat uit den boze is, gewoon een link zetten waar ze op kunnen klikken.

overigens hoef je niet per se een cookie te zetten (maar het moet nog wel bewaard worden in de database), je kan het ook gewoon doorgeven als volgt :

http://www.site.be/pagina.php?hash=random_string

vermits het een random string is kan de persoon met verkeerde bedoelingen niet anticiperen op de url die daar moet komen en zo spaar je dan toch een cookie uit.

/\quila · 28 jul 2004

Inderdaad, toen ik in mn bed der nog over lag te piekeren had ik ook door dat dit niet ideaal was

.
Dan zou ik het zoals servi voorstelt met get's werken.
of
Momenteel werkt ge eigenlijk met 3 pagina's waarvan ik de laatste twee heb besproken, maar ge kunt eigenlijk het setten v cookie en db storage 1 pagina vervroegen, zodat het wel lukt met u headers etc.

servi · 28 jul 2004

Inderdaad, toen ik in mn bed der nog over lag te piekeren had ik ook door dat dit niet ideaal was .

hehe, komt me bekend voor, zeer vervelend zoiets

Archief - php: Help met security bug (beveiligde pagina als afbeelding)

Squealer

Legacy Member

servi

Legacy Member

/\quila

Legacy Member

Squealer

Legacy Member

Squealer

Legacy Member

/\quila

Legacy Member

Squealer

Legacy Member

servi

Legacy Member

Squealer

Legacy Member

servi

Legacy Member

Squealer

Legacy Member

/\quila

Legacy Member

Squealer

Legacy Member

/\quila

Legacy Member

Squealer

Legacy Member

/\quila

Legacy Member

Squealer

Legacy Member

servi

Legacy Member

/\quila

Legacy Member

servi

Legacy Member