Website Hacking: Common Web Vulnerabilities and Brief Solutions 2023

In this article we will learn about Website Hacking.

Introduction to Website Hacking:

In this final installment of the Website Hacking series, we’ll list 18 common web vulnerabilities and bugs and briefly provide solutions. Some of them are covered for the first time in the Hacking Website series, and some we have covered before, but in more detail.

Saving all user inputs

If you’re using a framework, such as a PHP framework, you might be tempted to store all user input in your model or database because it’s already been validated and escaped. Let’s say you’re using CakePHP and you’ve included a registration form using CakePHP’s form helper.

The registration view may look something like this:

Click below to download the code snippets associated with this article:

[download]

Snippet 1

Now, you might be tempted to save all the data from CakePHP’s $this->request->data array/method as is unless you read the docs carefully or look at some of the examples there (live blog site).

Snippet 2

Just save all the data and thank the creators of the framework. However, there are at least two things you did wrong:

$this->request->data does not contain leaked/sanitized input, only input from superglobals.

First, you should use CakePHP’s h() function to prevent people from putting tags in your username: like this h($this->request->data)

However, this is not enough and is the wrong approach. If you store all user input in your model (database), the user can add new input tags right in their browser and try to guess some of the columns in your user table that you didn’t input in the web form.

For example, many CakePHP applications have a “role” column set to user/admin or something similar (also used in the docs).

The user can just open their developer tools, find the registration form, or right-click and select Inspect Element, click Edit as HTML, and add a new input like this:

Or, whatever the way forms currently interact with your models, guess the column names and put values ​​into them.

One way to solve this is to change the column that defines the user roles and permission name to something unpredictable. However, this is not the safest approach you can take.

You can either insert the data into the database manually, which will ensure that no additional columns are stored:

Snippet 3

Or you can still store all the user data, but explicitly set column values ​​that you won’t find in the form:

Snippet 4

Allowing User Access to Assets

Many websites work with and store user input and user data. Clients can see where their assets are stored, so they don’t have to guess. For example, the client saw that the images he uploaded were stored in /uploads/{username} because the images he uploaded were loaded into the page from that directory, so if he knew some usernames of different people, he could simply change the directory name to another user and browse all their data without having to brute force directory names.

The first way to deal with this problem that we talked about earlier is not enough (adding Options All – Indexs to the .htaccess file). This would prevent users from traversing the directories and opening whatever they want, but they would still know the directory exists and can still guess directory names because the server will return a 403 Forbidden (indicating that something exists in that path). Additionally, they could guess the filenames from some of the patterns the filenames follow and open them.

Therefore, you need to block access to the files in the upload directory. If you are storing text files (let’s say users can save notes and view/edit them whenever they want), you can add the following rule to your .htaccess:

RewriteEngine On

RewriteRule ^uploads/.*.(txt|doc)$ – [F,L,NC]

The F flag returns a 403 Forbidden response, the L flag causes other rules to stop processing, and NC eliminates case sensitivity.

Figure 1: The page with only directory listing disabled.

Figure 2: The page with only directory listing disabled. You cannot browse directories, but if each user has a notes.txt file, you can easily view user’s notes by knowing only their username.

Figure 3: Trying to access the notes with both directory listing and controlled access to files.

If you use an override rule to prevent users from browsing other users’ notes, your backend will still be able to access, display, or edit the notes to users. For example:

Snippet 5

Where the $user variable would come from a session in a real application.

Running a basic WordPress installation

Common errors here do not limit login attempts on your wp-admin page. This would allow anyone to brute force your credentials and destroy your blog/site. This is even easier because most people create their main username as “admin”, which just involves brute forcing the password to get full access to the WP site. Another mistake is that the wp-admin login page is left without a CAPTCHA form or bot protection.

That combined with no limit on login attempts equals the certain death of your online presence at some point in the future. You can avoid all 3 of these things and also change the default wp-admin path to be something different as well (confusion).

Relying too much on IP addresses while having weak protection against bots

Most ISPs provide dynamic IP addresses, and an IP address that you have disabled or saved can be out of date in less than a day. In addition, it is often not too difficult to change your IP address – use a proxy, release it from the router or from the OS, change the location.

