Password exported by "Generate session URL" has html encoded characters

Advertisement

Jochen Van den Bossche
Joined:
Posts:
1

Password exported by "Generate session URL" has html encoded characters

This is with WinSCP 5.7.5 (build 5665)

I have been given a password (that starts) with a comma ",".
For scripting purposes, I use the "Generate Session URL" feature. The result of which is for example:
sftp://myuser:%2Ccomma@sftp.server.com/dir1/dir2/

In that case the password was
,comma

When using that URL in a script the connection fails, If I adapt the URL to
sftp://myuser:,comma@sftp.server.com/dir1/dir2/
The connection works fine.

So there is a simple workaround, but some people might be get confused over this small bug.

J.

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

Re: Password exported by "Generate session URL" has html encoded characters

Thanks for your report.

I'm having no problems with this command:

open sftp://user:%2Ccomma@host/

Please attach a full log file showing the problem (using the latest version of WinSCP).

To generate log file, use /log=path_to_log_file command-line argument. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.

Reply with quote

Guest

You state that
Note that passwords and passphrases not stored in the log.
Therefore a log would not be useful at all.

That log would just say that the wrong password was used, which is perfectly correct.

The reason the wrong password is used is what counts: the "Generate Session URL" feature changes the password from the entered/stored one, when that password includes a comma.


Test case:
1) Set up an account with a password that begins with a comma
2) Make a new entry for that account in WinSCP, and store the password.
3) Connect to that account using the WinSCP GUI: works OK.
4) Now use the "Generate Session URL" feature to obtain an URL for that connection that can be used in a script.
You'll notice that the URL does not include a comma at all.
Where the passord is supposed to be (so immediatly after the colon) the first characters are %2C.
After that %2C are all remaining characters of the password (those after the comma) and then the @-character followed by the host etc
5) Using that URL in a script leads to a refused connection caused by bad credentials (which is correct)
6) If the log of the server would show the used password (I guess it won't) then that password would start with "%2C" instead of with ",".


I see two options for what you need to correct:
    A) "Generate Session URL" should not URL-encode the password string
    B) The script engine should convert the URL-encoded password back before sending it to a sever.
If you go for option B, I suggest adding a security improvement: if the scripting engine has to decode the password anyway, why not make it a bit more secure by really encrypting the passwords in the generated URLs?

I won't be following this up any more since my workaround is working fine.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

Anonymous wrote:

B) The script engine should convert the URL-encoded password back before sending it to a sever.
Of course it does.

If you go for option B, I suggest adding a security improvement: if the scripting engine has to decode the password anyway, why not make it a bit more secure by really encrypting the passwords in the generated URLs?
That's not encryption. That's mere obfuscation.
See https://winscp.net/eng/docs/guide_protecting_credentials_for_automation

I won't be following this up any more since my workaround is working fine.
Would you please attach the log anyway? It might be useful. You can even enable password logging in preferences (or use /loglevel=* command-line parameter).

Reply with quote

Advertisement

You can post new topics in this forum