Tokens bei AJAX API

MichaelM

Hallo,

ich schreibe ein Python-Programm mit dem ich per AJAX API die Fakten auslesen will.
Das funktioniert auch schon ganz gut:

    import requests    
    session = requests.Session()

    login_url = 'https://mghh.church.tools/?q=login/ajax&func=login'
    data = {'email': 'xxxxx', 'password': 'xxxxx'}
    auth = session.post(url=login_url, data=data)

    response = session.post('https://mghh.church.tools/?q=churchservice/ajax&func=getAllFacts')

Frage zu CSRF-Token:
Warum kann ich die Fakten auslesen, ohne ein CSRF-Token mit zu übergeben? Ich weiß nicht, ob die CSRF-Token bei der mghh-CT-Instanz deaktiviert sind. Bei unserer sind sie auf jeden Fall nicht deaktiviert und es funktioniert genauso.
Frage zu Login-Token
Ich habe unter anderem hier im Forum gelesen, dass der Login mit Token besser/sicherer sei.
Kann mir jemand sagen warum und wie das ablaufen würde?
Erst mit Email und Passwort einloggen, dann das Login-Token abfragen? Was soll ich dann mit dem Login-Token, bin ja schon angemeldet? Was würde das für einen Unterschied machen?
Oder das Login-Token direkt aus der ChurchTools-Weboberfläche holen und fest im Quellcode speichern? Aber wenn sich das Token ändert müsste ich wieder den Quellcode ändern.
Mir gefällt es auch nicht, dass ich Benutzername und Passwort so im Quellcode stehen habe (auch wenn ich einen eigenen Benutzer mit minimalen Rechten anlegen würde).
Wie wird das ganze üblicherweise gelöst?

Danke für eure Hilfe, ich kenne mich mit Authentifizierung nicht so gut aus...

jziegeler

@michaelm schau mal hier:
https://forum.church.tools/topic/7027/resourcenbelegung-via-php-curl_exec-abfragen/8 Hans-Helge hat es eigentlich ganz gut erklärt

MichaelM

Danke, das hilft.
Aber zum CSRF-Token, da schreibt er ja auch: "Du musst diesen CSRF Token abfragen und mit den POSTs bei der alten API mitschicken."
Ich schicke es nicht mit (siehe oben) und die Abfrage der Fakten funktioniert trotzdem. Ich hätte erwartet, dass die Abfrage in dieser Form fehl schlagen muss.

MarkusP

@michaelm
Das kann ich auch bestätigen. Ich programmiere seit ein paar Tagen auch an einem Programm und der CSRF Token ist egal. Auch über Postman funktioniert das ohne Problem ohne den CSRF Token.

Zum Login Token:

Über API V1 mit Token und ID anmelden und Cookie speichern (login/ajax;func=loginWithToken; token; id)
Über API V2 bei einem Call (z.B. api/whoami) den Token im Header mitgeben (Authorization: Login <Token>) und Cookie speichern (falls du mit der API V1 weiterarbeiten möchtest)

Für die API V2 muss man sich nicht speziell einloggen, da reicht es den Token immer im Header mit zu geben. Dann muss man auch nicht mit Cookie rumhantieren.

Ich sehe aber im Login Token keine höhere Sicherheit, es macht es nur bei API V2 einfacher, weil du dich nicht einloggen bzw. dauernd ein Cookie mitschleppen musst.

bwl21

@markusp sagte in Tokens bei AJAX API:

Für die API V2 muss man sich nicht speziell einloggen, da reicht es den Token immer im Header mit zu geben. Dann muss man auch nicht mit Cookie rumhantieren.

dann macht er aber mit jedem Aufruf eine neue Session auf. Du siehst das dann im Frontend, dass der Benutzer x mal eingeloggt ist.

MarkusP

@bwl21
Ich glaube da kommt es darauf an, in welchem Umfang man die Schnittstelle benötigt. Wenn er einmal die Woche die Fakten ausließt (nur ein Call), dann wäre dies nicht so schlimm.

In meinem Fall verwende ich nach dem Login auch den Cookie, da ich einige Aufrufe durchführe.

Aber ehrlich gesagt wusste ich das gar nicht. Dann wäre es gut, wenn das auf der API Seite im Punkt Authentication auch noch ergänzt wird. Da ließt man es so, dass beides gute Lösungen sind.

hbuerger

Um hier etwas Klarheit rein zu bringen.

Authorization

Egal ob AJAX API (v1) oder REST API (v2) in beiden Fällen kann man sich mit Username/Passwort einloggen ODER den Login Token mitschicken.

Authorization: Login <token> funktioniert mit beiden APIs.

Wichtig: In beiden Fällen bekommt man ein Cookie zurück und dieses Cookie sollte man mitschicken in folge Requests. Wenn das Cookie fehlt und man immer fröhlich den LoginToken mitschickt, dann wird für jeden Request eine neue Session erstellt.

