This is the fifth (wow, that is quite a lot) post in the One Tool, All APIs: PowerShell series. Previous posts:
- One Tool, All APIs: PowerShell As The All-Purpose API Client
- One Tool, All APIs: API Authentication With PowerShell
- One Tool, All APIs: API Parameters with PowerShell
- One Tool, All APIs: Construct API Headers with PowerShell
In today’s article, we will look into API cookies & client session controls.
As usual, let’s start from the basics. Cookies are small pieces of data stored in the user’s browser by websites they visit. Typically, they are used to cover 3 major use cases – tracking, session management and personalization.
Tracking is pretty self-explanatory and users are very cautious about them. They are used for analytics, advertising, and tracking user behavior on websites.
Session management (slight overlap with our next category) maintain information about a user’s session. This allows the server to recognize & distinguish users as they navigate the site.
Personalization is also an obvious one, they can store user preferences, language settings, and other customization options.
All cookies can be grouped into two buckets: session cookies and persistent cookies. First ones are temporary and exist only for the duration of a user’s session. Meaning that once the connection is closed, they are deleted.
Persistent ones, on the other hand, persist even after the browser is closed and can have expiration dates set for even years. Usually, they are used for long-term personalization.
As for the session controls, we are going to focus on the client-side session controls. API endpoints have their implementation and specific rules for session controls that we (API consumers) cannot alter. But (there is always but) there are a few things that are still under control of the API client aka PowerShell in our case.
There are 4 options available for client side session controls.
First one is using cookies for session management. As mentioned above, information about user session is stored in session cookies and is appended in subsequent requests client sends to the server. This way server knows/tracks/identifies user session and can provide personalized content to the users.
Another (second) option is related to storage mechanism. During the web surfing, session storage is available only for the duration of the session and is purged when the session ends. In local storage, on the contrary, data persist after session is closed and is available across browser sessions.
Next one, (third) Jason Web Tokens (JWT) is closely related to authentication. Using JWT it is possible to manage user sessions by including information like user ID, expiration time, and other relevant data.
And the last but definitely not the least one, are the security measures. Secure cookies are transmitted only over encrypted connections, reducing the risk of interception. HttpOnly cookies cannot be accessed via client-side scripts, mitigating certain types of attacks.
RFC 6265 defines the modern standard for the HTTP cookies. It covers attributes like secure, HttpOnly, domain, path, expiration, etc., providing guidelines for cookie creation, usage, and security considerations. RFC 7230 and RFC 7231 define specifications for HTTP/1.1, outlining how HTTP messages are constructed and transmitted. Those RFCs don’t specifically describes session management, as they outline basics of the HTTP protocol and session management techniques rely on those basics. Also, it is worth to mention RFC 7519 which outlines the structure and use of JSON Web Tokens (JWTs), which can be utilized in managing sessions.
Cookies & Session Control with PowerShell
At this point you might think that all of this is interesting and educational but where the hell PowerShell stores the cookies? Is it different from the regular browser?
In PowerShell, when you use Invoke-WebRequestInvoke-RestMethod
Example
In the example, we will login to the web endpoint and then use session variable (and cookies) to access additional resources without subsequent authentication.
We will use the Natas by Overthewire CTF game as our endpoint. (Do not worry, I will not spoil the passwords for the levels and will use the basic Level 2 for example).
Approach
- Authenticate (refer to One Tool, All APIs: API Authentication With PowerShell for more details) and store session info and cookies in a variable
- Use the authenticated session object to access resources
$creds=Get-Credential $response=Invoke-WebRequest -uri "http://natas2.natas.labs.overthewire.org" -Credential $creds -AllowUnencryptedAuthentication -SessionVariable Natas2Session $response.content
Now, lets try to access the resources in the files directory. If we try without any credentials we will receive an error:
To access it we can pass the credentials again, BUT we also can use our $Natas2Session variable, which stores information that we are authenticated.
$response3=Invoke-WebRequest -uri "http://natas2.natas.labs.overthewire.org/files/" -WebSession $Natas2Session
Conclusion
As you already figured, the conclusion is pretty much obvious and the same as in the previous articles from this series. If you know what you need to do and the fundamentals of how it supposed to work and/or behave, you can easily interpret the knowledge and apply it to any other realm. Like using PowerShell as you API client including all the configurations and parameters available.
Icons created by Freepik – Flaticon.
Thanks a lot for reading.
