Most common security mistakes

During our work with multiple clients, we have noticed one most common vulnerability in new web applications. To make sure these vulnerabilities do not exist and the developers are made well aware of it, we will like to share a little article about it.

When our red team starts to test out an application, we no longer think as good hackers. We take the sides of bad hackers and ask ourselves a question: “If we really wanted to destroy this company, how would we do it?”. Simple vulnerabilities like XSS are common but are those the ones that we can use to completely take control of an application? Not always. You can sometimes get lucky and end up getting bXSS(Blind XSS) and get admin cookies which eventually gives you access to admin console but that is limited in many situations. One thing that we always target is functionalities that are crucial.

Some examples of crucial functionalities that we check are issues where you can delete and add files. These can be dangerous in many situation. What if I can download someone else’s private files? Lets take Medium for example: what if I could get access to your draft articles that are not out yet? That could have some risk at it. Along with that comes the risk of deleting someone else’s file. If I could delete someone else’s resume or update it in a Job app that could be bad. Sometimes we even get access to files that have applications with SSN (social security number). That is really bad.

Another risk that we check is uploading files. When you upload image or pdf files to a website, can you manipulate and upload HTML/php files? Uploading HTML files could be pretty bad. For example you could post your own content. When testing an app of one of our clients ( a good friend of ours ), we decided to have fun and uploaded a following application:

Client had a good chuckle about this (he did not get mad)

How can this work?

Most of the time, when you upload a file a POST request is sent to the server with file contents. Along with that is the file name and a mime type. Mime type is often set like this: Content-type: image/png . This tells the application that the file is a .png image. In the file name it could be something like this: [filename].png . This is when the fun starts.

What we often do is change the file type and add the following code:

<h1>Hi, this is Securify Red Team testing your application for obvious reasons</h1>
<script>alert(document.domain)</script>

This way we can always show our clients that their application now can have any form of files with any contents along with XSS and many more. After we change the content, we change the name to [filename].html but still keep the content type to image/png . This way if the app is checking just the mime type, we can still print the file. We have so far add a success rate of 90% with these kind of attack measures.

This is extremely common in many modern applications. What makes this more risky is if the file is uploaded to the same server in which the main application is running. This can allow you to conduct much more critical attacks depending on which kind of files it can read. To make sure this is prevented, we always recommend that our clients store their files to AWS and secure it from there. This way if someone does finds a way to upload HTML file or other extensions the security risk is minimized. This does not however give excuse to allow uploads of any files.

Thank you for reading.

Security Red Team