Web Security & Best Practices

Web Security & Best Practices

How do you secure your home? By installing locks, only giving your house keys to your family members, making sure the fence is high enough, installing CCTVs, and probably a lot more that I don’t know about.

But what about your web application? Is your app secure? How do you even know if it’s secured? How can a person hack an application?

In this post I will be sharing about web application security and the best practices. There are a few common exploits a hacker can use against you.

Common Exploits

SQL Injection

Let's start with something basic that you may have heard about. SQL injection prey on applications where a user can affect an SQL query directly. Say you have a table list with a search on top, and you developed this on vanilla PHP with no framework and no input sanitization. Chances are, a user can input an SQL script into the search bar and have direct access to your database. Try this and see:


; DROP TABLE users;

If the users table is deleted. Bad news, your application is prone to this basic attack. If your database is safe, then congrats. 

SQL injection is highly uncommon nowadays due to it being as old as the internet and frameworks blocking this exploit by default.

Cross Site Scripting (XSS)

Think of SQL injection, but instead of SQL it's JavaScript. Same principle, just different language. Try typing a simple JS script into one of your site’s inputs to see if it’s susceptible to this attack. Then save it to your database.

<script>

    window.alert('if you see this, you’re cooked lol');

</script>

If that alert pops up, you absolutely should be worried. This attack may seem silly, but on the wrong hands can be deadly. Especially when combined with the next exploit.

Cross Site Request Forgery (CSRF)

Request forgery basically means an attacker is wrongly using an actual user’s session to log into your system. They can craft a JS that steals the cookies or caches of your site’s user, then send it to themselves to use for malicious reasons.

Broken Access Control (BAC)

This is the most common exploit nowadays. An application gets too large too quickly, and nobody cares to test all access for all pages. To test this, try to directly access a page that you don’t have access to. Examples include opening reports without logging in, trying to access an admin-only page with a normal user account, randomly replacing numbers at the end of a URL to access data that isn't yours. 

Best Practices

We now know the problems, so what the heck is the solution? It’s actually simpler than you might think.

Ditch Vanilla, Go Framework

This alone will solve 99% of all vulnerabilities, provided you know how to use the framework’s security libraries. 

Input Sanitization

Never assume a user’s input as safe. Always handle them like it’s contaminated. Validate on both frontend and backend. Sanitize it by removing any HTML, JS or SQL code. 

Validate File Extensions

Never trust a file’s extensions. Would you plug a stranger’s usb stick into your computer? Why would you trust a stranger’s file? A ‘.pdf.php’ file might contain malicious code that can run on your server if you didn’t properly check its extensions extensively. 

Even More Access Checking

Example:

- Check if user is logged in

- Check if the user has appropriate access to the module. Eg: admin/hr/finance

- Check if user have access for requested data

- Check if user have access to write/delete data

In conclusion, being a bit paranoid pays off and frameworks exists for a reason. That is all.