Forward slash in password

[LeonM]

Voor een applicatie maak ik een ftps (niet te verwarren met sftp) verbinding met behulp van curl.

code:

curl -k ftps://login:passwo/rd@123.123.123.123:1234

Nou is het probleem dat er in het password een forward slash zit, die interpreteerd bash, dus krijg je de error:

code:

curl: (6) Couldn't resolve host 'login:passwo'

Geen probleem zou je zeggen, doe 'passwo/rd' (met quotes) of passwo"\/"rd, maar dat helpt dus niet. Ik ben geen unix guru, en heb al flink gezocht op google, maar kan behalve de qoute en backslash methodes weinig oplossingen vinden.

Het password wijzigen is geen optie, heeft iemand nog suggesties?

[ Voor 0% gewijzigd door LeonM op 19-01-2010 15:24 . Reden: Slash stond verkeerd om in voorbeeld ]

[DaRKie]

Is de escape char niet \ op linux?

Probeer eens passwo\\rd

[JohnR]

In plaats van curl autoexpect proberen. Daarmee kun je als het goed is strings opgeven die je letterlijk naar de andere kant kunt echo-en

[CyBeR]

Twee opties:

code:

curl -k ftps://login:passwo\\rd@123.123.123.123:1234
of
curl -k 'ftps://login:passwo\rd@123.123.123.123:1234'

[LeonM]

Damn, ik heb net verkeerd om gezet in de startpost.

In het password zit dus een FORWARD slash, in het voorbeeld gaf ik een backward

code:

curl -k ftps://login:passwo/rd@123.123.123.123:1234

En het escape character van linux is idd een BACKslash, en dat heb ik dus geprobeerd:

code:

curl -k ftps://login:passwo\/rd@123.123.123.123:1234

Maar dat helpt dus niet.

CyBeR schreef op dinsdag 19 januari 2010 @ 15:08:
Twee opties:

code:

curl -k ftps://login:passwo\\rd@123.123.123.123:1234
of
curl -k 'ftps://login:passwo\rd@123.123.123.123:1234'

Volgende geprobeerd:

code:

curl -k ftps://login:passwo\/rd@123.123.123.123:1234

en

code:

curl -k 'ftps://login:passwo/rd@123.123.123.123:1234'

Maar werkt allebei niet

[ Voor 12% gewijzigd door LeonM op 19-01-2010 15:25 ]

[CyBeR]

Een / wordt niet speciaal behandeld. Kun je 't wel doen als je met openssl s_tunnel -connect server:port verbindt? Dan moet je even typen, nadat je de banner gekregen hebt:
USER login
PASS passwo/rd

[LeonM]

CyBeR schreef op dinsdag 19 januari 2010 @ 15:25:
Een / wordt niet speciaal behandeld. Kun je 't wel doen als je met openssl s_tunnel -connect server:port verbindt? Dan moet je even typen, nadat je de banner gekregen hebt:
USER login
PASS passwo/rd

Je bedoeld waarschijnlijk s_client -connect.

Anyway, dat werkt gewoon. Alleen met curl werkt dat niet correct.

[CyBeR]

LeonM schreef op dinsdag 19 januari 2010 @ 15:32:
[...]


Je bedoeld waarschijnlijk s_client -connect.

Anyway, dat werkt gewoon. Alleen met curl werkt dat niet correct.

Eh, ja. s_tunnel is een ander programma inderdaad. Maar interessant. Mischien kun je 't over een niet-gecrypte connectie proberen en dan sniffen? Anders moet je even een certificaat fixen en openssl s_server gebruiken.

[netvor]

Heb je al geprobeerd de slash met URL encoding te escapen? Met andere woorden, "%2F" i.p.v. "/".

VZIW hebben tools als curl of wget helaas niet de mogelijkheid een "credentials file" te gebruiken. Jammer.

Laatste optie is dan, zoals al genoemd, de credentials via een expect script doorgeven. Dat heeft dan ook weer het voordeel dat het wachtwoord niet zichtbaar is voor andere gebruikers via ps.

[kluyze]

Inderdaad, was het ook juist aan het typen. Ik dacht zoals netvor.

De / staat in een url, die url moet omgezet worden naar een ip door een dns server en die dns gaat die url niet goed kunnen resolven.

[Tim]

Als je

code:

curl -k ftps://login:passwo\/rd@123.123.123.123:1234

gebruikt dan escape je de forward slash in bash. Dus misschien dat

code:

curl -k ftps://login:passwo\\/rd@123.123.123.123:1234

wel werkt. Volgens man heeft curl ook nog een -u optie voor het wachtwoord. Misschien doet dat iets.

