Skip to content

Sessions, and Authorisation Lab

This week we looked authentication and authorisation. We also looked at sessions, and storing data on the clients computer.

In the lab tasks for this week, we will look at how we can work with different auth methods, as well as read, and manipulate local storage information.

As with the Lab on requests last time, as you complete each task you will get a flag. You are free to use whatever method you want (for example the browser, tools like burp, or code) to complete the tasks. However, it is a good idea to try to complete the tasks in several ways, this will give you practice working with different methods.

HTTP Basic Authentication

First lets take a look at HTTP Basic Authorisation The first time we visit the page at /sessions/basicAuth we get a prompt for authentication. Look at the Response headers. See how we get the authentication header.

Note

If you tick the "Preserve Log" option of the network viewer, you will see the full request history. Here you can see the original "failed" 401 Auth failiure.

You can also view the 401 headers when the login dialog is shown

WWW-Authenticate: Basic realm="Authentication Required"

You can login using the following credentials:

  • Username: Erebus
  • Password: Davin

Once the login is successful, the browser will cache the credentials and forward them as part of the request headers. You can check this by inspecting the request headers for further requests.

Authorization: Basic RXJlYnVzOkRhdmlu

Easytask

Visit the basicAuth page, Check the request and response headers. See how the username and password are encapuslated in the BasicAuth Header.

In the first challenge this week can be found at challenges -> basicAuth you will need to use HTTP Basic Auth to log into the page, and get the flag.

Task

The page at /sessions/challenges/basicAuth has a version of HTTP Basic auth implmented.

Modify the Request to login as

  • User: Lorgar
  • Password: Cadia

Token based authentication

No demo this time arouse, only a challenge. Research how other forms of HTTP authentication work to complete the task

Task

Authentication tokens can take the place of passwords for either API's or when a 3rd party authentication method is used.

The page at /sessions/challenges/tokenAuth Uses HTTP Bearer authentication, and the token EJUBeTGBlI

Authenticate with the page to get a flag.

Using Requests to store state

Some applications use the requests themselves to store state. For example, in a multi stage process, previous elements my be appended to the request. This is not a secure way of doing things, but can be convenient.

Example

We can find an example of this under /sessions/state

We have a form that takes a user name. If we look at the source for the form, we can see a "hidden" field for admin.

Modifying this in the inspector tool in the broswer, lets us change the type of user we are logged in as.

Task

The challenge for this is under /sessions/challenges/state

We have a similar process here, look at the source, and the requests sent and recieved to become admin on this page.

Client Side Session data

Some technologies like Flask make use of client side session data.

To keep the data secure they then sign the cookie with a cryptographically secure key. If we can get hold of the key, we might be able to modify the session data

Hardtask

Take a look at the tutorial here and see if you can get set the flask cookie user to admin.

You will need the Secret key of "Sekr3t_Tok3n"

Back to top