[Magnus_A]

Ajax är en rolig teknik som möjliggör spännande lösningar.
Men när man flyttar ut en del av affärslogik till webbläsarlagret och låter delar av dataflödet den vägen uppstår problem med att hantera data säkert och undvika obehörigt utnyttjande.
Dels finns risken för att personuppgifter skickas i klartext (json, xml) fram och tillbaka i större utsträckning och därmed öppnar för sniffning i till exempel trådlösa nätverk.
Dels öppnar man upp för obehörigt utnyttjande genom att botar kan utnyttja ajax-anropen för att komma åt data i trevligt formaterad form.


Jag förstår att det i princip är omöjligt att skydda sig med någon form av kryptering, eftersom javascriptet ligger vidöppet i browsern för analys. Https är naturligtvis den bombsäkra lösningen.

Men kan man göra det svårare att utnyttja ajaxanropen för obehöriga utan att behöva ta till https?

[Lumax]

På vilket sätt menar du att det skulle vara någon skillnad med ajax-anrop? Trafiken går ju lika okrypterad på en "vanlig" sajt. Och om du har en lösning som kräver inloggning så gäller det även ajax-anrop.

[pelmered]

Ja, precis. Det är ju ingen skillnad ur säkerhetssynpunkt.

Du har ju fortfarande samma sessionkontroll m.m. när det gäller AJAX-anrop så jag ser inte problemet. All data skickas ju lika okrypterat utan AJAX.
All datahantering förutom presentationen hanteras ju fortfarande serverside så här har du samma säkerhet.

Du ska ju inte sköta någon logik med javascript utan att även kontrollera indatan serverside. Att göra kontroller av formulärdata m.m. med Javascript ger en bättre användarupplevelse än att man bara kontrollerar allt serverside så att hela sidan måste laddas om. Men detta är bara för att just förbättra användarupplevelsen, alla kontroller av indatan måste även ske serverside i dina PHP/ASP/JSP/etc.-script för att det ska vara säkert.
Javascript och AJAX är alltså bara ett komplement för att kunna göra trevligare WUIs och inte på något sätt en ersättare för webbsidans logik och datahantering.

[Magnus_A]

Tack för svar hittills.
Hur kan man, förutom sessionskontroll, undvika att man blir någon annans backend för diverse uppslag?

[rhdf]

Om en inkommande request saknar en giltig session så bör ju ditt backend inte returnera nånting.

här finns en teknik för att hantera detta beskrivet
http://ennuidesign.com/blog/Creating...cratch+Part+9/

man fixar altså ett unikt värde:
$_SESSION['token'] = md5(uniqid(rand(), TRUE));
Sen sätter man detta värde i ett dolt formulärfält på alla dina sidor.
Finns inte "token värdet" med i requesten så skickar man bara tillbaka en tom sida
if ( $_POST['token'] == $_SESSION['token']

[pelmered]

Ursprungligen postat av rhdf

Om en inkommande request saknar en giltig session så bör ju ditt backend inte returnera nånting.

här finns en teknik för att hantera detta beskrivet
http://ennuidesign.com/blog/Creating...cratch+Part+9/

man fixar altså ett unikt värde:
$_SESSION['token'] = md5(uniqid(rand(), TRUE));
Sen sätter man detta värde i ett dolt formulärfält på alla dina sidor.
Finns inte "token värdet" med i requesten så skickar man bara tillbaka en tom sida
if ( $_POST['token'] == $_SESSION['token']

Va? nej... Så behöver man inte göra.
Med PHP räcker det med att du sätter det du vill ha i sessionsvariabeln så finns den där tills sessionen får timeout. Varje gång sidan laddas om nollställs timeout tiden och detta gäller även AJAX-requests.
Det räcker alltså med att sätta sessionsvariabeln när man loggar in på sidan och sedan kollar man den. Du behöver inga dolda formulär.

Vid login räcker det med t.ex:
$_SESSION['id'] = $userId;
$_SESSION['loggedIn'] = true;

Sedan kollar du på varje sida innan du gör något annat:
if ($_SESSION['loggedIn'] == false || !$_SESSION['id'] > 0)
die();

[rhdf]

ja man BEHÖVER inget formulärsfält, men om du läser sidan jag länkade till så förstår du anledningen till varför det är en bra idé

mer finns att läsa här
http://shiflett.org/articles/cross-s...uest-forgeries

[studiox]

Jag kan väl delvis hålla med Magnus här att det kan vara ett problem.

När jag byggde min jämförelsesajt så var första motorn faktiskt skriven helt i ajax då det gav en riktigt vass och snabb användarupplevelse. Men på sikt blev det inte hållbart, dessutom gillar ju inte google ajax så det slutade med att det blev serverside allt igen

Det jag tror Magnus menar är att om "renderingen" av data sker på klienten hur man kan då hindra att någon snor det? Om Magnus har en supercool lösning för att räkna ut elpriser (exempel) så vill han kanske inte att den lösningen ska liga i javascript så att någon kan sno den.

Det spelar ju ingen roll om du har en session eller inte, om uträkningen sker i klienten så får du ju tillgång till det då du automatiskt har en session. (Session löser ju inget i vilket fall som helst då alla kan få en session)

Jag tyckte själv det blev ett problem och såg till att bygga en snabb backend istället.

[pelmered]

Ursprungligen postat av rhdf

ja man BEHÖVER inget formulärsfält, men om du läser sidan jag länkade till så förstår du anledningen till varför det är en bra idé

mer finns att läsa här
http://shiflett.org/articles/cross-s...uest-forgeries

Okej, ska kolla upp det!

Ursprungligen postat av studiox

Det jag tror Magnus menar är att om "renderingen" av data sker på klienten hur man kan då hindra att någon snor det? Om Magnus har en supercool lösning för att räkna ut elpriser (exempel) så vill han kanske inte att den lösningen ska liga i javascript så att någon kan sno den.

Det spelar ju ingen roll om du har en session eller inte, om uträkningen sker i klienten så får du ju tillgång till det då du automatiskt har en session. (Session löser ju inget i vilket fall som helst då alla kan få en session)

Jag tyckte själv det blev ett problem och såg till att bygga en snabb backend istället.

Ja, det kan ju vara ett problem. Men en lösning på det problemet kan ju vara just AJAX
Då kan du ju lyfta ut den logiken/algoritmen till ett serverside script som du anropar med AJAX. Det är dessutom mycket enklare att utveckla och underhålla mer avancerade saker i ett serverside script så det är i många fall att föredra.