Grundsätzliche Frage SSL

[lowmax_5]

Hallo,

ich möchte gerne einen Rest-Service per SSL ansteuern. Ein Kennwort/Token ist dabei in der https-Url codiert.

Ist dieses ein akzeptabler und gangbarer Weg? Wird bei einem Aufruf REST-Client Aufruf die Url bereits entsprechend verschlüsselt?

Habe mir das ganze über Wireshark angesehen.Der Response definitiv gecrypted und eine Url konnte ich nicht im Klartext finden.

[mjustin]

Zitat:

Zitat von lowmax_5 (Beitrag 1361681)

Ist dieses ein akzeptabler und gangbarer Weg? Wird bei einem Aufruf REST-Client Aufruf die Url bereits entsprechend verschlüsselt?

Ja, das ist sie. Einziges Problem: der Client kennt das Token :)

Bei einem SSL (TLS) Verbindungsaufbau zu einem HTTP Server wird zuerst der Server kontaktiert und die Verschlüssselung ausgehandelt. Die tatsächliche URL des Requests wird erst danach an den Server gesendet.

Man in the middle Attacken sind dann aber z.B. über einen Proxy möglich, dessen Zertifikat vom Client akzeptiert wird. Der Proxy sieht den gesamten Traffic dann unverschlüsselt. Zum Beispiel bei Unternehmensfirewalls gibt es solche transparenten Proxyserver.

[Namenloser]

Zitat:

Zitat von lowmax_5 (Beitrag 1361681)

Wird bei einem Aufruf REST-Client Aufruf die Url bereits entsprechend verschlüsselt?

Ja. SSL bzw. TLS arbeitet auf OSI-Schicht 4 (daher der Name "Transport Layer Security"), HTTP/REST auf Schicht 6 bis 7. Das heißt, die komplette HTTP/REST-Kommunikation einschließlich dem Übermitteln von URLs ist verschlüsselt.

Ich würde mir nur Gedanken machen, ob die Aufrufe vom Server eventuell geloggt werden. Da könnte es sein, dass das Token dann im Klartext im Logfile auftaucht. Keine Ahnung, ob das bei deiner Anwendung ein Problem ist.

[lowmax_5]

Vielen Dank für die Antworten! Dass hilft mir weiter!

[Zacherl]

Zitat:

Zitat von mjustin (Beitrag 1361685)

Man in the middle Attacken sind dann aber z.B. über einen Proxy möglich, dessen Zertifikat vom Client akzeptiert wird. Der Proxy sieht den gesamten Traffic dann unverschlüsselt. Zum Beispiel bei Unternehmensfirewalls gibt es solche transparenten Proxyserver.

Geht aber auch nur, wenn der Client es versäumt den Public-Key/des Zertifikat des Servers gegenzuprüfen. Ist diese Vorraussetzung aber erfüllt, dann ist dein Traffic - zumindest für heimliche Mitleser - nicht mehr einzusehen.

Zitat:

Zitat von mjustin (Beitrag 1361685)

Ja, das ist sie. Einziges Problem: der Client kennt das Token :)

Sehe ich nicht als Problem, da der Client ja autorisiert sein sollte. Ist das nicht garantiert, kann man das Token notfalls auch erst nach einem entsprechenden Login vom Server generieren und an den Client senden lassen.

Wichtig ist nur, dass das Token zufällig gewählt wird, damit ein Angreifer keine Möglichkeit hat z.b. durch einfaches Erhöhen einer Nummer, plötzlich andere Identitäten anzunehmen.

[lowmax_5]

Zitat:

Wichtig ist nur, dass das Token zufällig gewählt wird, damit ein Angreifer keine Möglichkeit hat z.b. durch einfaches Erhöhen einer Nummer, plötzlich andere Identitäten anzunehmen.

Als Token verwende ich eine GUID.

[mjustin]

Zitat:

Zitat von Zacherl (Beitrag 1361745)

Zitat:

Zitat von mjustin (Beitrag 1361685)

Man in the middle Attacken sind dann aber z.B. über einen Proxy möglich, dessen Zertifikat vom Client akzeptiert wird. Der Proxy sieht den gesamten Traffic dann unverschlüsselt. Zum Beispiel bei Unternehmensfirewalls gibt es solche transparenten Proxyserver.

Geht aber auch nur, wenn der Client es versäumt den Public-Key/des Zertifikat des Servers gegenzuprüfen. Ist diese Vorraussetzung aber erfüllt, dann ist dein Traffic - zumindest für heimliche Mitleser - nicht mehr einzusehen.

Ein Restrisko ist dann vorhanden, wenn die Firewall angreifbar ist, zum Beispiel Request-Logs schreibt (in denen dann das Token erscheint), oder andere "heimliche" Anwendungen Zugriff haben können.

Das Prüfen des Zertifikats durch den Client schliesst diese Lücke nicht.

[Valle]

Auf dem Überragungsweg sind die Daten verschlüsselt, aber in den Logdateien des Webservers stehen die Daten (also die Request-URL) meist im Plaintext drin. Eventuell solltest du das beachten.

[mjustin]

Zitat:

Zitat von Valle (Beitrag 1361856)

Auf dem Überragungsweg sind die Daten verschlüsselt, aber in den Logdateien des Webservers stehen die Daten (also die Request-URL) meist im Plaintext drin. Eventuell solltest du das beachten.

Daher sollten Token etc. auch nicht in der URL enthalten sein.

Zitat:

Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

https://www.owasp.org/index.php/REST...ion_management