[CyBeR]

kluyze schreef op dinsdag 19 januari 2010 @ 15:41:
De / staat in een url, die url moet omgezet worden naar een ip door een dns server en die dns gaat die url niet goed kunnen resolven.

Eh, nee. Dat zou inhouden dat je elke keer je username, ww en ook de hostname waarnaar je probeert te verbinden plaintext naar je dns server stuurt. Ik denk dat je ook wel inziet dat dat niet het beste idee is.

[T-MOB]

CyBeR schreef op woensdag 20 januari 2010 @ 17:20:
[...]
Eh, nee. Dat zou inhouden dat je elke keer je username, ww en ook de hostname waarnaar je probeert te verbinden plaintext naar je dns server stuurt. Ik denk dat je ook wel inziet dat dat niet het beste idee is.

Nee ergens zal dat url geparsed moeten worden: ftps://login:passwo/rd@123.123.123.123:1234 kun je interpreteren als:

protocol: ftps
host: login:passwo
path: /rd@123.123.123.123
port: 1234

De slash encoden lijkt me in elk geval het proberen waard. Daarmee haal je de (mogelijke) ambiguiteit uit het url.

[CyBeR]

T-MOB schreef op woensdag 20 januari 2010 @ 17:45:
[...]

Nee ergens zal dat url geparsed moeten worden

Ja, maar da's niet de DNS-server

[MartinMeijerink]

LeonM schreef op dinsdag 19 januari 2010 @ 15:23:
Volgende geprobeerd:

code:

curl -k ftps://login:passwo\/rd@123.123.123.123:1234

en

code:

curl -k 'ftps://login:passwo/rd@123.123.123.123:1234'

Maar werkt allebei niet

Combinatie van beiden wil ook nog weleens werken, escape char EN quotes:
[code]curl -k 'ftps://login:passwo\/rd@123.123.123.123:1234'[/code]

Bij mij werkt het als ik dit doe:

code:

curl -u login:passwo/rd http://zutphen.nu/password/

Ik heb hier nl ff geen sftp draaien, maar in jouw geval moet dan dus dit werken:

code:

curl -u login:passwo/rd -k ftps://123.123.123.123:1234

[ Voor 22% gewijzigd door MartinMeijerink op 20-01-2010 19:26 . Reden: eerder voorgestelde oplossing werkte niet ]

[kluyze]

CyBeR schreef op woensdag 20 januari 2010 @ 18:03:
[...]


Ja, maar da's niet de DNS-server

Maar de host moet wel door een dns server volgens mij en als het paswoord gezien wordt als een host wordt die naar een dns gestuurd lijkt me.

Hoe doet die het anders dan wel? De error melding "couldn't resolve host" wil toch zeggen dat die host niet naar een ip omgezet kan worden. Ik zou denken dat die gaat zoeken naar een "/" of "@" wat die ook eerst tegen komt, in dit geval een "/" waardoor die denkt dat alles daarvoor een host name is en naar een dns stuurt. Zelf kan die dat niet omzetten omdat die dan alle data van alle dns servers zou moeten kennen. Omzetten naar ip zal altijd via een dns server gaan. Maar als de url juist zou zijn en dus als eerste een "@" zou vinden dan gaat die alles na de "@" tot aan de "/" naar de dns sturen.

Dat die een paswoord plain tekst naar een dns zou sturen is de fout van de persoon die de url geschreven heeft en zou bij een juiste werking inderdaad niet gebeuren. Maar als jij in je url een paswoord typt dan kan geen enkel programma weten dat dat een paswoord is. Zou wel een ideale wereld zijn als alles automagisch gebeurde en niemand zich ooit aan enige standaarden moest houden.

Nu, ik ken de werking van curl niet, maar ik weet dat in elk geval een dns server gebruikt moet worden om het juiste ip te weten te komen.

[ Voor 5% gewijzigd door kluyze op 20-01-2010 20:40 ]

[CyBeR]

kluyze schreef op woensdag 20 januari 2010 @ 20:38:
[...]
Maar de host moet wel door een dns server volgens mij en als het paswoord gezien wordt als een host wordt die naar een dns gestuurd lijkt me.

Wat je in de rest van bovenstaande post zegt klopt als een bus. Maar in je originele post had je 't over de url die geresolved moet worden en dat is niet zo. Een URL bestaat uit een aantal onderdelen, een ervan is de hostname en die moet geresolved worden naar een ip als 't dat niet al is.

Verder heb je gelijk: curl bugt op de /. Aangezien er een : voor en een @ na komen hoort 'ie die niet te interpreteren als onderdeel van een pad, maar dat doet 'ie wel.