There are countless ways to do this. To prevent bots from causing unwanted consequences, it would be better to use alternative ways – improve your CAPTCHA, add inputs that only bots fill, require JavaScript/cookies enabled for form submission, etc.

Incorrect redirects

Let’s say you have a redirect page or a GET value (for simplicity) that redirects the user to another page on your site or to another site. However, if you forget to disable redirects to third-party websites, or if you enable them, if you don’t create a warning page before the redirect that tells users where they’re going and that they’re leaving the site – users can easily abuse your site by providing links that appear to point to your website, but they redirect users to malicious websites.

if (isset($_GET['redirect'])) {
		header("Location: " .  $_GET['redirect']);
	}

If we have something this simple, then users can easily get confused and enter the wrong page by following a URL like this:

http://localhost:8079/articles/Website%20Hacking%20Part%20VII/?redirect=http://www.somemalicioussitehere.com

Request forgery between sites

If your site allows users to make comments/posts and insert tags like and load a third-party image, they may provide a link that isn’t an image, but trick client browsers (users who will read to load the resource and perform an action on the site if they are authenticated on it.For example, if Facebook only needed a few GET parameters or a specific URL to track someone/something on their network, we could add an image.

And if the user is currently logged in, they would follow any person. Of course, that wouldn’t work in this particular situation.

Insecure handling of files

A common mistake is to believe that the file does not contain anything inappropriate. The code can be disguised as an image, so checking the file extension is not enough. At a minimum, the MIME type should also be checked. Also ASCII / text files should be escaped.

Here is an example of such a vulnerability:

Snippet 6

The vulnerability occurs when we display the contents of a .txt file on our page at some point:

Snippet 7

If the file we send contains the following code:

After that, all user cookies for that site will be displayed in the notification.

Display and Trust of HTTP Headers

These can be changed by users and can be harmful. For example, if you display the client’s User-Agent header, it could be changed to include code that would then be executed in your backend.

This also applies to the referring resource header, so it should not be used to determine whether a user can access a particular page on its own (for example, checking if the referring page is a login page and assuming the user has successfully logged in since being redirected to the member area index page from the login page).

Disclosure of Information

Your live applications should not be in debug mode. Errors should not be displayed.

Browsing directories

If you use some parameter that opens different files on your site based on user input, your backend should escape special characters like . (dot) or / (slash) from the input and preferably use whitelisting.

Use of HTTP for semi-confidential data

A common mistake is to use HTTP for sites that include mechanisms such as registration/login. Even widely used online marketplaces in Bulgaria use simple HTTP (eg http://www.olx.bg ). Using HTTP makes it easy for potential attackers on your network to sniff your traffic and get your credentials without any real effort. For example, if you log into olx while connected to Wi-Fi, you are putting yourself at risk.

Seats can be stolen

Sessions can be stolen so an attacker logs in as someone else. There are multiple defense vectors here – such as IP address checking, user agent and session recovery, and adding cookies.

Be careful which third-party libraries, CDNs and plugins you use

They can simply be outdated and open a wide variety of security holes, or they can be malicious – giving access to your server to shady library creators.

Boots are everywhere

Take care of malicious bots not by banning their IPs, but by improving CAPTCHAs, adding hidden form fields that users won’t fill out, and requiring JavaScript or cookies enabled to submit the form.

Use only HTTP cookies

This would reduce the impact of some other attacks – such as XSS

Hashing

Hash your passwords and try to avoid md5 or sha-1 algorithms (https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know, http: //security.stackexchange.com/questions/33108/why-does-some-popular-software-still-use-md5). Use salts to prevent rainbow table attacks.

Always escape entry unless you really, really don’t trust the source (admin panel). You can either remove tags or view them as entities depending on your needs. | PHP: strip_tags($input, $allowedTags); htmlspecialchars($input, ENT_QUOTES); htmlentities($input); |

SQL Injection

Use prepared statements or don’t execute a non-hardcoded query without sanitizing it (PHP: PDO class or sanitize with mysqli_real_escape_string($conn, $str) if you’re using mysqli. Don’t use mysql_*).

Also Read:Getting started with ethical hacking Complete Guide By Blackhat Pakistan 2023

Conclusion

This was the last installment in the Hacking Website series. We’ve introduced some new vulnerabilities and briefly discussed them, summarizing our points on everything we’ve talked about so far.