SQL Injection - SQLI

 Hello Team

I found that the parameter "(vulnerable parameter)" in URL:(vulnerable url) is vulnerable to SQL Injection.

Description:

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.

Data Found:

(Write all the data you found, for e.g. the back end dbms, database names, no. of tables, etc, and also include screenshots of them).

Impact:

Here the database which is crucial for the company can be derived, if an attacker puts a query to delete those databases and tables, then it would be a huge loss of data for the company and it will disrupt its whole functioning, Hence this is a very critical vulnerability and should be fixed.

Mitigation:

Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.

Parameterized queries can be used for any situation where untrusted input appears as data within the query, including the WHERE clause and values in an INSERT or UPDATE statement. They can't be used to handle untrusted input in other parts of the query, such as table or column names, or the ORDER BY clause. Application functionality that places untrusted data into those parts of the query will need to take a different approach, such as white-listing permitted input values, or using different logic to deliver the required behavior.

For a parameterized query to be effective in preventing SQL injection, the string that is used in the query must always be a hard-coded constant, and must never contain any variable data from any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and continue using string concatenation within the query for cases that are considered safe. It is all too easy to make mistakes about the possible origin of data, or for changes in other code to violate assumptions about what data is tainted.

Note:

I have provided a video POC of all the walkthroughs in the attachments and I have also provided a txt file which I used in video POC and contains the important commands I used.

Kindly ask me if you need more information

Thank You