Stoppa oönskad användning av api

[HakanBrakan]

Hej

Här kommer en lite teknikorienterad fråga.

Nästan alla som har “hämta uppgifter” för personnummer säkerställer inte på något sätt att frågorna kommer från rätt håll.

Här en stor aktör (CDON Group) som helt öppet exponerar denna funktionalitet för vem som helst att använda om man så önskar (lite lättare att klaga på stora drakar, men dom är inte ensamma).

https://www.gymgrossisten.com/cgi-bin/ibutik/Klarna.pl?personnummer_att_skicka=YYMMDDXXXX&sprak_att_anvanda=SV&funk=get_addresses

Byt ur YYMMDDXXXX mot önskat personnummer.

Hittade ca 10 (stora och små) på 5 minuters letande som gjorde på nästan samma sätt, men vill inte blotta någon liten aktör.

Eftersom vi små kan bättre än dom stora :p så undrar jag om ni gjort något för att stoppa denna typen av möjlighet för snyltare?

Några förslag jag hittat på hur man hindrar detta:

• Kolla Referrer.
• Unik nyckel i sessionen som måste stämma i requesten.
• Checksumma.
• Rullande lösenord/löpnummer.

Ingen av dessa alternativ är dock 100% säkra.

Tack på förhand
Håkan

[Katrin Lundgren]

Ok, jag är nog puckad men eftersom klarna tillhandahåller tjänsten och api för att använda den, är det då inte de som behöver kolla vartifrån slagningarna mot den kommer ifrån???

Eller har jag missförstått problemet totalt eftersom jag inte ens får upp länken du givit i inlägget.

[HakanBrakan]

Hej Kodmyran. Tänk på att du måste byta ut YYMMDDXXXX mot ett personnummer för att du inte ska på felkoder tillbaka.

Problemet är ju att i exemplet ovan går all trafik mot gymgrosisten så dom måste filtrera frågorna. Sedan är det ju deras servrar som ställer frågorna mot “klarna gissningsvis om man kollar på länken” i detta falllet med deras konto som förfrågare och om det finns en kostnad förknippad med uppslaget så belastas deras konto.

[Katrin Lundgren]

Jag kommer inte ens in lå länken för att byta ut några yymmddxxxx jag får en felkod -2 error direkt

[Dan]

Testar du med ett riktigt personnummer, annars förklarar det saken. Testade med mitt egna och det funkar.

Håkan: Du borde maila Gymgrossisten och alla andra du hittar för att vara snäll.

[FredrikGust]

Man verkar ofta glömma bort möjligheten att kontrollera giltig session eller referer på ajaxfrågor när ett javascript behöver data även om någon med lite kunskaper lätt kommer runt sådant också.

Liknande problem finns i flera populära opensourceprogramvaror, tex roundcube för webmail.

Gör gärna som Dan föreslår även om jag tror få kommer missbruka en sådan tjänst.

[Johan W]

Skapa session och ge besökaren en temporär token som kollas när hämtningen görs (inne i scriptet) skulle jag väl anse vara det säkraste.

[bell]

Instämmer med Johan_W. Det är en beprövad approach för att förhindra så kallad CSRF.

Gissningsvis kommer ingen att missbruka detta löpande, utan snarare vid enskilda tillfällen för att utöka diverse dataregister till exempel. Således kan det vara en bra idé att även begränsa antalet förfrågningar per IP och dygn till 20 eller 30. Kommer inte störa någon vanlig besökare, men ytterliggare försvåra omfattande slagningar.

/Bell

[Dan]

Det är väl bara att först anropa kassan och ta emot en session eller cookie och sedan anropa scriptet?

Hur stoppar det missbruket? Om en vanlig användare kan anropa scriptet så kan en bot alltid också göra det?

[mephisto73]

Lösning: se till att scriptet kräver en giltig hash som genereras per anrop och skickas med i queryn.

[Författare]

Inlägg