OWASP stands for Open Web Application Security Project. This series focuses on the top 10 most vulnerable security vulnerabilities.
OWASP top 10 Information Security topics
- Injection attack
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities (XXE)
- Broken Access Control
- Security Misconfiguration
- Cross-site Scripting (XSS)
- Insecure Deserialization Insecure Deserialization
- Using Components with Known Vulnerabilities
- Insufficient Logging and Monitoring
Injection attacks
An injection attack is an attack in which insecure data is passed to the interpreter as commands or statements during SQL, NoSQL, system commands, and LDAP injection. Hostile data from these attackers can fool the interpreter into executing dangerous commands or retrieving data without authorization
Understanding injection attacks
The first thing to consider is that external users, internal users, administrators, and so on May send insecure messages to the system. An injection attack occurs when an attacker sends hostile data to the interpreter.
Injection vulnerabilities are common, especially in older systems. The most likely places include SQL, LDAP, XPath, OS commands, XML parsers, SMTP headers, Expression Languages, ORM statements, OGNL (Object Graph Navigation Library), etc.
It is easy to find injection vulnerabilities by examining the code. Attackers often use scanning software or fuzzy testing software to find injection vulnerabilities.
Injection vulnerability can lead to many serious consequences, such as data loss, data corruption, data leakage, data authorization destruction, and sometimes the entire system can be completely controlled by the attack
What kind of applications are vulnerable to attack
- The program does not verify, filter or clean the data submitted by users.
- Dynamic SQL statements, or nonparametric injection statements, are passed directly to the interpreter without handling special symbols.
- Non-validation data is used directly in ORM search parameters
- Non-validating data is used directly in SQL, system commands, dynamic SQL, or stored procedures
The best way to prevent injection attacks is code review, followed by rigorous testing of data inputs such as:
- Parameters
- Headers
- URL
- Cookies
- JSON
- SOAP
- XML
The company now basically runs some scans on CICD pipelines to test software to find these vulnerabilities.
Injection vulnerability attack instance
Example 1: a program uses unvalidated data to create SQL statements
String query = "SELECT * FROM accounts WHERE custID='"+ request.getParameter("id") + "'";
Copy the code
Example 2: The program uses non-validated data to create HQL statements
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='"+request.getParameter("id")+"'");
Copy the code
In the two examples above, an attacker could tamper with the ID parameter in the browser, sending ‘or ‘1’=’1
Example: http://example.com/app/accountView?id=' or '1'='1
Copy the code
The above two Queries will return all the data in the table Accounts. So as you can see, injection attacks are very serious and can completely get, destroy data.
Injection prevention vulnerability
- Queries, system commands, etc
- Use a secure API and avoid the interpreter altogether
- Use parameterized interfaces
- Without parameterized apis, we would have to be very careful how we handle special symbols in the interpreter.
- Input data can be actively validated, but many systems require special symbols as input, making it difficult to fully detect injection vulnerabilities.
- Use the keyword LIMIT or other SQL Query controls to avoid returning large amounts of data.