[AJAX] AJAX + Greasemonkey. Veilig?

[Arcane Apex]

Ik vroeg mij af of greasemonkey problemen kan geven mbt AJAX.
Met AJAX is het namelijk mogelijk om mbv Javascript data aan te roepen welke op de server staat. Maar stel nou dat iemand een javascript greasemonkey script toevoegt aan een AJAX pagina op internet.
Kan deze persoon dan data opvragen van de server mbv de AJAX elementen van die webpagina?
Of werkt dat opvragen van data via AJAX alleen aan de server-side ook al is Javascript over het algemeen een client-side script?

[Cartman!]

Jemig...ik vind je tekst echt heel onduidelijk geschreven.. Ik heb even opgezocht wat Greasemonkey is en het is blijkbaar een extensie voor Firefox die scripts kan aanmaken op de lokale pc op bepaalde sites om functionaliteiten toe te voegen of juist te fixen.
Ik welk opzich denk je dat dit problemen zal opleveren want ik snap je vraag niet helemaal...

[Swaptor]

Maar ook zonder AJAX is het mogelijk data op te vragen die op de server staat, daar is HTML en HTTP uitermate geschikt voor.
AJAX en aanverwante technieken zijn alleen handig voor het weergeven van de betreffende data zonder volledige screenrefresh, dus ik snap je vraag niet.

[Arcane Apex]

Ok ik zal de vraag opnieuw proberen te stellen.
Stel je hebt de user accounts van je website opgeslagen in een MySQL database of in een XML file.
Met behulp van AJAX zou je als beheerder van de site die data kunnen weergeven op een pagina van je website zonder de pagina te herladen. Echter dat doe je als beheerder selectief. Je dumpt niet alle data van je database op een pagina zodat iedereen dat kan zien.
Echter met AJAX is het mogelijk die data op te vragen met behulp van een client-side script namelijk Javascript.
Mijn vraag is dus of iemand met Greasemonkey een script kan schrijven die toch de hele database of xml bestand op een pagina kan dumpen zodat hij/zij die kan inzien.
Met Greasemonkey kun je zelf javascripts toevoeven aan een pagina, javascript is immers client-side.
Wat ik me nou afvraag is dus of iemand met Greasemonkey AJAX elementen/functies kan aanspreken welke de beheerder gebruikt om data in zijn pagina te laden vanaf een MySQL server of een XML file of txt file.
Echter werkt een AJAX script alleen wanneer het op een server staat, dus ik weet niet of dit nou problemen met zich mee kan brengen of niet.

[djluc]

Je fout is dat je server mogelijk data teruggeeft die de ingelogde gebruiker niet mag zien. Dus als je dat voorkomt is je probleem ook meteen weg.

[Victor]

Een HTTP request door XMLHttpRequest kan net zo goed door de browser zelf gedaan worden, qua beveiliging voegt AJAX niets toe. Je zult dus moeten zorgen dat die database uitvoer nooit getoond kan worden, zonder daartoe toegang te hebben gekregen. Zij het via een 'normale' webpagina, danwel een AJAX request.

Greasemonkey heeft hier dus weinig mee te maken.

[GlowMouse]

Zolang je op de server alleen informatie verstuurt die de client ook echt mag zien, ben je veilig. Je moet dus zorgen dat wanneer iemand anders de JavaScript van de administrator draait, hij de gegevens niet krijgt zolang hij niet ook als administrator is ingelogd. Maar dat probleem speelt niet alleen bij AJAX, maar bij eigenlijk alles (wat doe je als een user naar www.site.com/adminpanel/ gaat? Juist, je laat de user eerst inloggen voordat hij ook maar ergens bij kan).

[CrashOne]

Waarom zou AJAX een risico zijn? Je vraag toch nog steeds gewoon 'paginas' met bepaalde parameters op? Die kan je in een losse pagina (post/get) ook vervangen/manipuleren. En als je bepaalde technieken niet beheerst of er geen oplossing voor weet, implementeer het dan niet in een live omgeving.

