Developing a file upload application with a Barracuda WAF
Background
The application has two parts the submit information and the file upload. The application is broken down like this to allow users to enter their information and then allow them to go get the files they need to upload later. This presents a problem because we must make sure the user that submitted the application is the same user that enter the information in the first part of the application. To do this we will verify the users email and their reference number that they received at the end of the first part of the submission.
The area that we are interested is what happens when the user logs back into the system. How can we make this as secure as possible and stop malicious users trying to abuse the system? The most obvious type of abuse that a user could inflict would be to upload a virus. To combat that we have a Web Application Firewall (WAF) with a virus scanner. That is that then? Not quite that will throw up a whole new set of problems that we will encounter.
File upload high level architecture
As we can see from the below diagram the user will enter the file upload journey via the log in screen. Every POST back to the server must first go through the WAF to protect the servers from harmful content. So, the scanning and checking of all the content happens before the POST data ever gets to the servers. The WAF will protect the servers from several threats not just viruses. We are using the WAF to only allow certain file types e.g. jpg, png. This will stop the user uploading executables or files more likely to contain viruses. We are also using the WAF to stop users uploading file more than 10MB. A malicious user may wish to use up resources by uploading a massive file that would eat up our bandwidth and storage. To avoid this the WAF filters out any files that are greater than 10MB.
Scenario 1 — Malicious User tries to submit files repeatedly.
One of the possible attacks is that a malicious user will try to repeatedly submit files to the system to use up resources and bring the site down. The most obvious way they would try to do this is to login to the site repeatedly using the same email and reference. To mitigate against this, when the user has completed their file upload their record is marked as complete and they are not able to log into the system again.
At step 4 after the files have been uploaded successfully the users record is updated to complete and at stage 5, they will no longer be able to use that email and application reference.
Scenario 2 — Malicious User tries to upload a forbidden file
A malicious user may try to upload a file that we do not want them to. If a user tries to upload a file that is contains a virus, is too big or is not the correct file type it will be rejected by the WAF.
1. The user will log into the system with their email and reference
2. They will select the forbidden file and upload it.
3. The WAF will scan the file and reject it.
4. The user will be redirected to an error page.
The user will then have to start their journey over again. This presents a problem for the system. The user has been able to submit a file and has not had their record locked out. This means that a malicious user could keep repeating this process and use up the WAFs resources to scan the same file repeatedly. To combat this, we have introduced a count per email and reference record. Every time a user logs into the system the counter is incremented. Once the counter passes a threshold the user is no longer able to access the system.
The WAF sits between the user at the front end and the server at the backend as such if a problem has been detected in the WAF it will prevent any access to the backend. This will prove to be a problem when we want to increment our counter for the number of times the user has tried to upload a document. To get round this we must increment the count on the GET method. Or to put it another way when the page is loaded opposed to when the file is uploaded.
In the below diagram we can see the green arrow is when the page is requested from the server. At that point we can update the count for the number of attempts to 1. If the user tries to upload a file and is rejected be the WAF (3) they will go to the error page (4). If the user hits the back button on their browser from the error page, they will go back to the file upload page (2) and the page will be requested from the server. This will then update the count for the number of attempts to 2. To make sure the user does not receive a cached version of the file upload page (2) no-cache was added to the header of the file upload page. The process continues incrementing each time until the predefined limit has been reached. Once the user has reached the limit they will be redirected away from the page and have an error page asking them to contact the helpdesk. A genuine application will have no problem contacting the helpdesk whereas a user attempting to do harm will not.
One drawback is that if the user loads the file upload page and keeps refreshing the page, they will lock themselves out of the application. The chances of this happening are small. One possible way to navigate the issue would be to lock the account out for a set period e.g. 30mins. However, this may be over engineering the problem.