Das ist nicht nur doof, weil es auf der Startseite angezeigt wird, sondern hat auch Performance Gründe. Bei einer neuen Session werden die Rechte für den Nutzer berechnet. D.h. mit Cookie ist der Request auch schneller.

Hint: Man kann den LoginToken trotzdem mitschicken zusätzlich zum Cookie. Wenn die Session im Cookie noch aktiv ist, dann ist alles supi. Wenn es keine Session gibt, dann fällt CT zurück und nutzt den Login Token.

CSRF Token

Der Token sollte immer vom System geprüft werden, wenn ein Formular abgeschickt wird, dass mit POST verschickt wird.

Ich investigiere gerade ob hier ein Bug vorliegt. Mit welchem Content Type verschickt ihr denn den Request?

MichaelM

Danke schonmal für eure Antworten.

@hbuerger
Ich hatte bisher überhaupt kein Content Type angegeben und es funktionierte (s.o).
Wenn ich einen Header mit application/x-www-form-urlencoded übergebe, bekomme ich die Meldung "'CSRF-Token is invalid'". Wenn ich dann auch noch das CSRF-Token übergebe, funktioniert die Abfrage wieder.

# Header mit Content-Type aber ohne CSRF-Token --> Fehler
headers = { 'Content-Type': 'application/x-www-form-urlencoded',
          # 'CSRF-Token': csrf_token 
        }
response = session.post('https://mghh.church.tools/?q=churchservice/ajax&func=getAllFacts', headers=headers)

Gleiches Spiel im Postman: Sobald ich den Content-Type mit übergebe, kommt die Fehlermeldung. Ohne Content-Type ist kein CSRF-Token notwendig.

MarkusP

@hbuerger sagte in Tokens bei AJAX API:

Authorization: Login <token> funktioniert mit beiden APIs.

Wenn ich das bei der AJAX API mache (func: getPersonById), dann kommt aber beim ersten Aufruf eine Fehlermeldung (message: Parameter func not defined) und beim zweiten Mal klappt es dann, weil ein Cookie vorliegt. Test lief über Postman.

Mit welchem Content Type verschickt ihr denn den Request?

Beim Postman habe ich für getPersonById den Type multipart/form-data und für f_group den Type application/json verwendet. Beides hat ohne CSRF-Token geklappt
Ich hatte irgendwo gelesen, dass man application/x-www-form-urlencoded verwenden soll, aber nach kurzen Tests ist mir aufgefallen, dass man bei application/json den CSRF-Token nicht benötigt.

hbuerger

@michaelm sagte in Tokens bei AJAX API:

Ich hatte bisher überhaupt kein Content Type angegeben und es funktionierte (s.o).

Wenn du keinen Content-Type explizit angegeben hast, dann wird es vermutlich als text/plain verschickt. Das ist auch kein Problem.

Ich habe zudem einen Fehler gefunden, der mit v3.72.1 (die kommt in den nächsten Tagen) gefixt ist. Ab dann wird der Token für application/x-www-form-urlencoded und multipart/form-data erzwungen. Das sind die zwei Content Types, die mit Formularen genutzt werden in ChurchTools.

@markusp sagte in Tokens bei AJAX API:

Wenn ich das bei der AJAX API mache (func: getPersonById), dann kommt aber beim ersten Aufruf eine Fehlermeldung (message: Parameter func not defined) und beim zweiten Mal klappt es dann, weil ein Cookie vorliegt. Test lief über Postman.

func: musst du immer mit geben. Das ist ja der Methoden Aufruf, das hat nichts mit dem Login Token zu tun. func schickst du ja als Content mit. Den Login Token schickst du als Header mit.

MarkusP

@hbuerger sagte in Tokens bei AJAX API:

Ich habe zudem einen Fehler gefunden, der mit v3.72.1 (die kommt in den nächsten Tagen) gefixt ist. Ab dann wird der Token für application/x-www-form-urlencoded und multipart/form-data erzwungen. Das sind die zwei Content Types, die mit Formularen genutzt werden in ChurchTools.

Und wie sieht es mit application/json aus? Sollte es nicht bei allen Content Types erzwungen werden?

func: musst du immer mit geben. Das ist ja der Methoden Aufruf, das hat nichts mit dem Login Token zu tun. func schickst du ja als Content mit. Den Login Token schickst du als Header mit.

Das mache ich ja. Zwischen dem ersten und zweiten Aufruf mache ich keine Änderung, außer dass Postman automatisch das Cookie hinzufügt.

davidschilling

@markusp für application/json ist es nicht notwendig.

CSRF ist eine Sicherheitslücke die über Formulare in Browsern passieren kann. Wenn du einen ajax request im browser machst kannst du keinen csrf ausnutzen.