Almost all applications rely on a data store for managing the data which is processed by the application. In most cases, that data drives the core app logic. It also holds the user accounts and permissions and much more. But the data stores have evolved and became the significantly more passive containers for the data. Most of them hold them in a structured format, which is accessed using a predefined query format or language. It also contains internal logic which helps with managing the data. We will in this topic describe you the steps you can take to identify and exploit the defects that happen. Before we start, remind yourself about the cyber security tips and internet security tips. So, let’s go now!
Injecting Into Interpreted Context
The one whose execution involves a runtime component that interprets the language’s code and carries out the instruction it contains is an interpreted language. It is the truth that any language can be implemented by using either an interpreter or a compiler. The distinction is not an inherent property of the language itself. But, most of the languages are normally implemented in one of the two ways. The first one we already mentioned, and in the second one-a compiled language.
Injecting into SQL
For storing the various kinds of information that needs to be operated almost every web app employs a database. Let’s say a web application which is deployed by the online retailer may use the data storage to store the information such as user accounts, credentials, some personal information, descriptions, and prices of some goods for sale, any order, account statements, payment details and much more.
So what is the SQL? It is the Structured Query Language, used for accessing information within the database. Useful for reading, updating, adding or deleting the information held within the database. It is an interpreted language and web apps commonly construct SQL statements that incorporate user-supplied data. Of course, if it’s done in an unsafe way, the app may become vulnerable to SQL injection.
Let’s take a look at injecting into different statement types. We explained what the SQL language is. It contains a number of verbs which might appear at the beginning of the statement. It is the most commonly used verb and that is why the majority of SQL injection vulnerabilities arise within the SELECT statement. It is important for you to be aware of some important considerations which are in a relation to each. You will need to do it by making a guess which has to be based on the type of the application’s function you’re dealing with.
Besides the SELECT statements, there are the INSERT statements. They are used to create a row of data within a table. Also, commonly used when an app adds a new entry to an audit log or creates a new user name account or even generates a new order. So, if the username or password are vulnerable to SQL injection, the attacker can easily insert the arbitrary data into the table, and also including his own values for ID and privs. Besides those two, there are also UPDATE statements and DELETE statements. The first one is used to modify one or even more existing rows of data within a table. It works as same as the INSERT statement. The second one is used to delete one or more rows of data within a table.
Finding SQL Injection Bugs
Those flaws may be discovered and conclusively verified by supplying a single item of the unexpected input to the app. Sometimes, bugs may be extremely subtle and might be difficult to distinguish from other categories of vulnerability or from benign anomalies which do not present a security threat.
Fingerprinting the Database
There are some exploitation techniques which are more advanced. In that case, the differences between the platform become more significant. So, you will increasingly need to know which type of back-end database you are actually dealing with. We know that we can extract the version string of the major database types. But, sometimes it cannot be done this way, so in that case, it is possible to fingerprint the database using other models. The best way is to use the different means by which databases concentrate strings.
Second Order SQL Injection
This is an interesting type of filter. Most of the applications handle the data safely when it is first inserted into the database. So, once the data is stored in a proper database, then it can be later processed in the unsafe ways. It can happen either by the app itself or by any other back-end processes. Let’s suppose that the application implemented a password change function. It is reachable only by the authenticated users. But that’s not all. For the extra protection, the app requires the users to submit their old password. Then, the two strings are compared, and if they valid, the user can enter and have the authorization.
Beyond SQL Injection: Escalating the Database Attack
You need to know that the successful exploit of a SQL injection vulnerability most of the times results in a total compromise of all the app’s data. So, most applications, in that case, employ a single account for all database access and rely on app-layer controls to enforce segregation of access between the different users. When the attacker gains the unrestricted use of the app’s database account, it results in access to all the user’s data.
Using SQL Exploitation Tools
We described many techniques for exploiting SQL injection vulnerabilities. They involve a great amount of performance for extracting the requests and small amounts of data at a time. It is the truth that the numerous tools are available that can automate much of this process and that are aware of the database-specific syntax which is required to deliver the most successful attacks.
Defense in Depth
A robust approach to security should always employ a defense-in-depth measure for providing the additional protection in the event that front line defenses fail for any reason that may happen. There are the three layers of the defense that can be employed.
1.It is recommended that the application should always use the lowest possible level of privileges when accessing the database. It doesn’t need the DBA-level permission.
2.It is well known that the most of the enterprise databases include a large amount of default functionality that can be leveraged by the attacker who gains the ability to execute arbitrary SQL statements. So, the unnecessary functions should be removed or disabled for your better safety.
3.The vendor-issue security patches. All of them should be tested, evaluated, and applied in a timely way to fix the known vulnerabilities within the database software itself. Here, the database administrators can use some various subscriber-based services to obtain the advance notification of some known vulnerabilities that haven’t yet been patched by the vendor. In that case, they can also implement the appropriate measures and the workaround measures in the interim.
We introduced you with the real threat that these kinds of attack can bring. We also gave you some new knowledge for better understanding the SQL injection. Hope you’ve enjoyed and learned a lot! If you like it, you can share and of course, comment, give your opinion or ask the questions!