Onderwerp: AJAX veiligheid

Er zijn ook genoeg firewalls die http referer niet doorgeven dus dan werkt je applicatie niet meer.

firewalls van clients? of de firewalls van het netwerk waar je in zit?

Let wel op dat dit absoluut geen beveiliging is.

http://en.wikipedia.org/wiki/Security_through_obscurity

Oorspronkelijk geplaatst door ebhosting

Triloxigen > klopt, maar waar het me om gaat, is dat er niet via de url script.php?var=val ingevoerd wordt. Als je dan daarbij referer check doet ben je toch rond? of mis ik iets..

Ja, referers zijn aan te passen en er zijn ook gebruikers met Norton Internet Security en dat soort pakketten die geen referers doorsturen.
https://addons.mozilla.org/en-US/firefox/addon/4513

Oorspronkelijk geplaatst door Ramon Fincken

ja Maarten ik mis ook iets denk ik ... kijk dat je zelf POST (headers) kunt maken/spoofen ok prima, maar dat is toch net ietsje meer werk dan alle GET's uitlezen en gewoon die url bezoeken ..

Iedereen die een FF addon kan gebruiken kan een post eenvoudig maken;
https://addons.mozilla.org/en-US/firefox/addon/1290


(en dan heb ik het niet eens over geavanceerdere methodes zoals html, curl, etc)

Het is gewoon een beveiliging van 0, het maakt niet uit of het een beetje onveilig is of heel erg onveilig. Onveilig is onveilig of er nou 1 vekeerd iemand in kan of 1.000.000, dat maakt in feite niks uit.

Je kunt altijd de generated-source opvragen van een website. Altijd. Desnoods met FireBug waarbij je de requests en de bijbehorende headers met gemak uitleest...

Daarnaast; WAAROM zou je willen dat mensen je code niet kunnen zien?

Daarnaast; WAAROM zou je willen dat mensen je code niet kunnen zien?

de vraag was om niet de code maar de url van de request file te verbergen

Oorspronkelijk geplaatst door Ramon Fincken

de vraag was om niet de code maar de url van de request file te verbergen

Daarnaast; WAAROM zou je de url van de request file willen verbergen?

ik heb geen idee, is me aan de hand van bovenstaande replies ook niet duidelijk geworden

Het ging mij erom dat die files niet zichtbaar werden voor het geval dat je een programmeer fout hebt gemaakt, waardoor een lek zou ontstaan. Wanneer iemand dan de files ook niet zien kan/ benaderen dan heb je wel een lek, alleen word dat opgevangen doro het blokeren van de files

zolang PHP niet als txt word gezien zou dat geen probleem moeten zijn (maar dat is een apache iets .. ), errors kun je ook opvangen en laten mailen / in txt file schrijven

1.) Javascript is client-side code, hierdoor is het net zo onmogelijk je javascript te verbergen als je html te verbergen.
2.) Als er een (ajax) request gemaakt wordt is dat door plugins als firebug altijd uit te lezen.
3.) Als je je code goed schrijft hoeft dit geen probleem te zijn.
4.) "Security trough obscurity" is geen goede manier om je applicatie te beveiligen (http://en.wikipedia.org/wiki/Security_through_obscurity)

Wat je eventueel kan doen is je javascript packen,.. zijn zat tooltjes voor op het internet (het maakt je script code moeilijk leesbaar maar vooral kleiner)

Sowieso zal je alle REQUESTS die naar je script toe komen moeten controleren, en zolang niemand je PHP/MySQL code kan zien,,,, geen probleem toch!

Als je je posts (forms/ajax/...) veiliger wil maken, dan dien je even te kijken naar "tokens". Deze zorgen ervoor dat je je form niet kan submitten als je niet eerst data gekregen hebt van je scripts op die server.

Het niet zien van de broncode van je php-bestand dat de ajax call afhandelt heeft quasi niets te maken met programmeertalent, maar alles met systeembeheer. Het enige wat de programmeur moet doen, is ervoor zorgen dat het script dat publiek staat, geen gevoelige info bevat, maar dit include uit een map die niet binnen de docroot staat.

Alle andere dingen zijn lapmiddelen en gaat je enkel tegenwerken.

Maar een bestand dat niet binnen de docroot staan is ook maar quasi veilig. Als het vanaf een andere PHP bestand benaderd kan worden kan het ook uitgelezen en geprint worden.

Er bestaan ook bepaalde applicaties die je javascript code "crushen", ofwel onleesbaar maken. Dit is uiteraard geen echte beveiliging, want het is ook weer om te keren met bepaalde applicaties. Maar het maakt het wel lastiger.