Bekijk Volledige Versie : Wordt $_session['var'] client-side of server-side bewaard?
Hoi groep,
Ik heb een inlog systeempje geschreven, na wachtwoord controle wordt
iets als $_SESSION['ip'] aangemaakt. Op alle volgende pagina's
controleerd het script o.a. ($_SESSION['ip'] == $_SERVER['REMOTE_ADDR'])
Opeens overvalt mij de vraag of ik hier een goed contole middel heb of
alleen schijnveiligheid? Na het nodige leeswerk twijfel ik nog steeds of
dat $_SESSION['ip'] op de server bewaard wordt (veilig toch?) of bij de
client, dus te beinvloeden.
De groep kennende kost me deze vraag weer een extra avond studie door
andere aspecten die naar boven komen maar daar wordt ik alleen maar
wijzer van. Bij voorbaat dank dus.
bjorri.
bjorri <no@nl.invalid> wrote:
> Hoi groep,
>
> Ik heb een inlog systeempje geschreven, na wachtwoord controle wordt
> iets als $_SESSION['ip'] aangemaakt. Op alle volgende pagina's
> controleerd het script o.a. ($_SESSION['ip'] == $_SERVER['REMOTE_ADDR'])
>
> Opeens overvalt mij de vraag of ik hier een goed contole middel heb of
> alleen schijnveiligheid? Na het nodige leeswerk twijfel ik nog steeds of
> dat $_SESSION['ip'] op de server bewaard wordt (veilig toch?) of bij de
> client, dus te beinvloeden.
Bij PHP wordt alles van de $_SESSION array op de server opgeslagen
(standaard in bestanden, alhoewel je ook je eigen session handler zou
kunnen schrijven die het bijvoorbeeld in een database opslaat).
De enige informatie die naar de client gaat en weer terugkomt is de
session_id, meestal in een cookie, maar kan ook via GET/POST waardes
worden gepropageerd.
Hecht overigens niet tevaal waarde aan dat REMOTE_ADRR, daar kunnen veel
verschillende gebruikers achter zitten (bijvoorbeeld een bedrijfsnetwerk
of een proxy), en kan ook zo veranderen tijdens een sessie (dynamisch IP).
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Rik wrote:
> bjorri <no@nl.invalid> wrote:
>
>> Hoi groep,
>>
>> Ik heb een inlog systeempje geschreven, na wachtwoord controle wordt
>> iets als $_SESSION['ip'] aangemaakt. Op alle volgende pagina's
>> controleerd het script o.a. ($_SESSION['ip'] == $_SERVER['REMOTE_ADDR'])
>>
>> Opeens overvalt mij de vraag of ik hier een goed contole middel heb of
>> alleen schijnveiligheid? Na het nodige leeswerk twijfel ik nog steeds
>> of dat $_SESSION['ip'] op de server bewaard wordt (veilig toch?) of
>> bij de client, dus te beinvloeden.
>
> Bij PHP wordt alles van de $_SESSION array op de server opgeslagen
> (standaard in bestanden, alhoewel je ook je eigen session handler zou
> kunnen schrijven die het bijvoorbeeld in een database opslaat).
>
> De enige informatie die naar de client gaat en weer terugkomt is de
> session_id, meestal in een cookie, maar kan ook via GET/POST waardes
> worden gepropageerd.
>
> Hecht overigens niet tevaal waarde aan dat REMOTE_ADRR, daar kunnen veel
> verschillende gebruikers achter zitten (bijvoorbeeld een bedrijfsnetwerk
> of een proxy), en kan ook zo veranderen tijdens een sessie (dynamisch IP).
> --Rik Wasmus
> Posted on Usenet, not any forum you might see this in.
> Ask Smart Questions: http://tinyurl.com/anel
OK, dank voor je vlotte antwoord. Ik ben vrijwel geheel gerustgesteld op
dit punt. Bedoelde site heeft een zeer beperkt aantal gebruikers (< 10)
dus is het redelijk onwaarschijnlijk dat iemand onder het zelfde ip gaat
hacken. Een proxy zou ik nog wel rekening mee moeten houden misschien.
Ik heb ondertussen begrepen dat de geldigheidsduur van een sessie is te
beinvloeden, dat is dan nog een aanrader.
Risico is de vermenigvuldiging van kans maal gevolg, in dit geval schat
ik de kans klein en het gevolg zeker niet prettig maar overkomelijk. Het
product is dus aanvaardbaar laag.
Het wijzigen van een ip tijdes eens sessie is dan wat overlast voor een
gebruiker, niet meer dan dat.
Heel hartelijk bedankt voor je toelichting.
bjorri
bjorri <no@nl.invalid> wrote:
> Rik wrote:
>> bjorri <no@nl.invalid> wrote:
>>> Ik heb een inlog systeempje geschreven, na wachtwoord controle wordt
>>> iets als $_SESSION['ip'] aangemaakt. Op alle volgende pagina's
>>> controleerd het script o.a. ($_SESSION['ip'] ==
>>> $_SERVER['REMOTE_ADDR'])
>>>
>>> Opeens overvalt mij de vraag of ik hier een goed contole middel heb of
>>> alleen schijnveiligheid? Na het nodige leeswerk twijfel ik nog steeds
>>> of dat $_SESSION['ip'] op de server bewaard wordt (veilig toch?) of
>>> bij de client, dus te beinvloeden.
>> Bij PHP wordt alles van de $_SESSION array op de server opgeslagen
>> (standaard in bestanden, alhoewel je ook je eigen session handler zou
>> kunnen schrijven die het bijvoorbeeld in een database opslaat).
>> De enige informatie die naar de client gaat en weer terugkomt is de
>> session_id, meestal in een cookie, maar kan ook via GET/POST waardes
>> worden gepropageerd.
>> Hecht overigens niet tevaal waarde aan dat REMOTE_ADRR, daar kunnen
>> veel verschillende gebruikers achter zitten (bijvoorbeeld een
>> bedrijfsnetwerk of een proxy), en kan ook zo veranderen tijdens een
>> sessie (dynamisch IP).
>
> OK, dank voor je vlotte antwoord. Ik ben vrijwel geheel gerustgesteld op
> dit punt. Bedoelde site heeft een zeer beperkt aantal gebruikers (< 10)
> dus is het redelijk onwaarschijnlijk dat iemand onder het zelfde ip gaat
> hacken. Een proxy zou ik nog wel rekening mee moeten houden misschien.
> Ik heb ondertussen begrepen dat de geldigheidsduur van een sessie is te
> beinvloeden, dat is dan nog een aanrader.
>
> Risico is de vermenigvuldiging van kans maal gevolg, in dit geval schat
> ik de kans klein en het gevolg zeker niet prettig maar overkomelijk. Het
> product is dus aanvaardbaar laag.
>
> Het wijzigen van een ip tijdes eens sessie is dan wat overlast voor een
> gebruiker, niet meer dan dat.
Waarom zou je eigenlijk controleren op IP voor iets anders dan
statistieken?
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Rik <luiheidsgoeroe@hotmail.com> wrote:
> bjorri <no@nl.invalid> wrote:
>> Rik wrote:
>> Het wijzigen van een ip tijdes eens sessie is dan wat overlast voor een
>> gebruiker, niet meer dan dat.
>
> Waarom zou je eigenlijk controleren op IP voor iets anders dan
> statistieken?
& iets anders dan daadwerkelijk maar enkele IP's toestaan/bannen
natuurlijk :-)
Ik controleer wel het IP bij inlogpogingen, met een tijdelijke ban na
teveel mislukkingen, en ik log het bij eventuele veranderingen voor
bijvoorbeeld een mogelijke abusemelding. Is echter iemand eenmaal ingelogd
dan blijft deze ook ingelogd als het IP wijzigd.
In het stateless HTTP protocol heeft vaste ip's aan sessie's koppelen erg
weinig zin. Ook is het trouwens zo dat als je het koppelt aan IP het in
Nederland via de meeste providers wel goed gaat, maar heb je bijvoorbeeld
AOL gebruikers uit de VS hebben die vaak bij elk request een ander IP
(maken geloof ik gebruik van dynamische proxies oid). Niet dat ik denk dat
dat een goede zaak is, maar het zou dus zo kunnen dat een provider van een
van je gebruikers op hun manier van werken overstapt, en dan mag je de
boel gaan reparen...
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Rik schreef:
> bjorri <no@nl.invalid> wrote:
>> Rik wrote:
>>> bjorri <no@nl.invalid> wrote:
>>
>> Het wijzigen van een ip tijdes eens sessie is dan wat overlast voor
>> een gebruiker, niet meer dan dat.
> Waarom zou je eigenlijk controleren op IP voor iets anders dan
> statistieken?
Als iemand je cookies jat is het wel handig als je op ip+cookie checkt.
Geef mij een website waar ik javascript kan injecteren en je hebt meteen
toegang tot iedereens account :-)
--
Arjen
http://www.hondenpage.com - Mijn site over honden
Arjen <dont@mail.me> wrote:
> Rik schreef:
>> bjorri <no@nl.invalid> wrote:
>>> Rik wrote:
>>>> bjorri <no@nl.invalid> wrote:
>>>
>>> Het wijzigen van een ip tijdes eens sessie is dan wat overlast voor
>>> een gebruiker, niet meer dan dat.
>> Waarom zou je eigenlijk controleren op IP voor iets anders dan
>> statistieken?
>
> Als iemand je cookies jat is het wel handig als je op ip+cookie checkt.
> Geef mij een website waar ik javascript kan injecteren en je hebt meteen
> toegang tot iedereens account :-)
Een paar overwegingen:
- Zoals eerder vermeld kan een IP veranderen. Ik zou niet zo'n site voor
de huidige AOL'ers in Amerika maken, zowat bij elke page-refresh weer
uitgelogd.
- Als je javascript kan injecteren, dan is er al iets anders grondig fout
aan de website. De rest is nutteloos lapwerk.
- Als je geen SSL gebruikt voor beveiligde pagina dan vraag je om
session-hijacking.
- "Laat mij ingelogd"-opties zijn funest, ik leg altijd uit waarom ik daar
niet aan doe.
- Laat maar 1 iemand onder een account ingelogd. De laatste die het
wachtwoord juist heeft doorgestuurd logt altijd een ander uit die onder
dezelfde crenbdentials werkt.
- Een IP-verandering kan je best loggen, voor een evntuele latere
abuse-melding.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Arjen wrote:
> Rik schreef:
>> bjorri <no@nl.invalid> wrote:
>>> Rik wrote:
>>>> bjorri <no@nl.invalid> wrote:
>>> Het wijzigen van een ip tijdes eens sessie is dan wat overlast voor
>>> een gebruiker, niet meer dan dat.
>> Waarom zou je eigenlijk controleren op IP voor iets anders dan
>> statistieken?
>
>
> Als iemand je cookies jat is het wel handig als je op ip+cookie checkt.
> Geef mij een website waar ik javascript kan injecteren en je hebt meteen
> toegang tot iedereens account :-)
>
Laat ik dan een iets concreter iets vragen.
Ik heb dus een site waarvan ik er even uit ga dat de wachtwoord
verificatie redelijk waterdicht is. Na de wachtwoord check creeer ik een
session variabele waarmee ik op elke volgende pagina check wie er is
ingelogd. Als de variabele niet bestaat of onzin bevat dan
{header("Location: index.php")} om alsnog een wachtwoord in te vullen.
Gezien het beperkte aantal gebruikers hou ik niet echt rekening met hack
pogingen van binnenuit. Alleen het inlogscherm beveilig ik zo sterk
mogelijk. Ik moet er dan natuurlijk wel van uit kunnen gaan dat iemand
ook werkelijk via de inlog is binnengekomen.
Op mijn gevoel, zonder te kunnen beredeneren twijfel aan de veiligheid
van die sessievariabele dus vandaar de extra variabele met ip en
controle of het volgende request van hetzelfde ip af komt.
vraag 1 is dus: Ben ik er wel met slechts die ene (simpele) sessie
variabele?
Zo nee, in welke richting moet ik het dan zoeken.
Hm, een van de twee anti 'brute force' beveiligingen werkt ook op basis
van ip, dat heeft dus weinig meerwaarde begrijp ik. Kan ik dus ook beter
ombouwen naar wat anders.
Beiden bedankt voor het meedenken.
bjorri.
> Een paar overwegingen:
> - Zoals eerder vermeld kan een IP veranderen. Ik zou niet zo'n site voor
> de huidige AOL'ers in Amerika maken, zowat bij elke page-refresh weer
> uitgelogd.
> - Als je javascript kan injecteren, dan is er al iets anders grondig
> fout aan de website. De rest is nutteloos lapwerk.
> - Als je geen SSL gebruikt voor beveiligde pagina dan vraag je om
> session-hijacking.
> - "Laat mij ingelogd"-opties zijn funest, ik leg altijd uit waarom ik
> daar niet aan doe.
> - Laat maar 1 iemand onder een account ingelogd. De laatste die het
> wachtwoord juist heeft doorgestuurd logt altijd een ander uit die onder
> dezelfde crenbdentials werkt.
> - Een IP-verandering kan je best loggen, voor een evntuele latere
> abuse-melding.
Allemaal helemaal waar ! Maar alleen punt 1 vind ik echt een overweging
om geen ip te koppelen aan je login gegevens.
Bij de rest conflicteert het niet. Ik werk zelf vaak met veel
verschillende rollen waarbij rollen met het zwaarste gewicht ook nog
eens aan ip worden gekoppeld, kortere levensduur hebben etc etc.
En javascript injecteren is soms niet te voorkomen. Ik kan 100 dingen
dichtzetten maar als je echt wil kom je er wel met het 101e lek doorheen :-(
--
Arjen
http://www.hondenpage.com - Mijn site over honden
bjorri <no@nl.invalid> wrote:
> vraag 1 is dus: Ben ik er wel met slechts die ene (simpele) sessie
> variabele?
> Zo nee, in welke richting moet ik het dan zoeken.
Je beviliging hangt in dat geval niet echt af van die sessie-variabele (ik
neem aan dat je register_globals uit hebt staan), maar van de sessie_id.
Zolang die lang genoeg is, en _alleen_ verstuurd wordt over SSL
verbindingen zit je redelijk OK.
> Hm, een van de twee anti 'brute force' beveiligingen werkt ook op basis
> van ip, dat heeft dus weinig meerwaarde begrijp ik. Kan ik dus ook beter
> ombouwen naar wat anders.
Wel, aan anti 'brute force' check op ip (als in een ip (tijdelijk) blocken
na teveel mislukte inlogpogingen is juist _wel_ een goed idee. Alhoewel
een echte brute force attack honderden zo niet duizenden verschillende
IP's zal gebruiken, schrikt het toch wel wat af als je met 1 ip maar 3
keer per kwartier oid kan proberen in te loggen in plaats van honderden
keren.
Absolute beveiliging bestaat niet naast je server van het net halen (en
zelfs dan, inbrekers...). Er is een duidelijke reden dat bijvoorbeeld
banken nadat je bent ingelogd voor internetbankieren nog steeds per
transactie een uniek id vragen dat niet eerder via die internetverbinding
is gestuurd. Het enige wat je kunt doen is het de mogelijke aanvaller zo
lastig en onaantrekkelijk mogelijk maken.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Arjen <dont@mail.me> wrote:
>> Een paar overwegingen:
>> - Zoals eerder vermeld kan een IP veranderen. Ik zou niet zo'n site voor
>> de huidige AOL'ers in Amerika maken, zowat bij elke page-refresh weer
>> uitgelogd.
>> - Als je javascript kan injecteren, dan is er al iets anders grondig
>> fout aan de website. De rest is nutteloos lapwerk.
>> - Als je geen SSL gebruikt voor beveiligde pagina dan vraag je om
>> session-hijacking.
>> - "Laat mij ingelogd"-opties zijn funest, ik leg altijd uit waarom ik
>> daar niet aan doe.
>> - Laat maar 1 iemand onder een account ingelogd. De laatste die het
>> wachtwoord juist heeft doorgestuurd logt altijd een ander uit die onder
>> dezelfde crenbdentials werkt.
>> - Een IP-verandering kan je best loggen, voor een evntuele latere
>> abuse-melding.
>
> Allemaal helemaal waar ! Maar alleen punt 1 vind ik echt een overweging
> om geen ip te koppelen aan je login gegevens.
>
> Bij de rest conflicteert het niet.
Nee, dat waren nog een aantal bonusioverwegingen :P
> Ik werk zelf vaak met veel
> verschillende rollen waarbij rollen met het zwaarste gewicht ook nog
> eens aan ip worden gekoppeld, kortere levensduur hebben etc etc.
Een eerdere timeout op kritieke rechten lijkt me inderdaad geen verkeerd
plan. Net zoals je op je computer normaal niet als root/admin ingelogd
bent, maar dat even doet om een aantal zaken aan te passen en direct
daarna weer doorgaat als normale gebruiker, lijkt me dat bij een kritieke
webinterface ook wel van toepassing. Helaas zijn nog weinig mensen gewend
dit zo te doen.
> En javascript injecteren is soms niet te voorkomen. Ik kan 100 dingen
> dichtzetten maar als je echt wil kom je er wel met het 101e lek doorheen
Hangt er helemaal vanaf van wat er precies moet gebeuren natuurlijk. Geef
gebruikers nooit rechten die ze momenteel niet nodig hebben. Gouden regel
van beveiliging is natuurlijk ook: zet alles dicht, en dan mondjesmaat
weer open totdat je de minimale rechten hebt om de vooraf omschreven taak
uit te voeren.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
> vraag 1 is dus: Ben ik er wel met slechts die ene (simpele) sessie
> variabele?
> Zo nee, in welke richting moet ik het dan zoeken.
Ach het is ergens wel 'redelijk veilig' zolang niemand je sessie id kan
lezen. Als iemand dat wel kan lezen komt dat door een lek ergens anders.
Om dat tegen te gaan (en je zegt zelf dat het maar voor een paar
gebruikers ,waarschijnlijk niet AOL) zou ik het eea toch dicht zetten op
ip nummer (sry Rik we zijn het oneens :-) )
En zoals eerder aangegeven een korte time out.
SSL certificaatje misschien ?
En zorgen dat er geen rechten zijn om rechten te geven :-)
> Hm, een van de twee anti 'brute force' beveiligingen werkt ook op basis
> van ip, dat heeft dus weinig meerwaarde begrijp ik. Kan ik dus ook beter
> ombouwen naar wat anders.
Dat ligt er aan ... als het zorgt dat je vanaf 1 ip maar een paar keer
kan proberen is het heel wat anders dan kijken naar combinatie van
sessie id + ip.
>
>
> Beiden bedankt voor het meedenken.
>
> bjorri.
--
Arjen
http://www.hondenpage.com - Mijn site over honden
Arjen <dont@mail.me> wrote:
>> vraag 1 is dus: Ben ik er wel met slechts die ene (simpele) sessie
>> variabele?
>> Zo nee, in welke richting moet ik het dan zoeken.
>
> Ach het is ergens wel 'redelijk veilig' zolang niemand je sessie id kan
> lezen. Als iemand dat wel kan lezen komt dat door een lek ergens anders.
>
> Om dat tegen te gaan (en je zegt zelf dat het maar voor een paar
> gebruikers ,waarschijnlijk niet AOL) zou ik het eea toch dicht zetten op
> ip nummer (sry Rik we zijn het oneens :-) )
Tja, ik maak meestel generieke systemen, die zo goed als overal (met
natuurlijk een paar vereisten) toepasbaar moeten zijn. Als dit een ad hoc
oplossing is voor een beperkt aantal gebruikers, waarvan zeker is dat deze
de hele sessie hetzelfde IP houden, kun je die check wel doorvoeren. Mijn
antwoord ging meer over het algemene principe.
> SSL certificaatje misschien ?
Lijkt mij geen misschien maar een must om session-hijacking te voorkomen.
Hoeft ook niets te kosten: een self-signed certificate is prima, zolang je
gebruikers je maar vertrouwen en de pop-up van de browser dat het niet van
een vertrouwde bron komt niet deert.
>> Hm, een van de twee anti 'brute force' beveiligingen werkt ook op basis
>> van ip, dat heeft dus weinig meerwaarde begrijp ik. Kan ik dus ook beter
>> ombouwen naar wat anders.
>
> Dat ligt er aan ... als het zorgt dat je vanaf 1 ip maar een paar keer
> kan proberen is het heel wat anders dan kijken naar combinatie van
> sessie id + ip.
Inderdaad, van hetzelfde ip meerdere mislukte inlogpogingen kan nauwelijks
toeval zijn, niets mis mee om daar wel een check op uit te voeren.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Rik wrote:
> Arjen <dont@mail.me> wrote:
>> bjorri wrote:
>>> Ben ik er wel met slechts die ene (simpele) sessie
>>> variabele?
>>
>> Ach het is ergens wel 'redelijk veilig' zolang niemand je sessie id kan
>> lezen. Als iemand dat wel kan lezen komt dat door een lek ergens anders.
>>
<<>>
>> SSL certificaatje misschien ?
>
OK, ga ik uitzoeken. Goed advies.
> Lijkt mij geen misschien maar een must om session-hijacking te
> voorkomen.
>
Wordt mn volgende studie object, session hijacking. Kan ik een afweging
maken of dat certificaat echt nodig is.
<<>>
>
> Inderdaad, van hetzelfde ip meerdere mislukte inlogpogingen kan
> nauwelijks toeval zijn, niets mis mee om daar wel een check op uit te
> voeren.
OK, ik laat het lekker staan.
> Ask Smart Questions: http://tinyurl.com/anel
Met belangstelling (deels) gelezen. Helder en waar verhaal, soms een
beetje arrogant maar dat vermeld het verhaal zelf ook al.
Mannen bedankt, weer een hoop geleerd vandaag.
bjorri.
bjorri <no@nl.invalid> wrote:
>> Ask Smart Questions: http://tinyurl.com/anel
>
> Met belangstelling (deels) gelezen. Helder en waar verhaal, soms een
> beetje arrogant maar dat vermeld het verhaal zelf ook al.
Joah, die arrogantie daar sta ik niet helemaal achter, maar verder een
zeer nuttig verhaal voor dat soort mensen die threads openen met als
subject 'URGENT: PLEASE HELP', met een extreem googlebaar antwoord :-)
Hier in NIWS niet echt last van, in bijvoorbeeld alt.html &
comp.lang.javascript is het af en toe om te huilen.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
On Fri, 09 Mar 2007 12:24:47 +0100, bjorri <no@nl.invalid> wrote:
> Arjen wrote:
>> Rik schreef:
>>
>> Als iemand je cookies jat is het wel handig als je op ip+cookie checkt.
>> Geef mij een website waar ik javascript kan injecteren en je hebt meteen
>> toegang tot iedereens account :-)
>>
> Laat ik dan een iets concreter iets vragen.
>
> Op mijn gevoel, zonder te kunnen beredeneren twijfel aan de veiligheid
> van die sessievariabele dus vandaar de extra variabele met ip en
> controle of het volgende request van hetzelfde ip af komt.
Als je dat doet houd dan iig rekening met de X_FORWARDED_FOR die transparante
proxies soms mee geven. Let daarbij op dat niet alle proxies dat doen.
>
> vraag 1 is dus: Ben ik er wel met slechts die ene (simpele) sessie
> variabele?
> Zo nee, in welke richting moet ik het dan zoeken.
Naast de controle kun je bij elke pagina de session reregisteren, ze
krijgen dan een nieuwe session id. Mocht je perongelijk transparantie
sessies draaien dan voorkom je iig dat ze makkelijk een sessie hijacken.
Knal daarnaast bijvoorbeeld een check op de user agent in diezelfde controle.
Hans
--
IM: hans.wolters@jabber.xs4all.nl
http://lonki.xs4all.nl
On Fri, 09 Mar 2007 13:25:50 +0100, Arjen <dont@mail.me> wrote:
> En javascript injecteren is soms niet te voorkomen. Ik kan 100 dingen
> dichtzetten maar als je echt wil kom je er wel met het 101e lek doorheen :-(
Als je goed weet wat mensen kunnen submitten en daar checks voor hebt
kun je alleen nog xss bugs tegen komen in lekke meuk zoals een pagina
met phpinfo(). Zoek maar op de Month Of PHP Bugs die nu loopt.
Hans
--
IM: hans.wolters@jabber.xs4all.nl
http://lonki.xs4all.nl
Hans schreef:
> On Fri, 09 Mar 2007 13:25:50 +0100, Arjen <dont@mail.me> wrote:
>
>> En javascript injecteren is soms niet te voorkomen. Ik kan 100 dingen
>> dichtzetten maar als je echt wil kom je er wel met het 101e lek doorheen :-(
>
> Als je goed weet wat mensen kunnen submitten en daar checks voor hebt
> kun je alleen nog xss bugs tegen komen in lekke meuk zoals een pagina
> met phpinfo(). Zoek maar op de Month Of PHP Bugs die nu loopt.
Hebbut gezien idd. Ik moet alleen de 1e pagina die helemaal dicht staat
nog tegenkomen.
--
Arjen
http://www.hondenpage.com - Mijn site over honden