[Duroth]

Javascript zal toch niet volstaan om even een databaseje leeg te trekken. Tenminste, ik heb nog nooit gehoord van de mogelijkheid om een MySQL query uit te voeren middels javascript. Daarnaast zal je altijd nog de toegangsgegevens moeten hebben. De enige manier om middels AJAX databasegegevens te verkrijgen is door een PHP-script aan te roepen dat deze gegevens retourneert. Tenzij je PHP-scripts zodanig slecht beveiligd zijn dat MySQL Injection een optie is, maakt het echt niet uit hoeveel AJAX scriptjes je erop loslaat, je zal toch nooit enige vertrouwelijke gegevens boven water kunnen halen. Hetzelfde zal wel waar zijn voor XML files. En zoals hierboven al gezegd is, je kunt ook gemakkelijk zonder AJAX een server-side script aanspreken. Er is dus geen sprake van een toegenomen beveiligingsrisico.

Daarnaast, was AJAX niet gewoon een adaptie van Javascript die het mogelijk maakt server-side scripts zonder refresh aan te spreken? Nog nooit gehoord van server-side AJAX. Of ik zit ernaast, is natuurlijk ook mogelijk.

En wat betreft je txt file... als ik weet welke file ik moet hebben, ga ik wel eventjes naar www.jouwdomein.nl/pad_naar_bestand/bestandje.txt ... Daar heb ik geen enkele regel JS voor nodig ;-)

[ Voor 7% gewijzigd door Duroth op 22-11-2007 21:33 ]

[Arcane Apex]

Duroth schreef op donderdag 22 november 2007 @ 21:31:


Daarnaast, was AJAX niet gewoon een adaptie van Javascript die het mogelijk maakt server-side scripts zonder refresh aan te spreken? Nog nooit gehoord van server-side AJAX. Of ik zit ernaast, is natuurlijk ook mogelijk.

AJAX maakt inderdaad gebruik van Javascript, preciezer gezegd het XMLhttpRequest object. Javascript ansich is een client-side script. Echter als ik me niet vergis werkt een AJAX script _alleen_ wanneer het op een server staat. (Dat terwijl Javascript een client-side script is)
Maar ik vroeg mij dus af of iemand dan toch via javascript XMLhttpRequest kan aanroepen waardoor via dat dan weer een PHP script aangeroepen wordt welke de database leegtrekt.

Maar als ik het zo hoor komt het dan neer op dat je bepaalde PHP scripts en XML files goed moet beveiligen zodat deze niet zomaar aangeroepen kunnen worden.
Maar zelfs dan, om een voorbeeld te noemen. Stel dat iemand inlogt op je site, waarna er vervolgens een session variabele op true gezet wordt en bepaalde php scripts alleen aangeroepen kunnen worden wanneer deze session variable true is. Kan iemand dan niet gewoon zijn/haar session cookie aanpassen, de variable op true zetten en dan dus wel die php scripts aanroepen via AJAX? Of is dat in zijn algemeen gewoon bad coding?

[ Voor 26% gewijzigd door Arcane Apex op 22-11-2007 21:46 ]

[DanielG]

Arcane Apex schreef op donderdag 22 november 2007 @ 21:41:
[...]


Echter als ik me niet vergis werkt een AJAX script _alleen_ wanneer het op een server staat. (Dat terwijl Javascript een client-side script is)

Je vergist je wel. AJAX is ook Client side (en staat totaal los van server side) en kan niks meer dan wat je met een browser ook gewoon kan. Je hebt niet eens Greasemonkey nodig om 'AJAX code' uit te voeren op een site die je bekijkt.

[Janoz]

Arcane Apex schreef op donderdag 22 november 2007 @ 21:41:
Echter als ik me niet vergis werkt een AJAX script _alleen_ wanneer het op een server staat. (Dat terwijl Javascript een client-side script is)

