Invoke-Webrequest using secure string

[notdosom]

Hello everyone,

here is my question, I can't find anything online nor will AI help me (Might be my fault tho)

So I want to use some Invoke-Webrequest cmdlts, but I first have to login to the website.

I tried it with PLAIN Credentials, everything is working like expected. But now I have to get the script working with a Secure String password (and a SecretVault for stored Creds but thats not the Problem right now)

The Webpage is reading the Secure String literal so it obviously wont accept my pw.

Is there a way to format the String so im able to correctly pass it to the webpage? I know i can make it plain but thats obviously not what i want. Maybe there is a compromise?

The request has to be POST

Or maybe there is even a way to properly imbed the Secure String so its readable for the webpage(?)

#This is not the acutal script im working on but a mini version on a test site, the $dbForm.Action is probably not working but it doesnt matter here

$r = Invoke-WebRequest -uri "https://keepass.info/help/kb/testform.html" -SessionVariable ses $dbForm = $r.Forms.Fields

$dbForm["LoginFormUser"] = "testuser"

#Note that i want this to be a Secure String but as of right now this only works plain :(

$password = "PlainPW"

$dbForm["pwd"] = $password

$r1 = Invoke-WebRequest -uri ("https://keepass.info/help/kb/testform.html" + $dbForm.Action) -WebSession $ses -UseBasicParsing -Method Post -Body $dbForm

I will successfully login using the plain PW (again, it wont work with a secure string) and can now crawl. Please suggest anything that comes to your mind :)

[#2]

Hi @notdosom 

You already use a HTTPS Connection and the Website receives the Username/Password in a HTTPS POST.

The Website needs to be able to read your password in order to Verify if it is correct. Webservers do not understand SecretString - therefore that can not work.

I guess that's just how it is.

Kind Regards

Andres

[#3]

@notdosom 

Hi, Dominik.

It's important to note that a secure string cannot be sent from one machine to another. You can only decrypt a secure string locally on the machine that created the secure string.

So, if the system hosting the web application is also creating the secure string containing the password and wants to send that password to another server, it will have to send the plain text version.

If the web application is sending the password to another local process running on the same system, you could send it, but it's complicated and - depending on the implementation - comes with the risk of memory leaks (as some unmanaged buffer work is involved where you're responsible for the memory allocation and clean-up).

Here's an example of the first approach, where you leverage the [pscredential] type to do all the hard work of the latter approach for you to get the plain text version of the password stored in the secure string.

I'm not particularly convinced there's much point in storing the encrypted password in memory only to transmit the plain text password over the network (where you'd hopefully be utilising and TLS connection) but that's a judgement call only you can make.

Cheers,

Lain