A1 Injection OWSAP

A1 Injection vulnerability is currently ranked #1 on the OWASP Top 10 chart which means that it is responsible for a largeportion of public disclosures and security breaches.
So what is an injection vulnerability? Well, there are actually several types. Some of the most common types include SQLinjection, code injection and LDAP injection. With the different types of injection, the attacker will construct his attack in a different way.

SQL is an structured Query language that enables interaction with database servers. SQL commands such as INSERT, RETRIEVE, UPDATE, and DELETE are used to perform operations on the database.

SQL injection is a technique which attacker takes non-validated input vulnerabilities and inject SQL commands through webapplication that are executed in  backend database.

SQL Injection:

Authentication Bypass:

Here an attacker could enter into network without providing any Authentication and gain highest privilege.

Information disclosure:

After attacker enters into the network, he will get access to sensitive date stored in the network.

Compromised data Integrity:

Attacker changes content of website by entering malicious contents.

Compromised Availability of data:

Using this technique attacker will delete sensitive and crucial information from database.

Remote Code Execution:

An attacker could modify, delete, or create data or even can create new accounts with full user rights on the servers that share files and folders. It allows an attacker to compromise the host operating system.

Significant risks

A1 Injection vulnerabilities also present some of the most significant risks when effectively exploited. Some of these risks include:

• Data loss or corruption
• Data theft.
• Unauthorized access.
• Denial of service.
• Complete host system takeover.

SQL QUERY Vulnerable to attack:

select count (*) FROM Users  WHERE UserName=’ ” + txtUser.Text + ” ‘ AND passwords=’ ” + txtpassword.Text + ””’;

Similarly a blind text in framework make the framework vulnerable.

Query HQLQuery = session.createQuery(“FROM accounts WHERE custID=’“ + request.getParameter(“id”) + “‘”);

Understanding SQL Injection:

                          http://mydomain.com/test?Id=1                                       

                                     ↓

                        SELECT * FROM test WHERE ID = 1

Under normal circumstances it will probably translates down to  SELECT * FROM test WHERE ID = 1 , there might be a table named test and it simply saying select ID no.1 from the table. We need to look over here for different class of information.

                      Trusted data         http://mydomain.com/test?Id

                      Untrusted data       1

The first part we need to see here is what is trusted  data (http://mydomain.com/test?Id) and the un-trusted (1), the unstruted is the one which vulnerable to attack.

Now what happens if an attacker appending the condition http://mydomain.com/test?Id=1 or 1=1 if this condition passes through database then the login is going to change, instead of pulling a single ID it will pull the entire database.

COMMON DEFENSES:

1. Whitelist untrusted data

• What does we need trust?
• Does it adhere to expected patterns?

2. Parameterise of SQL Statements

• Separate the Query from the input data.
• Type cast each operator.

3. Fine tune DB Permissions

• Segment accounts of admin and public.
• Apply “the principle of least privilege”.

Suggested Tools : Burp Suite, ZAP, Vega, SQLMAP, SQLSUS

Also Read:

• A2 – Broken Authentication and Session Management
• A3 – Cross Site Scripting
• A4 – Insecure Direct Object References
• A5 – Security Misconfiguration
• A6 – Sensitive Data Exposure
• A7 – Missing Function Level Access Control
• A8 – Cross-Site Request Forgery (CSRF)
• A9 – Using Components with known Vulnerabilities
• A10 – Unvalidated Redirects and Forwards