Malicious users will try to access your web application without your consent. Therefore, you should implement the necessary security features to protect yourself from new web application threats: Spoofing, information disclosure and data tampering. Let’s see how together we can mitigate threats using Plesk security tools.
1. Spoofing
Spoofing is one of the modern web application threats, despite security measures you may implement back-end to protect users’ credentials. It’s pretending to be someone or something other than yourself. And it can happen in many ways.
Fake User Authentication
Attackers can create a fake login page similar to that of a web application to trick users to log in. So that they can steal users’ login credentials. For spoofing, attackers can even use SET (social engineering tools) to clone a login page of a popular web application.
Cross-Site Request Forgery (CSRF)
Cross-site request forgery tricks a web browser into executing an unwanted action. Like transferring funds from one account to another account in a web application where a user is already logged in. Attackers usually use social engineering tricks to implement CSRF by sending links to authenticated users on social media. In other words, those already logged into a web application.
Then unsuspecting users end up sending a forged request to a server on behalf of a malicious user. Though it’s quite difficult to prevent this, below is how you can mitigate cross-site request forgery.
How to Prevent Spoofing Threats
- Implement an SSL/TLS Certificate
To defend against authentication spoofing, make sure that a web application such as banking portal has an SSL/TLS certificate in place. Plesk lets customers get these certificates for free in just a few clicks.
Even less technical customers can use the Let’s encrypt extension on Plesk platform to easily create SSL certificates for their domains. And make it difficult for attackers to create spoofing attacks.
Generate Random Tokens
Otherwise, to prevent forged requests, you can even use tokens to validate GET/POST requests from users. For example, to enable csrf protection in Flask-based applications, you can use the Flask extension CSRFProtect by enabling it globally.
from flask_wtf.csrf import CSRFProtect
csrf = CSRFProtect(app)
Alternatively, you can use FlaskForm to prevent forgery request in flask web applications. However, the standard way of preventing CSRF threats in Java or PHP web applications is by implementing an anti-CSRF token only visible to the user’s browser and web application inside a session variable with a request. If the value of the session variable and hidden form field match, the user’s request is accepted.
2. Information Disclosure
Allowing unauthenticated users to access documents restricted to only authenticated users can be defined as information disclosure. The following describe diverse ways information disclosure can take place.
IDOR – Indirect Object Reference
IDOR attack is possible when a web application provides direct access to the object based on a user-supplied input. It makes it possible for unauthorized users to access resources restricted to them. Let’s assume user A logs in to a banking web portal, then the user is redirected to the following url:
https://mybank.com/acc=00012345
In this case, 00012345 is user A’s account number. If the user wants to access other customers’ account details, user A just needs to change acc=00012345 to acc=000112367.
Therefore, the above action allows a user to access account details of another user without the owner’s consent.
How to prevent
There are different ways to prevent indirect object reference. Another way to prevent exposure of real identifier to an internal object, like database record, is using a salted hash value to replace the identifier.
https://mybank.com/acc=00012345
https://mybank.com/acc=12eryrxhwgq
SQL Injection
SQL injection is one of the most common ways malicious users use to disclose information restricted from public view. Attackers can send commands such as SELECT to download an entire database, CREATE to create new users in the database or UPDATE to modify accounts.
How to prevent
You can use prepared statements to prevent an attacker from changing the purpose of a query. A prepared statement separates the query from the data. Thus, the data submitted by an attacker can’t be used to modify the query. Moreover, for flask developers, you can also prevent SQL injection by using SQLAchelmy to interface with the database. It comes with features to prevent SQL injection threats.
3. Data Tampering
Data tampering is the act of intentionally modifying data through unauthorized channels. There can be two states of data: in transit and at rest. In both instances, malicious users can intercept and tamper with data. Here’s how data tampering can take place.
Parameter Pollution
Let’s assume a web application allows users to send sensitive data. Like login credentials or transact funds via GET and POST methods. In this case, an attacker can tamper with URL parameters and modify data.
To prevent parameter pollution threats in a web application, you need to encode user-supplied input whenever a user sends a GET/POST request to the backend server.
Session hijacking
Session hijacking is also another type of attack where malicious users steal session cookies. Each user is assigned a session when they log into a web application. The sessionID is usually stored in a cookie. Attackers use session hijacking to modify data in transit from the client (web browser) to the web server.
How to prevent: Generate Random Session IDs.
Moreover, Plesk also provides loads of security extensions for customers to prevent or mitigate threats not mentioned above. For example, the Sucuri Security Scanner extension on Plesk to remotely detect website security issues and weaknesses in the source code.
Avoiding these new web application threats
Having said that, don’t just rely on Plesk extensions to protect web applications from web attacks. You also need to use your own secure coding practices to mitigate these threats. So, equip yourself, but stay vigilant.
