Logging into a website with Powershell

Powershell is great, and it's lately been my go-to shell while I'm working on Windows.

Sorry command prompt

I really don't do a lot of work in the shell, but I do like to play with low-level interfaces from time to time. The article is about Linux shells, but goes into good explanation about what a shell is if you don't know.

Log into a website

Today, I wanted to do something that I have never really tried before and that is logging into a website using Powershell. The concepts behind this are quite simple really, as Powershell has support to send HTTP requests and that's usually all we need, unless the server has CSRF protections in place (which it should).

We are going to attempt to log in to my favorite website for buying socks, Absolute Socks:

Is that a turkey?!

In order to do that, we need to have a login. So if you don't already have an account on www.absolutesocks.com, go make one now.

Viewing the login request

On websites, a login request is a HTTP POST (you should never be logging in with a HTTP GET request). Typically, in these requests, we send the server our credentials (user name/email and password) and they return for us a token or cookie that we use in subsequent requests. It is the presence of this token or cookie that tells the server we have successfully authenticated (not authorized - that is different!).

There is a difference between token and cookie based authentications. The simple explanation is that in cookie-based authentication, the cookie holds a value to the session on the server. This session stores information about a current user's visit. In token-based authentication, the token acts as an object that gives the bearer (the user) access to pages that require authentication. Token-based authentication is stateless while cookie-based authentication retains state. For a longer and more detailed explanation please visit this page. 

Let's see what our login request looks like on the site, and to do that we need the inspector open (I am using Chrome as it is my go-to browser) and focus on the Network tab. I also want Preserve log (which prevents requests from clearing out when the page navigates) and Disable cache (prevents client-side caching). I would recommend clicking clear before logging in, as you may have some strangler requests in your Network tab:

Prepping the inspector

A lot of websites now are using javascript to login, so in order to check if our login is handled by javascript, I will filter my requests in the Network tab by XHR:

Viewing XHR requests

I really do not see anything that could possibly be a login request in here. Shucks. Let's change the filter to All and see if we can find the login request:

Viewing All requests

Bingo! First request. Let's click on the name of the request and look at the details a bit:

Request detail view

It appears to me that the login endpoint takes in two values, a login_email and login_pass. This seems easy enough to replicate in Powershell now. Let's open up a Powershell instance.

Writing Powershell code

In order to send a web request, we will use the Invoke-WebRequest command, passing in the HTTP method and body of the request (our login credentials):

Invoke-WebRequest -Uri "https://www.absolutesocks.com/login.php?" -Method Post -Body @{login_email='[email]';login_pass='[password]';}

We are using a hashtable to pass in our email and password. This can be seen in the official docs as one method of POSTing data using Invoke-WebRequest.

Our request should have succeeded, but it doesn't. We get an Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send. Unfortunate for us. Googling the error gives us a fix for this issue, which is to execute this code prior to executing our Invoke-WebRequest. So let's execute this in our Powershell instance:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 

One possible reason why we need to explicitly set the SecurityProtocol is that Powershell is picking the wrong version of TLS for us. According to official documentation, the default value for SecurityProtocol is 0, which means Powershell is automagically selecting our TLS version for us.

Making another request

Running our original request is taking a long time, almost too long. I end up on this github issue and read it enough to see that we should add the -UseBasicParsing flag to our Invoke-WebRequest command. Let's do that now:

We've logged in!

The StatusCode of the message reads 200 which means the request was successful!

Where do we go now?

I'll leave that as an open question, and possible continuation of this post sometime in the future.