Helaas, je vergist je. Ook ajax drait gewoon op de client. Het is niks meer dan javascript. Wat er op de server draait is gewoon je serverside script (php bijvoorbeeld). Een ajax request roept een (bijvoorbeeld) php script aan en die geeft vervolgens de gewenste gegevens terug zodat ze met javascript op de client verwerkt kunnen worden. Zolang die serverside code maar goed geschreven is heb je geen enkel security probleem. Greasemonkey heeft er helemaal niks mee te maken verder.

Stel dat iemand inlogt op je site, waarna er vervolgens een session variabele op true gezet wordt en bepaalde php scripts alleen aangeroepen kunnen worden wanneer deze session variable true is. Kan iemand dan niet gewoon zijn/haar session cookie aanpassen

Sessie data staat op de server, niet in een cookie. In een cookie is enkel een token opgeslagen zodat de server weet welke client bij welke data op de server hoort. Het is dus voor de client onmogelijk om zomaar sessiedata te veranderen.

[ Voor 25% gewijzigd door Janoz op 22-11-2007 21:50 ]

[Swaptor]

Het gaat er hier om dat AJAX geen script is, maar een methodiek. En zelfs eentje waarbij je je client-side (JS) scripts zo orchestreert dat het netjes en naadloos aansluit op je server-side (vaak PHP, maar alles kan, zolang het maar XML uitpoept) script.
Beveiliging van het systeem moet dus zoals je waarschijnlijk zelf ook weet _absoluut_ serverside gebeuren. Alles wat bij de client vandaan komt dient met gezonde paranoia behandeld te worden.

Met bovenstaande in gedachten snap ik jouw gedachtengang niet: een AJAX-systeem heeft inderdaad zowel een clientside als serverside deel nodig, waarbij het laatste alleen werkt als het op de server aanwezig is. (doh! )
Wanneer ik met mijn eigen (clientside) scripts ga zitten requesten op jouw (serverside) ajax-component is dat voor het systeem niet anders dan wanneer de requests van jouw eigen geschreven clientside scripts zouden komen.

Ik hoop dat ik het duidelijk genoeg heb gebracht zo: de termen lijken linguistisch op elkaar in zo'n brij tekst

Edit: aaaargh! Wat Janoz & DanielG zeggen dus...

[Arcane Apex]

DanielG schreef op donderdag 22 november 2007 @ 21:46:
[...]


Je vergist je wel. AJAX is ook Client side (en staat totaal los van server side) en kan niks meer dan wat je met een browser ook gewoon kan. Je hebt niet eens Greasemonkey nodig om AJAX te laten draaien op een site die je bekijkt.

Echter wanneer je AJAX code aan een bestand toevoegt en gewoon op je pc zet dan werkt het niet in een browser.
Zet je dat bestand op een server, dan werkt het wel in een browser. Dit terwijl dit met gewone Javascript wel mogelijk is op je PC.

[Swaptor]

Wat bedoel je met AJAX-code?
JavaScript of PHP?

In het geval van JS: wijst het wel naar de juiste locatie om dingen aan te vragen?

[ Voor 47% gewijzigd door Swaptor op 22-11-2007 21:50 ]

[DanielG]

Arcane Apex schreef op donderdag 22 november 2007 @ 21:48:
[...]


Echter wanneer je AJAX code aan een bestand toevoegt en gewoon op je pc zet dan werkt het niet.
Zet je dat bestand op een server, dan werkt het wel. Dit terwijl dit met gewone Javascript wel mogelijk is op je PC.

Ik snap je redenatie niet, ik kan javascript (en dus ook AJAX/XMLHttpRequest) laten draaien op elke pagina die ik kan bezoeken met een browser. Ik hoef de pagina niet eerst lokaal op te slaan.

[Arcane Apex]

Swaptor schreef op donderdag 22 november 2007 @ 21:50:
Wat bedoel je met AJAX-code?
JavaScript of PHP?

Met AJAX bedoel ik de doorsluis methode van het XMLhttpRequest object. Deze methode trekt data van de server door naar de client via http en presenteert het dan aan lokale client-side javascripts welke deze data dan kunnen gebruiken.

[Swaptor]

