Meow's CyberAttack - Application/Server Attacks - Injection

• Meow’s CyberAttack - Application/Server Attacks - Injection
  • Injection
  • Protection

book: Security+ 7th ch9

---

Meow’s CyberAttack - Application/Server Attacks - Injection

---

Injection

One successful web application attack, injecting malicious commands into the input string.

• The objective: to pass exploit code to the server through poorly designed input validation in the application.

Many types of injection attacks can occur.

• This can occur using a variety of different methods

• file injection

  : injects a pointer in the web form input to an exploit hosted on a remote site.

• command injection

  : injects commands into the form fields instead of the expected test entry

• shell injection

  : gain shell access using Java or other functions

• SQL injection

  : exploit weaknesses in statements input by users.

• LDAP injection

  : exploits weaknesses in LDAP (Lightweight Directory Access Protocol) implementations.

• XML injection attack

  : users enter values that query XML (known as XPath) with values that take advantage of exploits

Protection

The following guidelines provide the ultimate protection for any web application:

1. Input Validation

   – do not trust any data from any source. Validate the information for content, length, format, and other factors prior to use.

2. Parameterized statements

   – avoid dynamic SQL statements. Always bind data to parameters that clearly identify the data type of the bind value.

3. Business rule validation

   – always apply business validation to input. Business validations include length, type, and expected value.

4. Least privilege

   – only allow read only access to the data as a general rule, and other access as an exception. If a form within an application simply views the data, only call the database with a read-only database user. If adding or modifying data, call the database with a modify and add database user.

5. Logging

   – always log access to data, modification of data, and, if necessary, access to the data.

6. As a general rule, do not allow deletion

   – mark record for deletion and create a separate process to delete.

7. Threat modeling

   – always threat model an application to understand access points to the database, input points to the application, and what boundaries and layers are involved through the data flow of the application.

8. Error handling

   – do not throw detailed error messages to the screen for viewing by the user. The detailed information that is included in an error message is invaluable to an attacker providing valuable clues on how to modify the attack to allow the attack to execute without error.

9. Trust but verify

   – verify and validate any requests, data, and calls into your application, even if you trust the source, because the source itself could have been compromised.