dd

[Riccardo-ten-Cate]

dd

[skf-integration[bot]]

Security knowledge framework!

Expand checklist

**Did you check all components that have no sec issues** - [ ] Verify uneeded components **Did you added and or modified SQL** **Did you added and or modified system commands** **Did you added and or modified LDAP**

[skf-integration[bot]]

Security knowledge framework!

Expand checklist

**Did you check all components that have no sec issues**

More information

```` ###identify all application components
### Description: When you are building an application you first want to map where you are placing source files, libraries and executables. With these components identified and mapped, it becomes transparent where possible pitfalls might be in your application and increases the maintainability of the system. Also, you have an indicator where possible reinforcements have to be implemented to avoid attacks.(i.e places where your application contains executable's) Solution: Verify that all application components (either individual or groups of source files, libraries, and/or executables) that are present in the application are identified. When you identified these components you may want to map and document them in order to have a quick reference to this infrastructure when needed. ````

• [ ] Verify uneeded components

Did you added and or modified SQL

More information

###SQL injection Column truncation
<br/>### Description:

Whenever an applications structural logic mismatches with the database structural logic an attacker gains the opportunity to truncate his submit towards your database column by submitting a value longer than the limit allowed in the database.
Imagine you have a system where users can register themselves.

The attacker can abuse this behavior of the database to overflow the length limit and truncate his submit and register himself as the admin, thus gaining its privileges.

 Solution:

On critical places where unique values are enforced and expected,
such as usernames in order to authorize or distribute certain privileges. The users submit
should be checked on the server side in order to verify if it does not exceed the limit
set in your database.

````</details>
**Did you added and or modified system commands**
<br/><details><summary>More information<summary>

Command injection

### Description:

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attackersupplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation. This attack differs from Code Injection, in that code injection allows the attacker to adds his own code that is then executed by the application. In Code Injection, the attacker extends the default functionality of the application without the necessity of executing system commands.

Solution:

Userinput that is used in a shell command should not contain dangerous characters. A blacklist of characters is not a good option because it may be difficult to think of all of the characters to validate against. A white list containing only allowable characters should be created to validate the userinput.

**Did you added and or modified LDAP**
<br/><details><summary>More information<summary>

LDAP injection

### Description:

LDAP (Lightweight Directory Access Protocol) Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it is possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

Solution:

The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries does not contain any attacks. However, in some cases, it is necessary to include special characters in the input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually part of the LDAP query.