What is it?
Injection!! That too in security!! How? Well, to most of us reading this article “injection” might sound something like a term from a medical background. If you are thinking of that “injections” then, you are thinking correctly to some extent because the use of injection is to inject medicine into the human body similarly injection in cyber security is related to injecting (or simply adding) parameters or commands into the requests of the web application to modify its behavior and request additional information from the server.
Attack Surface
-
SQL Injection
This type of vulnerability allows the attacker to inject SQL queries into the requests of the application to the server in order to fetch some unauthorized data from the SQL database. Data that can be fetched can range from fetching a single row to fetching the whole table or even executing commands through SQL queries. Not only the data can be fetched but also can be modified or deleted by the attacker which makes this vulnerability a high-risk one.
Example: https://www.xyz.com/accountView?id=' or '1'='1
An attacker can modify the “id” parameter in this request and can execute some specific test queries to check for injections like this one. Sometimes the query might not return any outputs, at that point, the request can be checked for “Blind SQL Injection”
-
OS Command Injection
This type of vulnerability allows the attacker to inject (or execute) commands specific to the server’s operating system into the requests from the application to the server in order to perform malicious actions on the server like encrypting the data, installing a backdoor, etc. to gain precious information from the server like confidential files, database data, etc.
Example: https://www.xyz.com/app/ping?host=”127.0.0.1 || ping attacker_machine_ip”
An attacker can modify the “host” parameter in this request and can execute multiple ping commands one on the same machine and the other on the attacker machine. To verify that the ping command works a ping listener can be activated on the attacker machine.
-
LDAP Injection
The vulnerability of LDAP injection occurs when queries are constructed from untrusted input without prior validation or sanitization. LDAP queries are built from predicates that include the use of special characters (e.g., brackets, asterisks, ampersands, or quotes). Metacharacters like these influence the meaning of the query, influencing the type and number of objects retrieved from the underlying directory. If an attacker can submit input containing these control characters, the query can be altered and the intended behavior changed.
Example: A user can find out precisely which resource is available in the system using some resource explorers. Taking a website that sells apparel as an example. The user can search for a particular pair of pants or shirts to discover if they are for sale. OR LDAP Injections are employed in this case:
(|(type=Resource1)(type=Resource2))
The resources in the system are depicted by Resources 1 and 2, respectively. Resources Resources1=Jeans and Resources2=T-Shirts display every pair of jeans and every T-shirt that is for sale in the system. How may this be used by hackers? using the (uid=*) injection into Resource1=Jeans. Next, the following inquiry is made to the server:
(|(type=Jeans)(uid=*))(type=T-Shirts))
The user objects and jeans are then displayed by the LDAP server.
-
XML Injection
When user input is placed into a server-side XML document or SOAP message in an unsafe manner, XML or SOAP injection vulnerabilities occur. It could be useful to alter the generated XML’s structure using XML metacharacters. Depending on how the XML is utilized, it can be capable of obtaining sensitive information, tampering with the application’s logic, or performing unauthorized actions.
Example: If an application is using XML requests like <?xml> for fetching some specific details then those requests can be checked for XML injection by modifying or adding XXE (External XML Entities) and noting the behaviors of the application in the response.
Examples of Attacks
Scenario #1:
An application does not sanitize the user input for a particular request parameter
https://www.xyz.com/account/details?id=’+SQL_PAYLOAD+HERE--
Note: Sometimes the application does not parse the response from the server in an effective manner. In that case, UNION SQL injection can be utilized.
Scenario #2: An application uses untrusted data in the construction of the following vulnerable SQL call:
String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";
Scenario #3: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
In both end cases, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1. For example:
http://example.com/app/accountView?id=' or '1'='1
What’s the Impact?
The impact of the presence of Injection can be very devastating for organizations as well as an individual because of the reason that the application is not securely handling the requests made due to which vulnerabilities like SQL Injection, sensitive information disclosure, information modification, etc. is present which can be exploited by an attacker with motives like exposing sensitive information online, gaining an internal foothold of the network of an organization, modifying information crucial to the organization, etc.
What’s the remediation?
Injection-related vulnerabilities can effectively be mitigated by implementing the sanitization of every single input point of the application which accepts input from the client. Apart from that, the parameters which are accepted from the client side can be checked and verified from a list of predefined inputs in order to filter unnecessary inputs. Some steps are also listed below to help in mitigation:
-
The safer approach is to adopt a safe API that avoids utilizing the interpreter entirely, has a parameterized interface, or migrates to Object Relational Mapping Tools (ORMs). Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or if hostile data is executed with EXECUTE IMMEDIATE or exec ().
- Use positive server-side input validation. This is not a complete defense because many applications, such as text areas or APIs for mobile applications, require special characters.
- Escape special characters for any residual dynamic queries using the interpreter’s specific escape syntax. Because SQL structures such as table and column names cannot be escaped, user-supplied structure names are dangerous. This is a common problem with report-generation software.
- In the case of SQL injection, use LIMIT and other SQL controls within queries to prevent mass disclosure of records.
- LDAP encoding functions should be used to escape all variables.
- LDAP injection can be prevented using frameworks that automatically guard against it.
- Least Privilege assignment to the environment processes and users.
As the old saying goes, “better be safe, than sorry!”, for more details and consulting related to SQL injection and other vulnerabilities please contact ASPIA Infotech.
