How to build and hack a simple flask web app with OWASP

How to build and hack a simple Flask web app with OWASP

How to build and hack a simple flask web app with OWASP? Well not with OWASP but you can use OWASP as inspiration on what to build and hack. The idea behind this post is to explore web vulnerabilities both as a Bug Bounty hunter or a penetration tester, a SOC analyst / Blue teamer, and a developer.

How to build and hack a simple flask web app

To identify a starting point for this process the OWASP top 10 has been chosen. This top ten list tracks and writes about the top ten web vulnerabilities each year. Their goal is to educate companies and developers about their biggest mistakes. A perfect list for us to choose an issue to experiment with.

We will make this easy and explore the first one on the list: A01:2021 Broken Access Control.

The gist of this category of vulnerabilities is that a user is enabled to (read or write) access content that it should not have permissions to access. For example, a non administrative user manually browsing to the /admin page and being allowed to enter the page without having administrative privileges. 

In an attempt to explore and understand this category of vulnerabilities we will focus on the following points.

  • Developer : Build the simplest web app possible to test this vulnerability.
    •  This will force us to learn what we need to do / not do to both get a vulnerable site and how to fix it.
  • Bug Bounty Hunter / Penetration Tester : How do we detect this vulnerability on the site and exploit it?
    •     Are there any patterns or hints that we can observe and take with us into the future?
  •  SOC Analyst / Blue Teamer : Are there any kind of monitoring we can do that would identify the broken access control?

[Not all steps taken will be shown – try the lab out yourself. Learn through practice] 

Now let’s build and hack a simple Flask web app.

How to build a simple flask app

Put on your developer hat and start your Linux box! (or at least install a Linux subsystem on your Windows box)

In this example we imagine that the easiest way for us to implement a website with this type of vulnerability is to build a site with two types of users: administrators and normal users. All users can access the homepage of the website while only admins should be able to access the admin-page.

This is a reasonable scenario – of course there are levels to this but let’s start off easy.

We are now a developer and has chosen to build a website with flask, this is where we go after a quick Google search: https://flask.palletsprojects.com/en/2.0.x/quickstart/#a-minimal-application. Follow the guide and get the web app up and running.

Build a simple Flask app
Woho! We got a web app running. We build a simple Flask app.

Now let’s add that admin page. Further down on the same flask minimal application page we learn about routes and displaying different pages. Lets add a /admin route

Admin site to Flask app
Admin route added to page

Well actually at this stage of the website we already have broken access if we assume that the contents under the admin-page was for admin eyes only. There is no way for someone to browse to the admin-page from the start-page. But if we manually change the URL there is no access control to stop us. We will build a bit more functionality into the web app but lets change into an attacker now. How do we find this secret admin-page?

How to hack a simple flask app

Browsing to the startsite, we can inspect the HTML source code but we find nothing. No hints of there being anything else available on this site. A typical starting point for an attacker would be to start some kind of brute force tool that tries to enumerate all possible available paths on a site.

We will use Gobuster to test a large number of possible pages on the website and report back to us with the results. To achieve this we also have to tell Gobuster what pages to try using a wordlist. There are public good wordlists available, for example the “directory-list-lowercase-2.3-small.txt“-list. Looking at this list it contains strings that we believe we might find pages on the website we are testing, for example “login”, “help”, “register”, etc …

Running Gobuster against our local web app will find the admin page almost instantly:

Hacking a simple Flask app
Hacking a simple Flask app

The output shows that it found the page /admin with a HTTP response code of 200 which is “OK” – a successful request to the page. Browsing manually to this URL from the browser we get full access!

App successfully breached

Well. That is not good. Our precious admin page with all the confidential information has been breached – did we detect it? Time to switch over to our defender hat.

Defend the flask web app

How are we expected to detect someone visiting our admin-page? Do we even have this capability? Yes. We can watch the web logs.

With the current setup there are no log files to watch, the only data we have is the running command “flask run”. At this moment in time we first observe that someone has visited a lot of non-existent pages. This is a mess, let’s call the developer and tell them to at least log this to a file so we have something persistent to look at.

Enable logging for the flask app

Obviously this is running in a development environment and without a web server etc.. But let’s keep it simple and implement logging ourselves. There is a section on this in the documentation with a simple example, let’s implement that!

After implementing this feature we at least have the detection capability to detect when someone did access our admin-page. The prevention part of the defense is missing though and the site is still vulnerable.

The next lab will go through how to add an administrator to the site and a login page to mitigate this vulnerability. In the process of implementing this with SQL it is possible that we stumble upon and investigate SQL injections as well. Follow the second lab to create a Flask app login vulnerable to SQL injection.

Develop, hack, and defend: Broken Access Control

Learning the underlying possible mistakes that a developer might do will help you as a bug bounty hunter or penetration tester to know what to look and test for. In this simple lab example we looked at a web app from three different perspectives.

  • The developer perspective – How to actually build it and get it up and running.
  • From the perspective of a hacker – How to find hidden pages with brute force
  • And from a defender perspective – Get the ability to detect

This kind of exercise is highly valuable for you to try out and learn new things. Get new perspectives that you can use in the future. Do you have something in mind that you wanted to learn how to hack better? Well build it and hack it.

Continue sharpening your hacking and defending skills by also create a XSS vulnerable website to learn about Cross site scripting vulnerabilities.

Do you have something that you want to defend better? Well, how would an attacker do it? Learn how to think like a hacker.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *