Port Forwarding and How to Prevent Open Redirection Attacks

Through port forwarding a hacker cannot get access to you, but the router can be exploited in order to allow configuration on a web port.

A web application that redirects to a URL that is specified using a request based on a querystring can be easily tampered with via a redirection of the users to an external and malicious URL. This kind of attack is known as an open redirection attack .

To perform an attack and to encounter this vulnerability, it is very important to understand how login redirection works in an ASP.NET MVC web application project. In the example presented below, we can see that if we are going and access a controller action which has in its structure the [Authorize] attribute, this will redirect the unauthorized users to the /Account/LogOn view. The mentioned redirection to /Account/LogOn has in its structure a parameter known as returning_url querystring in such way that the user will be returned to the genuine URL that was requested after being logged in with success.

Attacks based on open redirection are very dangerous. The attacker knows exactly when we are proceeding to log into a certain website. This can make us vulnerable to a phishing attack. As an example, consider an attacker who sends malicious emails to users who are subscribed to a certain website in order to capture their passwords.

Let’s consider the following example in which an attacker sends a link to users which contains a login page on a specific webpage (e.g. http://apressprocryptoexample.com) which has in its component a redirection to the forged page,

http://apressprocryptoexample.com/Account/LogOn?returnUrl=http://apresprocryptoexample.com/Account/LogOn. Pay attention to the returning URL, which points to apresprocryptoexample.com. Note that an "s" is missing from the word “apress.” This means that the domain apresprocryptoexample.com is being controlled by hackers.

If the login is performed correctly, the AccountController LogOn action from ASP.NET MVC will redirect us to the URL mentioned in the querystring parameter, returning_url. In this situation, the URL is the one used by the attacker, which is http://apresprocryptoexample.com. If we are not paying attention, we will not notice the difference in the browser. The attacker is a very well versed person and is careful to make sure that the fake page looks exactly like the original one. The fake login page includes an error message that says that we need to log in with our credentials again. Once we retype our credentials, the fake login page will save the data and send us back to the original page, ApressProCryptoExample.com. At this point, ApressProCryptoExample.com will have already logged us in with success, and the fake authentication page is able to redirect us to that specific page. The final result is based on the fact that the attacker is aware of our credentials (user name and password) and we, the real users, are not aware that we have provided our credentials so easily [4].

SQL Injection

For many companies, their business occurs online and in environments [5] such as cloud computing and big data, so their web sites are becoming more and more exposed to the possibility of data theft. Hackers can get important information from their data and pass it to other players on the market.

SQL injection is one of the most common methods through which malicious users can inject different SQL commands into a SQL statement using web page input. By doing so, the malicious users can break the security of the web application.

In this section, we will consider the following web application, which is built from scratch for this purpose. The reason of creating such an application from scratch is to illustrate the common mistakes developers make during the development process.

The first step is to build a database with a table that holds the login data for users. The database is created in Microsoft SQL Server v.17.9. Figure 22-1 shows the structure of the table and Listing 22-3 shows the SQL script code for generating the table. One of the common mistakes is that many web applications store passwords in plaintext. It is recommended to avoid this practice. The best practice is to use hashes of the password (such as MD5, SHA128, SHA256 etc.). For our example, we will use plaintext passwords.

The second step is to populate the table with some data, as in Figure 22-2. And then we execute the script against the table from Listing 22-4.

The third step consists of building the web application. For this, we will not use an extra fancy web application architecture. It’s just a simple web application with two web pages. The connection to the database is done using ADO.NET. With other object relational mapping (ORMs) such as NHibernate, LINQ-to-SQL, or Entity Framework, the results are the same. The single difference is the long time for processing the SQL injection.

The first page that we build is Login.aspx. As you can see in Figure 22-3, the page contains a simple form. The code is shown in Listing 22-5.

Other types of SQL injections can be seen in Table 23-1. Some of them are quite dangerous and are not recommended to be used against live production databases.

In case of an ASP.NET MVC web application, the procedure is similar with the one described above.

Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is a security vulnerability where an attacker inserts client-side scripts, mostly JavaScript, into web pages. When a user accesses a web application, the browser will load the affected pages, and the scripts found within those pages will run, providing attackers a way to get possession of cookies and session tokens. Most of the time, XSS vulnerabilities occur when the web application takes the user input and outputs it to another page without validating, encoding, or escaping it.

As an example, we will consider how HTML encoding behaves with the Razor engine used in MVC, which encodes the entire output from variables. For this not to happen we need to have a workaround to prevent this situation. An HTML attribute related to encoding represents a superset of the HTML encoding type, which means we don’t need to worry if we should use HTML encoding or HTML attribute encoding. We just need to be sure to use ‘@’ in the HTML context and not when we are trying to add untrusted data as input directly with JavaScript.

This being said, in practice it is difficult to pay attention to the encoding process. The encoding takes place on the output and the encoded values should not be stored in the database or on servers, especially in cloud computing in a big data environment.

Conclusion

This chapter presented three common attacks that occur in a web application: port forwarding with redirection attacks, SQL injections, and cross-site scripting attacks.

Bibliography