Ondanks het feit dat je me netjes, (zij het zonder de edit) quote heb je mijn vraag niet beantwoord.

Bedoel je de Javascript-code als je AJAX-code zegt, of puur de backend die je aanroept en dus de data aanlevert?

[DanielG]

Arcane Apex schreef op donderdag 22 november 2007 @ 21:52:
Met AJAX bedoel ik de doorsluis methode van het XMLhttpRequest object. Deze methode trekt data van de server door naar de client via http en presenteert het dan aan lokale client-side javascripts welke deze data dan kunnen gebruiken.

Dit klopt, echter zonder AJAX kan je ook die data van de server onttrekken. Zelfs zonder een web browser.

[Borizz]

Arcane Apex schreef op donderdag 22 november 2007 @ 21:41:
[...]


AJAX maakt inderdaad gebruik van Javascript, preciezer gezegd het XMLhttpRequest object. Javascript ansich is een client-side script. Echter als ik me niet vergis werkt een AJAX script _alleen_ wanneer het op een server staat. (Dat terwijl Javascript een client-side script is)
Maar ik vroeg mij dus af of iemand dan toch via javascript XMLhttpRequest kan aanroepen waardoor via dat dan weer een PHP script aangeroepen wordt welke de database leegtrekt.

Maar als ik het zo hoor komt het dan neer op dat je bepaalde PHP scripts en XML files goed moet beveiligen zodat deze niet zomaar aangeroepen kunnen worden.
Maar zelfs dan, om een voorbeeld te noemen. Stel dat iemand inlogt op je site, waarna er vervolgens een session variabele op true gezet wordt en bepaalde php scripts alleen aangeroepen kunnen worden wanneer deze session variable true is. Kan iemand dan niet gewoon zijn/haar session cookie aanpassen, de variable op true zetten en dan dus wel die php scripts aanroepen via AJAX? Of is dat in zijn algemeen gewoon bad coding?

Ik denk niet dat je helemaal begrijpt wat AJAX of beter gezegd XMLHttpRequest inhoudt. Het XMLHttprequest roept namelijk gewoon een pagina/script/bestand op de server aan (al dan niet met parameters), wat jij later met de output van dat bestand doet in Javascript (waarschijnlijk de data parsen en op een bepaalde manier weergeven) heeft daar niets mee te maken. Je kan die url namelijk ook direct aanroepen vanuit je browser, waarin je direct de output ziet.

Beter gezegd via een XMLHttpRequest kan je net zoveel van de server afhalen als dat jij toestaat met je eigen server side scripts. Een sessie wordt op de server opgeslagen, de client (browser) heeft enkel een sessie id (al dan niet opgeslagen in een cookie), waarmee hij aangeeft welke sessie op de server van hem is.

Het is dus onmogelijk om client side (cookie / javascript), je server side sessie variabele aan te passen. Tenzij je je sessie dus geheel client side opslaat in een cookie, wat dus zowiezo niet slim is, omdat dan iedereen (ook zonder AJAX) de gegevens in de cookie aan kan passen. Je moet zo denken: alles wat ik niet server side beschikbaar stel (via php of wat voor server side taal dan ook) kan niet door de buitenwereld uitgelezen worden (tenzij er veiligheidslekken in je script zitten).

[Arcane Apex]

Swaptor schreef op donderdag 22 november 2007 @ 21:54:
Ondanks het feit dat je me netjes, (zij het zonder de edit) quote heb je mijn vraag niet beantwoord.

Bedoel je de Javascript-code als je AJAX-code zegt, of puur de backend die je aanroept en dus de data aanlevert?

Ik bedoel javascript-code.

[Arcane Apex]

Borizz schreef op donderdag 22 november 2007 @ 21:55:
[...]
Je moet zo denken: alles wat ik niet server side beschikbaar stel (via php of wat voor server side taal dan ook) kan niet door de buitenwereld uitgelezen worden (tenzij er veiligheidslekken in je script zitten).

Aha, dat is vrij duidelijk. Bedankt.