CYBE230 Lab 9 - Modern Web Vulnerabilities

For this lab we created a web server with Django which is a much more modern web server based on python compared to the LAMP stack. In the setup we created a project, the superuser to manage it, and the allowed hosts to be the domain from the DNS we set up. We then created a simple Hello World page to show what it looks like when visiting the site and the path to use.

By default, Django gives a large amount of debug information on error pages, this could lead to the leaking of data from the server, about what the server is running. This leaking of information could be used to find potential exploits or weaknesses in the systems.

The next major issue we talked about is Cross Site Scripting (XSS). This is a type of attack where a malicious user can inject scripts into a page and have them be executed, either by the user or the server. This is one of the most common vulnerabilities in web applications. In this lab, we showed non-stored XSS with a box that would repeat back what the user types in. So putting in something like <script>alert('hello')</script> would show hello in the alert box. To show how this can be more powerful, we used a Kali virtual machine and the BEEF framework to example a phising attack with XSS. To do this we used the BEEF framework to generate an XSS payload that would cause the web page from the Kali machine to load instead of the intended page. We then had a “user” input our script into the page which would redirect to a fake Gmail login page.

This attack was only possible as there was not proper input validation, and escaping of the input. To fix this issue we were told to look at the Python that was running on the server, and look for what was causing the issue. Looking at the code, there was a specific line that stood out to me. \{% autoescape off %} turning this on and rebuilding the site fixed the XSS issue.

After fixing the issues with the site, I then set it up to start on boot. How we originally set up the site though it was only run by us, so in the event of a reboot the website would go down. We had an automated checker that would turn green when our services were up. So I then set up a systemd service that started the web server on boot as a webserver user.